RE: [Bug 6401] Draft proposal of issue 6401

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
<http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0
086.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
<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">
<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]

Received on Thursday, 14 May 2009 20:19:31 UTC