Jeff, Why do you consider WSRF can be used only on a research project ? I do know that WSRF is used in research projects. For example, the caBIG project of the National Cancer Institute uses WSRF as part of its SOA enabled caGrid implementation of of the Globus Toolkit.
Henryk 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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], 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 > > > > > > > > > > > > > > > > > > > > > > > > >
