On Fri, Jan 9, 2009 at 11:56 AM, Simon Laws <[email protected]>wrote:
> Yep, I have more comments but what with Christmas and all I've not got my > finger out and committed them to email just yet. Two things I would like to > do... > > 1/ Start a thread on the ways that we want to support starting Tuscany > (yesterday I wrote down all the ways I can think of so will transcribe) > 2/ Extend Raymond's excellent scenario page ( > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Composite+Application+Deployment+with+SCA+Domain > ) > 2-1/ Definitions handling > 2-2/ late binding > 2-3/ Other contribution configurations (which started this thread), e.g. > where a composite is provided independently of a contribution > > Some immediate comments in line. > > Regards > > Simon > > > On Fri, Jan 9, 2009 at 11:25 AM, ant elder <[email protected]> wrote: > >> >> >> On Wed, Dec 31, 2008 at 1:09 PM, ant elder <[email protected]> wrote: >> >>> >>> >>> On Wed, Dec 10, 2008 at 11:08 PM, Simon Laws >>> <[email protected]>wrote: >>> >>>> I'm just reviewing my understanding of the relationship between >>>> contributions and composites with a view to reviewing how users start the >>>> Tuscany Java SCA runtime and configure SCA application, It doesn't look >>>> like >>>> what the OASIS specs say on this subject differs much from the OSOA specs. >>>> >>>> Tuscany users see two primary modes of operation of the Java SCA >>>> runtime; >>>> >>>> Standalone - the SCA application runs on a single Tuscany SCA node >>>> Distributed - the SCA application is distributed across a number >>>> distributed nodes which are all running as part of the same domain >>>> >>>> As we aim to make the life of the SOA developer easier I imagine that >>>> people are interested in the distributed configuration however the >>>> standalone configuration is useful, particularly for us when testing. >>>> >>>> The composites which describe the various composite assemblies that >>>> combine to form the SCA application are added to the runtime contained >>>> within one or more contributions (the contribution is just a handy >>>> packaging notion). There are a number of ways contributions and composites >>>> can >>>> be organized. >>>> >>>> An SCA application can be made up of >>>> >>>> i/ A single contribution >>>> ii/ Multiple contributions. In this case some contributions may depend >>>> on one other. >>>> >>>> Each contribution can contain >>>> >>>> a/ one or more composite files with none listed in >>>> META-INF/sca-contribution.xml >>>> b/ a composite file and META-INF/sca-contribution.xml which defines one >>>> deployable composite >>>> c/ many composite files and META-INF/sca-contribution.xml which defines >>>> more than one deployable composite >>>> d/ no composite file >>>> >>> >>> Is there a reason for the distinction between b/ and c/? Couldn't b/ just >>> be considered a specific configuration of c/? >>> >> They are just different ways that a contribution can be configured. I was > interested in this as currently our node only runs a single composite. The > important question is which composite is that. Looking at the current node > code (in 1.x) it would seem that there is now some code to aggregate > deployable composites into one super composite in the case that there are > more than one so maybe this is the approach to take. We assume, regardless > of how many composites or deployable composites definitions are provides > that any that are detected are aggregated together. > >> >>> >>> Also note that the assembly spec does say that a contribution should >>> contain an sca-contribution.xml file >>> >> And so sca-contribution.xml is optional, Should as opposed to must. > >> >>> >>> >>> >>>> >>>> Alternatively >>>> >>>> e/ a composite can be provided independently of a contribution as just a >>>> string or external file >>>> >>> >>> Is e/ actually mentioned in the SCA specs anywhere (I can't find it)? >>> >> See 1.10.4.2 addDeplymentComposite > >> >>> >>> >>>> >>>> In 1.x the user starts the runtime from the command line in the >>>> following ways. >>>> >>>> Standalone >>>> Run a node/webapp and tell it what contribution/composite to run, e.g. >>>> >>>> >>>> java -jar nodeLauncher.jar compositeURI contributionLocation >>>> >>> >>> Does "java -jar nodeLauncher.jar" actually work in 1.x? I think virtually >>> all the samples don't do that but instead use one of: >>> - command line Java using binary distribution tuscany-sca-manifest.jar >>> - Ant build script using the tuscany-sca-manifest.jar >>> - Ant build script using the tuscany-maven-ant-generator plugin >>> >> I made a list today and came up with aobut 10 different ways/environments > in which a user may kick off a runtime (doesn't imply 10 different APIs > though) so I'll start a separate thread for this specific question > >> >>> >>> >>> >>>> >>>> So this can exploit i/ a/ and b/ (but in this case I don't think >>>> sca-contribution.xml takes any part) >>>> >>> >>> AFAIK the sca-contribution.xml _is_ used in 1.x, and additionally also >>> the special sca-deployables folder. For example, in the SCANodeFactory >>> createNode methods you can use null for the composite uri if the >>> contribution defines either a deployable composite in the >>> sca-contribution.xml file or has a .composite file in the sca-deployables >>> folder. (and as the spec says a contribution should contain an >>> sca-contributions.xml file this should usually work) >>> >> I'd forgotton about the sca-deployables folder;-) We certainly need to add > that to the list of possible ways that a user may configure a contribution. > Just to be complete there's also the application composites - META-INF/application.composite, WEB-INF/web.composite etc. ...ant
