I think Jeff put things clearly but do you want each computer to host their own repository/registry? In that case, an open source software Anne mentioned can put installed on each computer to list services available on each computer - just create a service to list available services on that computer. You'll also have to add a method to propagate information to other servers.
H.Ozawa --- In service-orientated- [EMAIL PROTECTED], "jeffrschneider" <[EMAIL PROTECTED]> wrote: > > Couple random thoughts: > > - Peer-to-Peer refers to a system of nodes where each node that has > the ability to act as both a client and a server; some p2p systems > leverage dynamic discovery, however this is not a mandatory attribute > of a p2p system; I would suggest that you are (perhaps) less > interested in the network topology and more interested in the > federated capabilities of the infrastructure (metadata, and the > ownership); what i'm saying here is "you don't want p2p, you want > federated metadata" > > - Many organizations have moved down the 'federated esb' path; their > assumption is that there will be many 'service connectors & > containers' based on many products from many vendors. In large > federated environments, the goal isn't to own the ESB, Registry, etc. > or even standardize on one. The goal is to enable ownership for > multiple parties, but to have the ability to apply policy across > domains and to not create new silo's of data and metadata. > > - If the Department of Defense and all of their agencies can go > federated registry & esb, there's a good chance that it will cover > your needs as well. > > - The decision to "go with JBI" seems really odd; if you were an ISV, > I'd understand why you'd choose a standard at this level of the > plumbing. Assuming that you have your reasons, I'll still say that it > seems like an odd choice. (IMHO) Even then, I'm not sure how it would > play into a registry decision. > > - Unless you're on a research project, I'd rethink WSRF. > Jeff > > > --- In [email protected], henryk mozman > <henrykmozman@> wrote: > > > > Anne, > > > > > > I have not considered using AtomPub or RSS. > > Thanks for the pointer. I definitely will look into these choices. > > We have made the decision of using JBI. This decision may > eliminates some of the registeries you mention. > > > > Another option I am considering is WSRF > > > > > > Henryk > > > > > > Anne Thomas Manes <atmanes@> > wrote: Have you considered using > AtomPub or RSS as a means to propagate > > service information? > > > > Three registry/repository products support AtomPub and RSS: > > - Mule Galaxy (open source) > > - WSO2 Registry (open source) > > - HP SOA Systinet > > > > Anne > > > > On Jan 28, 2008 11:00 AM, henryk mozman <henrykmozman@> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Steve, > > > > > > The requirements constraint for the architecture which I am > helping to > > > design cannot have a single directory for discovery. > > > > > > Henryk > > > > > > > > > > > > Steve Jones <jones.steveg@> 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 <henrykmozman@> 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 <jeffrschneider@> 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], henryk > mozman > > > > <henrykmozman@> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
