Re: [Bug 6401] Draft proposal of issue 6401

Would it make sense to separate this out into two parts?  First part is 
what goes on the wire.  The WSDL must accurately describe that. Whether 
its wrapped or raw, the WSDL needs to have all of the operations/messages 
that wsdl2code tooling can use to generate the proper client-side 
listeners/stubs.  The second part is the definition of the events 
themselves.  Due to the extensibility points (whether its Mode, Format or 
any other one), what ends up on the wire could look radically different 
from the original event.  And since the WSDL needs to be an accurate 
representation of the end result of all this processing, its possible that 
the WSDL could end up not sharing anything in common with the original 
event.  In order for things like Filtering to work (which acts on the raw 
event) perhaps we should just define a new metadata type that people can 
retrieve (using MEX) and that's how they know what the raw events look 
like.  Yes if the source supports sending raw events then this will be 
duplicate information with what's in the WSDL, but at least the Subscriber 
can know with certainty exactly how and where to get the raw event schema 
from.

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.



Gilbert Pilz <gilbert.pilz@oracle.com> 
05/15/2009 07:53 PM

To
"Chou, Wu (Wu)" <wuchou@avaya.com>
cc
Doug Davis/Raleigh/IBM@IBMUS, public-ws-resource-access@w3.org, "Li, Li 
(Li)" <lli5@avaya.com>
Subject
Re: [Bug 6401] Draft proposal of issue 6401






Wu,

I think your first statement is too strong (perhaps I misunderstand the 
context). As much as I favor the idea of using WSDL to accurately describe 
the schema and binding of Notifications messages, I think it is going too 
far to require that all deployments of a WS-Eventing Event Source 
everywhere and forevermore MUST advertise their Notification types via the 
mechanisms we have been working on. Just as the use of WSDL itself is not 
a hard requirement, I think the use of a Notification WSDL should be 
optional.

With regards to your statement that "the wrapped interface is gone", I 
don't agree. Remember that, on the wire, SOAP messages carry no trace of 
their wsdl:portType or wsdl:binding. I would argue that my 
"SlightlyLessGenericSinkPortType" is a subclass of your 
"GenericSinkPortType". Service stubs built from the "GenericSinkPortType" 
will be able to handle messages generated by client stub built from the 
""SlightlyLessGenericSinkPortType"; the wire-level messages will look 
exactly the same.

As far as the extra effort required to build these subclasses of the 
Notify element and the GenericSinkPortType; I agree that it is rather 
cumbersome but I think this use case is not likely to be encountered all 
that often. In fact, I don't understand why we are worrying about how to 
"transform" a description of a raw Notification into a description of a 
wrapped Notification in the first place! I thought the whole point of 
wrapped Notifications is that you either don't want to or are unable to 
describe them? If you have the description of a raw Notification, and you 
want to use that description to help process the Notification (e.g. by 
auto-generating service stubs), why not just use raw Notifications?

Finally, your assertion that your new WSDL binding style (Doc/lit wrapped 
Notification) can be supported via minor code changes runs completely 
counter to my understanding of how things like RPC/lit and Doc/lit are 
supported in our current tools. It could be that we are talking about 
completely different things. For instance, I don't know what you mean when 
you say "it can be composed at run time" and your point about "static 
expansion vs. run-time expansion" leaves me similarly confused.

To try and clear things up on my end here's what I am imagining:

1.) For some reason (again, I have no idea why you would want to do this) 
I would like to generate code to handle Notifications that are both 
strongly typed and "wrapped" in the wse:Notify element.

2.) Starting from a Notification WSDL that describes the raw 
Notifications, I run my "wsdl2code" tool with an option that effectively 
says "when I subscribe to the Event Source that emits these messages I am 
going to specify http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Wrapped
". This tells my tool to generate service stubs using the 
GenericSinkPortType and GenericSinkSOAP*" binding, and that the wsdl:parts 
of the raw Notification messages will be carried inside the 
soap:Body/wse:Notify element.

I can't see being able to do (2) without some pretty serious enhancement 
to my wsdl2code tool.

- gp


On 5/15/2009 3:00 PM, Chou, Wu (Wu) wrote: 
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">
  <wsdl:types>
    <xs:schema targetNamespace="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"/>
    </wsdl:operation>
  </wsdl:portType>

  <wsdl:binding name="SlightlyLessGenericSinkSOAP11" 
type="wse:SlightlyLessGenericSinkPortType">
    <soap:binding style="document" transport=
"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/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]