- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Wed, 8 Jul 2009 13:57:11 -0400
- To: Doug Davis <dug@us.ibm.com>
- Cc: Geoff Bullen <Geoff.Bullen@microsoft.com>, Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, "public-ws-resource-access-request@w3.org" <public-ws-resource-access-request@w3.org>
- Message-ID: <OF56A5025E.B79B40FA-ON852575ED.006047D3-852575ED.00629EF6@us.ibm.com>
+1 When did Microsoft start having issues with the SOAP processing model? Would it help at all to dig up XMLP WG email threads in which MSFT employees made the case as to why order of the SOAP header blocks was not important? Maybe we should also go back and rehash the WS-Security specification because, all of a sudden, Microsoft cares deeply about the order of processing of security tokens, too? Maybe it should suffice to reiterate what is said in the SOAP1.2 specification in section 2.6 [1]: The processing of one or more SOAP header blocks MAY control or determine the order of processing for other SOAP header blocks and/or the SOAP body. For example, one could create a SOAP header block to force processing of other SOAP header blocks in lexical order. In the absence of such a controlling SOAP header block, the order of header and body processing is at the discretion of the SOAP node. Header blocks MAY be processed in arbitrary order. Header block processing MAY precede, MAY be interleaved with, or MAY follow processing of the SOAP body. For example, processing of a "begin transaction" header block would typically precede body processing, a "logging" function might run concurrently with body processing and a "commit transaction" header block might be honored following completion of all other work. These words were not introduced by accident. [1] http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#procsoapmsgs Cheers, Christopher Ferris IBM Distinguished Engineer, CTO Industry Standards IBM Software Group, Standards Strategy email: chrisfer@us.ibm.com blog: http://www.ibm.com/developerworks/blogs/page/chrisferris phone: +1 508 234 2986 public-ws-resource-access-request@w3.org wrote on 07/08/2009 12:15:42 PM: > From: > > Doug Davis/Raleigh/IBM@IBMUS > > To: > > Geoff Bullen <Geoff.Bullen@microsoft.com> > > Cc: > > Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource- > access@w3.org" <public-ws-resource-access@w3.org>, "public-ws- > resource-access-request@w3.org" <public-ws-resource-access-request@w3.org> > > Date: > > 07/08/2009 12:16 PM > > Subject: > > RE: Extension Handling 101: Example 4 > > Sent by: > > public-ws-resource-access-request@w3.org > > > Geoff wrote: > ... > > A. The limitation we are discussing concerns the processing > > order of the “Set of QNames” (extension elements) we decided to use > > in 3). It does seem to be a legitimate limitation in interoperability. > > Please provide an example where 'order' matters and is something that > WS-E needs to worry about instead of the extension itself. > > > B. The limitation exists with or without the presence of the > > Delivery element, which is orthogonal to this discussion. > > No its very important since having a new extension processing mechanism > just for one extension point in WS-E introduces an inconsistency that > will be hard to explain. > > > C. This issue was raised by Wu during the con call on Tuesday, > > but I think was confused with the issue around the definition of a > > Push QName – they are separate issues. > > D. Wu suggested we should consider a different solution to 2) > > based around the Policy framework, rather than the extension > > framework proposed in 3). > > E. Both the current solution 3) and Wu’s proposed policy-based > > solution have pros and cons. > > F. In order to move forwards here, we need to discuss the > > limitation in solution 3) openly and in an unbiased way in order to > > decide how important the limitation is and if it causes us to in any > > way reconsider the decision taken in 3) above. > > you first need to show this limitation in a real concrete way because > I just don't see it. Any limitiation you claim to exist here would > apply to all extensions. Trying to say that Delivery is 'special' > requires some proof because any scenario you come up with will probably > just as easily apply to any extension point. > > > One observation I would make is this: > > To date, the extension framework has been successful in providing a > > mechanism for adding composable functionality where that > > functionality is largely independent in nature. Each extension > > affects the SOAP message (reliable, secure, …) but extensions do not > > tend to affect each other. In this case extensions (Pull, Ack, > > Pause, …) can have an effect on each other (Ack may only work with > > Push, not Pull). This may be the first time that such side effects > > have to be taken into account. > > Sorry - but I don't buy the premise that SOAP itself is broken or > that no two extensions have ever been written to interact with each > other. E.g. WSA (an extension) interacts with Tx, RM just fine. > MC (ie. pull) works just fine with WSA, RM... > WS-Eventing is just not that special :-) What's different here > is that people keep trying to make it special. Why? I dunno. > > > --Geoff > > > > > > From: Doug Davis [mailto:dug@us.ibm.com] > > Sent: Wednesday, July 08, 2009 5:18 AM > > To: Geoff Bullen > > Cc: Gilbert Pilz; public-ws-resource-access@w3.org; public-ws- > > resource-access-request@w3.org > > Subject: RE: Extension Handling 101: Example 4 > > > > > > Geoff, > > > > I'd ask this question.... will this: > > <Subscribe> > > <wse:Delivery>...</wse:Delivery> > > <X/> > > <Y/> > > </Subscribe> > > > > always produce the same results as this: > > <Subscribe> > > <wse:Delivery>...</wse:Delivery> > > <Y/> > > <X/> > > </Subscribe> > > > > Or will: > > <Subscribe x="foo" y="bar"> > > <wse:Delivery>...</wse:Delivery> > > </Subscribe> > > > > always produce the same result as this: > > <Subscribe y="bar" x="foo"> > > <wse:Delivery>...</wse:Delivery> > > </Subscribe> > > > > The question you're asking isn't Delivery specific and applies to > > all WS* specs and all extension points (including soap headers). > > > > I'm having a hard time understanding why we're trying to add special > > semantics and rules for this one extension point when I can't think > > of any other WS* spec that has ever had a need to do so. Why would > > WS-Eventing need to change the normal extension processing model? > > > > If keeping "Delivery" around is causing so much trouble (its just a > > wrapper for an xs:any) then perhaps we made the wrong choice by > > keeping it. Clearly its history and implied "specialness" is > > causing some people to forget everything we'd done in the past w.r. > > t. extensions. > > > > thanks > > -Doug > > ______________________________________________________ > > STSM | Standards Architect | IBM Software Group > > (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com > > The more I'm around some people, the more I like my dog. > > > > > Geoff Bullen <Geoff.Bullen@microsoft.com> > > Sent by: public-ws-resource-access-request@w3.org > > 07/07/2009 11:46 PM > > > > To > > > > Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource- > > access@w3.org" <public-ws-resource-access@w3.org> > > > > cc > > > > Subject > > > > RE: Extension Handling 101: Example 4 > > > > > > > > > > > > > > Hi Gil, > > Thanks for these examples. Can I share one with you please? > > > > Let’s look at order of processing. > > Will this: > > a) > > <wse:Delivery> > > <X /> > > <Y /> > > </wse:Delivery> > > Always be guaranteed to produce the same results (subscription or > fault) as: > > b) > > <wse:Delivery> > > <Y /> > > <X /> > > </wse:Delivery> > > > > Where in the spec can I see this guarantee defined? > > Note a) and b) could be compatible or incompatible extensions. > > > > What about between implementations? > > Is a) guaranteed to produce the same subscription or fault across > > implementations of Eventing? > > > > Note that in the original spec using the mode attribute to define a > > new mode MODE_X_Y would allow such a guarantee of interoperability. > > > > Thanks, > > Geoff > > > > From: public-ws-resource-access-request@w3.org [mailto:public-ws- > > resource-access-request@w3.org] On Behalf Of Gilbert Pilz > > Sent: Tuesday, July 07, 2009 6:25 PM > > To: public-ws-resource-access@w3.org > > Subject: Extension Handling 101: Example 4 > > > > OK, here it is. The extended Subscribe request that our mother > > always warned us about, Example 4: > > <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" > > xmlns:wsa="http://www.w3.org/2005/08/addressing" > > xmlns:wse="http://www.w3.org/2009/02/ws-evt" > > xmlns:frq="http://www.refractory.org/timeDilation" > > xmlns:dev="http://www.smalldevices.org/evt-ext"> > > <s:Header> > > <wsa:Action>http://www.w3.org/2009/02/ws-evt/Subscribe </wsa:Action> > > . . . > > </s:Header> > > <s:Body> > > <wse:Subscribe> > > <wse:Delivery> > > <wse:NotifyTo> > > <wsa:Address> http://www.example.com/MyEventSink/OnStormWarning > > </wsa:Address> > > </wse:NotifyTo> > > <frq:Dilate> > > <frq:TimeScale useRelative="true"> > > <frq:PhaseShift>-73.243</frq:PhaseShift> > > </frq> > > <frq:Margin>2009-07-07T15:27:26-0700</frq:Margin> > > </frq:Dilate> > > <dev:Pauseable> > > <dev:Duration>P3H</dev:Duration> > > </dev:Pauseable> > > </wse:Delivery> > > </wse:Subscribe> > > </s:Body> > > </s:Envelope> > > It bends the mind! How can we possibly figure out how frq:Dilate and > > dev:Pauseable are supposed to interact? Will the time dilation > > shorten or lengthen the pause duration and, if so, by how much? But > > wait! We don't support frq:Dilate. Using the "power of ignorability" > > granted to us by the WS-Eventing spec, we can (nay SHOULD!) act as > > if frq:Dilate element wasn't even there! In which case we can create > > a pauseable Subscription (because we support that) and respond as we > > did in Example 3: > > <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" > > xmlns:wsa="http://www.w3.org/2005/08/addressing" > > xmlns:wse="http://www.w3.org/2009/02/ws-evt" > > xmlns:dev="http://www.smalldevices.org/evt-ext"> > > <s:Header> > > <wsa:Action>http://www.w3.org/2009/02/ws-evt > > /SubscribeResponse</wsa:Action> > > . . . > > </s:Header> > > <s:Body> > > <wse:SubscribeResponse> > > <wse:SubscriptionManager> > > <wsa:Address> > > http://www.example.org/oceanwatch/SubscriptionManager > > </wsa:Address> > > </wse:SubscriptionManager> > > <dev:Pauseable> > > <dev:Duration>P1H</dev:Duration> > > </dev:Pauseable> > > </wse:SubscribeResponse> > > </s:Body> > > </s:Envelope> > > And so concludes Example 4. > > > > - gp
Received on Wednesday, 8 July 2009 17:58:02 UTC