Re: The purpose of bindings

An implementer is defining an interface that they know is almost 
certainly going to be used over HTTP and they want to require for the 
purpose of interoperability that any time the interface is used with 
HTTP that TLS MUST be used. I see two ways that the implementer can 
specify this information:

At the interface level - they can stick in a feature/policy/wizbang that 
says "Any HTTP binding to this interface MUST use TLS".

At the binding level - They can publish both an interface and an 
associated HTTP binding. The HTTP binding is incomplete, e.g. it doesn't 
have an address, but does specify minimum requirements like the use of TLS.

The previous scenario reminds me of ebXML's CPP and CPA. A CPP 
advertises the things you 'can/are willing' to do. A CPA defines exactly 
what you will do with a specific partner for a specific connection.

The example I give above is a CPP style scenario. It is an attempt by 
the implementer to specify, independent of a particular instance, what 
behaviors are allowable in an instance.

So another way to describe the issue is - how should WSDL be used in CPP 
style scenarios versus CPA style scenarios?

	Just fumbling my way in the dark,

		Thanks,

			Yaron

paul.downey@bt.com wrote:

> 
> 
> Jacek
>  
> this is how i understand it, with the addition that the interface is an
> abstraction allowing the same operations to be implemented using
> a different transport and serialisation, all without impacting an agent.
>  
> Paul
>  
>  
> -----Original Message-----
> From: www-ws-desc-request@w3.org on behalf of Jacek Kopecky
> Sent: Fri 09/04/2004 13:46
> To: WS-Description WG
> Cc:
> Subject: The purpose of bindings
> 
> 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/
> 
> 
> 
> 
>

Received on Tuesday, 13 April 2004 13:40:56 UTC