Requirements of issue 6401-6661

Doug, Gil, Geoff,
 
Here is a draft of requirement list of issue 6401-6661 for discussion.
It is a minor extension to the use case list, since the use case list is
more of a requirement list. Please let me know your
comments/suggestions. If there is a need, we can go over them in a
conference call next Monday afternoon.
 
Thanks,
 
- Wu Chou.
 
----------------------------------------------------
 
Requirements for Issue 6401-6661 (Draft version 0.1)
 

I. WS-I Basic Profile 

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

II. 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 (on-the-wire) 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). 

III. 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. 

IV. 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. 

V. Non-Metadata Use Cases

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

VI. 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. 

VII. Advertise Notification Variations

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

VIII. 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. 

IX. Extensibility of Message Exchange Patterns (MEPs)

It should not prohibit 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: 

A. Constrained Environments

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

B. 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). 

C. Consistent with UDDI

It must be possible for an Event Source and an Event Sink to publish and
register their services through UDDI, so that they can be discovered and
consumed through the existing web service infrastructure.

D. Support Migration

It should facilitate a migration path of eliminating the offending
outbound operations in existing web service implementations.

E. Support Composition

It should facilitate easy compositions with other WS-* standards. 

----------------------------------------------------------