- From: Amelia A Lewis <alewis@tibco.com>
- Date: Thu, 22 Jan 2004 17:25:13 -0500
- To: ygoland@bea.com
- Cc: Web Services Description <www-ws-desc@w3.org>
Three of these scenarios (1, 2, and 4) are as or more easily implemented using the properties and features functionality. Which apply to interfaces, a point that BEA may have missed (properties and features can be associated with both interfaces, to require or indicate support for a particular functionality, or with bindings, to specify how this information is encoded in the message). In my opinion, the properties and features functionality does a better job than this proposal does, in these three cases, as it encourages better definitions, not just slap-a-header-on. As for use case three, I can't comment. What's a WSDL function? Amy! On Jan 22, 2004, at 4:17 PM, Yaron Goland wrote: > There are four scenarios that motivated my proposal. In each case > static > headers are used whose definition rightfully belongs at the interface, > not > the binding level. I believe that any one of these scenarios, much > less all > four, justifies the inclusion of the header/body style in WSDL 2.0. > > Scenario #1 - Backwards/Forwards Compatible Evolution > > A system deploys a new version of Interface Alpha called Alpha1. > Alpha1 > consists of nothing but backwards compatible changes to Alpha. > Specifically, > Alpha1 adds new optional features to the Alpha operations. Due to the > numerous problems with XML Schema that David Orchard has pointed out > [1] > it's not always possible to put the optional features directly into > the old > message body. Therefore the new optional features are added as a > header to > the original message. When a message arrives at Alpha1 the processor > checks > to see if an extension header is present. If so then it implements the > message with the additional options offered by the extensions. If not, > then > it processes the message as the original interface Alpha would have. > > If a Alpha1 client is talking to a Alpha server then the Alpha1 > client can > send a Alpha1 message with the optional features in the header. The > Alpha > server will ignore the optional header and process the message > normally. > > This is why we can refer to Alpha1 as being both backwards and > forwards > compatible. Alpha clients can send messages to Alpha1 servers and > Alpha1 > clients can send messages to Alpha servers and everyone gets a > reasonable > experience. > > A classic example of this design pattern is byte-range headers in > HTTP. If > someone sends a GET request with a byte-range header to a server that > doesn't support byte-ranges then the client receives back a normal GET > response. If the client sends the GET request with a byte-range header > to a > server that does support byte-ranges then the client gets back a > dedicated > byte-range response. But in all cases everyone gets a reasonable > result. > > To implement this scenario in WSDL 2.0 we need a way to specify > headers > directly in the interface definition so that the various features > added in > the optional extensions can be directly specified. > > Scenario #2 - Inbound Intermediary Communication > > A system deploys interface Beta. Interface Beta handles various types > of > messages but is also able to handle certain kinds of data from > intermediaries. When intermediaries are deployed in the system Beta > runs in > they need to know what kinds of application specific data can be > handled by > the systems downstream. Beta is able to specify this information in > its WSDL > by defining headers it understands. These headers are not > infrastructure > based and do not represent functionality implemented at the WSDL level > so it > is not useful to define them as WSDL functions as the WSDL engine will > obviously not provide support for an application specific header. > > For example, a bank implements a web service Beta that is used to > evaluate > loan requests. The quality of service used to process the loan request > will > depend on how much the bank values the customer. In the absence of any > specific customer 'value' data the loan system will use a default > quality > level. Beta only knows about the customer's credit worthiness, it knows > nothing about how much the bank 'values' the customer. Instead an > intermediary is used that is tied to a database of customer 'value' > information. When any request enters the system the intermediary > examines > the request, determines if it is a customer oriented request, if it is > then > it looks up the customer in its database and slaps a header onto the > request > with customer value information. It is that header that Beta has been > programmed to look for in setting its quality of service. > > The key issues in this scenario are - how did the intermediary know > that > the message being sent to Beta was a customer request, how did it know > how > to pull out the customer information and how did it know that Beta > would be > able to handle the header? > > The answer to the first two questions is actually pretty easy if you > are > familiar with BPEL. BPEL has a concept called message properties that > are > defined using property Alias's. Both properties and property Aliases > are > defined in the WSDL file. All that would be required therefore is to > give > the intermediary the WSDL for Beta and the intermediary can see if the > 'CustomerID' property (for example) is available (via a propertyAlias) > on > any of the messages that Beta receives. If it is then the intermediary > knows > that the message is customer related, can find the CustomerID and > therefore > can do its database lookup. > > The third question, how did the intermediary know Beta would process > the > header, is important because the intermediary doesn't want to do the > work of > looking up the customer value if Beta is just going to ignore it. It is > tempting to just say 'oh well, there was a WSDL function that says > that Beta > supports the header.' But that is an evasion. If that answer is > acceptable > then we should pull out message definitions from WSDL as well since > one can > just as easily say 'I don't need a message definition, I can just > declare a > function'. The reality is that there is a syntax and it needs to be > declared, especially so that it can itself be versioned. E.g. Beta may > support the customer value header with a set of extensions. > > This is where being able to declare headers in the interface is so > important. By allowing Beta to specify its support for the header > explicitly > in its interface the intermediary knows both that Beta supports the > header > and what syntax of the header it supports. > > Scenario #3 - WSDL Function Complementary Declaration > > Let us assume that WSDL functions take off. Even so, there is likely > to be > a fairly long lag between when a function is defined and when it is > widely > supported in WSDL engines. In the case of functions that define > headers this > means it will be necessary to both include the function for WSDL > engines > that support it and explicitly include the header declaration for WSDL > engines that don't support the function but whose applications do > support > the associated functionality. > > For example, imagine a new header that is a signal that specifies > that a > previously sent message has been successfully processed. A WSDL > function is > defined that identifies that an interface supports receiving this type > of > signal. However, it is going to take some time before all WSDL engines > are > updated to provide support for this new function. In the meantime > applications that are build on WSDL engines that don't support the > function > but still want to receive the header will have no choice but to > explicitly > include the header's declaration so that they can see and process the > header. Therefore the header's definition is included in the interface > even > though it is redundant with a function. > > Scenario #4 - WSDL Interface Based Languages (e.g. BPEL) > > BPEL is a new Web Services programming language being standardized in > OASIS > that uses WSDL 1.1 as its 'view' of the world. In BPEL everything is a > portType. It is universally expected within the BPEL TC that when WSDL > 2.0 > is released BPEL will move over to it (which, btw, is why SOAP 1.1 > support > in WSDL 2.0 is so crucial since BPEL programs need to work with > existing web > services). In fact, there is already a tracking item in BPEL to watch > WSDL > 2.0 and to try, as best we can given the requirement to be based on > WSDL > 1.1, to position BPEL for an easy transition over to WSDL 2.0 when it's > ready. > > In BPEL (using WSDL 2.0 terminology), if it isn't in the interface > then it > can't be seen by the programmer. BPEL completely isolates the > programmer > from the binding, which is a great thing as it allows programs to be > truly > portable. This is, after all, the essence of the WSDL vision as I > understand > it and why interfaces and bindings are kept separate. > > However this means that if the programmer needs access to a header, > see my > previous scenarios for several examples of why a programmer would need > this > access, the only way the programmer can get it is if the header is > defined > in the interface. WSDL functions could be used here but only if the > BPEL > engine supports that particular function. As scenario #3 illustrated > there > is often a gap, sometimes an infinitely long one, between when a > function is > introduced and when engines add support for it. In order for a BPEL > programmer to gain access to a header described by a function that > isn't > supported by their engine they must be able to express the header's > definition in their interface definition. > > [1] http://www.pacificspirit.com/Authoring/Compatibility/ > >> -----Original Message----- >> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On >> Behalf Of Sanjiva Weerawarana >> Sent: Thursday, January 22, 2004 9:06 PM >> To: Amelia A Lewis; David Orchard >> Cc: jmarsh@microsoft.com; www-ws-desc@w3.org >> Subject: Re: Header/Body Style Proposal >> >> >> >> I'm +1 to Amy's strong -1 on this - we don't need an abstract header >> mechanism and we went thru many months (nearly 2 years of it) trying >> to simply WSDL and come up to a much better point that WSDL 1.1 was. >> I am not willing to give up an approach that was worked out with >> so much work at this point. What new information exists to re-open >> the abstract header issue? >> >> Sanjiva. >> >> ----- Original Message ----- >> From: "Amelia A Lewis" <alewis@tibco.com> >> To: "David Orchard" <dorchard@bea.com> >> Cc: <jmarsh@microsoft.com>; <www-ws-desc@w3.org> >> Sent: Thursday, January 22, 2004 10:16 AM >> Subject: Re: Header/Body Style Proposal >> >> >>> >>> Strongly -1 to this. >>> >>> And if it's a choice between properties/features and the header/body >>> proposal, I'm strongly -1 on that proposal as well. >>> >>> Amy! >>> On Wed, 21 Jan 2004 14:57:37 -0800 >>> David Orchard <dorchard@bea.com> wrote: >>> >>>> I haven't seen what a generic header-adding property/feature looks >>>> like as it hasn't been published. It seems that this decision is >>>> dependent upon the generic header-adding property/feature being >>>> acceptable to the group. The group has a choice of: a >> proposal on the >>>> table, or a proposal that has been due since November. Aren't we >>>> running out of road here? >>>> >>>> Besides, I'm a bit negative on properties/features >> anyways, given that >>>> I can't figure out how to version them, extend them, use >> them, interop >>>> test them. Seems to me like doing the published >> header/body proposal >>>> and dropping prop/feature solves a concrete (or at least we think >>>> concrete) problem and reduces complexity. >>>> >>>> Cheers, >>>> Dave >>>> >>>>> -----Original Message----- >>>>> From: www-ws-desc-request@w3.org >>>>> [mailto:www-ws-desc-request@w3.org]On Behalf Of Jonathan Marsh >>>>> Sent: Wednesday, January 21, 2004 12:20 PM >>>>> To: ygoland@bea.com; www-ws-desc@w3.org >>>>> Subject: RE: Header/Body Style Proposal >>>>> >>>>> >>>>> >>>>> After only a brief read it appears this would >> constitute a reversal >>>>> in the direction we agreed to pursue at our November >> FTF, which is >>>>> to replace explicit structural support for headers at >> the abstract >>>>> level with a feature/property based mechanism. One of the main >>>>> motivators was >>>>> that static headers (those that can be usefully >> described in WSDL) >>>>> are both rare and not very interesting. >>>>> >>>>> From >>>>> >> http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0062.html: >>>>> >>>>> Headers: >>>>> RESOLVED: Remove @headers attribute. >>>>> RESOLVED: Rename @body to @message. >>>>> RESOLVED: Rename @detail to @message >>>>> ACTION: Glen to write up rationale for removing >> headers (and?) >>>>> proposal >>>>> for a generic header-adding property/feature. >>>>> >>>>> ...which action is still open. I don't expect it to be >>>>> completed by the >>>>> FTF, but we can hope :-). >>>>> >>>>>> -----Original Message----- >>>>>> From: www-ws-desc-request@w3.org >>>>>> [mailto:www-ws-desc-request@w3.org] >>>>> On >>>>>> Behalf Of Yaron Goland >>>>>> Sent: Tuesday, January 20, 2004 4:26 PM >>>>>> To: www-ws-desc@w3.org >>>>>> Subject: Header/Body Style Proposal >>>>>> >>>>>> >>>>>> Arguably the most common protocol design style for application >>>>> protocols >>>>>> is >>>>>> what this letter will refer to as the headerBody style. >>>>> Protocols such >>>>> as >>>>>> HTTP, SOAP, FTP, IMAP, ACAP, SMTP, etc. all use application >>>>>> messages >>>>> that >>>>>> contain a single body and multiple headers. >>>>>> >>>>>> Given the universal popularity of this design style >> this letter >>>>> proposes >>>>>> that WSDL 2.0 add direct support for this style to WSDL 2.0. >>>>>> >>>>>> The headerBody style will use the message attribute >> to identify >>>>>> the message's body. A new XML element, for use as a child of >>>>>> input/output/infault/outfault in interface >> definitions, will be >>>>>> used >>>>> to >>>>>> specify one or more headers. The XML element is defined as >>>>>> headerDef >>>>> and >>>>>> has >>>>>> four attributes: >>>>>> >>>>>> * name - A NCNAME that uniquely identifies a >> header instance >>>>> within a >>>>>> specific input/output/infault/outfault within a >> specific operation >>>>> within >>>>>> a >>>>>> specific interface. Name is optional and is only needed if a >>>>>> binding >>>>> will >>>>>> need to provide additional information about the header. >>>>>> * header - The QNAME of a XML element schema >> definition that >>>>> defines >>>>>> the >>>>>> contents of the header. >>>>>> * max - An int which specifies the maximum number of times >>>>>> that >>>>> header >>>>>> instance can be repeated. Max is optional and its default >>>>> value is 1. >>>>>> * min - An int which specifies the minimum number of times >>>>>> that >>>>> header >>>>>> instance can be repeated. Min is optional and its default >>>>> value is 1. >>>>>> >>>>>> max MUST be greater than or equal to min. >>>>>> >>>>>> The headerDef XML element can be used 0 or more times. >>>>>> >>>>>> For example: >>>>>> >>>>>> <definitions...> >>>>>> <interface...> >>>>>> <operation...> >>>>>> <input message="My:body"> >>>>>> <headerDef header="My:header"/> >>>>>> <headerDef header="My:otherHeader" >> min="3" max="7"/> >>>>>> <headerDef name="optheader" header="My:header" >>>>>> min="0"/> >>>>>> </input> >>>>>> </operation> >>>>>> </interface> >>>>>> </definitions> >>>>>> >>>>>> The headerBody style depends on the binding to define if the >>>>>> header ordering >>>>>> is meaningful. In the previous example the first and third >>>>> headers are >>>>> of >>>>>> the same type. Allowing types to repeat is useful for bindings >>>>>> where >>>>> the >>>>>> order of headers is meaningful. >>>>>> >>>>>> The headerBody style will be useful with both of the >> bindings that >>>>> WSDL >>>>>> 2.0 >>>>>> provides, SOAP and HTTP as both of these protocols >> are based on >>>>>> header/body >>>>>> style messages. If this style is adopted then we can >> remove the >>>>> element >>>>>> attribute from the wsoap:header XML element and replace it >>>>> with a name >>>>>> attribute that would point to the name of the associated >>>>> header in the >>>>>> interface definition. The mustUnderstand and role >> attribute would >>>>> remain >>>>>> the >>>>>> same. >>>>>> >>>>>> The SOAP binding for the headerBody style would >> specify that when >>>>> sending >>>>>> a >>>>>> message the header ordering SHOULD be maintained by the WSDL >>>>> processor. >>>>>> >>>>>> In the case of receiving a message the WSDL processor MUST >>>>> be able to >>>>>> accept >>>>>> SOAP headers in any arbitrary order and MUST be able to >>>>> accept headers >>>>>> that >>>>>> were not defined in the SOAP message's WSDL interface/binding >>>>> definition. >>>>>> >>>>>> SOAP headers MAY be implicitly rather than explicitly >> included in >>>>>> an operation definition as a consequence of a WSDL >> function or a >>>>>> SOAP >>>>> module. >>>>>> In other words, rather than explicitly including a reliable >>>>> messaging >>>>> or >>>>>> security header one can readily imagine such headers being >>>>> added as a >>>>>> consequence of a WSDL function/SOAP module that required >>>>>> reliability >>>>> or >>>>>> security of a certain type. >>>>>> >>>>>> However, in many cases support for a particular function or >>>>> module may >>>>> not >>>>>> be widespread amongst WSDL processors (even if the application >>>>>> layer >>>>> above >>>>>> the WSDL processor is aware of and able to handle the header >>>>>> implied >>>>> by >>>>>> the >>>>>> function/module) and so it may be necessary to include the >>>>> SOAP header >>>>>> definition explicitly, even if it is redundant to a particular >>>>>> function/module, in order to allow for the widest syntactic >>>>> compatibility. >>>>>> >>>>>> The following is an example of a WSDL operation and SOAP >>>>> binding that >>>>> uses >>>>>> the headerBody style. >>>>>> >>>>>> <definitions xmlns:my="http://foo/bar"> >>>>>> <types> >>>>>> <xs:scheme targetName="http://foo/bar"> >>>>>> <xs:element name="headerOrBody" type="xs:string">/ >>>>>> </xs:scheme> >>>>>> </types> >>>>>> <interface name="sample" >>>>>> >> styleDefault="http://www.w3.org/@@@@/@@/wsdl/style/headerBody"> >>>>>> <operation name="sampleOp1" >>>>>> pattern="http://www.w3.org/@@@@/@@/wsdl/in-only"> >>>>>> <input message="my:headerOrBody"> >>>>>> <headerDef name="sampleOp1Header" >>>>> header="my:headerOrBody" >>>>>> min="0"/> >>>>>> </input> >>>>>> </operation> >>>>>> </interface> >>>>>> <binding name="soapSimplebind"> >>>>>> <wsoap:binding >>>>>> protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"/> >>>>>> <operation name="sampleOp1Binding"> >>>>>> <input messageReference="sampleOp1"> >>>>>> <header name="sampleOp1Header" >> mustUnderstand="True"/> >>>>>> </input> >>>>>> </operation> >>>>>> </binding> >>>>>> </definitions> >>>>>> >>>>>> To save space I used the same element for the header >> and the body. >>>>> What's >>>>>> interesting about this example is that while >> sampleOp1Header is >>>>> optional >>>>>> (min="0"), the binding specifies that mustUnderstand = "True". >>>>>> What >>>>> this >>>>>> means is that IF the header is used THEN the mustUnderstand >>>>> attribute >>>>> MUST >>>>>> be put on the header and assigned the value true. >>>>>> >>>>>> Either of the following SOAP 1.2 messages would be >> legal using the >>>>>> previous >>>>>> definition and binding: >>>>>> >>>>>> <env:Envelope >> xmlns:env="http://www.w3.org/2003/05/soap-envelope" >>>>>> xmlns:my="http://foo/bar"> >>>>>> <env:Header> >>>>>> <my:headerOrBody >>>>> mustUnderstand="true">really?</my:headerOrBody> >>>>>> </env:Header> >>>>>> <env:Body> >>>>>> <my:headerOrBody>Uh huh</my:headerOrBody> >>>>>> </env:Body> >>>>>> </env:Envelope> >>>>>> >>>>>> Or >>>>>> >>>>>> <env:Envelope >> xmlns:env="http://www.w3.org/2003/05/soap-envelope" >>>>>> xmlns:my="http://foo/bar"> >>>>>> <env:Body> >>>>>> <my:headerOrBody>Ahhh</my:headerOrBody> >>>>>> </env:Body> >>>>>> </env:Envelope> >>>>>> >>>>>> The HTTP binding would work similarly to SOAP but I'm waiting >>>>>> until >>>>> the >>>>>> HTTP >>>>>> POST/PUT proposal gets a bit firmer before I try to put in >>>>> details. I >>>>>> think >>>>>> the most interesting issue with HTTP header support is how to >>>>> translate >>>>>> the >>>>>> XML element name and body for the WSDL header into a HTTP >>>>> header. One >>>>> can >>>>>> imagine a myriad of different encoding possibilities. >> A minimal >>>>> encoding >>>>>> would require the header body to be a string. But one >> could also >>>>> imagine >>>>>> an >>>>>> encoding that either strips out elements or replaces >> elements with >>>>>> a divider >>>>>> character such as a ";". Perhaps we will need to >> support both and >>>>> specify >>>>>> which one to use on a header by header basis. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yaron >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Amelia A. Lewis >>> Architect, TIBCO/Extensibility, Inc. >>> alewis@tibco.com >> >> >
Received on Thursday, 22 January 2004 17:24:45 UTC