View source

From Web Services Resource Access Working Group Wiki

You do not have permission to do that, for the following reasons:
The action you have requested is limited to users in the group user.
You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.
You can view and copy the source of this page:
== List of known Delivery Modes ==
Below is the list of known Delivery Modes.  Any solution we pick should
keep in mind this list so we make sure we continue to allow for those
delivery mechanism.  This list will also allow us to think about what each of these might look like under each proposal.

* Push
* Pull
* UseProxy
* PushWithAck
* Batched


Comments:
* Batched really isn't a Delivery mechanism since its orthogonal to how notifications are sent.  For example, it could apply to both Push, Pull, PushWithAck or Proxy.  So it seems as though Batched should really be a Format rather than a Delivery Mode.
* PushWithAck is an interesting one.  If this is meant to be a transport-level acknowledgment then there is clear overlap with WS-RM. If this is meant to be more of an application level "receipt" type of response (something that the pub/sub engine would need to know about) then this could be needed regardless of how Notifications are sent. Meaning, like Batched, it could apply in all Delivery Modes (push, pull...).  In which case, this should really be a property of the Subscription rather than a Delivery flag.  Both views appear to be valid so perhaps the WG needs to decide how each of these should be expressed within a Subscribe no matter which proposal is adopted - perhaps part of a Primer.

== Proposal A. remove @Mode, leave wse:Delivery with attribute and element extension ==
The XML Schema for wse:Delivery would be:

<pre>
<xs:complexType name="DeliveryType" mixed="true">
  <xs:sequence>
    <xs:element ref="wse:NotifyTo" minOccurs="0" maxOccurs="1" />
    <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded" />
  </xs:sequence>
  <xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>
</pre>

A hypothetical extended Subscribe request might look like the following. The extension indicates the Subscribers desire to engage a hypothetical pause/resume feature with the additional constraint that undelivered Notifications for this subscription be persisted when the subscription is paused.

<pre>
<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:wso="http://www.extender.org/spec/that/extends/wse">
  <s:Header>
    <wsa:Action>http://www.w3.org/2009/02/ws-evt/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://www.example.org/oceanwatch/EventSource</wsa:To>
    <wso:UsePausable mustUnderstand="1"/>
  </s:Header>
  <s:Body>
    <wse:Subscribe>
      <wse:Delivery>
        <wse:NotifyTo>
          <wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address>
        </wse:NotifyTo>
        <wso:Pausable wso:PersistWhenPaused="true"/>
      </wse:Delivery>
    </wse:Subscribe>
  </s:Body>
</s:Envelope>
</pre>

Note that the use of the wso:UsePausable SOAP header element is optional. Its purpose is to cause the Subscribe operation to fail in cases where the Event Source does not understand the wsa:Pausable extension. There are cases in which the Subscriber is willing to accept the creation of a subscription without the extension. In these cases the wso:UsePausable SOAP header element would not appear in the message.

== Proposal B. remove wse:Delivery element and all it's sub-elements ==
The wse:NotifyTo element is preserved by moving it under the wse:Subscribe element. The XML Schema for the wse:Subscribe element would be:

<pre>
<xs:element name="Subscribe">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="NotifyTo" type="wse:EndpointReferenceType"/>
      <xs:element name="EndTo" type="wsa:EndpointReferenceType" minOccurs="0"/>
      <xs:element name="Format" type="tns:FormatType"/>
      <xs:element name="Expires" type="tns:ExpirationType" minOccurs="0"/>
      <xs:element name="Filter" type="tns:FilterType" minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" />
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax" />
  </xs:complexType>
</xs:element>
</pre>

An extended Subscribe request might look like the following:

<pre>
<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:wso="http://www.extender.org/spec/that/extends/wse">
  <s:Header>
    <wsa:Action>http://www.w3.org/2009/02/ws-evt/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://www.example.org/oceanwatch/EventSource</wsa:To>
    <wso:UsePausable mustUnderstand="1"/>
  </s:Header>
  <s:Body>
    <wse:Subscribe>
      <wse:NotifyTo>
        <wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address>
      </wse:NotifyTo>
      <wso:Pausable wso:PersistWhenPaused="true"/>
    </wse:Subscribe>
  </s:Body>
</s:Envelope>
</pre>

Note that the use of the wso:UsePausable SOAP header element is optional. Its purpose is to cause the Subscribe operation to fail in cases where the Event Source does not understand the wsa:Pausable extension. There are cases in which the Subscriber is willing to accept the creation of a subscription without the extension. In these cases the wso:UsePausable SOAP header element would not appear in the message.


People asked for an example of what it would look like to use WS-Policy within the Subscribe to turn on some QoS.  Below are two examples:

1. This first one uses a PolicyReference to refer to a predefined policy assertion:
<pre>
<s:Envelope ...>
 <s:Header>
   <wsa:Action>http://www.w3.org/2009/02/ws-evt/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://www.example.org/oceanwatch/EventSource</wsa:To>
   <wsmex:ExamineEPRPolicy mustUnderstand="true"/>
 </s:Header>
 <s:Body>
   <wse:Subscribe>
     <wse:NotifyTo>
       <wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address> 
       <wsp:PolicyReference URI="http://example.com/Policies/RM"/>
     </wse:NotifyTo>
   </wse:Subscribe>
 </s:Body>
