RE: [Bug 6401] Draft proposal of issue 6401

Doug,
 
Maybe the confusing comes from referencing two separate emails at the
same time.
 
The example in our previous email has all the WSDL constructs. You can
do a mix and match to support the following three variations (including
a source that only supports wrapped as in your question):
1. To support unwrap delivery only: event port type->binding

2. To support wrap delivery only: event port type+wrap
interface->binding

3. To support both: event port type->binding + wrap interface->binding

Thanks,

- Wu Chou.


________________________________

From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Thursday, May 14, 2009 4:26 PM
To: Chou, Wu (Wu)
Cc: Li, Li (Li); public-ws-resource-access@w3.org
Subject: RE: [Bug 6401] Draft proposal of issue 6401



Wu, 
  you seem to have said two different things: 
1 -  We think such info should be gathered through some other
metadata... 
2 - event source MUST advertise the events by specifying the raw event
messages in WSDL... 

unless "other metadata" means WSDL, these seem to be in conflict. 
Can you please show me what the WSDL would look like for a source that
only supports wrapped?  Would it include both the raw and wrapped
messages? 

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> 

05/14/2009 04:18 PM 

To
Doug Davis/Raleigh/IBM@IBMUS 
cc
<public-ws-resource-access@w3.org>, "Li, Li (Li)" <lli5@avaya.com> 
Subject
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]