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. > >> >> >>> >>> Distributed >>> Run a domain and configure it >>> >>> java -jar nodeLauncher.jar domain >>> >>> Using the domain management GUI; >>> Specify node configurations >>> Add contributions >>> Associate composites with nodes >>> >>> Start a node given a URL to it's configuration >>> >>> java -jar nodeLauncher.jar http://localhost:8080/mydomain/mynode >>> >>> Node runs a single composite (from one or more associated >>> contributions) >>> >>> So this, as a whole, can exploit i/ ii/ a/ b/ c/ d/ (but again I'm not >>> sure that sca-contribution.xml is consulted) >>> >>> Does this sounds right so far? >>> >>> Simon >>> >> >> How to start a Tuscany runtime is interesting, i think we should >> understand what it is we're really want to achieve and then work out what >> the best approach is. >> >> The "java -jar nodeLauncher" approach is an alternative to >> tuscany-sca-manifest.jar or the Ant scripts for starting Tuscany at a >> command prompt and enables the launcher class to programatically configure >> the classpath environment instead of configuring the environment in the Ant >> build.xml or the manifest jar classpath entry. >> >> What are the reasons and benefits for changing to use a launcher program? >> One drawback of the launcher approach is that it makes it hard to see what >> the environment is being used, for example, the current launcher class does >> all sorts of messing about with jar filtering based on jar file names and >> folders, whereas using an Ant build.xml makes it quite clear and most people >> are familiar with using Ant. If some osrt of programatic launcher really is >> needed then another approach could be to use a batch or shell script which >> is what most projects that start some sort of runtime do (tomcat, geronimo, >> synapse, etc), and the script approach has the benefit of being plain text >> so its still easy to see what environment gets configured. > > Lets try and get everything on the table on a separate thread. We have lots of ways of doing this that have been created for different reasons. > >> >> ...ant >> >> > Bring this thread up again as it went quiet over the year end break, anyone > have any more comments? > >
