W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2001

Re: Causality: A possible remedy to our one-way, request/response debate.

From: Mark Nottingham <mnot@akamai.com>
Date: Tue, 17 Apr 2001 17:04:32 -0700
To: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Cc: XML Distributed Applications List <xml-dist-app@w3.org>
Message-ID: <20010417170426.A14365@akamai.com>

Hi Henrik - sorry for the delay - too much mail also ;)

On Tue, Apr 10, 2001 at 03:11:27PM -0700, Henrik Frystyk Nielsen wrote:
> Ok, a more specific example is the SOAP MIME multipart related spec
> [2] and see how that relates to the SOAP spec [3]. The SOAP MIME
> multipart is effectively a protocol binding in its own right - it
> defines how a SOAP message can be embedded within a MIME multipart
> related message and how one can use URIs to refer to individual
> entity bodies within the multipart message.
> However, MIME multipart is in itself not really a protocol - it is
> a message description format and so it doesn't say where to send
> the message etc. However, the MIME multipart binding can be nested
> to fit within other protocols that support MIME entities. For
> example, one can nest the SOAP/MIME multipart binding and the HTTP
> binding to get a mechanism for exchanging the message.


> The point about the RPC convention is that it has a lot in common
> with a binding in that it imposes constraints on the SOAP message
> (what can go in the body and in the headers) and also defines a
> message exchange pattern: request/response.
> However, similar to the SOAP MIME multipart binding, the RPC
> convention doesn't actually provide a mechanism for exchanging
> messages. In order to solve this problem, the RPC convention can be
> nested with the HTTP binding or some other binding. In the case of
> HTTP, HTTP naturally supports request/response. However, it doesn't
> support RPC as such and therefore some of the conventions are
> expressed within the SOAP envelope.
> One could imagine nesting the RPC convention with other bindings
> like an SMTP binding that doesn't support request/response. In
> order to compensate, we could therefore define a module that took
> care of the correlation between requests and responses.
> As more an more modules get defined one can wonder whether SOAP
> eventually won't "grow up" and simply become a complete protocol in
> its own right with enough modules for handling the 80% case.
> One can even imagine nesting the RPC convention within MIME
> multipart within HTTP.

I think we're visualizing this in different ways, and that's causing
the disconnect - I don't disagree with anything you say, but the way
you express it does make me scratch my head. While I can see MIME as
a binding, RPC seems to fit elsewhere, to me.

All SOAP applications, including those that use the RPC convention,
will have some form of what I've been calling 'application message
exchange pattern'; those that use the RPC convention will need

Separately, every transport binding will have an implicit message
exchange pattern; HTTP has request/response, SMTP has one-way (and
maybe multicast? ;), and BEEP offers a few possibilities, because
it's really a protocol framework.

So, the task that I see applications performing is mapping their
message exchange pattern onto their chosen transports' message
exchange patterns, which may be complimentary, or may be different,
and require things like in-message correlation.

My point is, a number of things place constraints on the content of
the message, the message exchange pattern, etc. I don't know that
it's useful to visualize all such things as 'bindings' just because
they evince things that the transport bindings happen to do.

> >We've been talking about message exchange patterns and the flow of
> >messages, but not how they relate to the establishment of the
> >connection to a 'service URI', although there has been hand-waving
> >about the service URI itself. Should we pick this apart into a
> >separate layer (service layer)?
> Yes, I think that makes to do so. One reason for that is that we
> avoid getting into the situation of having to define how to export
> endpoints.

Hmm... is this in scope for the AM, or should it be punted up as an
issue to higher levels (i.e., Web Services)?

Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
Received on Tuesday, 17 April 2001 20:05:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:12 UTC