- From: Amelia A Lewis <alewis@tibco.com>
- Date: Fri, 28 Jan 2005 11:51:00 -0500
- To: Asir Vedamuthu <asirv@webmethods.com>
- Cc: www-ws-desc@w3.org
Okay.
At this point I have to say that I've come to think that *any* change to
the status quo is a mistake, as it has the potential to reintroduce the
hideous soap:header mess. soap:header is pretty close to
lay-down-in-the-road and scream loudly; it's disastrous.
So TIBCO will oppose changing in that direction at all, I think.
Amy!
On Fri, 28 Jan 2005 04:41:20 -0800
Asir Vedamuthu <asirv@webmethods.com> wrote:
>
> > I sincerely hope we'll consider resurrecting soap:header
>
> I like that one too. soap:header passes my test - independent of F and
> P framework and Simple. Like other proposals, I bet this one has its
> own merits and de-merits. Thus far, we have four possibilities:
>
> (a) Status Quo - Application Data Feature, Module and Serialization as
> HTTP Headers
> (b) Headers Proposal V1.2 + Application Data Feature, Module and
> Serialization as HTTP Headers
> (c) First Class Headers
> (d) soap:header
>
> PS: I did not understand your versioning concerns. To the extent that
> I understood, this concern may be predicated on optional, choice and
> repeating things described in Sanjiva's e-mail.
>
> Regards,
> Asir S Vedamuthu
> asirv at webmethods dot com
> http://www.webmethods.com/
>
> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
> On Behalf Of Roberto Chinnici
> Sent: Thursday, January 27, 2005 3:37 PM
> To: Sanjiva Weerawarana
> Cc: www-ws-desc@w3.org
> Subject: Re: First Class Headers - Proposed Resolution for LC76d
>
>
>
> +1 to Sanjiva's remarks. I don't like this direction either.
>
> LC76d was asking for a binding-level construct to replace the AD
> feature. This proposal instead defines a gratuitous interface-level
> construct. The WSS header example itself is misleading in that
> normally we wouldn't want it to be expressed at the interface level
> (binding it to HTTP anyone?). Furthermore, as Sanjiva pointed out,
> this proposal reintroduces most of the wsdl:message construct, with
> its well-know drawbacks in terms of complexity, tooling,
> expressiveness, etc., all without the benefits of reusability across
> operations. I sincerely hope we'll consider resurrecting soap:header
> from WSDL 1.1 (presumably in the form of wsoap:header) before going
> down this route.
>
> I also heard versioning concerns used as a motivation for this general
> direction. Once again, we'd be introducing some schema-like constructs
> in WSDL 2.0 to work around XML Schema limitations. As a proof,
> consider the following: if by default every GED in schema was
> extensible and there was a simple way to say "I extend that GED over
> there", would we still want a Header component to help with versioning
> of Web services? I bet we wouldn't.
>
> Roberto
>
>
> Sanjiva Weerawarana wrote:
> > I'm sorry to rain on the parade, but I don't think this is a good
> direction.
> >
> > First of all, we've been here before; I made a similar proposal when
> > I
> made
> > the <message> elimination proposal. Then we decided to remove it ..
> >
> > The problems with this proposal are:
> > - what's the intended programming model for this? I know that's out
> > of
> scope
> > for us, but do you expect that a stub, for example, would have an
> > additional
> > parameter for each header? Having this messes up the nice clean
> > simple programming model one can derive from WSDL as it stands
> > now.
> >
> > - One of the reasons @headers was removed IIRC was because it was
> > too
> weak:
> > you cannot say there's an optional header or a choice or a
> > repeating thing. This proposal has the same problems (and in fact
> > that was part of the motivation for dropping <message>).
> >
> > - Putting this feels to me like we are basically inlining <message>
> > inside
> > the <input> etc. elements. Its like the doc/lit rule that WS-I
> > came up
> > with ..
> > only 1 body part and any # of header parts. I don't like it one
> > bit
> > because
> > it loses the clean and simpleness we achieved with a lot of work
> > over
> > a very
> > long time.
> >
> > I'm sure I can think of more problem over time ;-).
> >
> > Sanjiva.
> >
> >
> > ----- Original Message -----
> > *From:* Prasad Yendluri <mailto:pyendluri@webmethods.com>
> > *To:* www-ws-desc@w3.org <mailto:www-ws-desc@w3.org> ;
> > asirv@webmethods.com <mailto:asirv@webmethods.com>
> > *Cc:* jeffsch@windows.microsoft.com
> > <mailto:jeffsch@windows.microsoft.com>
> > *Sent:* Thursday, January 27, 2005 4:24 AM
> > *Subject:* Re: First Class Headers - Proposed Resolution for
> > LC76d
> >
> > Hi Asir,
> >
> > I echo the remarks of Jean-J and Kevin on simple and easy to
> > follow nature of the proposal. It is pretty comprehensive as
> > well.
> >
> > As I reviewed, I came up with a few comments.
> >
> > Regards, Prasad
> >
> > General Comments:
> > -------------------
> >
> > 1. This proposal does not address if all headers that can be
> > exchanged via input, output or fault messages in an interface
> > (operations) MUST be declared. Or if this is only a subset of
> > all the potential headers (including things that are added
> > dynamically) that the definer of the interface chose to declare.
> >
> > 2. The @required of the {header} component and the
> > @disableHeaders at the {binding} component level are in total
> > contradiction.
> >
> > The "REQUIRED" @required on the {header} component is defined to
> > be: "An xs:boolean. If the value of this property is true, then
> > the Web Service consumer/client MUST use the Header that is
> > identified by the {element declaration}."
> >
> > Where as, the purpose of the disableHeadersDefault AII at the
> > binding level is to "disable" header generation at the binding
> > level.
> >
> > So, if @required on a {header} component at the
> > interface/operation level says the "header MUST be used", a
> > binding can arbitrarily override that to ignore that (and even
> > all) header(s)?
> >
> > I am not sure that is desirable at all.
> >
> > 3. Somewhat related to the above. Headers concept is not native
> > to many of the potential bindings; and the HTTP binding already
> > identifies issues/difficulties with binding {header} components
> > at the abstract level. Any proposal that introduces headers
> > needs to speak to this aspect of, if bindings that have no
> > concept of headers *can* be used with interfaces that specify
> > {header} components and if so, a general guidance on how the
> > header components can be bound would be helpful.
> >
> > Specific Comments on individual parts:
> >
> > Section (1) Introduce a NEW Header Component
> > ---------------------------------------------------
> >
> > 4. In the proposal, the Header component is defined recursively
> > using the term header to define itself.
> >
> > "A Header Component describes an abstract piece of *header* that
> > is associated with the exchange of messages between the
> > communicating parties."
> >
> > We need to fix this.
> >
> > 5. The {namespace name} on the header REQUIRED but no defaulting
> > is defined. I believe we need to permit the use of elements
> > declared locally in the default (local) namespace as headers.
> > Perhaps that is the intent but that is not clear from the
> > proposal.
> >
> > 6. {mustUnderstand} OPTIONAL. An xs:boolean. If the property is
> > true, then the bindings that support expression of mandatory
> > data should mark them as mandatory in an appropriate way.
> >
> > Why is it a "should mark them as mandatory" and not a "must"?
> > With this it seems a specific SOAP binding can choose not to
> > mark the headers with "mustUnderstand=true" even when at the
> > interface/operation level {header} components sets this
> > attribute to true.
> >
> > Section (4) Syntax Level Default Mechanism to Disable Header
> > Construction
> >
> ---------------------------------------------------------------------
> ------- --
> >
> > 7. The proposal states, "disableHeaderDefault AII (at the
> > binding component level) is a syntax level convenient mechanism
> > and does not contribute anything to the component model."
> >
> > Is that really so? Does it not specify the default value for
> > this attribute for all sub-components unless explicitly
> > overridden?
> >
> > Also, I hope we would add some actual description of
> > disableHeaderDefault AII is all about. The proposal is drafted
> > in a form that can be inserted in the spec in appropriate
> > sections, hence I ask.
> >
> > Section (5) Mechanism to Disable Header Construction for the
> > Binding Fault Component
> >
> ---------------------------------------------------------------------
> ------- ------
> > 8. "{disable headers} OPTIONAL. An xs:boolean. If this property
> > exists and is true, then header construction is turned off."
> >
> > We need to be more specific here. Does turned off mean, the
> > {header} components are not serialized at all or not serialized
> > as headers? Can they go as some other piece of the serialized
> > message?
> >
> > Section (7) Add to SOAP Binding's Default Binding Rules
> > -----------------------------------------------------------
> > 9. "Default value of the Binding Operation Component's {disable
> > headers} property is false."
> >
> > The {operation} component in binding is not shown to have this
> > AII (e.g. in section (6) of the proposal).
> >
> > Section (8) Add to HTTP Binding's Default Binding Rules
> > -----------------------------------------------------------
> > 10. "an Header component's {element} property in the {headers}
> > property MUST be turned into HTTP header if possible."
> >
> > Eliminate use of MUST and "if possible" in the same sentence
> > above.
> >
> > -------- Original Message --------
> > Subject: First Class Headers - Proposed Resolution for
> > LC76d Resent-Date: Mon, 24 Jan 2005 13:47:15 +0000
> > Resent-From: www-ws-desc@w3.org
> > Date: Mon, 24 Jan 2005 08:46:20 -0500
> > From: Asir Vedamuthu <asirv@webmethods.com>
> > To: 'www-ws-desc@w3.org' <www-ws-desc@w3.org>
> > CC: 'jeffsch@windows.microsoft.com'
> <jeffsch@windows.microsoft.com>
> >
> >
> > LC76d - http://www.w3.org/2002/ws/desc/4/lc-issues/#LC76d
> >
> > #1: At the Melbourne F2F, I observed a simple majority to
> > #explore
> > header proposals that are independent of the Features and
> > Properties framework. This draft is one such mechanism. It
> > accommodates SOAP 1.1, SOAP 1.2 and HTTP Bindings. AFAIK, this
> > draft resolves all the sub issues raised by Jeffrey Schlimmer in
> > LC76d.
> >
> > The number two driving force behind this proposal is the desire
> > for simplicity. I bet the user community will enthusiastically
> > receive a product that simplifies their work and reduces their
> > time to market.
> >
> > This is the first draft. I made it as brief as possible. If
> > there is sufficient interest, I will continue to produce newer
> > versions that will accommodate your requirements and issues. At
> > the least, this proposal will provide sufficient information to
> > the WSDL Working Group to make an informed decision.
> >
> > Comments, suggestions, corrections, thumbs up, thumbs down ..
> > are greatly appreciated.
> >
> > Regards,
> >
> > Asir S Vedamuthu
> > asirv at webmethods dot com
> > http://www.webmethods.com/
> >
> >
> ---------------------------------------------------------------------
> ---
> >
> >
> > First Class Headers - Proposed Resolution for LC76d
> >
> > Lets begin with a simple example. The following example shows
> > the WSDL definition of a simple service providing stock quotes.
> > This service supports a single operation called
> > GetLastTradePrice, which is deployed using the SOAP 1.2 protocol
> > over HTTP. I added 3 statements to turn on WS-Security header
> > support. Again, just 3 statements - import schema statement,
> > header in input message reference component and header in output
> > message reference component.
> >
> > <?xml version="1.0"?>
> > <wsdl:definitions name="StockQuote"
> xmlns:wsdl="http://www.w3.org/@@@@/@@/wsdl"
> > targetNamespace="http://example.com/stockquote"
> > xmlns:tns="http://example.com/stockquote"
> > xmlns:wsoap="http://www.w3.org/@@@@/@@/wsdl/soap"
> >
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-w
> ssecuri ty-secext-1.0.xsd">
> >
> > *<xs:import
> >
> namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-ws
> securit y-secext-1.0.xsd"
> >
> schemaLocation="http://docs.oasis-open.org/wss/2004/01/oasis-200401-w
> ss-wsse curity-secext-1.0.xsd"/>*
> >
> > <wsdl:types>
> > <xs:schema targetNamespace="http://example.com/stockquote"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema">
> > <xs:element name="TradePriceRequest">
> > <xs:complexType>
> > <xs:all>
> > <xs:element name="tickerSymbol" type="xs:string"/>
> > </xs:all>
> > </xs:complexType>
> > </xs:element>
> > <xs:element name="TradePrice">
> > <xs:complexType>
> > <xs:all>
> > <xs:element name="price" type="xs:float"/>
> > </xs:all>
> > </xs:complexType>
> > </xs:element>
> > </xs:schema>
> > </wsdl:types>
> >
> > <wsdl:interface name="StockQuoteInterface">
> > <wsdl:operation name="GetLastTradePrice"
> > pattern="http://www.w3.org/@@@@/@@/wsdl/in-out">
> > <wsdl:input element="tns:GetLastTradePriceInput">
> > *<wsdl:header element="wsse:Security" required="true"
> mustUnderstand="true"/>*
> > </wsdl:input>
> > <wsdl:output element="tns:GetLastTradePriceOutput">
> > *<wsdl:header element="wsse:Security" required="true"
> mustUnderstand="true"/>*
> > </wsdl:output>
> > </wsdl:operation>
> > </wsdl:interface>
> >
> > <wsdl:binding name="StockQuoteSoapBinding"
> interface="tns:StockQuoteInterface"
> > type="http://www.w3.org/@@@@/@@/wsdl/soap"
> > wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
> > <wsdl:operation ref="tns:GetLastTradePrice"
> > wsoap:action="http://example.com/GetLastTradePrice"/>
> > </wsdl:binding>
> >
> > <wsdl:service name="StockQuoteService"
> interface="tns:StockQuoteInterface">
> > <wsdl:documentation>My first service</wsdl:documentation>
> > <wsdl:endpoint name="StockQuoteEndPoint"
> binding="tns:StockQuoteBinding"
> > address="http://example.com/endpoint/stockquote"/>
> > </wsdl:service>
> >
> > </wsdl:definitions>
> >
> > Proposed solution has nine parts:
> >
> >
> > (1) Introduce a NEW Header Component
> >
> >
> > Header Component
> >
> > An Header Component describes an abstract piece of header that
> > is associated with the exchange of messages between the
> > communicating parties. The presence of an Header Component in a
> > WSDL description indicates that the service supports the header
> > and may require a Web Service consumer/client that interacts
> > with the service to use that header. Zero or more such headers
> > may be used.
> >
> >
> > Header Component has 5 properties:
> >
> > * {namespace name} REQUIRED. An xs:anyURI. This URI MUST be
> > absolute as defined by [IETF RFC 2396].
> > * {local name} REQUIRED. An xs:NCName.
> > * {element} REQUIRED. A reference to an XML element
> > declaration
> > in the {element declarations} property of The Definitions
> > Component. This element represents a header.
> > * {required} REQUIRED. An xs:boolean. If the value of this
> > property is true, then the Web Service consumer/client
> > MUST use the Header that is identified by the {element
> > declaration}.
> > * {mustUnderstand} OPTIONAL. An xs:boolean. If the property
> > is
> > true, then the bindings that support expression of
> > mandatory data should mark them as mandatory in an
> > appropriate way.
> >
> >
> > Header Component's XML Representation is,
> >
> > <header element="xs:QName" mustUnderstand="xs:boolean"?
> required="xs:boolean"?>
> > <documentation />?
> > </header>
> >
> >
> > Header Component's mapping is,
> >
> > * {element} = The element declaration from the {element
> > declarations} property of The Definitions Component
> > resolved to by the value of the element attribute
> > information item if present, otherwise empty. It is an
> > error for the element attribute information item to have a
> > value and that value does not resolve to a global element
> > declaration from the {element declarations} property of
> > The Definitions Component.
> > * {namespace name} = actual value of the {element
> > declaration}'s
> > [namespace name] property.
> > * {local name} = actual value of the {element declaration}'s
> > [local name] property.
> > * {mustUnderstand} = actual value of the mustUnderstand
> > attribute information item if present, otherwise absent.
> > * {required} = actual value of the required attribute
> > information item if present, otherwise "false".
> >
> >
> > (2) Hook Header Component into the Interface Fault Component
> >
> >
> > *Add the property {headers}*
> >
> > Add the property {headers} to the Interface Fault Component:
> > {headers} OPTIONAL. A set of Header components.
> >
> >
> > *Modify the XML Representation of Interface Fault
> > Component*
> >
> > <definitions>
> > <interface>
> > <fault
> > name="xs:NCName"
> > element="xs:QName"? >
> > <documentation />?
> > [ *<header />* | <feature /> | <property /> ]*
> > </fault>
> > </interface>
> > </definitions>
> >
> >
> > Modify the Mapping of Interface Fault's XML
> > Representation to Component Properties
> >
> > Addition to Table 2-3:
> >
> > {headers} = The set of Header components corresponding to the
> > header element information items in [children], if any.
> >
> >
> > (3) Hook Header Component into the Message Reference
> > Component
> >
> >
> > Add the property {headers}
> >
> > Add the property {headers} to the Message Reference Component:
> > {headers} OPTIONAL. A set of Header components.
> >
> >
> > Modify the XML Representation of Message Reference
> > Component
> >
> > <definitions>
> > <interface>
> > <operation>
> > <input
> > messageLabel="xs:NCName"?
> > element="union of xs:QName, xs:Token"? >
> > <documentation />?
> > [ *<header />* | <feature /> | <property /> ]*
> > </input>
> > <output
> > messageLabel="xs:NCName"?
> > element="union of xs:QName, xs:Token"? >
> > <documentation />?
> > [ *<header />* | <feature /> | <property /> ]*
> > </output>
> > </operation>
> > </interface>
> > </definitions>
> >
> >
> > Modify the Mapping of Message Reference's XML
> > Representation to Component Properties
> >
> > Addition to Table 2-6:
> >
> > {headers} = The set of Header components corresponding to the
> > header element information items in [children], if any.
> >
> >
> > (4) Syntax Level Default Mechanism to Disable Header
> > Construction
> >
> >
> > Modify the XML Representation of Binding Component
> >
> > <definitions>
> > <binding
> > name="xs:NCName"
> > interface="xs:QName"?
> > type="xs:anyURI"
> > *disableHeadersDefault="xs:boolean"?* >
> > <documentation />?
> > [ <fault /> | <operation /> | <feature /> | <property /> ]*
> > </binding>
> > </definitions>
> >
> > disableHeaderDefault AII is a syntax level convenient mechanism
> > and does not contribute anything to the component model.
> >
> >
> > (5) Mechanism to Disable Header Construction for the Binding
> > Fault Component
> >
> >
> > Add the property {disable headers} to Binding Fault
> > Component
> >
> > {disable headers} OPTIONAL. An xs:boolean. If this property
> > exists and is true, then header construction is turned off.
> > Scope of {disable headers} is limited to the WSDL Header
> > components defined for the Interface Fault Component in {fault
> > reference}. This property does not interact with any other WSDL
> > feature, Bindings, Extensions or Feature and Properties
> > framework.
> >
> >
> > Modify the XML Representation of Binding Fault Component
> >
> > <definitions>
> > <binding>
> > <fault
> > ref="xs:QName" *disableHeaders="xs:boolean"?* >
> > <documentation />?
> > [ <feature /> | <property /> ]*
> > </fault>
> > </binding>
> > </definitions>
> >
> >
> > Modify the Mapping of Binding Fault's XML Representation
> > to Component Properties
> >
> > Addition to Table 2-11:
> >
> > {disable headers} = The actual value of the disableHeaders
> > attribute information item, if present. If not, the actual value
> > of the disableHeadersDefault attribute information item of the
> > parent wsdl:binding element information item, if present. If not
> > the value as defined by the concrete binding, if applicable.
> >
> >
> > (6) Mechanism to Disable Header Construction for the Binding
> > Message Reference Component
> >
> >
> > Add the property {disable headers} to Binding Message
> > Reference Component
> >
> > {disable headers} OPTIONAL. An xs:boolean. If this property
> > exists and is true, then header construction is turned off.
> > Scope of {disable headers} is limited to the WSDL Header
> > components defined for the Interface Operation component being
> > bound by the containing Binding Operation component. This
> > property does not interact with any other WSDL feature,
> > Bindings, Extensions or Feature and Properties framework.
> >
> >
> > Modify the XML Representation of Binding Message
> > Reference Component
> >
> > <definitions>
> > <binding>
> > <operation>
> > <input
> > messageLabel="xs:NCName"? *disableHeaders="xs:boolean"?*
> > >
> > <documentation />?
> > [ <feature /> | <property /> ]*
> > </input>
> > <output
> > messageLabel="xs:NCName"? *disableHeaders="xs:boolean"?*
> > >
> > <documentation />?
> > [ <feature /> | <property /> ]*
> > </output>
> > </operation>
> > </binding>
> > </definitions>
> >
> >
> > Modify the Mapping of Binding Fault's XML Representation
> > to Component Properties
> >
> > Addition to Table 2-11:
> >
> > {disable headers} = The actual value of the disableHeaders
> > attribute information item, if present. If not, the actual value
> > of the disableHeadersDefault attribute information item of the
> > ancestor wsdl:binding element information item, if present. If
> > not the value as defined by the concrete binding, if applicable.
> >
> >
> > (7) Add to SOAP Binding's Default Binding Rules
> >
> >
> > SOAP Header block construction
> >
> > Default value of the Binding element's disableHeadersDefault AII
> > is false. Default value of the Binding Operation Component's
> > {disable headers} property is false.
> >
> > If the {headers} property exists and non empty, and {disable
> > headers} is false, element information item conforming to an
> > Header Component's {element} property in the {headers} property
> > MUST be turned into a SOAP Header block.
> >
> > These elements are serialized according to their schemas, and if
> > the Header Component's {mustUnderstand} property exists with the
> > value "true", that particular SOAP header should be marked as
> > "mustUnderstand='true'" or "mustUnderstand='1'" as per the SOAP
> > specification.
> >
> >
> > (8) Add to HTTP Binding's Default Binding Rules
> >
> >
> > HTTP Header construction
> >
> > Default value of the Binding element's disableHeadersDefault AII
> > is false. Default value of the Binding Operation Component's
> > {disable headers} property is false.
> >
> > If the {headers} property exists and non empty, and {disable
> > headers} is false, element information item conforming to an
> > Header component's {element} property in the {headers} property
> > MUST be turned into HTTP header if possible.
> >
> > Only element information items of type "xs:string" or
> > "xs:anyURI" may be serialized. All complex data types are
> > ignored. Attributes on data elements are ignored.
> >
> > Each such element information item is serialized as follows:
> >
> > The HTTP header name used is the element information item local
> > name. The element information item local name MUST follow the
> > field-name production rules as specified in section 4.2 of [IETF
> > RFC 2616]; if not, the element information item MUST be ignored.
> > If an HTTP header corresponding to the element information item
> > local name is set by a different mechanism other than the HTTP
> > Binding, such as the HTTP stack or another feature, then an
> > error MUST be raised.
> >
> > The HTTP header content is serialized from the corresponding
> > element information item value in UTF-8. If this serialization
> > is NOT possible, then the element information item MUST be
> > ignored.
> >
> >
> > (9) Changes to XML Schema for WSDL 2.0
> >
> > PENDING
> >
>
--
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com
Received on Friday, 28 January 2005 16:51:23 UTC