"REST-based open source registry" is a new term. At least to me. I appreciate if you can explain to us what is the differences between REST registry and WS-* registry (UDDI) ? I am not convinced by such words like "make it simpler than UDDI" or "UDDI is a heavyweight registry". I think we need more specific comparison to understand the differences.
All the best Ashraf Galal ----- Original Message ----- From: Anne Thomas Manes To: [email protected] Sent: Saturday, February 02, 2008 8:02 AM Subject: Re: [service-orientated-architecture] Re: SOA with JXTA And I recommend RSS/Atom/AtomPub for the propagation mechanism. If you're looking for a lightweight, REST-based open source registry that supports Atom, check out Mule Galaxy [1] and WSO2 Registry. [1] http://www.mulesource.com/products/galaxy.php [2] http://wso2.org/projects/registry Anne On Feb 1, 2008 5:47 PM, htshozawa <[EMAIL PROTECTED]> wrote: > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
