See my comments below. Thanks, Raymond ________________________________________________________________ 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 Jul 12, 2010, at 1:38 PM, ant elder wrote: > On Sun, Jul 11, 2010 at 1:33 AM, Jean-Sebastien Delfino > <[email protected]> wrote: >> Raymond Feng wrote: >>> >>> Hi, >>> >>> We had a debate on this topic. See: >>> >>> http://osdir.com/ml/dev-tuscany.apache.org/2010-06/msg00164.html >>> >>> And apparently, we didn't reach agreement. >> >> It's probably a good idea to restart that discussion and find a consensus on >> this. After having not looked at the Tuscany code for a while I must admit I >> was a little confused by the multiple Node types. >> >> I'll try to participate in the discussion as much as I can, although I have >> little spare time these days. In the meantime, I'd like to continue to use >> the mainstream Node implementation for some time in samples/launcher-shell, >> as it's what's working with webapps, all the test cases, samples etc. >> >>> >>> I think it would be a good idea to agree on the commands for shell. This >>> will help us understand how users use SCA. Then it can be translated into a >>> set of API/SPIs. Mixing different steps into one layer could prevent us from >>> seeing the complete user story. >> >> And like I tried to say in another email in this thread, I think we should >> distinguish: >> - Domain management, assembling components in a domain; >> and >> - Runtime instance configuration and management, loading a contribution in a >> runtime instance and starting/stopping it. >> >> They are really different IMHO, for example an SCA domain administrator can >> spend a day assembling components in a domain before starting a single >> runtime instance, and stopping a server doesn't mean that he's removing a >> composite from the SCA domain... >> >> -- >> Jean-Sebastien >> > > I'm out till Wednesday so will comment more on this and the previous > email when i'm back, but its worth pointing out now that the 2.x Nodes > are different than the old 1.x ones - the 2.x o.a.t.s.node API makes > Nodes that _are_ part of a domain not isolated standalone Node > instances. So for example when you use the sample shell and you start > Nodes they are all part of a domain named "default" and you can wire > from references in one Node to services in another Node and exports > from one Node are used by imports in another Node, and if you start a > component that has the same component name as an existing one it will > overwrite the old one. There is not currently a way with the 2.x APIs > to create a Node that is not part of a domain and is isolated from all > other Nodes. > The 2.x Node is the execution environment for deployable composites within an SCA domain. The runtime does provide an endpoint registry that allows all nodes to share the endpoint descriptions for domain-level wiring. But this registry can be implemented using different ways: 1) A centralized registry 2) A p2p registry 3) Offline xml files We use the NodeConfiguration collects the information about the contributions, deployment composites and some other configurations. The NodeConfiguration can be created programmatically, loaded from an XML document or (potentially) provisioned from the SCA domain manager. AFAIK, I don't think we allow the contribution import/export to go beyond the node boundaries. Is it a new behavior in some other modules? > ...ant
