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
>  > > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > >
>  > > >
>  > > >
>  > > >
>  > >
>  >
>
>  

Reply via email to