Re: [Issue 6425] redux

Gil,
  I'm ok with #1 because in #2 you say the extra header came from an EPR. 
However, in #3 you when you talk about how the <sc009:OrderID> 
ref-param/header ties the lifetimes of two objects (the PO and the 
Subscription) I get worried.  This is semantics that are not defined by 
anything.  Yes the Subscribe() is sent to the PO but the secondary object 
created (the subscription) may or may not be tied to the PO.  If the 
semantics of the PO subscription service are defined to say they are 
linked then that's ok - but without this explicit statement I don't think 
people can assume anything.  However, the usecase that Wu is talking about 
is slightly different that this.  I believe in his case there is only one 
subscription manager/source - in your case each PO is its own Subscription 
manager/source.  Another difference is that I believe Wu wants the client 
to populate the ref-params with a SessionID while you (correctly) treat 
the ref-params as opaque entities. 
  If we didn't  have the history/reasoning behind why this additional 
sentence is being added it probably wouldn't be that big of a concern to 
me - but because its being used as a precursor for doing things that 
violate WS-Addressing I don't think we should do it.  There shouldn't even 
be a discussion about this.  People will have references to event sources 
(EPR) and they'll send Subscribes to those EPRs.  If they want to subset 
the event stream coming form that event source then they'll use a filter. 
WS-Eventing already says all of this - why do we need to say more? Why 
would we even talk about when to use ref-params vs filters when any 
additional "advice" that we put into WS-Eventing related to this will only 
put the idea of doing 'bad' things into people's heads - ie. implicitly 
encourage it.

 As for #4 and the * - sure.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com



Gilbert Pilz <gilbert.pilz@oracle.com> 
Sent by: public-ws-resource-access-request@w3.org
02/18/2009 07:25 PM

To
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
cc

Subject
[Issue 6425] redux






Let me try to back-up a bit on this issue. I see it as being composed of 
the following points:

1.) We need to make clear to Subscribers / Event Sinks that the Event 
Source MAY take into account additional information that appears in the 
SOAP Headers of the request that carries the wse:Subscribe message when it 
creates a subscription. This information may affect the contents, 
structure, and delivery of the Notifications in that subscription. For 
example, if the Subscriber sends this:
<s12:Envelope . . .>
  <s12:Header>
    <wsa:Action>http://www.w3c.org/2009/02/Subscribe</wsa:Action>
 <wsa:MessageID>uuid:d7c5726b-de29-4313-b4d4-b3425b200839</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://www.example.com/MyEventSink</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To>http://webservice.bea.com/PO/EventSource</wsa:To>
    <sc009:OrderID>PJ-73f250</sc009:OrderID>
  </s12:Header>
  <s12:Body>
    <wse:Subscribe>
      <wse:Delivery>
        <wse:NotifyTo>
          <wsa:Address>
            http://www.example.com/MyEventSink/POUpdates
          </wsa:Address>
        </wse:NotifyTo>
      </wse:Delivery>
    </wse:Subscribe>
  </s12:Body>
</s12:Envelope>

it may result in the Event Sink receiving different information than if 
the Subscriber had sent this:
<s12:Envelope . . .>
  <s12:Header>
    <wsa:Action>http://www.w3c.org/2009/02/Subscribe</wsa:Action>
 <wsa:MessageID>uuid:d7c5726b-de29-4313-b4d4-b3425b200839</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://www.example.com/MyEventSink</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To>http://webservice.bea.com/PO/EventSource</wsa:To>
    <sc009:OrderID>DR-2a673c</sc009:OrderID>
  </s12:Header>
  <s12:Body>
    <wse:Subscribe>
      <wse:Delivery>
        <wse:NotifyTo>
          <wsa:Address>
            http://www.example.com/MyEventSink/POUPdates
          </wsa:Address>
        </wse:NotifyTo>
      </wse:Delivery>
    </wse:Subscribe>
  </s12:Body>
</s12:Envelope>
2.) When Event Sources do this sort of thing they SHOULD include this 
"additional information" in the form of EPRs. For example, a purchase 
order response type might be defined as follows:

<xs:complexType name="OrderRespType">
  <xs:sequence>
    <!-- Info about the newly created purchase order. -->
    <xs:element name="OrderInfo" type="tns:OrderInfoType"/>

    <!-- EPR to which the consumer may send a WS-Eventing Subcribe message 
in order to
         receive notifications about the ongoing status of the newly 
created purchase order.
      -->
    <xs:element name="SubscriptionEPR" type="wsa:EndpointReferenceType"/>

    <xs:any namespace="##other" processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>

The semantic of the purchase order system are such that, when it creates 
an order with an ID of "DR-2a673c" it will mint a SubscriptionEPR like so:

<sc009:SubscriptionEPR>
  <wsa:Address>http://webservice.bea.com/PO/EventSource</wsa:Address>
  <wsa:ReferenceParameters>
    <sc009:OrderID>DR-2a673c</sc009:OrderID>
  </wsa:ReferenceParameters>
</scc09:SubscriptionEPR>

3.) We should advise developers of Event Sources that using additional 
elements in the headers is not meant to replace the filter facility built 
into the WS-Eventing protocol. In this case, the semantics of including 
the OrderID in the header of a Subscribe message are "I want to receive 
Notifications about this purchase order until such time as the process has 
completed, at which point I want the subscription to be terminated." The 
reason we are using a header instead of defining a filter is that we want 
to tie the lifetime of the subscription to the lifetime of the purchase 
order; as far as I know there is no way of specifying this using the 
current filter semantics. The point is: if what you are doing can be done 
using a filter, you should use a filter.

4.) Implementations should note that (2) contradicts the Architecture of 
the World Wide Web, Volume One [1] by using reference properties to 
identify resources (in our example case the subscription service for a 
PO). This use of reference properties to identify resources may lead to 
situations in which your resources are not readily accessible via HTTP.*

If people agree on these points, I'll write up a concrete proposal that 
embodies them.

- gp

[1] http://www.w3.org/TR/webarch/

* Would should just sprinkle statements like this throughout the WS-RA 
specs everywhere we talk about the use of reference parameters.