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

RE: open transport protocol for aysnc web services?

From: john d. beatty <jbeatty@gonesilent.com>
Date: Thu, 12 Jul 2001 15:40:25 -0700
Message-ID: <3B4E2759.7EE854C8@gonesilent.com>
To: www-ws@w3.org
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 18:40:41 GMT

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