Re: [Bug 6401] Draft proposal of issue 6401

Wu,

I think your first statement is too strong (perhaps I misunderstand the 
context). As much as I favor the idea of using WSDL to accurately 
describe the schema and binding of Notifications messages, I think it is 
going too far to require that all deployments of a WS-Eventing Event 
Source everywhere and forevermore MUST advertise their Notification 
types via the mechanisms we have been working on. Just as the use of 
WSDL itself is not a hard requirement, I think the use of a Notification 
WSDL should be optional.

With regards to your statement that "the wrapped interface is gone", I 
don't agree. Remember that, on the wire, SOAP messages carry no trace of 
their wsdl:portType or wsdl:binding. I would argue that my 
"SlightlyLessGenericSinkPortType" is a subclass of your 
"GenericSinkPortType". Service stubs built from the 
"GenericSinkPortType" will be able to handle messages generated by 
client stub built from the ""SlightlyLessGenericSinkPortType"; the 
wire-level messages will look exactly the same.

As far as the extra effort required to build these subclasses of the 
Notify element and the GenericSinkPortType; I agree that it is rather 
cumbersome but I think this use case is not likely to be encountered all 
that often. In fact, I don't understand why we are worrying about how to 
"transform" a description of a raw Notification into a description of a 
wrapped Notification in the first place! I thought the whole point of 
wrapped Notifications is that you either don't want to or are unable to 
describe them? If you have the description of a raw Notification, and 
you want to use that description to help process the Notification (e.g. 
by auto-generating service stubs), why not just use raw Notifications?

Finally, your assertion that your new WSDL binding style (Doc/lit 
wrapped Notification) can be supported via minor code changes runs 
completely counter to my understanding of how things like RPC/lit and 
Doc/lit are supported in our current tools. It could be that we are 
talking about completely different things. For instance, I don't know 
what you mean when you say "it can be composed at run time" and your 
point about "static expansion vs. run-time expansion" leaves me 
similarly confused.

To try and clear things up on my end here's what I am imagining:

1.) For some reason (again, I have no idea why you would want to do 
this) I would like to generate code to handle Notifications that are 
both strongly typed and "wrapped" in the wse:Notify element.

2.) Starting from a Notification WSDL that describes the raw 
Notifications, I run my "wsdl2code" tool with an option that effectively 
says "when I subscribe to the Event Source that emits these messages I 
am going to specify 
http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Wrapped". This tells my 
tool to generate service stubs using the GenericSinkPortType and 
GenericSinkSOAP*" binding, and that the wsdl:parts of the raw 
Notification messages will be carried inside the soap:Body/wse:Notify 
element.

I can't see being able to do (2) without some pretty serious enhancement 
to my wsdl2code tool.

- gp


