Re: Requirements of issue 6401-6661

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.
Wu:
I need some clarification on your requirement”
“
: 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.
“

There is great value in having Notifiations to be one-ways (however with 
an http empty response body)

Notifications can only be fanned out if there are no responses, other 
than the http empty response body. It seems to me that you take away the 
ability to do fanning out if each ultimate destination has to actually 
send something back other than an empty http response.

The problem is how does the secondary transmission response get sent 
back to the originating source?

For example, original source sends to sink A, sink A then sends the 
notifications it receives to downstream sinks (acting as a secondary 
source ). Since sink A can only send one response with a body to the 
original source, it cannot take the multiple responses from its 
secondary sinks and determine which one to send back to the original source.

Allowing data in a notification response seems to gum up the simple 
model. Tha is, a notification with actual data in the resonse (other 
than the http response headers) takes away some downstream 
redistribution options,. I do not understand any use case for data in 
the body of a notification response


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


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Tuesday, 30 June 2009 01:30:58 UTC