Steve,
A registry is an authoritative, centrally controlled store of information.
The architecture I am designing needs to be peer-to-peer, since the
requirements do not allow for a single point of control and management.
Hence the consideration of JXTA or of WSRF.
P2P allows Web services to discover each other dynamically.
Henryk
Steve Jones <[EMAIL PROTECTED]> wrote: which is
fine, I've done multi-UDDI federations and you can do similar approaches with
lots of other registry/directory technologies. A way I did it with RMI was to
have registry "ring" which new services subscribed to one node of and this
then propagated the information around the ring (really a mesh, but that just
confused people!).
Steve
On 28/01/2008, 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
<[EMAIL PROTECTED]> 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
>
