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

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.

Yes.


> 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
request/response.

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