Proposal for a Binding Framework

One of the things that I think we as a group keep circling around is the characteristic (for better or for worse) of SOAP that in effect it does not define an application in the traditional sense of an application layer protocol. It does not stand up and say: "I am a hypertext protocol (HTTP)", or "I am a file protocol (FTP)", or "I am a mail protocol (SMTP)". Rather, it says: "I am sort of a funny protocol that you can use for a lot of things - likely including the applications above."

[CBF] As I read this, all I could think of was the scene from "Goodfellas"... "funny how?" ;-)

One way to approach this is to say something like this: SOAP doesn't really define an application, but because we want to make a variety of typical applications easy to support, we define a set of properties that are typical of commonly used applications. In many ways this is consistent with the definition of the RPC convention which I see as a particular application - it defines certain behaviors, a particular message exchange pattern, and has certain expected QoS behaviors.

[CBF] Agreed.

I also believe that saying that such applications can be part of the binding is a consistent way of approaching this. I tend to see the RPC convention as effectively a binding and because we have a nested binding model, one can nest the RPC binding with the SMTP binding. We can even model SOAP attachments in the same way allowing one to nest the RPC binding with the SOAP attachments binding with the SMTP binding, say.

[CBF] Agreed.

However, it also seems feasible not to use a binding that implies some sort of application but rather have the application be defined within the SOAP message using the SOAP extensibility mechanism. This is for example the case with the DIME binding. DIME doesn't define an application but completely leaves this up to the SOAP layer.

[CBF] Okay, now you've lost me... [CBF reads on...]

I think we have to accommodate both models—if for nothing else then because we have real examples of both types of bindings. The model provided here is rather simple but I think it might allow for much of what I think we have been talking about

A binding is characterized by three things:
    The name of the binding in the form of a URI which can be used to identify the binding in places like WSDL etc.

    [CBF] yes.

    A set of properties describing the binding. Properties also have names that can allow them to be reused by other bindings and to be referred to by nestable bindings

    [CBF] right.

    A description of how that binding may be nested with other bindings. Each nested binding has its own name and nested bindings can be made by anybody independent of who has made the bindings that are nested

    [CBF] I have always felt that this would be expressed by the pre/post conditions/constraints. Also, it seems to me that a crucial aspect of a binding, missing from your proposal is a specified canonical mapping of the abstract properties in to the bound "protocol".  For instance, say there is a property defined as "media-type". In a MIME binding, this property is mapped to/from the MIME Content-Type header. In a DIME binding, this property is mapped to/from the Type field and the length of the value of the media-type property is computed and mapped to the Type-Length field, etc.

Following is an example of how this can play out (The FOO: notation is used to indicate where the properties are defined)

SMTP binding

SMTP Binding Name

SMTP Properties

SMTP Nesting

We expect that the SMTP binding will be at the bottom and not nested downwards with any other bindings

[CBF] again, I would prefer that any nesting constraints be expressed in terms of any properties that the binding uses/requires as input as well as those "output" (e.g. any properties that are generated by the binding itself) For example, SMTP would likely generate a unique MID for the message. This would be reflected back up the stack at a receiving SOAP node in the set of properties for the message.

Attachment binding

Attachment Binding Name

Attachment Properties

Attachment Nesting

The SOAP attachment binding can be nested with the SMTP binding in which case we give it a name Which exposes the following properties:

RPC binding

RPC Binding Name

RPC Properties

RPC Nesting

The RPC binding can be nested with the SMTP binding as well as the SOAP attachment binding. In the former case we get a nested binding with a name like: and it has the following properties Because some of the properties overlap (correlation is an example), we will have explain how they interact. In the latter case, we get another nested binding with a name like and with this set of properties:  Nested bindings do not have to include all properties of the various bindings - it is a choice of the designer of the nested binding.
Henrik Frystyk Nielsen

@(#) $Id: binding_framework.htm,v 1.3 2001/08/16 00:28:30 henrikn Exp $