On Wed, May 27, 2009 at 5:21 PM, Raymond Feng <[email protected]> wrote: > Hi, > > We have been discussing the idea to use p2p protocols to manage an SCA > domain. There are some interesting use cases coming up as I look into the > dynamicity perspective for the OSGi RFC 119 implementation using > Tuscany/SCA. > > To use SCA domain to manage a collection of OSGi frameworks so that the OSGi > services can see each other as follows: > > 1) Discover remote OSGi services provided by other OSGi frameworks. In SCA > term, the information about the published services (domain-level component > services) is managed by the SCA domain. The service metadata of interest is > the service endpoints, associated properties and policies. Such data can be > exchanged across the nodes using a p2p or centralized coordinator. > > 2) Synchronize between the OSGi frameworks for the states of the services > via the SCA domain. For example, if a property for a remote OSGi service > exposed to SCA domain is updated, the change will be reflected to the OSGi > service which is an SCA proxy in the client-side OSGi service registry. > > In OSGi, we look up the service references from the service registry with > the name of the service interface together with a LDAP-style filter which > matches against the service properties. Mapping to SCA, it's like the > domain-level autowiring or wiredByImpl which allows the references to be > resolved within the SCA domain with some matching criteria. > > As the starting point, I'm thinking of making the SCA service registry > remotely accessible. It can serve the service descriptions to SCA nodes or > clients. The service registry can be managed by an SCA domain manager which > receives publication of services from the nodes. The other option is to use > p2p protocol to build a distributed group of the nodes and exchange the > service metadata within the group. With a distributed service registry, we > can resolve the SCA references which uses the SCA wiring > (componentName/serviceName/bindingName) within the SCA domain. It also > allows us to deal with domain-level autowiring. > > I start to play Tomcat Tribes which provides a set of simple APIs to use IP > Multicast to build a group of members. I got a Tribe sample working in my > environment. The other interesting project is ZooKeeper from Apache Hadoop > (http://hadoop.apache.org/zookeeper/). We will use the Extension > Point/Extension pattern to make the p2p layer pluggable. > > Thoughts? > > Thanks, > Raymond >
I think this could be really realy good for Tuscany, OSGi/RFC119 asside, a dynamic distributed SCA domain will make Tuscany a much more compelling SOA solution. I've tried Tribes too. One thing i read about Tribes (in a presentation i can't find again right now but will keep looking) is that its not designed for many-to-many communication (i guess because its for moving http sessions around a tomcat cluster?), so that may be relevant depending on what we need to do. There's also https://shoal.dev.java.net/ which looks quite good. And theres the Distributed Hash Table approach that Giorgio has talked about on the ML before with using http://overlayweaver.sourceforge.net/. That actually sounds like quite an easy approach - if the service registry is just a map of endpoint objects keyed by endpoint uri then using a distributed hashtable would make it pretty simple and overlayweaver would handle all the distribution and discovery for us. This is quite a complicated area though and we've not been able to get much consensus on what to do in the past, so could we break it down in to several smaller pieces that may make it easier? For example, it sounds like we're starting to agree on having some sort of registry so could we have that as a separate piece to get going first without needing all the RFC119 and P2P complications? Yesterday I committed itest\nodes\two-nodes-test which starts to try to use two Nodes in a simple inVM domain, if we got that going would it help at all as a stepping stone for whats needed by RFC119? ...ant
