- 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