- From: Nick Nadgauda <nick@invertica.com>
- Date: Fri, 29 Jun 2001 17:15:00 -0400
- To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>, <www-ws@w3.org>
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