RE: Protocol Bindings

Henrik,

> Stuart,
> 
> Obviously a lot of work has gone into this but I am not sure I agree
> with the stated purpose of a protocol binding:
> 
> >The purpose of an XML Protocol Binding is to provide rules for 
> >the transfer of XML Protocol messages over some specific 
> >underlying protocol. The purpose of a binding architecture is 
> >to provide an abstraction so that the core of the XML protocol 
> >can be defined(specified) independently from the definition
> >(specification) of particular protocol bindings.
> 
> IMO, it is not the role of the binding to provide rules for how messages
> are to be *transferred* by the underlying protocol. 

You're right... I think we disagree! OTOH it may be that we do agree, but
just express ourselves very differently.

I think I and a number of others strongly believe that the purpose of a
protocol binding IS to describe how to make use of a particular underlying
protocol to transfer XMLP/SOAP messages. You seem to be stating that that is
not the case.

Nevertheless, I think that getting to a point where we can all agree on the
purpose/role of a binding would be a good thing. 

> Such rules can either be provided by the underlying protocol itself or 
> by some SOAP extension. 

Maybe I haven't been clear, or maybe you have misunderstood my intent with
the definition above.

Your response seems to suggest that you expect the rule for transferring
SOAP/XMLP messages to be intrinisic to an underlyling protocol already or
defined within the domain of some SOAP/XMLP extension. The way I see it is
that an underlying protocol *provides* some communication service(s). The
rules of procedure of that underlying protocol define the mechanisms by
which it *provides* those communication services. 

The rules I'm refering to are about how you *make use of* the communication
services of underlying protocol to transfer a SOAP/XMLP message. I think you
have interpreted me as referring to the rules of procedure that *provide*
the communication services of the underlying protocol - that was not my
intent.

How about...

"The purpose of an XML Protocol Binding is to describe how to *make use of*
the communication services of particular underlying protocol to transfer an
XML protocol message."

> As SOAP itself does not define any routing semantics, it can't really say
much about how messages are to be 
> exchanged or their exchange patterns for that matter.

Not really sure where this comes from or where its going.

> On the other hand, one of the things that I think the SOAP protocol
> binding should say is how to encapsulate a SOAP message given a specific
> underlying protocol.

Agreed, "...one of the things..."

>As an example one could describe how to stick a
> SOAP message within an HTTP message and how the two interact.

So take another example - say TCP.

In your view would it be enough for a SOAP/TCP binding to say how a SOAP
message is framed and then serialised into a TCP bytestream? 

Would a SOAP/TCP binding have anything to say about the establishment and
tear-down of the supporting TCP connection?

Certainly, a binding must detail how a message is
'encapsulated'/framed/serialised over an underlying protocol, but I think
that it also has to deal with how the actions of sending and receiving a
SOAP message are mapped on to the operations/services of the underlying
protocol. In some cases this will be more trivial/obvious than others.

> It is also fine to talk informally about how protocol layering can be
> used to compose services and how these services may be used by SOAP.

I think informality leads to loose definitions that lead to
misinterpretation. I think that an appropriate level of formality is very
definitely required.

> However for exactly the same reasons that the internals of a SOAP node
> is outside the scope of the SOAP specification, so I believe are the
> internals of the underlying protocol.

I don't think anyone (myself included) has suggested otherwise with respect
to the internals of underlying protocols.

> Henrik Frystyk Nielsen
> mailto:henrikn@microsoft.com

Regards

Stuart

Received on Thursday, 5 July 2001 07:15:44 UTC