Issue 6692 -a, b, c delivery policy for delivery mode extension

Bob, 
 
Here is a proposal on using delivery policies for delivery mode
extension. It is to address 6692-a, b, c, and may has impact to 6692 -d
as well.
 
Many thanks
 
- Wu Chou/Li Li
---------------------------------------------------------------

Proposal to Issue 6692-a, b, c

Version 0.5 Wu Chou, Li Li (7/20/09)


A. Overview


 

As a consensus at F2F meeting, Qname is used to define the delivery mode
extension for the ease of composition. As a replacement of the original
Delivery/@Mode URI, these special Qnames represent literally defined
requirements (non-nested assertions as the replaced URIs cannot be
nested). However, there are some critical issues related to the use of
Qnames for delivery mode extension (see Section C for details). This
draft is a proposal of using delivery policies to decorate the delivery
element of WS-Eventing for delivery mode extensions.

 

B. Proposal - Use Delivery Policies for Delivery Mode Extension

 

B.1 WS-Eventing Standard Policy Assertion: Define assertion <wsp:Push />
in the policy name space wsep for the literal specification/requirement
of Push as defined in the current WS-Eventing spec.

 

B.2 Policy Subject: The policy subject of Delivery policies is the
<wse:Delivery> element. Event source MAY attach the delivery policy or
all its supported delivery policy alternatives to the XML Schema
definition of the <wse:Delivery> element of the event source WSDL as
illustrated below:

 

(01) <xs:element name="Delivery" type="tns:DeliveryType" >

(02)      <wsp:Policy id="DeliveryPolicy ">

(03)                      <wsep:Push wsp:optional="false" />

(04)                      <sp:Ack wsp:optional="true" />

(05)      </wsp:Policy>

(06) </xs:element>

             

 

B.3 Subscribe Messages: Event subscriber attaches the delivery policy to
the Delivery element in the Subscribe message:

 

<wse:Subscribe>

             <wse:Delivery ...>

                          <wse:NotifyTo>wsa:EndpointReferenceType
</wse:NotifyTo>

                          <wsp:Policy>

                                      <wsep:Push wsp:optional="false" />

<sp:Ack wsp:optional="true" />

                          </wsp:Policy>

                          xs:any*

             </wse:Delivery>

</wse:Subscribe>

 

Event source should respond with one policy alternative that it will use
to convey the event notification, 

 

<wse:SubscribeResponse>

             <wse:SubscriptionManager>wsa:EndpointReferenceType
</wse:SubscriptionManager>

             <wse:Delivery>

                          <wsp:Policy>

                                      <wsep:Push />

                          </wsp:Policy>

             </wse:Delivery>

             xs:any*

</wse:SubscribeResponse>

 

In this case, the <wse:SubscribeResponse  /> indicates the optional
<sp:Ack  /> is not used for the event notification.

 

Only compact form of Policy expressions is required for both event
source and the event subscriber. 

 

Event source and the event subscriber MUST support non-nested delivery
policy assertions.

 

If the requested delivery policy cannot be satisfied by the event
source, it MUST fault with wse:DeliveryPolicyUnsupported fault. 

 

B.4 Delivery Policy Publication and Negotiation

The event source MAY attach all supported delivery policy alternatives
to the XML Schema definition of the <wse:Delivery> element of the event
source WSDL for policy publication and negotiation. The event subscriber
should follow the event source supported delivery policies to construct
its event subscription messages. 

 

Notes: The support for non-nested delivery policy assertions can be
implemented through Qname matching without a full featured WS-Policy
implementation. 

 

C. Background

The original extensibility model in WS-E for delivery element consists
of two parts, i.e. one through Delivery/@Mode URI and one through the
xs:any. In WS-Eventing, @Mode is at a higher semantic hierarchy and it
provides the critical context, e.g. Push, Pull, etc., for processing
other extension elements. 

 

For example, it has a default value "Push", the default value can only
be changed by Delivery/@Mode URI, and extension elements in xs:any
should not contradict or overwrite the delivery mode.

 

These constraints are important for interoperability, because the
delivery mode is an anchor point for other extension elements. To
process other elements in xs:any, it needs first to determine the
delivery mode, e.g. Push or Pull, before being able to establish the
semantics of other extensions, e.g. allowed or not allowed, etc.
Determination of Mode in original WS-E is straightforward, since it is
either the default "Push" or the one given by the @Mode URI.

 

When using Qnames for delivery mode extension and lump them with other
extension elements in xs:any, the original extensibility structure of
WS-E is no longer there, and it introduces the following issues:

1.     It is unclear how to determine the semantics of expressions
(combinations) formed by Qnames in order to establish the delivery mode,
and what algorithm should use to parse and determine the delivery mode
from xml block under xs:any. 

 

2.     For example, the expression <Push /><Pull  /> can be interpreted
as: 1) Invalid, since both <Push  /> and <Pull  /> occur; 2) <Pull  />
since <Pull  /> is after <Push  /> and therefore, overwrites <Push  />;
3) two supported delivery options of <Push  /> and <Pull  />, since
there is no mU header; etc. It is unclear how a subscriber should do to
indicate using either <Push  /> or <Pull  />, but not both. This issue
is acute for more complex expressions, e.g. <Push  /><Pull /><Push />?
<Push /><Pull  /><Push /><Ack />? ...

 

3.     It is unclear how the event source should define and specify the
permissible Qname expressions (combinations) so that the subscriber
knows which one to use for a particular event source.

 

4.     It is unclear how an event source should satisfy both optional
and non-optional requirements and how the event sink can know which
particular combination of requirements that the event source apply/use
in its event delivery. For example, when optional delivery Qnames, e.g.
Push, Pull, MC, etc., are used, the event sink has no clue which
particular delivery option that event source uses to send the
notification even receives a positive response. This will cause the
notification to break.

 

5.     How do we constrain the mode changing QNames so that it does not
incur huge overhead for the event source to process it?

 

6.     The composition in the generic SOAP extension is somewhat
different from the QName composition here. In generic SOAP extension,
different extensions are independent in the sense they can fit into a
Chain of Responsibility design pattern (where each extension is
implemented by an interceptor). Whereas no such effect exists  here and
all QNames have to be processed as a whole, and the delivery mode may
need to be determined first in order to process and deliver the
notifications correctly.

 

To address the abovementioned issues, we propose to use delivery
policies for delivery mode extensions in WS-Eventing and it is described
in Section B with details. 

 
------------------------------------------