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:09:57 UTC