> > > 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? >
This is a key point that Raymond is making here. I'm going to repeat it to see if I get is right but hopefully I'm saying the same thing but with a few more words. We've not designed the 2.x infrastructure with any strict domain configuration architecture in mind other than that we've provided a registry for exchanging information between the various points at which composites from a domain are running (we happen to call these points Nodes). How this registry is implemented and populated is an exercise for the reader (actually the act of starting a composite does populate the registry with endpoint information but I'm glossing over that). The registry is really just an SPI. At the moment we have a couple of shared cache implementations based on Hazelcast and Tribes. In terms of exploiting this model initially we've focused on a peer to peer model where nodes discover each other and exchange information, via the registry, about the domain that they together describe. This happens to be convenient for testing. There are many other approaches that could be considered. For example, here's two.... 1/ when we embed Tuscany in an app server like Geronimo or Tomcat we might expect some level of centralization of management of contributions which are then run in separate parts of the app server infrastructure. The registry model is the same though in that nodes are configured with contributions and exchange domain information via the registry. We may also expect the registry to exploit services provided by the app server for sharing domain data. 2/ I'd like to make a file system based version where you can place contributions in a set directory and have then form a domain. Again the running nodes will exchange information via the registry. With this approach you would either register the domain configuration centrally using tools that's able to read the configuration and start nodes on that basis or you could use a shared file system, start nodes individually and have them populate the registry. Having said all of this there is still work to do. The registry API currently only deals with endpoint information. This is the basis of all of our reference resolution logic and allows contributions to be brought up at different times in different places. However it's not currently able to pass information either about the service interface or about policies that may be in action. Having just done some work on normalizing interfaces I think we're in a position to fix the interface deficiency. Haven't thought much about the policy issue yet. The other thing that is lacking is any higher level domain information exchange, such as information about contributions and composites. We currently expect contributions to be delivered to Nodes out of band. I think it would be useful to share a wider domain description via the registry. We don't need to transport the contributions themselves via the registry we just need to provide the URL of where they can be obtained from. In this we we could achieve the goal of either populating the registry and starting nodes based on the information there or starting the nodes and having them populate the registry (or a bit of both). Either way the end result is the same and tools that are able to exploit the registry API get a full view of what's going on. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
