- From: Chou, Wu (Wu) <wuchou@avaya.com>
- Date: Mon, 18 May 2009 14:03:01 -0400
- To: <gilbert.pilz@oracle.com>
- Cc: <public-ws-resource-access@w3.org>, "Doug Davis" <dug@us.ibm.com>, "Li, Li (Li)" <lli5@avaya.com>
- Message-ID: <F81BDFA28AE48D4793E253362D1F7A740112ABD9@300813ANEX2.global.avaya.com>
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. 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. 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. 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" <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/00 86.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 <http://schemas.xmlsoap.org/ws/2004/08/eventing/wrap/GenericSinkPortType /NotifyEvent> </wsam:Action> </Header> <Body> <wse:Notify actionURI="http://www.example.com/NotificationPortType/NotifyPurchaseEve nt" <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> <mailto: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> <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]
Received on Monday, 18 May 2009 18:03:53 UTC