RE: Protocol Bindings

>	Couple of quick observations:
>
>	1.	Agreed. Binding is encapsulation and nothing 
>more, nothing less. And
>yes, protocol implies more.

For the core SOAP protocol - absolutely.

>	2.	Before we get to binding, I assume we will 
>articulate an essential set
>of what XMLP would need and use. (Which I think is the main 
>theme of Stuart's e-mail) As Mark pointed out, we can only say 
>what XMLP needs and any other initiatives like normalizing 
>features provided by other transports is outside the scope and 
>is a Herculean task. It would be a good undertaking, though.

Maybe for a cold winter day :)

>	3.	Which also means, if there are more "features" 
>available at the
>transport layer, (like the multi-channel capability of BEEP or 
>the publish capability of UDP) XMLP wouldn't use them. Of 
>course, implementations can make use of the extra "features" 
>as an optimization.

An application can of course take advantage of additional services
provided by underlying protocols but SOAP core doesn't care what those
services are or how they are provided.

>	4.	Would the XMLP specification have the actual 
>bindings (and examples) for
>popular transports like TCP, HTTP, BEEP, ... ?

I think we only are chartered for the HTTP binding

>	The paragraph, "NB: This proposal makes the assumption 
>that the purpose of a binding is to create a common 
>abstraction across all underlying protocol that 'hides' the 
>functional differences between different underlying protocols."

In my view it is absolutely not the purpose (or within the capabilities)
of a SOAP binding to hide differences between underlying protocols. How
would we expect the core SOAP specification to hide the differences
between, say UDP and TCP and why would we? If I want to use SOAP over
UDP it is because I want the services that UDP provides rather than what
TCP provides.

>	*could* read something like
>
>	"The purpose of binding is to create the minimum 
>abstraction required by XMLP to successfully operate across 
>all protocols and provide recommendations" as a mission 
>statement and then add the requirements Mark has in his e-mail.

Yes, as long as the minimum abstraction is targeted what SOAP core
actually provides.

Henrik

Received on Thursday, 5 July 2001 15:17:45 UTC