Re: issue 6401 - 6661 satisfaction by Notification wsdl approach

On 7/27/2009 5:50 AM, Chou, Wu (Wu) wrote:
> Your example is about multipart notification message with one part 
> goes to the SOAP header. As discussed in the WS-RA WG meeting, the use 
> of multipart notification message is not encouraged and no one showed 
> interest to implement such support. Therefore, this main problem you 
> have on Notification WSDL (approach A), e.g.  "It was this use case 
> that caused me to abandon my support of the "Notification WSDL" 
> approach" should be a separate issue and should not be a factor for 
> approach A.
<gp>It's not a matter of what is "encouraged" and what is "not 
encouraged"; WSDL allows multi-part messages, period. Your proposal 
either has to describe how these are handled or you need to disallow 
their use in Notification WSDLs. If you don't do either of these things 
you create an interoperability issue. The same goes for the use of 
RPC/lit bindings, etc.</gp>
> One extra comment is: Notification WSDL for the event sink 
> is specified by the event source. Therefore, the event source knows 
> how to support, e.g. binding, etc., because Notification WSDL is what 
> the event source wants the event sink to do based on its (event 
> source) own capability. It is not the case as in your example that an 
> event sink has the Event Sink WSDL which requires  the event source to 
> match and support.
<gp>I agree that the Event Source is "in the driver's seat" on this, but 
you are missing the point. If I, as a Subscriber/Event Sink, cannot 
determine *exactly* what the Notifications will look like based on (a) 
the Notification WSDL that is supplied to me and (b) the Format URI that 
I select at Subscribe time, then we have an interoperability problem. If 
the Notification WSDL contains multi-part messages (or RPC/lit bindings, 
or . . .) and I, as the Subscriber/Event Sink, choose the 
"http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Wrap", I have no idea 
what the contents of the Notification will look like.</gp>
>   
>  
> Other comments *(BLUE) *are in line which is after yours to my email.
>  
> Thanks,
>  
> - Wu Chou.
>
> ------------------------------------------------------------------------
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Tuesday, July 21, 2009 3:11 PM
> *To:* Chou, Wu (Wu)
> *Cc:* Bob Freund; public-ws-resource-access@w3.org
> *Subject:* 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.
>>
>  (Gill: 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. )
> ** 
> *(Wu: Using policy to decorate the WSDL and policy assertions to 
> specify requirements are all standard practice specified by WS-Policy. 
> Policy assertions are specific to the particular standard or WSDLs, 
> and this practice is also standard as illustrated in other WS-* 
> standards, e.g. WS-Security, Policy, etc. In addition, how to map a 
> raw notification to its wrapped equivalent is defined in this 
> approach, 
> e.g. http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/att-0028/Web_Services_Eventing__WS-Eventing_.htm )
> *
<gp>I'm not saying that decorating WSDL with policy assertions is new, 
I'm saying that, to date, no one has linked WSDLs together the way you 
propose. That, in itself, is not necessarily a negative thing, but you 
can't criticize my proposal for doing "non-standard" things when your 
proposal does things that are equally "non-standard" and, in my opinion, 
for more complicated conceptually (e.g. "the box" of binding-interface 
linkages discussed at the last F2F).

W/regards to mapping a WSDL-defined raw notification to it's wrapped 
equivalent; *where in the proposal is this covered?* I have looked and I 
can't find it.</gp>
>>
>> 2. It is new knowledge beyond wsdl 1.1/2.0 specifications with a 
>> non-standard data type.
>>
>  (Gill: Ditto for linking components in one WSDL to components in 
> another WSDL. )
>  
> *(Wu: Using policy and policy assertions to decorate WSDL are not new 
> knowledge as explained above, and it fits without change to existing 
> web service infrastructures, e.g. UDDI, etc. Moreover, the use 
> of policy in approach A is Optional, etc. as described 
> in http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/att-0048/6401_6661_satisfication_0720_wu.pdf ) 
> *
>>
>> 3. Most policies are attached to the WSDL subjects (endpoint, 
>> message, operation and service) and they will not be available to ND 
>> anymore.
>>
>  (Gill: 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? )
>  
> *(Wu: In approach A, Notification WSDL for the event sink is specified 
> by the event source, NOT by the event sink. The event sink needs to 
> follow the Notification WSDL and related event source policies to 
> receive event notification from the event source. **It is not the case 
> that an event sink has a**n* * Event 
> Sink WSDL/policy * *which* * require**s* * the event source to match 
> and support.  Therefore, event sink policy is not a concern here. How 
> to match the event sink capability/policy with the capability/policy 
> of the event source is addressed in a separate contribution to 6692 
> -a, b, c, and d through policy negotiation, i.e. 
> **http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0050.html** )*
<gp>Again, true but irrelevant. You claim that your proposal is superior 
because it allows for the use of policy. I presumed you must have meant 
"policy in the Notification WSDL" because nothing in my proposal has 
anything to do with the Event Sink WSDL. My point is that your proposal 
doesn't really support the use of policy in the Notification WSDL 
because it (a) doesn't cover how to handle the case of multiple policy 
alternatives and (b) doesn't forbid a developer from creating a 
Notification WSDL with multiple policy alternatives.</gp>
>>
>> 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.
>>
> (Gill:  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. )
>  
> *(Wu: This point is relevant as we should allow WS-Eventing to be 
> extended to support other use case with ease. The problem with 
> EventDescriptions is: it is a private data type outside 
> wsdl 1.1/2.0* *. It is totally unclear* *what new inventions are 
> needed for EventDescription to support other MEPs, and if we should 
> recommend **other spec to take this private data type further which is 
> outside and parallel to the standard wsdl specification. Even for the 
> sake of * *interoperability and WS-I Basic Profile (**BP* *)* * 
> compliant, I am not sure if it is a good practice 
> to * *introduc**e* */us**e* * private data types outside wsdl 
> 1.1/2.0* * in web services.* * )*
<gp>This seems to be primarily an emotional argument. You are saying 
"new is bad" without saying what, specifically, is bad about it. IIRC we 
have each admitted that both of our approaches would require changes to 
existing tools to be fully supported in an automated fashion. Your 
approach would require additional functionality to resolve and 
cross-check the various out:Interface and out:Binding links whereas mine 
would require tools to fetch and transform the EventDescriptions.

Your use of the term "private data types" is interesting. Is 
mex:Metadata a "private data type"? Should WS-MEX be criticized for not 
sticking to "standard wsdl"? What about WS-Policy? I agree that one 
shouldn't go around inventing new metadata types for the fun of it, but 
I have stated the motivations behind EventDescriptions many times now. 
Believe me, no one would be happier than me if there were a way to make 
this Notification WSDL idea work but there are just too many problems 
with it. We are far better off working with a simpler, dedicated 
expression of Event Types and using that to derive a simple, constrained 
WSDL.</gp>
>>
>> **
>>
>> 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.
>>
>  (Gill:  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. )
>  
> *(Wu: I would like to assert that it is not comfortable or a 
> recommended practice for developers to work outside the scope of the 
> standard WSDL.  **I also assert there is no need in approach A to 
> provide any XSLT transform or any private data type. The use of 
> WS-Policy in approach A is * *o* *ptional**, and it is consistent with 
> the Industry trend of using policy, instead of private data types, to 
> address WSDL extensions.)*
>>
>> **
>>
>> Many thanks,
>>
>> - Wu Chou/Li Li
>>