Re: Requirements of issue 6401-6661

It would be helpful to have an enumeration of the cases that motivate 
use of wrapped Notifications. I've heard several over the past 6 months 
or so, but I don't know if I have them all straight in my mind.

- gp

On 6/30/2009 9:58 AM, Martin Chapman wrote:
>
> 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.
>
> ----------------------------------------------------------
>