RE: [Team 6401]: simplified approach

Hi Gil,
Please correct me if I am wrong here, but it seems that the event source must be running in order for this to work.  Is that correct?  There is an important use case associated with tools producing “notification stubs” for the event sink implementer to use, even before the event source code may have been written, and certainly not while it is running.  Can you explain how this use case can be satisfied using your approach?
Thanks,
Geoff

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
Sent: Thursday, May 28, 2009 4:56 PM
To: Chou, Wu (Wu); Li Li; Doug Davis; Geoff Bullen
Cc: 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

Received on Friday, 29 May 2009 22:54:57 UTC