Re: [Bug 6401] Draft proposal of issue 6401

Wu,

More comments to your comments . . .

On 5/18/2009 11:03 AM, Chou, Wu (Wu) wrote:
> Gil,
>  
> Thanks for your comments. We are generally fine with your thoughts and 
> added some of our comments in line.
>  
> - Wu Chou
>  
> ------------------------------------------------------------------------
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Friday, May 15, 2009 7:53 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 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. 
>
>  
>
> Wu: Optional may be O.K. But if not using WSDL, what are the 
> alternatives? An open question is if WS-RA should promote these 
> alternatives if they exists, or leave it open.
>
GP: One alternative that comes to mind is to use "wrapped" in 
conjunction with XML Schema (similar to SCA Eventing), but that's just a 
possible alternative, not something I think WS-Eventing should define. I 
think the use of "something else" to describe the schema and binding of 
Notifications should simply be left open as a possible extension point. 
We can't really say anything about them (these hypothetical extensions) 
other than to say that they may exist.
>
> 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. 
>
>  
>
>  Wu :  We are O.K. with this, since both  are  correct  in the sense 
> that  yours  interface = the module that implements the interface, 
> whereas our  use case interface = WSDL port type.  What we 
> meant by "wrapped interface is gone" is: the WSDL interface is 
> subtyped to the extent that it includes a raw interface .  
>
>
> 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? 
>
>  
>
> Wu :  As we said in previous email, both should be allowed and 
> probably should be included in the primer, not in the spec. One use 
> case  we have is for CSTA,  where the session  service provides 
> wrapped  interface. When  the session service  and ECMA-348 are 
> composed, the wrapped  interface  should  be 
> useable  for  receiving the raw CSTA events  as well.
GP: I understand that, but I still can't see why it is necessary to 
combine the description of raw Notifications with the concept of wrapped 
Notifications (which is how we got down this rat hole in the first 
place). It seems that the Event Sink that expects to receive both raw 
and wrapped Notifications should build a listener by combining the raw 
portType and the GenericSinkPortType into a single portType, describing 
a binding of that, etc.
>  
>
> 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. 
>
>  
>
> Wu: In our case, we wrote some code on top of the generated code/stubs 
> to insert raw event elements as the children of the Notify element.
>
GP: This is how I would to handle wrapped Notifications, but I'm not 
seeing how bringing WSDL into the picture helps you in any way if you 
expect to hand-write your marshaling/unmarshaling code in this manner.
>
>  
>
>
> 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 
> <mailto: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" 
> <http://www.w3.org/2009/02/ws-evt>>
>   <wsdl:types>
>     <xs:schema targetNamespace="http://www.w3.org/2009/02/ws-evt" 
> <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" 
> <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" 
> <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" 
> <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" 
> <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" 
> <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 
> <mailto: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 <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
> *"Chou, Wu (Wu)" <wuchou@avaya.com> <mailto:wuchou@avaya.com>*
> Sent by: public-ws-resource-access-request@w3.org 
> <mailto:public-ws-resource-access-request@w3.org>
>
> 05/05/2009 05:30 PM
>
> 	
>
> To
>
> 	
>
> <public-ws-resource-access@w3.org> 
> <mailto:public-ws-resource-access@w3.org>, 
> <member-ws-resource-access@w3.org> 
> <mailto:member-ws-resource-access@w3.org>
>
> cc
>
> 	
>
> "Gilbert Pilz" <gilbert.pilz@oracle.com> 
> <mailto:gilbert.pilz@oracle.com>, "Geoff Bullen" 
> <Geoff.Bullen@microsoft.com> <mailto:Geoff.Bullen@microsoft.com>, "Li, 
> Li (Li)" <lli5@avaya.com> <mailto: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]
>