RE: open transport protocol for aysnc web services?

See also DIME for the application of SOAP-RP to conveyance of generic
content.

http://www.gotdotnet.com/team/xml_wsspecs/dime/default.htm

Developmentor has a mailing list for discussion of DIME. 
http://discuss.develop.com/dime.html 


-----Original Message-----
From: john d. beatty [mailto:jbeatty@gonesilent.com] 
Sent: Thursday, July 12, 2001 3:40 PM
To: www-ws@w3.org
Subject: RE: open transport protocol for aysnc web services?


I believe SOAP-RP is more analogous to APEX [1] [2] than it is to raw
BEEP (APEX is an asynch messaging layer that uses BEEP as a transport).

Given that, what does anyone think of APEX vs. SOAP-RP?

IMO, there is a serious need for a generic, standard asynch messaging
protocol that allows any type of message to be routed.  SOAP-RP tightly
couples the message routing information to the message (e.g., the
message routing information is contained in the header of the SOAP
message), thus it is not a generic solution (only SOAP messages are
allowed).  APEX, on the other hand, allows arbritary messages.

However, SOAP-RP is more pragmatic in that it's pretty simple; it
doesn't require a more-complex transport like BEEP; there's a smaller
community to get the standard pushed through; etc.  (btw, I'm not sure
of the status of BEEP-over-HTTP.  There is currently only a BEEP-TCP
binding specified, AFAIK.)

Note that there is a SOAP-over-BEEP Internet Draft [3].  This is a
simplistic binding spec anologous to specifying a SOAP-over-HTTP
binding. It does not attempt to define an asynch messaging layer.

It might be a good thing for the SOAP community to clamor for a more
generic messaging solution than SOAP-RP and for to put pressure on
Microsoft, IBM, Sun, TIBCO, webMethods, et. al. to try a little harder
on a standard, generic asynch messaging protocol.

Quick question for the .NET-heads out there: is MSMQ 3.0 using SOAP-RP,
or is it something different?? I was just looking that the MSMQ 3.0
white paper [4], and it says it defines an HTTP-based transport with
MSMQ headers in the SOAP envelope: "From a programming point of view,
every message sent via HTTP will automatically be formatted as a
SOAP-based message. New properties, specific to SOAP, are available to
developers for controlling SOAP formatting at a fine level.  For
instance, it is possible for a message sender to insert non-MSMQ headers
into the SOAP envelope and have them retrieved and processed by the
message receiver."

john

[1] http://www.ietf.org/internet-drafts/draft-ietf-apex-core-04.txt
[2] http://beepcore.org/beepcore/specsdocs.jsp
[3] http://www.ietf.org/internet-drafts/draft-etal-beep-soap-03.txt
[4] http://www.microsoft.com/msmq

> From: Henrik Frystyk Nielsen (henrikn@microsoft.com)

> Although there certainly are similarities between SOAP-RP and BEEP, I 
> actually see them as being quite different in their scope and what 
> they do.
>
> SOAP-RP is a stateless, message oriented mechanism for exchanging 
> messages along message paths using any message pattern. One of the big

> differences to me is that I in SOAP-RP can address intermediaries and 
> have them perform tasks - in other words provide a decentralized 
> processing mechanism. This is useful in scenarios where you want to 
> role out web services as value add services.
>
> On the other hand I would categorize BEEP as a connection-oriented 
> hop-by-hop protocol with some notion of message exchange patterns like

> request/response, for example, although it doesn't actually define an 
> application.

Received on Thursday, 12 July 2001 19:11:50 UTC