On Thu, Sep 9, 2010 at 6:31 PM, Raymond Feng <[email protected]> wrote: > 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
Hi Raymond Am mulling this over and an initial question comes to mind about the difference between [2] and [3] from your list. Imagine I had a "Tuscany" interface (I just invented it so as not to get confused too much by what we already have) that gives me a place where I can do do things to either configure the runtime or get information out of it. Also assume that the concept of a Node, as the place where composites run, is still in play. I might want to.... A/ - create a node given a static configuration, for example, from an XML file on disc or at a URL. B/ - create and empty node and incrementally configure it before starting it. Are to separating [2] from [3] in the sense that B/ could be achieved by incrementally creating a node configuration and then running A/? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
