Hi, Simon. Thank you for bringing this topic for discussion again :-). I'm adding another thread [a] for the reference too.
In general, I think we need to agree on the terms first and distinguish them between those from the SCA spec (PM) and Tuscany (runtime). IMO, we are talking about five different things here: [1] SCA domain (which is a logical concept that provide a boundary for SCA wiring and policy definitions) [2] SCA packaging and deployment (manage the contributions and composites) [3] How to select a subset of the SCA domain composite (a group of top-level components which are typically defined by deployable composites from the contributions) and allocate runtime instances to host the components [4] How to take a set of deployable composites and required contributions and start/stop them all together. To me, it's more like a boundary of lifecycle, but not for the wiring as we use the Endpoint registry to perform the wiring. [5] How to share the metadata for the SCA domain, such as service endpoint descriptions and policy definitions among the participating runtime instances that host SCA applications for the same domain To me, 1 and 2 is from SCA PM. 3, 4, 5 is the runtime behavior. If we map the Tuscany code into these 5 functions, we have: We don't necessarily need to have a SCA Domain object in java to represent the SCA domain. SCAClient and Node APIs can connect to an SCA domain by the domain URI. domain-node module (together with Deployer, and minus the getService()) is more on [2] NodeConfiguration for [3] Node API is on [4] EndpointRegistry is for [5]. The registry URI is a physical URI that allows SCA clients or nodes to access the domain registry Thanks, Raymond [a] http://www.mail-archive.com/[email protected]/msg12877.html ________________________________________________________________ Raymond Feng [email protected] Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________ On Sep 8, 2010, at 10:24 AM, Simon Laws wrote: > The existing node APIs haven't been a focus for a good while now and > we've been adjusting them from time to time as the need has arisen. > Recently Ant has done some work to construct an API that more > faithfully represents the APIs that are described in the Assembly > specs > > Now seems to be a good time to review the various threads relating to > identifying and configuring nodes and domains and polish the code we > have ready for the 2.x release (I'm not sure this needs to hold up the > beta b.t.w) so that we have a simple and easy to use approach without > duplication and the associated confusion. > > I've been looking through the code base over the last day or so and > drew a couple of UML style diagrams of the parts of the infrastructure > that interested me relating to domains/nodes (made manually in an > Eclipse tool so are inevitably incomplete). I've updated the domain > page on the wiki [1] with these UML diagrams, an updated top level > diagram, and my thoughts so far. Note. I just pushed the original > domain content down the page (they are dated so you can identify which > is which - new stuff at the top under 2.x version2). > > We have been exercised in the past about such topics as. > - how many composites can a node run > - should contributions be added to a node on creation or incrementally > - how should we attach configuration to a domain URI > - how should we attach configuration to a node > > Multiple different answers have usually been offered and I think, in > most cases, we can easily accommodate the differing views without much > difficulty, e.g. [2]. > > I'm starting this thread without a specific proposal in order to > capture thoughts. Personally my ultimate objective would be a 3rd UML > diagram showing how the various APIs can be polished and can > cooperate. I'll start making one we can comment on if people are happy > for me to do that. > > [1] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Domain > [2] http://www.mail-archive.com/[email protected]/msg11205.html > > Regards > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com
