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

Hi Henrik,

PMFJI and sorry for the slow reply.

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.
>
In what way does a protocol binding (meaning e.g. HTTP or SMTP) constrain
what can go in the SOAP body and headers ? I suppose you could argue that
the act of transporting the message imposes the constraint that it complies
with the SOAP specification whereas until it is sent somewhere it is just an
arbitrary bit of XML but that might be overly philosophical.

Maybe I'm missing something but I'm still not entirely convinced by the
concept of MIME and RPC being considered as bindings. It seems to me that
there are as many differences as there are similarities. Consider the
attached table which lists some of the characteristics of a binding listed
above against some of the proposed 'bindings'. Conceptually I can see the
attraction in grouping these together but the only concrete similarity I can
see is that both HTTP and RPC constrain the message exchange pattern.

Personally I find it easier to think of this as a payload inside nested
envelopes (e.g. RPC in SOAP in MIME in HTTP) and one protocol binding (HTTP)
rather than multiple nested protocol bindings.

Turning to nesting, I think we need to consider what information and
constraints are passed in and out between such nested envelopes. Thinking of
the above case, RPC in SOAP in MIME in HTTP, we have the following
information passing from the inside out: destination URI (i.e. SOAPAction
value) and MIME type ("text/xml" from SOAP to MIME, "Multipart/Related...."
from MIME to HTTP). From the outside in we have the constraint that the
message exchange pattern is request/response. I guess it would be better if
the message exchange pattern constraint could be passed from the inside out
but that would make life difficult for protocol bindings.

Comments ?

Regards,
Marc.

--
Marc Hadley <marc.hadley@sun.com>