RE: Protocol Bindings

>I would class most of what you listed as application 
>protocols. I would class MIME multipart as mainly an encoding 
>- the fact that you have a SOAP envelope encoded as MIME 
>multipart does not define how such envelope gets from point A 
>in a network to point B. I would class TCP as a transport protocol.

I don't dispute the classification - the point of listing some of the
protocols/formats that already actively is being used to encapsulate
SOAP is that I think we should provide a model that actually enables us
to talk about what people are doing in a fairly straight forward manner.


>I think defining the following are all useful exercises: (A) a 
>routing protocol for SOAP, (B) a binary encoding for SOAP 
>envelopes and (C) a SOAP-specific application protocol above TCP.
>
>They are three distinct issues, and should be separately 
>defined. There is a need to clearly think through what is the 
>goal of such work.

Here's my answers to your exercises ;)

A: SOAP-RP
B: DIME
C: left to the designer of the application using SOAP and SOAP-RP

Note that the scope of SOAP-RP really only is to define how to send
messages around. I agree with you that often many more features and
functions such as security and reliability are needed and indeed just as
important.

>Your DIME specification is mixing up a description of a binary 
>format with some message semantics (e.g. discussing how DIME 
>records must be sequenced on a transport).

The point of that remark in the DIME spec is just to say that DIME
messages cannot be used directly for multiplexing. As DIME is a media
type, it indeed leaves it entirely up to other parties to figure out how
it can be exchanged.

>I think a better 
>approach would be for the XMLP WG to define the binary 
>encoding and leave it up to the individual bindings to the 
>application protocols to describe how such an encoding (or 
>current XML 1.1 encoding, or SOAPwA encoding) could be 
>transported. If the binary representation involved multiple 
>records within one message, some bindings might have to put 
>all on-the-wire in a serialized fashion, but some, such as 
>BEEP, could be capable of carried multiple binary messages at 
>the same time - by interleaving their "records" - thus you 
>could get pairs of threads in multithreaded apps talking 
>without serialization, which is highly desirable. The binary 
>encoding certainly should not be specifying this info.

Actually, I am not a believer in layered multiplexing as it causes a
number of problems, see for example [1]. In addition, as it from an
application point of view, doesn't address any head-of-line blocking
problems, increases the risk of dead-locks, and because the interleaved
channels are interconnected, one cannot abort channels in an independent
manner, I can't see the benefit (not that I haven't tried - some may
remember WebMux [2]).

If you want to have that flexibility then why not simply do SOAP-RP/DIME
over multiple TCP streams?

Henrik

[1] David Feldmeier, Multiplexing Issues in Communication System Design,
SIGCOMM 1990 
[2] http://www.w3.org/Protocols/MUX/WD-mux-980708.html

Received on Saturday, 7 July 2001 22:18:24 UTC