A registry _can_ be an authoritative centrally controlled store of information, or it can be more like DNS where there are peering arrangements between registry elements, caching of information and all manner of elements.
Just because a technology wants to be the single point of all truth doesn't mean that it has to be. The basic approach is very simple, just have something that when a new "registry" is added to the ring it propagates its information to all other "registries" this means that if one fails then services can use others (because after all a registry is just another service) you can even make every service a registry if you want to go mad. What I did was have a concept of overlapping rings so the P2P from one service to another could be bounded, this means that you can add proxy services between one P2P area and another. JXTA is one (quite heavy) way of doing this, and in some ways you could use WSRF. There are also broadcast protocols that could be used if you are in a local network environment. The choices are endless, but don't rule out federating registries just because most people only do single version of the truth. Steve On 30/01/2008, henryk mozman <[EMAIL PROTECTED]> wrote: > > > Steve, > A registry is an authoritative, centrally controlled store of information. > The architecture I am designing needs to be peer-to-peer, since the > requirements do not allow for a single point of control and management. > Hence the consideration of JXTA or of WSRF. > P2P allows Web services to discover each other dynamically. > > > Henryk > > > > *Steve Jones <[EMAIL PROTECTED]>* wrote: > > which is fine, I've done multi-UDDI federations and you can do similar > approaches with lots of other registry/directory technologies. A way I did > it with RMI was to have registry "ring" which new services subscribed to > one node of and this then propagated the information around the ring (really > a mesh, but that just confused people!). > > Steve > > > On 28/01/2008, henryk mozman <[EMAIL PROTECTED]> wrote: > > > > > > Steve, > > > > The requirements constraint for the architecture which I am helping to > > design cannot have a single directory for discovery. > > > > Henryk > > > > > > *Steve Jones <[EMAIL PROTECTED]>* wrote: > > > > One semi-interesting question here is when SOA isn't peer-to-peer. > > Each service (whether via REST, WS, Jini, etc) can be discovered > > dynamically, hot-deployed and have its actual end-point changed. These > > services can communicate directly with others without any need for a complex > > infrastructure or central point and they can communicate between different > > networks. > > > > Now some of that is theory (e.g. dynamic discovery) but lots of it is > > relatively standard for enterprise scale SOA deployments where you have a > > series of semi-disconnected entities communicating directly, often as a > > result (like most p2p solutions) of some form of directory. > > > > Steve > > > > > > On 28/01/2008, henryk mozman <[EMAIL PROTECTED]> wrote: > > > > > > Jeff, > > > > > > In reality, I am more interested in implementing a peer-to-peer SOA > > > than JXTA. > > > JXTA may be one way to implement SOA. I suspect that there are many > > > other ways, to implement p2p SOA. I was interested in hearing from any one > > > who has been there and done that. > > > > > > Henryk > > > > > > > > > *jeffrschneider <[EMAIL PROTECTED]>* wrote: > > > > > > When you say "SOA with JXTA", I'm assuming that you mean "SOAP over > > > JXTA", as in: https://soap.dev.java.net/ > > > > > > It's been years since I've done this but the general result was less > > > than what I'd hoped for. In some ways, JXTA is designed for the worse > > > case scenario. That is, it is more about resilience than high > > > throughput or low latency. Generally speaking, resilience isn't the > > > primary non-functional requirement in business systems. JXTA assumes > > > that you might have firewalls, NAT's and other ugly stuff in your > > > network and is designed to traverse the obstacle, at the expense of > > > speed and latency. > > > > > > It has been my experience that architects prefer to use alternative > > > mechanisms to increase reliability and availability. I don't want to > > > discourage anyone from going down this path, just encourage you to > > > force-rank your non-functional requirements. > > > > > > Here's an article I wrote 7 years ago on the subject :-) > > > http://www.openp2p.com/pub/a/p2p/2001/07/20/convergence.html > > > > > > Jeff Schneider > > > > > > --- In > > > [email protected]<service-orientated-architecture%40yahoogroups.com>, > > > henryk mozman > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > Has anyone in this group any experience in implementing SOA with the > > > > > > peer-to-peer > > > > JXTA ? > > > > > > > > I would be interested in reading about your experience > > > > > > > > > > > > Henryk > > > > > > > > > > > > > > > > > > > >
