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