- From: Amelia A Lewis <alewis@tibco.com>
- Date: Fri, 23 Jan 2004 11:42:17 -0500
- To: ygoland@bea.com
- Cc: "'Web Services Description'" <www-ws-desc@w3.org>
Apparently, there is some misunderstanding. A good source for material on the use of properties and features might be in the archive of the properties and features task force, which discussed these issues extensively before bringing them to the working group as a whole. There are probably good summaries in the general WG discussion as well. As I understand it, examples of usage, as with other examples, is likely to be in the tutorial, rather than in the spec itself. If scenario 3 refers to WSDL features, I am truly at a loss. It is not possible, under the current specification, for a WSDL 2.0 processor to *not* implement general feature support. That is, there is no partial roll out envisioned. Now, perhaps the idea is that each processor will be built monolithically, such that it only recognizes and handles a particular subset of published, well-known features. This is certainly a possible implementation, but for a general-purpose WSDL processor (and associated protocol message processor, such as a SOAP processor), I think it rather unlikely. Far more likely would be an implementation technique that allows the WSDL processor (and protocol message processor) to dynamically load software modules associated with particular features, and delegate processing to those feature-handling modules. If such an implementation is used, then locally-defined features are perfectly feasible. For instance, in versioning, scenario one below, the service adds optional features (at the interface level, or the interface/operation level), provides a standard binding and perhaps plugins for common toolchains, and as the service partners adopt the new modules, they gain access to the newly-defined enhancements. Similarly for BPEL. It would probably be trivially easy to define a "BPEL metadata" feature, containing the properties required for correct BPEL operation. In this case, the feature would likely be marked required, since the information that must be passed with each message can't be lost (all processors in a BPEL interaction must be BPEL-enabled processors, in other words). Again, once the feature is associated with the BPEL handler, the messages can be handed off, and all is serene. And if a non-BPEL processor gets into the process pipeline, it fails because it doesn't have a handler for the BPEL feature (or features, perhaps), which are required. I'm less clear on the intermediary example. Is the proposal that the intermediary exposes a WSDL, and the service itself a slightly different one? Or is there just one, with a transparent intermediary? In either case, assuming that the information is required to surface in a WSDL somewhere, then again, this can be done with a feature. Perhaps, in this case, the service WSDL shows a required feature, and the intermediary advertises a feature-free WSDL to the clients (that is, the intermediary proxies, in order to add information where needed, based on the requirements of the ultimate receiver, as expressed in the WSDL). So the intermediary adds the information, as it reroutes the message. Was this what was in mind? I'm guessing that it must be, since in the header/body as well, the information must presumably be hidden from the partners. In short, although these *particular* scenarios (versioning, choreography, and intermediary message enhancement) were not, as far as I can recall, discussed by the pftf or the working group, they are all well within the design parameters of the properties and features functionality; different use cases that p&f is well suited to fulfill. Some specifics below. On Jan 22, 2004, at 6:29 PM, Yaron Goland wrote: > I apologize if I have misunderstood the WSDL editor's specs but I am > unaware > of any language in those specs which define: > 1) How to specify the schema for an abstract header in an interface > definition as a WSDL feature/property That is a part of the feature definition, surely. Each feature definition describes a set of properties (think SOAP 1.2 module; that's why that appears in the binding-specific feature content model). Those properties have bindings (some of which are probably implicit--"if not specified in a soap binding, use this form of the header"). I'm uncertain of the use of the term "abstract header" here, though. Features and properties attempts to abstract to the level of saying "this information is supplied", and only the binding suggests that it's a header or [something else] > 2) How to bind in the binding an abstract header that was defined > using a > WSDL feature/property in the interface Feature-defined, surely. > Where may I review such a proposal so that I can compare it to the > proposal > I have made? Check the archives of the pftf and the summary presentations made by the pftf to the working group as a whole. The prior Cambridge face to face (last March, I think) was where this functionality was approved. Amy! > > In use case 3, "WSDL function" was a typo, I meant WSDL feature. > > Thanks, > > Yaron > >> -----Original Message----- >> From: Amelia A Lewis [mailto:alewis@tibco.com] >> Sent: Thursday, January 22, 2004 2:25 PM >> To: ygoland@bea.com >> Cc: Web Services Description >> Subject: Re: Header/Body Style Proposal >> >> >> 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 Friday, 23 January 2004 11:46:50 UTC