RE: Extension Handling 101: Example 4

Hi Doug,
I am not trying to start a discussion on the usefulness of extensions in general.  There is no point in such a discussion.  I want to focus specifically on this particular use case of the extension mechanism.

Remember where we came from here:

1)      We started out with a mechanism that described a set of characteristics: a mode attribute with a string value ("Pull_Ack").

2)      We saw limitations with this, due to combinatorial issues: ("Pull_Ack_Frog").

3)      We decided to remove the mode attribute and replace it with a "Set of QNames", using the SOAP extension framework as a mechanism for describing that set (<Pull /> <Ack /> <Frog />).

We are now discussing a potential limitation with the decision to use the SOAP extension framework 3) to solve the combinatorial issues described in 2).  Some thoughts:


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.

B.     The limitation exists with or without the presence of the Delivery element, which is orthogonal to this discussion.

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.

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.

--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"<http://www.w3.org/2003/05/soap-envelope>
            xmlns:wsa="http://www.w3.org/2005/08/addressing"<http://www.w3.org/2005/08/addressing>
            xmlns:wse="http://www.w3.org/2009/02/ws-evt"<http://www.w3.org/2009/02/ws-evt>
            xmlns:frq="http://www.refractory.org/timeDilation"<http://www.refractory.org/timeDilation>
            xmlns:dev="http://www.smalldevices.org/evt-ext"<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"<http://www.w3.org/2003/05/soap-envelope>
            xmlns:wsa="http://www.w3.org/2005/08/addressing"<http://www.w3.org/2005/08/addressing>
            xmlns:wse="http://www.w3.org/2009/02/ws-evt"<http://www.w3.org/2009/02/ws-evt>
            xmlns:dev="http://www.smalldevices.org/evt-ext"<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 15:52:50 UTC