RE: open transport protocol for aysnc web services?

Krishna,

Sounds like an interesting demo.  Web services over BEEP looks like a
definite possiblity for inside the enterprise.  The only hitch I can see
with BEEP (and P2P approaches in general) is the lack of multicast.  I'm not
an expert on this topic by any means, but proprietary pub/sub schemes like
Tibco and Talarian scale the way they do because they run over IP multicast.
I think APEX (or APEX over BEEP) is supposed to address the multicast issue
at some point.

Regards,
--Nick

-----Original Message-----
From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
Krishna Sankar
Sent: Thursday, June 28, 2001 9:03 PM
To: nick@invertica.com; www-ws@w3.org
Subject: RE: open transport protocol for aysnc web services?


Nick,

	Good thoughts.

	Inside an enterprise, processes to processes, I would propose a
peer-to-peer model (yep we would also need to overlay a pub-sub over the
basic Peer-to-Peer infrastructure) One of the assumption is that, even if we
do pub-sub, we would only be doing 1 to (say) 20.

	Just as an example, I am doing is to prototype the RosettaNet PIP3A4
choreography (involving orchestrator, conversation manager, PO service,
booking service, ...) on a JXTA over BEEP.

	In short, the concept of asymmetric, asynchronous, multi-channel wire
standard and associated discovery/description mechanisms do have an appeal
over the current proprietary, messaging systems. As one of our engineers
pointed out, even JMS does not have interoperability over the wire :-(

	cheers

|-----Original Message-----
|From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
|Nick Nadgauda
|Sent: Thursday, June 28, 2001 3:54 PM
|To: www-ws@w3.org
|Subject: open transport protocol for aysnc web services?
|
|
|One of the biggest holes to web service adoption inside the
|enterprise seems
|to be the lack of an open transport protocol for aysnc, reliable message
|delivery.  By this I mean an equivalent of HTTP which provides for two-way
|async communication with decent performance.  Ideally, this protocol should
|become a standard over time enabling "out of the box" web service
|interoperability between different vendors, products, systems, etc.  What
|I'm envisioning is having different systems be able to communicate
|asynchronously inside the enterprise the way they might communicate outside
|the enterprise via HTTP.
|
|There are a few proprietary alternatives (that I know of) including Tibco's
|Rendezvous, IBM's MQ APIs, and JMS.  But none of these is open and I don't
|think you would see widespread adoption as such.  One cannot assume that
|every system is going to be able to talk Rendezvous the way one can assume
|about HTTP.  JMS might be the closest thing to what I'm thinking about, but
|it seems tightly coupled to Java and it really is more of an API
|for driving
|messaging systems rather than a transport protocol.
|
|There's also a few open protocol possiblities (again that I know of)
|including the Jabber as Middleware effort (jam.jabber.org) which aims to
|provide a messaging transport over Jabber's XML on IM backbone.
|Anyone know
|of any (other?) efforts going on in this area?
|
|Regards,
|--Nick
|
|Nick Nadgauda
|:Chief Technology Officer
|:Invertica, Inc.
|:nick@invertica.com
|:[P] 212.571.4103 x6593
|:[F] 212.571.3588
|:[C] 917.847.7938
|
|

Received on Friday, 29 June 2001 13:49:33 UTC