Nice summary. I also started a wiki to illustrate the SCA domain concepts using the store tutorial. There is a table at the bottom of the page (Please help to complete it!). I use it to walk through the deployment steps for the scenario. This will help us understand what services should be provided by the SCA domain, what SPIs do we have today and what are the options to implement the services. Hopefully, we can build a consistent SCA domain story collaboratively.
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Composite+Application+Deployment+with+SCA+Domain Thanks, Raymond From: Simon Laws Sent: Wednesday, December 10, 2008 3:08 PM To: tuscany-dev Subject: [2.x] Composite/Contribution combinations 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 Alternatively e/ a composite can be provided independently of a contribution as just a string or external file 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 So this can exploit i/ a/ and b/ (but in this case I don't think sca-contribution.xml takes any part) 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
