- From: Doug Davis <dug@us.ibm.com>
- Date: Thu, 14 May 2009 17:46:08 -0400
- To: "Chou, Wu (Wu)" <wuchou@avaya.com>
- Cc: "Li, Li (Li)" <lli5@avaya.com>, public-ws-resource-access@w3.org
- Message-ID: <OF45F9C126.CD0B507D-ON852575B6.0077475A-852575B6.007794E8@us.ibm.com>
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/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]
Received on Thursday, 14 May 2009 21:46:52 UTC