RE: [Bug 6401] Draft proposal of issue 6401

Gil,
 
Thanks for your comments. We are generally fine with your thoughts and
added some of our comments in line. 
 
- Wu Chou
 
________________________________


From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Friday, May 15, 2009 7:53 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 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. 

 

Wu: Optional may be O.K. But if not using WSDL, what are the
alternatives? An open question is if WS-RA should promote these
alternatives if they exists, or leave it open.


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. 

 
 Wu :  We are O.K. with this, since both  are  correct  in the sense
that  yours  interface = the module that implements the interface,
whereas our  use case interface = WSDL port type.  What we meant by
"wrapped interface is gone" is: the WSDL interface is subtyped to the
extent that it includes a raw interface .  


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? 

 
Wu :  As we said in previous email, both should be allowed and probably
should be included in the primer, not in the spec. One use case  we have
is for CSTA,  where the session  service provides wrapped  interface.
When  the session service  and ECMA-348 are composed, the wrapped
interface  should  be useable  for  receiving the raw CSTA events  as
well.  

 
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. 

 

Wu: In our case, we wrote some code on top of the generated code/stubs
to insert raw event elements as the children of the Notify element. 




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"
<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 . 

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]