- From: Chou, Wu (Wu) <wuchou@avaya.com>
- Date: Fri, 15 May 2009 18:01:05 -0400
- To: "Doug Davis" <dug@us.ibm.com>
- Cc: "Li, Li (Li)" <lli5@avaya.com>, <public-ws-resource-access@w3.org>
- Message-ID: <F81BDFA28AE48D4793E253362D1F7A740112ABD5@300813ANEX2.global.avaya.com>
The port type name has no significance. The subscriber knows which port
types have raw events by checking WS-Policy assertions in the event
source WSDL. The assertions link the event source WSDL with the
notification WSDL, where these raw event port types are defined (details
see
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/00
12.html ).
wsa:Action in the SOAP header indicates this is wrapped delivery as we
have discussed in issue 6429 (this is in fact your suggestion that Gil
agreed recently).
Thanks,
- Wu Chou.
________________________________
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, May 14, 2009 5:46 PM
To: Chou, Wu (Wu)
Cc: Li, Li (Li); public-ws-resource-access@w3.org
Subject: RE: [Bug 6401] Draft proposal of issue 6401
becoming clearer.... So, is the name "NotificationPortType" a fixed
name? Meaning, Subscribers will know to look for that portType to get
the list of raw events - even if that portType is never directly used?
Also, in your example you have a soap header defined - do people really
expect that to be supported by ws-e? I was under the impression that
each event only had two pieces to it: an actionURI and a single element
(event data). If we allow things to be in headers then how do we filter
it?
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 05:15 PM
To
Doug Davis/Raleigh/IBM@IBMUS
cc
"Li, Li (Li)" <lli5@avaya.com>, <public-ws-resource-access@w3.org>
Subject
RE: [Bug 6401] Draft proposal of issue 6401
Yes, this means "a port type with the raw events". A concrete example
can look as follows, taken from our first response email (operations are
reversed already).
<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>
If source only supports wrapped delivery, it should include only the
following binding to warped delivery.
<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>
Maybe we can have a chat if it is still not clear.
Thanks,
- Wu Chou.
________________________________
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, May 14, 2009 5:00 PM
To: Chou, Wu (Wu)
Cc: Li, Li (Li); public-ws-resource-access@w3.org
Subject: RE: [Bug 6401] Draft proposal of issue 6401
I don't know "event port type" means. Does this mean "a port type with
the raw events" ? Please show me with a concrete example.
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:53 PM
To
Doug Davis/Raleigh/IBM@IBMUS
cc
"Li, Li (Li)" <lli5@avaya.com>, <public-ws-resource-access@w3.org>
Subject
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]
Received on Friday, 15 May 2009 22:02:31 UTC