</s:Envelope>
</pre>

The wsmex:ExamineEPRPolicy header is needed to ensure that the policy assertion isn't ignored. Its worth noting that if the Subscriber would be willing to live without RM being turned on (meaning they don't want the Subscribe to fail if the Source can't support RM) they could leave the mex:ExamineEPRPolicy header off, or remove the mU=true attribute.  This gives them the freedom to indicate optional extensions.

2 - This next example doesn't use a well-known policy reference, so it needs to put the policy assertions directly in the EPR:
<pre>
<s:Envelope ...>
 <s:Header>
   <wsa:Action>http://www.w3.org/2009/02/ws-evt/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://www.example.org/oceanwatch/EventSource</wsa:To>
   <wsmex:ExamineEPRPolicy mustUnderstand="true"/>
 </s:Header>
 <s:Body>
   <wse:Subscribe>
     <wse:NotifyTo>
       <wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address> 
       <wsp:Policy> 
         <wsrmp:RMAssertion/> 
       </wsp:Policy>
     </wse:NotifyTo>
   </wse:Subscribe>
 </s:Body>
</s:Envelope>
</pre>

This is has the same net effect as the previous one.

== Proposal C. close with no action ==
Preserve the schema for wse:Delivery and wse:Subscribe as they exist today. An extended Subscribe request might look like the following:

<pre>
<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:wso="http://www.extender.org/spec/that/extends/wse">
  <s:Header>
    <wsa:Action>http://www.w3.org/2009/02/ws-evt/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://www.example.org/oceanwatch/EventSource</wsa:To>
  </s:Header>
  <s:Body>
    <wse:Subscribe>
      <wse:Delivery wse:Mode="http://www.extender.org/PauseResumeMode">
        <wse:NotifyTo>
          <wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address>
        </wse:NotifyTo>
        <wso:PersistWhenPaused>true</wso:PersistWhenPaused>
      </wse:Delivery>
    </wse:Subscribe>
  </s:Body>
</s:Envelope>
</pre>

This message indicates events will be pushed every 300 seconds:
<pre>
<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:wso="http://www.extender.org/spec/that/extends/wse">
  <s:Header>
    <wsa:Action>http://www.w3.org/2009/02/ws-evt/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://www.example.org/oceanwatch/EventSource</wsa:To>
  </s:Header>
  <s:Body>
    <wse:Subscribe>
      <wse:Delivery wse:Mode="http://www.extender.org/IntervalPush">
        <wse:NotifyTo>
          <wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address>
        </wse:NotifyTo>
        <wso:Interval>300</wso:Interval>
      </wse:Delivery>
    </wse:Subscribe>
  </s:Body>
</s:Envelope>
</pre>

This message indicates events will be pulled every 300 seconds: 
<pre>
<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:wso="http://www.extender.org/spec/that/extends/wse">
  <s:Header>
    <wsa:Action>http://www.w3.org/2009/02/ws-evt/Subscribe</wsa:Action>
    <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To>
  </s:Header>
  <s:Body>
    <wse:Subscribe>
      <wse:Delivery wse:Mode="http://www.extender.org/IntervalPull">
        	<wso:Interval>300</wso:Interval>
      </wse:Delivery>
    </wse:Subscribe>
  </s:Body>
</s:Envelope>
</pre>

== Proposal D. Add new mode ==
Preserve the schema for wse:Delivery and wse:Subscribe as they exist today, but add a new, optional mode that would allow the use of the alternatives suggested in proposals A and B.  Below is the example used in Proposal A implemented using the new mode value.  The examples given in proposal B could similarly be implemented.  Simple examples could continue to utilize the existing mode infrastructure, but, by using the new mode, more advanced examples could be handled as well.  Please note that the delivery element itself is very important in that it clearly separates those features and extensions that apply to the lifecycle of the notifications from those that apply to the lifecycle of the subscriptions.

<pre>
<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:wso="http://www.extender.org/spec/that/extends/wse">
  <s:Header>
    <wsa:Action>http://www.w3.org/2009/02/ws-evt/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://www.example.org/oceanwatch/EventSource</wsa:To>
    <wso:UsePausable mustUnderstand="1"/>
  </s:Header>
  <s:Body>
    <wse:Subscribe>
      <wse:Delivery wse:Mode="http://www.w3.org/2009/02/ws-evt/DeliveryModes/None">
        <wse:NotifyTo>
          <wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address>
        </wse:NotifyTo>
        <wso:Pausable wso:PersistWhenPaused="true"/>
      </wse:Delivery>
    </wse:Subscribe>
  </s:Body>
</s:Envelope>
</pre>
Return to Proposals for 6692.
Retrieved from "http://www.w3.org/2002/ws/ra/wiki/Proposals_for_6692"
View source

From Web Services Resource Access Working Group Wiki

Views

Personal tools

Navigation

Search

Toolbox
