RE: Requirements of issue 6401-6661

Without using the words "raw" or "wrapped" I would really like to see the different requirements for these two features in this
document. 

At the moment there are no definitions, and no explanations as to why each are required.  Yet it is assumed we need them!

 

Martin.

 

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert Pilz
Sent: 29 June 2009 23:54
To: Chou, Wu (Wu)
Cc: Doug Davis; Geoff Bullen; public-ws-resource-access@w3.org; Li, Li (Li)
Subject: Re: Requirements of issue 6401-6661

 

Wu,

Comments on your additions:

I. This seems fine, although I would have thought it was obvious given WS-RA's charter.

IX. This one is OK, but I think the phrasing needs a little work.

C. This seems completely out of scope to me. When did WS-RA take a dependency to support UDDI? I'm not saying we should deliberately
do anything to make using UDDI impossible or even difficult, but neither should we make supporting it a requirement.

D. Although, in general, I agree with this principle it is not clear to me if we can properly scope the question "migrate from
what?" Because the treatment of advertising event types was underspecified in the member submission of WS-Eventing there are a
multitude of different ways one could have construed what little material there was. Is WS-RA responsible for supporting migration
paths from all of these constructions?

E. Although it's hard to disagree with this sentiment, it seems so vague as to be useless.

- gp

On 6/26/2009 12:11 PM, Chou, Wu (Wu) wrote: 

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. 

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