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/? Also note that the assembly spec does say that a contribution should contain an sca-contribution.xml file > > 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)? > > 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 > > 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) > > 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. ...ant
