Use Cases for 6401-6661

I. Event Sink Code Generation

It must be possible for a developer of an Event Sink to generate code that dispatches and marshals Notifications using current WSDL-based tools. There are three sub-cases:

A. Raw Notifications

It must be possible for developers to do the above for Raw Notifications.

B. Wrapped notifications

It must be possible for developers to do the above for Wrapped Notifications.

C. Extension Notifications

It should be possible for developers to do the above for Notifications who's OTW shape has been changed by an extension to WS-Eventing (e.g. a new Format). Since the WG cannot know at this time what sorts of extensions may be invented, it is impossible to determine whether any solution can satisfy this requirement for all possible extensions. At the very least, no solution for this requirement should do anything to make it impossible to support extensions that change the shape of the OTW Notification. A non-functional requirement of this use case is that it should be "easy" to support the kinds of extensions that are currently envisioned (e.g. a "batched" format).

II. Event Type Visibility

A Subscriber can view metadata about the set of potential Events Types (including schemas) that may be emitted by an Event Source. A non-functional requirement is that it must be possible to screen this metadata based on authorization decisions about the identity of the Subscriber.

III. Event Type Completeness

It must be possible for a service designer to take the metadata about the set of potential Event Types that may be emitted by an Event Source and implement the Event Sink.

IV. Non-Metadata Use Cases

It must be possible to realize ALL USECASES without the use of metadata.

V. Multiple Notification Variations

It must be possible for a single Event Source to transmit multiple variations of Notifications (Raw, Wrapped, *) for the same Event Type.

VI. Advertise Notification Variations

It must be possible to provide a Subscriber with metadata that describes the variations of Notifications (e.g. supported formats)

VII. Deterministic WSDL

It must be possible for a Subscriber to determine the WSDL that describes the interface that the Event Sink needs to implement based on the various parameters and extensions in the Subscribe request.

VIII. WS-I Basic Profile

WSDLs of Event Source and Event Sink must be WS-I Basic Profile compliant.

IX. Extensibility of Message Exchange Patterns (MEPs)

Although WS-Eventing is only required to support simple one-way Notifications, a solution should not prohibit the extension of message exchange patterns to support a variety of event notifications that can fit into WSDL 1.1 and WSDL 2.0 framework, e.g. WS-Management specifies that a notification can be acknowledged, and ECMA CSTA requires that the Event Sink responds to the notification with certain type of messages.

Global Non-Functional Requirements

Any solution to the above use cases should satisfy the following non-functional requirements:

Constrained Environments

All use cases must have 'reasonable' solution for constrained environments.

Known Technologies

Any solution to the above use cases must limit inventions to applications of well known technologies (e.g. WSDL, WS-Policy, WS-MetadataExchange).

Consistent with UDDI

Although WS-Eventing is not required to provide explicit support for UDDI, a solution should not prohibit either Event Sources or Event Sinks from publishing and registering their services through UDDI, so that they can be discovered and consumed through the existing web service infrastructure.