RE: open transport protocol for aysnc web services?

Henrik,

Thanks for the info.  I read through the SOAP-RP spec and it looks
promising.  I was wondering how you view it vis-a-vis BEEP?  SOAP-RP seems
to handle routing information plus low-level transport with its TCP and UDP
bindings while BEEP seems to be geared as a framework for building async
application protocols (not necessarily tied to web services).  Is this a
fair assesment?  Both protocols seems to provide a lot of the same
functionality but take different approaches.

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


-----Original Message-----
From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
Sent: Friday, June 29, 2001 4:58 PM
To: nick@invertica.com; www-ws@w3.org
Subject: RE: open transport protocol for aysnc web services?



You might want to take a look at SOAP-RP and DIME which you can find
linked from [1].

SOAP Routing Protocol (SOAP-RP) [2] is a simple SOAP-based protocol for
routing SOAP messages over a variety of protocols like TCP, UDP, HTTP
etc. It can be used for one-way messaging, two-way messaging like
request/response as well as peer-to-peer conversations, etc.

Direct Internet Message Encapsulation (DIME) [3] is a lightweight,
binary encapsulation format that can be used to wrap SOAP messages and
binary "attachments" into a single message construct.

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

[1] http://www.gotdotnet.com/team/xml_wsspecs/
[2] http://www.gotdotnet.com/team/xml_wsspecs/soap-rp/default.html
[3] http://www.gotdotnet.com/team/xml_wsspecs/dime/default.htm

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

Received on Friday, 29 June 2001 17:15:12 UTC