Re: [Team 6401]: simplified approach

I like this approach.  One of my concerns has been the combinatorial 
explosion of portTypes based on all of the possible options available to a 
Subscriber.  Between the filtering, the formatting and any other possible 
extension that the Source might support, the idea of the Source needing to 
expose a different portType for each possible combination just seems 
unmanageable.  And then its totally unknown to me how the Sink is support 
to figure out which one of those portType types actually matches the exact 
set of options that were specified on the Subscribe.  Allowing the 
Sink/Subscriber to craft its own WSDL based on how each option is tweaked 
(or more likely based on how it wants to see the events on the wire) seems 
like a much simpler approach. 

I also really like the idea of being able to get just the schema of the 
raw events without needing to troll through the WSDL - which could have 
event schema/messages/operations all mixed up with application stuff. 

One minor suggestion - add attribute extensibility to the NotificationType 
element.

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/28/2009 07:55 PM

To
"Chou, Wu (Wu)" <wuchou@avaya.com>, Li Li <lli5@avaya.com>, Doug 
Davis/Raleigh/IBM@IBMUS, Geoff Bullen <Geoff.Bullen@microsoft.com>
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
[Team 6401]: simplified approach






Attached is an outline of a new proposal for addressing 6401. As I stated 
on last week's concall, the previous approach (based on the idea that the 
Event Source should advertise a separate Notification WSDL that described 
the notification interface from the Event Sink's perspective) had run into 
a number of issues. Foremost amongst these was how to describe the 
relationship between the Notification Type as expressed in the form of a 
raw Notification in WSDL and that same Notification Type as it may appear 
in a wrapped Notification. Another problem was how to handle the case 
where there are a very large number of possible Notification Types, but 
the Event Sink is only interested in, and (via filtering) will only 
receive a small subset of those Notifications.

The attached proposal is similar to the previous proposal but simplifies 
things to a certain extent. Rather than attempting to express Notification 
Types directly in WSDL, it simply describes them in XML Schema. The 
Notification Types, their schema, and their associated action URI are 
encapsulated in a new WS-MEX dialect called NotificationDescriptions. Once 
retrieved, a NotificationDescriptions document can be used to generate a 
WSDL (via a simple set of mapping rules), but it can be used in other ways 
depending upon the @Format of the subscription. Finally this proposal 
touches on the notion of a new filter dialect that directly references the 
information in the NotificationDescriptions for a more efficient way of 
selecting individual Notifications from a set.

What has been lost in this proposal are the mechanisms for supporting 
policy advertisement and agreement for Notifications. I believe that (a) 
this should be handled as a separate issue and (b) we shouldn't advertise 
an Event Source's policies by attaching them to WSDLs that are intended to 
implemented by the Event Source; rather we should use policy nesting to 
indicate the policies that apply to the application endpoint, the 
WS-Eventing protocol, and the Notifications. For example:

<wsp:Policy>
  <foo:PolicyThatAppliesToApplicationEndpoint/>
  <wsep:Eventing>
    <bar:PolicyThatAppliesToWSEventingProtocol/>
    <wsep:NotificationPolicy>
      <zoo:PolicyThatAppliesToNotifications/>
    </wsep:NotificationPolicy>
  </wsep:Eventing>
<wsp:Policy>
  
- gp[attachment "Notification-Description-0.1.doc" deleted by Doug 
Davis/Raleigh/IBM]