REQ: Higher-level support for SOAP extensions/modules

Hi all!

Got up early this morning, and had a little time to read over the current requirements doc.  I was a bit dismayed not to find one of my pet issues there, namely the mechanism by which WSDL supports SOAP extensions... so, no time like the present to make a suggestion. :)

At present, it is possible with WSDL 1.1 to specify particular headers which should be included with particular messages.  This was, I believe, a reasonable first stab at integrating headers with a description language, but it falls far short of being able to support the kind of rich semantic additions that are going to be coming down the line as SOAP extensions over the next few months/years.

Without going into too much detail, I'd like to see us require the ability to specify that a particular SOAP "module" is offered by, or required by, particular services or operations.  SOAP 1.2 (part 1, sec 3) discusses the concept of SOAP "features", which are semantic extensions named with a URI and implemented by either SOAP extensions (headers) or bindings.  Bindings already have a requirement for URI naming, and I'm attempting to push for extensions to do the same.  Once we have URIs for such things, it becomes possible to say something like "this operation supports the 'http://www.w3.org/2002/06/reliable-message' extension", which would imply some set of headers/exchanges mandated by that specification.  It's unclear to me as to whether we would require a schema description of every possible header which such an extension might produce, but that's another facet of this which we should discuss.

This is also a potentially complex issue in that it gets into situations where messages that are not actually specified directly in the WSDL may become part of the exchange due to the extension specs, but I think we need to figure this stuff out if we hope to live in a world with true "orthogonal extensibility" and some hope of negotiation/interop.

Thanks,
--Glen

Received on Thursday, 28 March 2002 06:58:36 UTC