Re: SOAP Header Blocks in WSDL (was RE: First Class Headers - Propose d Resolution for LC76d

On Sun, 30 Jan 2005 16:10:27 -0800
Asir Vedamuthu <asirv@webmethods.com> wrote:
> Easy :-) I like the wsoap:header proposal. As I said, it passes my
> simple test - independent of F and P framework and something simple.
> Attached proposal is one such mechanism. This proposal relies on
> schema for optionality, choice, maxOccurs, etc.

Problems with this proposal:

1) it can't be validated
   That is, it requires the binding author to create a complexType
which, however, cannot be reliably used to validate the collection of
headers, which is explicitly said in the text to be incomplete, and
which may reasonably occur in an order different than presented in the
created type.

2) it's unduly burdensome
   That is, the author of a binding, not the author of an interface, is
required to extend the types component to support the transmission of
headers.

3) it's brittle
   A deployed service cannot reasonably and easily extend the types
defined for headers in a way that describes new requirements, and a
variant binding is better off starting from scratch than attempting to
extend.  If a SOAP header abstraction were to appear in WSDL, it *ought*
to be something that is reusable, in some fashion.

4) it's obscure
   Information about binding requirements are buried in the type system,
requiring an author to find the required use (in the example) of
WS-Security features by recognizing the type of the header, with no
other required information supplied (this could be ameliorated by
requiring documentation/annotation of each required header, I suppose,
but the utility of that seems to me strictly limited).

/me has a heart attack and sprawls across the road

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Monday, 31 January 2005 16:22:34 UTC