Re: Protocol Bindings

Henrik Frystyk Nielsen wrote:
> 
> >> What you state here is different from what you stated in the previous
> 
> >> mail. Either the "purpose of an XML Protocol Binding is to provide
> >> rules for the transfer of XML Protocol messages over some specific
> >> underlying protocol" or "the purpose of a protocol binding IS to
> >> describe how to make use of a particular underlying protocol to
> >> transfer XMLP/SOAP messages."
> >
> >Personally I think that both formulations say the same thing.
> >If the second communicates my intend more clearly to you, that's great.
> 
> There is a very big difference--it is not just a formulation problem and
> we must have agreement on which one before we can effectively talk about
> what bindings can do and cannot do. From an architectural consistency
> point of view I don't think we have a choice but to use the latter.
> 
FWIW I also fail to see the difference between the two. They both mean
the same thing.

> When you say that SOAP or the SOAP binding defines the *transfer* then
> what you are saying is that SOAP does routing - in order for SOAP to
> transfer a message it has to know where it is going. The reason why I
> keep saying that SOAP doesn't do routing is that some routing (or
> endpoint identification) mechanism is necessary in order to transfer
> messages but SOAP doesn't define that and neither does the binding.
> 
I can't see the difficulty here, the SOAP binding *is* responsible for
transferring the SOAP message. It defines how the SOAP message is
encapsulated in the underlying protocol and how that protocol is used to
transfer the message. That's what bindings do - right ?

> The binding is exactly what it sounds like - a gluing mechanism between
> SOAP and whatever underlying protocol. There should be no additional
> semantics defined by the binding because the places where we add
> semantics is either as SOAP extensions or as underlying protocols.
> Semantics defined by the binding is not defined as part of underlying
> protocols and not defined within the extensibility mechanism of SOAP. In
> other words we have no good way to talk about it in terms of processing
> model, extensibility model etc.
> 
Sounds like a good argument for getting rid of SOAPAction to me ;-)

Regards,
Marc.

--
Marc Hadley <marc.hadley@sun.com>
Tel: +44 1252 423740
Int: x23740

Received on Friday, 6 July 2001 12:59:32 UTC