On 5/15/2009 3:00 PM, Chou, Wu (Wu) wrote:
> Gil,
>  
> Thanks for your comments.
>  
> We think the following statement should still hold: "the event source 
> MUST advertise the events by specifying the raw event messages in WSDL 
> and MAY specify additional delivery formats for the raw events. The 
> wired forms of event messages are derived from the raw event messages, 
> the format metadata (WSDL) and some other rules. "
>  
> In our  use case, the event source advertises the events by specifying 
> raw events in portType. In your approach (2), the event source 
> advertises the events by specifying a separate expanded raw events 
> message schema under one operation (NotifyEvent). Both approaches fit 
> the above statement and should be allowed.
>  
> In your case, the wrapped interface is gone, since all events are 
> explicitly spelled out  in the schema under one operation. There are 
> pros and cons for both approaches, e.g. static expansion vs. run-time 
> expansion.  
>  
> In your case, because it is static, it is more friendly to existing 
> tools. However, for a given raw  events interface, it requires to 
> redesign an additional expanded  schema that contains the duplicated 
> events that are already in the raw events interface. To add a 
> new event to the raw event list, it requires additional modification 
> of  the expanded static wrapped interface schema  to make that wrapped 
> delivery operation consistent (maybe by hand since not sure if this 
> can be done by automatic tooling). Moreover,  if format is 
> involved, each new format will lead to a new expanded wrapped 
> schema/operation that cover all related raw events (e.g.  if there is 
> n formats, there are n  times number-of-events  in n separate schemas) . 
>  
> In our case, the expansion may need some extra code/utility ( quite  
> minor in the case of doc/lit). But it can be composed at run 
> time  while drawbacks listed above  can be alleviated.
>  
> In short, this should be a design choice (e.g. static expansion vs. 
> run-time expansion). And both should work under the current WS-E 
> framework.
>  
> - Wu Chou/Li Li
>  
>
> ------------------------------------------------------------------------
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Thursday, May 14, 2009 5:48 PM
> *To:* Chou, Wu (Wu)
> *Cc:* Doug Davis; public-ws-resource-access@w3.org; Li, Li (Li)
> *Subject:* Re: [Bug 6401] Draft proposal of issue 6401
>
> Wu,
>
> I don't think this is a very good idea for a number of reasons.
>
> 1.) The transformation between a raw Notification and the wrapped 
> version of that Notification is effectively another SOAP binding style 
> (take the individual message parts and add them as children to 
> soap:Body/wse:Notify). The creation of another SOAP binding style 
> would add to the confusion around RPC/encoded, RPC/literal, 
> Doc/literal, and Doc/literal wrapped by creating a new style 
> "Doc/literal Notification wrapped". Support for this new style would 
> require changing the existing WSDL 1.1 tool sets. This is very large 
> and undesirable requirement and arguably outside the scope of the 
> WS-RA WG.
>
> 2.) Defining a transformation between a raw Notification and a wrapped 
> version of that Notification is unnecessary. For any raw Notification 
> WSDL, it is possible to create another, analogous WSDL that extends 
> the wse:EventType to contain the parts you want, and use that in your 
> Event Sinks portType. To borrow from your example:
>
> <wsdl:definitions targetNamespace="http://www.w3.org/2009/02/ws-evt">
>   <wsdl:types>
>     <xs:schema targetNamespace="http://www.w3.org/2009/02/ws-evt">
>       . . .
>       <xs:complexType name="EventType" mixed="true">
>         <xs:sequence>
>           *<xs:element name="PO" type="po:POType"/>*
>           *<xs:element name="Invoice" type="po:InvoiceType"/>*
>           <xs:any namespace="##any" processContents="lax" 
> minOccurs="0" maxOccurs="unbounded"/>
>         </xs:sequence>
>         <xs:attribute name="actionURI" type="xs:anyURI" use="optional"/>
>         <xs:anyAttribute namespace="##other" processContents="lax"/>
>       </xs:complexType>
>
>       <xs:element name="Notify" type="wse:EventType"/>
>     </xs:schema>
>   </wsdl:types>
>
>   <wsdl:message name="NotifyEvent">
>     <wsdl:part name="parameter" element="wse:Notify"/>
>   </wsdl:message>
>
>   <wsdl:portType name="SlightlyLessGenericSinkPortType">
>     <wsdl:operation name="NotifyEvent">
>       <wsdl:input message="wse:NotifyEvent" 
> wsam:Action="http://www.w3.org/2009/02/ws-evt/Notify"/>
>     </wsdl:operation>
>   </wsdl:portType>
>
>   <wsdl:binding name="SlightlyLessGenericSinkSOAP11" 
> type="wse:SlightlyLessGenericSinkPortType">
>     <soap:binding style="document" 
> transport="http://schemas.xmlsoap.org/soap/http"/>
>     <wsdl:operation name="NotifyEvent">
>       <soap:operation soapAction=""/>
>       <wsdl:input>
>         <soap:body parts="parameter" use="literal"/>
>       </wsdl:input>
>     </wsdl:operation>
>   </wsdl:binding>
>
> </wsdl:definitions>
>
> You can use current WSDL tools to generate service stubs from the 
> above WSDL that are capable of marshaling the PO and Invoice elements 
> into language specific data binding classes yet still allow the 
> Notifications to be "wrapped" in the sense that SOAP body child of 
> every Notification message will be a completely schema-valid 
> wse:Notify.  Event Sources that may not know or care that these 
> Notifications contain PO and Invoice elements can still treat them as 
> generic, weakly typed, wrapped Notifications.
>
> Finally, I wonder if you could re-explain to me the purpose of wrapped 
> Notifications? I thought the point was that the Event Source and Event 
> Sink were either unable to or did not wish to tightly couple 
> themselves to the details of the Notification schema at build time, 
> but instead wished to allow Notifications with arbitrary XML to be 
> exchanged? Why are we trying to define what the contents of a wrapped 
> Notification will be in this manner? It seems to undo the whole point 
> of using wrapped Notifications.
>
> - gp
>
>
> On 5/14/2009 1:18 PM, Chou, Wu (Wu) wrote:
>>
>> Doug,
>>
>> This is a very good question. We think such info should be gathered 
>> through some other metadata, which is in agreement with your 
>> view expressed in 
>> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0086.html . 
>>
>>
>> Namely, the event source MUST advertise the events by specifying the 
>> raw event messages in WSDL and MAY specify additional delivery 
>> formats, e.g. wrapped interface, for the raw events. The wired forms 
>> of event messages are derived from the raw event messages, the format 
>> metadata (WSDL) and some other rules.
>>
>> Currently, we have two formats: unwrap (raw events) and wrap (defined 
>> in proposal 6429). We assume both raw events and the wrap interface 
>> have doc/lit bindings using either SOAP 1.1 or 1.2.
>>
>> When event message, possibly with multiple parts, is delivered using 
>> the "Wrap" format, the event message will be encapsulated inside the 
>> wrapper <wse:Notify> element underneath the SOAP Body. Logically, the 
>> <wse:Notify> element can be regarded as <xs:Choice> of <xs:sequence> 
>> of message parts (xs:element).
>>
>> For example, the following WSDL fragments specify a raw event 
>> "PurchaseEvent":
>>
>> <message name="PurchaseEvent">
>> <part name="header" element="tns:PO"/>
>> <part name="body" element="tns:Invoice"/> </message>
>> <portType name="NotificationPortType">
>> <operation name="NotifyPurchaseEvent">
>> <input message="tns:PurchaseEvent"/>
>> </operation>
>> </portType>
>> <binding name="NotificationPortTypeSoap" type="tns:NotificationPortType">
>> <soap:binding style="document" 
>> transport="http://schemas.xmlsoap.org/soap/http"/>
>> <operation name="NotifyPurchaseEvent">
>> <input message="tns:PurchaseEvent">
>> <soap:body parts="body" use="literal"/>
>> <soap:header message="tns:PurchaseEvent" part="header" use="literal"/>
>> </input>
>> </operation>
>> </binding>
>>
>> The following WSDL fragments specify the binding for the wrap interface:
>>
>> <binding name="GenericSinkPortTypeSoap" type="tns:GenericSinkPortType">
>> <soap:binding style="document" 
>> transport="http://schemas.xmlsoap.org/soap/http"/>
>> <operation name="NotifyEvent">
>> <input message="tns:notifyEvent">
>> <soap:body parts="parameter" use="literal"/>
>> </input>
>> </operation>
>> </binding>
>>
>> Using the wrap format, the "PurchaseEvent" event will be delivered in 
>> SOAP as follows:
>>
>> <Envelope>
>> <Header>
>> <wsam:Action>
>> _http://schemas.xmlsoap.org/ws/2004/08/eventing/wrap/GenericSinkPortType/NotifyEvent_
>> </wsam:Action>
>> </Header>
>> <Body>
>> <wse:Notify 
>> actionURI="http://www.example.com/NotificationPortType/NotifyPurchaseEvent">
>> <tns:PO>...</tns:PO>
>> <tns:Invoice>...</tns:Invoice>
>> </wse:Notify>
>> </Body>
>> </Envelope>
>>  
>> Thanks,
>>  
>> - Wu Chou
>>
>> ------------------------------------------------------------------------
>> *From:* Doug Davis [mailto:dug@us.ibm.com]
>> *Sent:* Wednesday, May 13, 2009 7:17 PM
>> *To:* Chou, Wu (Wu)
>> *Cc:* public-ws-resource-access@w3.org
>> *Subject:* Re: [Bug 6401] Draft proposal of issue 6401
>>
>>
>> Hi Wu,
>>   could you help me understand how you see wrapped events working? 
>> Let's say a source only supports wrapped format.  If wsdl then shows 
>> just the wrapped element, with an xs:any as a child, then how does 
>> the sink know what events it'll get?  From a pure tooling (e.g. 
>> wsdl2java) perspective the wsdl is "good enough" - but from an event 
>> processing perspective, the wsdl didn't provide me any useful info - 
>> like what the xsd of the events are.  Likewise, how does the source 
>> know the format of the events to know how to formulate the filter 
>> expressions?  Are you assuming that this info would be gathered 
>> through some other metadata?
>>
>> thanks
>> -Doug
>> ______________________________________________________
>> STSM |  Standards Architect  |  IBM Software Group
>> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
>> The more I'm around some people, the more I like my dog.
>>
>>
>> *"Chou, Wu (Wu)" <wuchou@avaya.com>*
>> Sent by: public-ws-resource-access-request@w3.org
>>
>> 05/05/2009 05:30 PM
>>
>> 	
>> To
>> 	<public-ws-resource-access@w3.org>, <member-ws-resource-access@w3.org>
>> cc
>> 	"Gilbert Pilz" <gilbert.pilz@oracle.com>, "Geoff Bullen" 
>> <Geoff.Bullen@microsoft.com>, "Li, Li (Li)" <lli5@avaya.com>
>> Subject
>> 	Re: [Bug 6401] Draft proposal of issue 6401
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>> Here is our concrete proposal of issue 6401 that was submitted to 
>> 6401 Task team on 05/04/09.
>>  
>> It is based on Gil's original proposal with amendments. An overview 
>> page is provided to illustrate the approach.
>>  
>> This proposal should be treated as work in progress. 
>> Comments/suggestions/contributions are welcome and appreciated.
>>  
>> Regards,
>>  
>> - Wu Chou/Li Li
>>  
>> Avaya Labs Research   [attachment "6401_proposal_v0.5.pdf" deleted by 
>> Doug Davis/Raleigh/IBM]