- From: Chou, Wu (Wu) <wuchou@avaya.com>
- Date: Fri, 15 May 2009 18:00:55 -0400
- To: "Gilbert Pilz" <gilbert.pilz@oracle.com>
- Cc: "Doug Davis" <dug@us.ibm.com>, <public-ws-resource-access@w3.org>, "Li, Li (Li)" <lli5@avaya.com>
- Message-ID: <F81BDFA28AE48D4793E253362D1F7A740112ABD4@300813ANEX2.global.avaya.com>
Gil,
Thanks for your comments.
We think the following statement should still hold: "the event source
MUST advertise the events by specifying the raw event messages in WSDL
and MAY specify additional delivery formats 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. "
In our use case, the event source advertises the events by specifying
raw events in portType. In your approach (2), the event source
advertises the events by specifying a separate expanded raw events
message schema under one operation (NotifyEvent). Both approaches fit
the above statement and should be allowed.
In your case, the wrapped interface is gone, since all events are
explicitly spelled out in the schema under one operation. There are
pros and cons for both approaches, e.g. static expansion vs. run-time
expansion.
In your case, because it is static, it is more friendly to existing
tools. However, for a given raw events interface, it requires to
redesign an additional expanded schema that contains the duplicated
events that are already in the raw events interface. To add a new event
to the raw event list, it requires additional modification of the
expanded static wrapped interface schema to make that wrapped delivery
operation consistent (maybe by hand since not sure if this can be done
by automatic tooling). Moreover, if format is involved, each new format
will lead to a new expanded wrapped schema/operation that cover all
related raw events (e.g. if there is n formats, there are n times
number-of-events in n separate schemas) .
In our case, the expansion may need some extra code/utility ( quite
minor in the case of doc/lit). But it can be composed at run time while
drawbacks listed above can be alleviated.
In short, this should be a design choice (e.g. static expansion vs.
run-time expansion). And both should work under the current WS-E
framework.
- Wu Chou/Li Li
________________________________
From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
Sent: Thursday, May 14, 2009 5:48 PM
To: Chou, Wu (Wu)
Cc: Doug Davis; public-ws-resource-access@w3.org; Li, Li (Li)
Subject: 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"
<http://www.w3.org/2009/02/ws-evt> >
<wsdl:types>
<xs:schema targetNamespace="http://www.w3.org/2009/02/ws-evt"
<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"
<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"
<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/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"
<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"
<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" <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> <mailto: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>
<mailto:public-ws-resource-access@w3.org> ,
<member-ws-resource-access@w3.org>
<mailto:member-ws-resource-access@w3.org>
cc
"Gilbert Pilz" <gilbert.pilz@oracle.com>
<mailto:gilbert.pilz@oracle.com> , "Geoff Bullen"
<Geoff.Bullen@microsoft.com> <mailto:Geoff.Bullen@microsoft.com> , "Li,
Li (Li)" <lli5@avaya.com> <mailto: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:01:48 UTC