- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Thu, 28 May 2009 16:55:56 -0700
- To: "Chou, Wu (Wu)" <wuchou@avaya.com>, Li Li <lli5@avaya.com>, Doug Davis <dug@us.ibm.com>, Geoff Bullen <Geoff.Bullen@microsoft.com>
- CC: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <4A1F248C.7090901@oracle.com>
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
Attachments
- application/msword attachment: Notification-Description-0.1.doc
Received on Thursday, 28 May 2009 23:56:45 UTC