W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > May 2009

[Team 6401]: simplified approach

From: Gilbert Pilz <gilbert.pilz@oracle.com>
Date: Thu, 28 May 2009 16:55:56 -0700
Message-ID: <4A1F248C.7090901@oracle.com>
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>
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:

- gp

Received on Thursday, 28 May 2009 23:56:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:49 UTC