RE: The purpose of bindings

Hi Anne!

While there are many cases where you are correct about abstract
components, I think that there are certainly cases where it is
appropriate to insert capabilities/requirements (c/r) information into
the abstract level of a service definition.  For instance, I may be
defining an industry-standard interface for which I want to make sure
that *all* implementations support a particular level of reliable
delivery.  Or I might be defining a binding which wants to advertise its
security level so that all users of that binding are aware of, and
conformant to, particular requirements in that regard (that might help
my implementation select a particular binding, for instance).

I think the choice of where this information goes is up to the service
developer, not mandated by us.

When you say "a separate definition", what exactly do you mean?  It's OK
to put information like that in your <service> element (or even a
particular <endpoint>?), right?

--Glen

> I haven't been involved in the conversation, but it occurs to
> me that it isn't appropriate to define authentication,
> authorization, confidentiality, etc requirements and
> constraints in an interface definition.
> 
> An interface is a *reusable*, abstract definition. Any number
> of service providers should be able to implement an
> interface. Authentication, etc, constraints apply to a
> specific implementation of an interface.
> 
> Likewise, a binding is a *reusable*, concrete mapping of an
> abstract interface to a set of protocols. Any number of
> service providers should be able to implement a binding.
> Hence you really shouldn't specify implementation-specific
> information in a binding. 
> 
> Information that applies to a specific implementation should
> be defined in a separate definition.
> 
> Anne
> 
> At 03:57 AM 4/9/2004, Jacek Kopecky wrote:
> 
>> Hi all,
>> 
>> during yesterday's call we discovered it may be unclear what the
>> purpose of bindings is, which makes very fuzzy the line of what
>> should be in a binding and what should be in an interface.
>> 
>> Here's my take:
>> 
>> In WSDL, an Interface describes the application-level interface with
>> all information necessary for the application. A Binding describes
>> how the interface is realized on the wire.
>> 
>> The main part of what the interface describes is the operations,
>> message formats and exchange patterns. Additionally, using features
>> (or extensions like policy or whatnot) an interface may specify other
>> constraints, e.g. the necessity of authentication, confidentiality of
>> communication, transactionality etc. Finally, an interface may
>> describe important properties of operations and messages, e.g. web
>> safeness or cacheability of results. 
>> 
>> A binding must be able to transfer the messages of its interface's
>> operations, following the message exchange patterns, to an endpoint.
>> Additionally, a binding must realize all features that an interface
>> mandates and it must follow all constraints specified in the
>> interface, e.g. the HTTP binding may realize communication
>> confidentiality by mandating the use of HTTPS, or the SOAP binding
>> may realize confidentiality by mandating the use of XML Encryption
>> in the messages. Finally, a binding may take advantage of the
>> properties described in its interface, for example by allowing
>> opportunistic pre-invocation of web-safe operations or by allowing
>> caching of cacheable results. 
>> 
>> To summarize, the boundary is in the application - information
>> important for the application goes into interfaces, implementation
>> details go into bindings. 
>> 
>> 
>> 
>> My on-line presence may be very sparse next week, so please be
>> patient if any clarifications are necessary.
>> 
>> Share and enjoy,
>> 
>>                    Jacek Kopecky
>> 
>>                    Systinet Corporation
>>                    http://www.systinet.com/
> 
> ~~~~~~~~~~~~~~~~~~
> Anne Thomas Manes
> VP & Research Director
> Burton Group

Received on Friday, 9 April 2004 12:30:47 UTC