W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

RE: Protocol Bindings

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Thu, 5 Jul 2001 12:04:51 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D0297CDB9@red-msg-07.redmond.corp.microsoft.com>
To: <Noah_Mendelsohn@lotus.com>, "Williams, Stuart" <skw@hplb.hpl.hp.com>
Cc: <xml-dist-app@w3.org>

If might be useful to step back a bit and look at why we have a notion
of protocol bindings in the first place. The reason why one might want
to use different underlying protocols is that they provide different
levels of functionality (in the broadest possible sense).

If I use SOAP in combination with HTTP it is because I am after what
effectively is an HTTP application style interaction. If I use SOAP in
combination with UDP, it is because I want the services provided by UDP.
If I am looking for a underlying protocol that both provides URP's
service and a request/response mechanism, then I have to find a protocol
that does that or define this extra functionality in some manner.

In the latter case, I have two choices: I can define it as part of an
underlying protocol(s) or I can define it as a SOAP extension. These are
effectively the two slots that we have available as there are no other
places that I can augment the functionality of the stack.

If it is defined as a SOAP extension then we have a model for how to go
about defining that extension including how it can be added to the SOAP
envelope etc. If it is defined as part of the underlying protocol then
the protocol binding will likely have to talk about how these features
can be used.

However, just as we don't provide mechanisms for how SOAP extensions are
to advertise their services or features to the rest of the world,
neither can we really tell underlying protocols how to advertise their
services. For both SOAP extensions and for protocol bindings this can
happen in any number of ways - using declarative means, writing a spec,
etc etc.

Much of this is really metainformation about how services are to be used
and here something like WSDL can be leveraged to describe what
combinations are possible for accessing specific services and where they
can be accessed. For example, WSDL enables you to describe where to send
messages and to a certain degree what bindings they should use.

In addition to what types of messages one can send to which endpoints,
we also need to figure out what message exchange patterns these messages
are part of. Just like information about the type, information about
message patterns is also metainformation. It is effectively a
description of the orchestration of messages.

No doubt that both message description and message exchange pattern
descriptions are important but neither seem to be within scope of what
the core SOAP specification is supposed to do according to our charter. 

I would also strongly urge us not to get into specific implementation
questions regarding how certain APIs may cover the differences between
certain protocol bindings. I have no doubt that tool builders will work
hard on making use of various bindings very easy within their

All I think we have to do is to look at the (rather narrow) protocol
speciation that we are working on and define what the requirements of
that protocol are to underlying protocol.

Received on Thursday, 5 July 2001 15:08:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:14 UTC