W3C home > Mailing lists > Public > www-ws@w3.org > June 2001

RE: open transport protocol for aysnc web services?

From: Krishna Sankar <ksankar@cisco.com>
Date: Fri, 29 Jun 2001 11:29:49 -0700
To: <nick@invertica.com>, <www-ws@w3.org>
Message-ID: <NABBJDOPDKGCDCNBNEDOGEMHELAA.ksankar@cisco.com>
Nick,

	I agree with your thought on the lack of multi-cast. Hence my assumption
that inside an enterprise, normal apps wouldn't need to do more than 10-25
subscribers and that too not frequently. My impression with Tibco was that
they use UDP broadcast, which itself is an issue with the security folks.

	So multi-cast is an issue to be solved, and again, following your thoughts,
we need standards on all layers incl the wire protocol.

	Re the demo, I also plan to write the JXTA/Sockets using C# (if a BEEP
implementation is available on C#, the better) and see if we can
(seamlessly) talk between a set of C#, Java peers, proving the
interoperability.

cheers

|-----Original Message-----
|From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
|Nick Nadgauda
|Sent: Friday, June 29, 2001 10:49 AM
|To: Krishna Sankar; www-ws@w3.org
|Subject: 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 14:28:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:38 GMT