RE: Protocol Bindings

>> 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.
>
>That may be a point of difference.

But what should the mechanisms be for defining semantics as part of the
binding? Unless we define a separate processing model for the binding, a
separate mechanism for identifying features, a separate mechanism for
defining faults, etc. then there is no framework within which I can
define such semantics.

What I am proposing is to say the following: Look, in SOAP we define a
protocol framework that is especially targeted the XML community. It
defines a processing model, an extensibility model and all that good
stuff needed for building distributed applications. However, we all know
that SOAP and XML are not alone in the world - there are plenty of
existing protocols and infrastructure around. In order to allow SOAP
based applications to take advantage of such services and features, we
allow SOAP to be bound to various other protocols in as straightforward
a way as possible.

This gives us what we want in that it allows SOAP applications to use a
variety of underlying protocols without us having to define a new
complex "binding language" that can support extensibility etc.

>> 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.

Henrik

Received on Friday, 6 July 2001 12:20:50 UTC