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]