WSRF has gained very little market acceptance outside the academic world.

Anne

On Jan 31, 2008 4:50 PM, henryk mozman <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> 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
>  > > > >
>  > > >
>  > > >
>  > > >
>  > > >
>  > >
>  > >
>  > >
>  > >
>  >
>
>
>  

Reply via email to