Re: issue 6401 - 6661 satisfaction by Notification wsdl approach

The main problem with Approach A involves Use Case V 
<http://www.w3.org/2002/ws/ra/wiki/Use_Cases_for_6401-6661>. It was this 
use case that caused me to abandon my support of the "Notification WSDL" 
approach in favor of the "Abstract Event Types" approach in my current 
proposal. As I've illustrated previously, suppose the Event Sink WSDL 
contained the following:

  <wsdl:message name="Ping">
    <wsdl:part name="Ping" element="sc002:Ping"/>
    <wsdl:part name="Fooble" element="sc002:Fooble"/>
  </wsdl:message>

  <wsdl:portType name="sc003Port11">
    <wsdl:operation name="Ping">
      <wsdl:input message="tns:Ping"
                  
wsaw:Action="http://www.wstf.org/docs/scenarios/sc002/Ping"/>
    </wsdl:operation>
  </wsdl:portType>

  <wsdl:binding name="sc003SOAP11Binding" type="tns:sc003Port11">
    <soap:binding style="document" 
transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="Ping">
      <soap:operation soapAction=""/>
      <wsdl:input>
        *<soap:header use="literal" part="Fooble" message="tns:Ping"/>*
        <soap:body use="literal" parts="Ping"/>
      </wsdl:input>
    </wsdl:operation>
  </wsdl:binding>

Notice how the "Fooble" wsdl:part is mapped to a SOAP header in the 
binding. Nothing in the proposal for Approach A tells us how this part 
will be mapped to a Wrapped Notification. Will it be included inside the 
wse:Notify message or as a SOAP header?

This is only one example of why WSDL is ill suited to the task of 
describing Event Types. The use of RPC/Literal bindings is another and, 
given enough time, I'm sure I could think of at least a dozen more. The 
truth is that WSDL, by design, includes both the description of the 
contents of a message as well as the binding of those contents to a 
particular SOAP serialization. The later is inextricably wrapped up in 
our notion of Notification formats. It is impossible to use WSDL to 
describe an Event Sinks interface in a way that does not pre-suppose the 
Notification format that will be used for the Subscription. It is also 
possible to use WSDL to describe interfaces which have *no mapping* to 
any currently defined Notification format.

The "Abstract Event Types" proposal (Proposal B) avoids this problem by 
simply describing, in XML Schema, the format/shape of the Events 
independently from the Notification format. It doesn't have to encompass 
all the flexibility of WSDL because the Event Sinks WSDL is generated 
from the EventDescriptions element using a fairly constrained mapping 
(Doc/Lit only, no multi-part messages, etc.)

Further comments inline . . .

On 7/21/2009 8:40 AM, Chou, Wu (Wu) wrote:
> Bob,
>
> We attach the summary of satisfaction of  issue 6401-6661 ( approach 
> A) with this email to provide information towards a closure of this 
> issue at F2F meeting. 
>
> To provide some background, two approaches are proposed to address 
> issue 6401 -6661:
>
> Approach A (Ours): It is based on the notification wsdls and 
> (optional) ws-policy assertions to link the operations of the event 
> sink with the events of the event source. 
>
> Approach B (Gill): It is based on customized NotificationDescription 
> (ND) xml dialect for subscriber to fetch and generate event sink wsdl.
>
> The main difference between these two approaches is:  approach A is 
> based on wsdl and approach B is based on customized xml dialect ND for 
> wsdl generation. ND is a simplified version of wsdl and anything 
> expressible by ND should be expressible by wsdl.
>
> However, as a non-standard private xml dialect, here are some 
> issues/differences with ND  based approach B comparing to the wsdl 
> based approach A. 
>
> 1. As a non-standard xml dialect, it requires extra processing 
> steps/procedures to transform ND into wsdl before the service can be 
> used and implemented. And this process is private to WS-Eventing and 
> not in any other WS-* standards.
>
The process of "linking" the Event Source WSDL to the Event Sink WSDL 
via WS-Policy assertions (as described by Approach A) is also 
non-standard and unique to WS-Eventing. Approach A is also woefully 
underspecified in a number of areas including (as mentioned above) how 
to map a WSDL-defined description of a Raw Notification to its Wrapped 
equivalent,  how the resolve the out:Outbound policy/links that may 
occur at different levels in the same hierarchy, etc.
>
> 2. It is new knowledge beyond wsdl 1.1/2.0 specifications with a 
> non-standard data type.
>
Ditto for linking components in one WSDL to components in another WSDL.
>
> 3. Most policies are attached to the WSDL subjects (endpoint, message, 
> operation and service) and they will not be available to ND anymore.
>
Approach A does not contain any description of how to interpret/handle 
any policies that may be attached the Event Sink WSDL. For example, 
suppose there is an Event Sink WSDL with 3 effective policy alternatives 
for a given Notification listener. How does the Event Source choose from 
among these alternatives? What if the Event Source is not capable of 
supporting any of these alternatives?
>
> 4. The ND does not support other MEPs (message exchange patterns) in 
> WSDL 1.1 and 2.0 except outbound, whereas wsdl based 
> approach (approach A) can supports     them out-of-the-box.
>
WS-Eventing does not require support for anything other than one-way 
Notifications so this point is irrelevant. The EventDescriptions element 
could easily be extended to support additional Notification MEPs by some 
other spec.
>
> 5. It requires tools and developers to familiarize with a new XML 
> dialect and its ND semantics, whereas in approach A, both WSDL and 
> optionally WS-Policy are well defined and widely used by the Industry 
> and other WS-* standards.
>
Both approaches require developers to familiarize themselves with new 
concepts and both approaches require either new tools or changes to 
existing tools. The EventDescriptions approach relies on the concept of 
transforming one XML document (containing the wsem:EventDescriptions 
element) into another XML document (containing the wsdl:definitions 
element). I assert that most web services developers are familiar with 
the concept of transforming one XML document into another and that the 
transformation described in Appendix F of the EventDesriptions is simple 
and straightforward enough that most people could do it by hand (though 
we probably should provide an XSLT for convenience). Meanwhile the 
concept of linking individual WSDL components to components in other 
WSDLs introduces a level of complexity that is (a) difficult to describe 
in the level of detail necessary to prevent interoperability problems 
(the current proposal certainly does not do this) and (b) difficult for 
people to understand. For example, the fact that you can use 
out:Outbound to create a single wsdl:port that supports multiple 
bindings seems to contradict the normal WSDL semantics of a 1-to-1 
relationship between wsdl:port and wsdl:binding.
>
> Many thanks,
>
> - Wu Chou/Li Li
>