RE: analysis of EventDescriptions proposal against use cases and requirements

Gil,

> Known Technologies - the EventDescriptions proposal is dependent upon the following known technologies: XML Schema, WSDL 1.1, and optionally XSL Transformations to transform the EventDescriptions element into a wsdl:definitions element.

For your proposal, the actual Event Descriptions metadata language that is used to define notifications is a new/unknown technology rather than a known technology. Correct?

--Geoff


From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert Pilz
Sent: Tuesday, July 21, 2009 10:27 AM
To: public-ws-resource-access@w3.org
Subject: analysis of EventDescriptions proposal against use cases and requirements

The following is an analysis of how the EventDescriptions proposal for describing and advertising Event Types attached to this email satisfies the use cases and requirements specified on the Wiki<http://www.w3.org/2002/ws/ra/wiki/Use_Cases_for_6401-6661>.

I. Event Sink Code Generation
A. Raw Notifications - the EventDescriptions proposal supports the use of current WSDL-based tools to generate the code to marshal and dispatch Raw Notifications by specifying the transformation of the EventDescriptions element into a BP 1.1 conformant, WSDL 1.1 definitions element (see Appendix F).

B. Wrapped Notifications - since the WSDL for Wrapped Notifications is already specified in Appendix D and, by definition, all listeners for Wrapped Notifications must support this WSDL, there is nothing more that needs to be done to provide support for Wrapped Notifications. Support for the additional marshalling of the contents of Wrapped Notifications may be provided by using XML data binding technologies (e.g. XMLBeans<http://xmlbeans.apache.org/>) in conjunction with the information in the /EventDescriptions/eventType though the use cases around this are unclear.

C. Extension Notifications - Since the EventDescriptions element describes the shape of Events independently of how they are included in a Notifications, it is well suited for the definition of additional Notification formats.
II. Event Type Visibility - As described in Section 6.2 "Retrieving Event Types", a Subscriber can view metadata (i.e. schema definitions) on the set of Event Types supported by an Event Source. An Event Source could pre-filter this metadata based on the Subscribers authenticated identity to insure that the Subscriber is only provided with a list of those Event Types to which he/she has access.

III. Event Type Completeness - There are two crucial pieces of information needed to implement an Event Sink. The first is the schema for the set of Event Types that may be emitted. This can be retrieved as described in Section 6.2 "Retrieving Event Types". The second is the format of the Notifications in which the Events will be transmitted. This is selectable at Subscribe time and defined by either the WS-Eventing spec (for Raw and Wrapped Notifications) or by some extension spec.

IV. Non-Metadata Use Cases - Nothing in the EventDescriptions proposal prevents the Subscriber and Event Source provider from communicating the information necessary to implement these use cases by some means other than metadata.

V. Multiple Notification Variations - because the EventDescriptions proposal separates the Event Type information from the Notification Format, it is particularly well suited to support this use case (this use case was, in fact, the motivating factor for the development of this proposal).

VI. Advertise Notification Variations - because it separates the description Event Types from Notification formats, nothing in the EventDescriptions proposal supports this use case, but neither is there anything that prevents its support via some other, more appropriate mechanism such as the use of WS-Policy assertions (or sub-assertions) that indicate which Notification formats are supported by an Event Source.

VII. Deterministic WSDL - for Raw Notifications a deterministic process for generating a WSDL is described in Appendix F. For Wrapped Notifications the WSDL is included in Appendix D. Extended Notification formats should describe the mapping for Event Types to Notifications in that format.

VIII. WS-I Basic Profile - the transformation of the EventDescriptions element into a WSDL 1.1 definitions element described in Appendix F results in a WSDL that conforms to Basic Profile 1.1<http://www.ws-i.org/Profiles/BasicProfile-1.1.html>.

IX. Extensibility of Message Exchange Patterns - the EventDescriptions proposal does nothing to prevent the definition of extended MEPS in WS-Eventing.

Global Non-Functional Requirements
Constrained Environments - since the EventDescriptions proposal describes build-time artifacts and processes, it does not impact constrained environments.

Known Technologies - the EventDescriptions proposal is dependent upon the following known technologies: XML Schema, WSDL 1.1, and optionally XSL Transformations to transform the EventDescriptions element into a wsdl:definitions element.

Consistent with UDDI - nothing in the EventDescriptions proposal prevents either the Event Source or Event Sink from publishing and registering their services though UDDI.
- gp