Re: [Bug 6692] New: Remove Mode from the specification

WS-Man uses delivery mode as an extension point and defines additional  
modes beyond Push:
they are:
PushWithAck
Batched
Pull
So it seems that this extensibility point is useful, but I wonder if  
we ought to define some of them or if we ought to simply leave a  
general extensibility point for any use whatsoever, be it Push or  
otherwise.
Also, if eventing were to be composed with MC, then a polled mode (in  
effect) would be accomplished without its explicit definition, which  
would then work with the WS-Man style Batched as well as PushWithAck  
to, in effect, also make them polled modes.  The combination of ideas  
such as envelope contents (Batched) as well as transport  
characteristics (polled or not, addressable or not, acknowledged or  
not) as well as other behavior such as the use of faults in some  
delivery modes to implicitly cancel a subscription should an event be  
overly large, seems a bit perverse at least to me.
-bob

On Mar 29, 2009, at 10:59 PM, Asir Vedamuthu wrote:

> Last week, on the WG conference call, I mentioned that we will  
> provide some clarity on the concept of delivery mode (in WS- 
> Eventing) and related use cases.
>
> Delivery mode [1] provides a subscriber with a mechanism to specify  
> the means by which an event is delivered. Delivery mode is  
> represented as a URI in a Subscribe message [2]. The semantics  
> indicated by a delivery mode are:
>
> 1)  Rules for the delivery of events
> a)  Semantics and lifecycle of a Notification delivery
> b)  Message Exchange Pattern used (One-way, Request-Response, etc.)  
> and how the delivery mode binds to those Message Exchange Patterns
> c)  Format of a response (if any)
> d)  Configuration parameters or context data (if any) to support the  
> Message Exchange Pattern
> e)  Rules for the delivery or other disposition of faults generated  
> during a Notification delivery
> 2)  Delivery mode specific protocol information (if any) to  
> guarantee interop
> 3)  Supported delivery formats.
>
> Some portion of the above semantics are captured by an EPR, in a  
> machine-readable form, but certainly not all. So, there is value  
> added by a formal mechanism to indicate a delivery mode.
>
> The delivery mode is an extension point in WS-Eventing. The WS- 
> Eventing specification defines a single built-in delivery mode, Push  
> Mode. Other delivery modes may be important for external groups or  
> other W3C Working Groups and are delegated to those groups. This is  
> similar to SOAP Bindings. The W3C XML Protocol WG defined SOAP  
> Protocol Binding Framework as an extension point and a concrete  
> binding, SOAP HTTP Binding (is also identified using a URI [3]).  
> Other groups defined SOAP bindings such as SOAP-over-JMS and SOAP- 
> over-UDP.
>
> The DMTF WS-Management WG defined three new delivery modes [4] and  
> these delivery modes have been widely adopted.
>
> Furthermore, based on the WS-RA WG charter [5], the WG deliverables  
> need to satisfy the following requirements as well:
>
> 1)  Charter scope - “Mechanisms to allow a subscriber to specify the  
> means by which an event is delivered and the definition of a push- 
> based delivery mode”.
> 2)  Charter scope – “In order to avoid disrupting the  
> interoperability of existing implementations, WS-MetadataExchange,  
> WS-Transfer, WS-Eventingand WS-Enumeration should remain compatible  
> with protocols and formats that depend on them, and offer a smooth  
> migration path from the submission to the standard.” We are aware of  
> two dependant protocols – DPWS [6] (uses Push Mode) and WS- 
> Management [4] (uses Push Mode and, as mentioned before, defines  
> three new delivery modes).
>
> [1] http://www.w3.org/Submission/WS-Eventing/#Delivery_Modes
> [2] http://www.w3.org/Submission/WS-Eventing/#Subscribe
> [3] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-bindname
> [4] http://www.dmtf.org/standards/published_documents/DSP0226.pdf -  
> Section 7
> [5] http://www.w3.org/2008/11/ws-ra-charter.html#scope
> [6] http://specs.xmlsoap.org/ws/2006/02/devprof/
>
> We hope this helps.
>
> Regards,
>
> Asir S Vedamuthu
> Microsoft Corporation
>
> -----Original Message-----
> From: public-ws-resource-access-notifications-request@w3.org [mailto:public-ws-resource-access-notifications-request@w3.org 
> ] On Behalf Of bugzilla@wiggum.w3.org
> Sent: Thursday, March 12, 2009 8:37 AM
> To: public-ws-resource-access-notifications@w3.org
> Subject: [Bug 6692] New: Remove Mode from the specification
>
> http://www.w3..org/Bugs/Public/show_bug.cgi?id=6692
>
>            Summary: Remove Mode from the specification
>            Product: WS-Resource Access
>            Version: CR
>           Platform: PC
>         OS/Version: All
>             Status: NEW
>           Severity: major
>           Priority: P2
>          Component: Eventing
>         AssignedTo: public-ws-resource-access-notifications@w3.org
>         ReportedBy: david.Snelling@UK.Fujitsu.com
>          QAContact: public-ws-resource-access-notifications@w3.org
>
>
> The concept of Mode is redundant in the current version of the  
> specification.
> All events can be thought of as being delivered. There is no actual  
> definition
> of "Push Mode" and no other recommended modes. We even have a  
> MakeConnection
> strategy to allow clients behind NATs to fetch events. Likewise,  
> strategies for
> complex queuing and distribution are supportable without adding  
> additional
> modes and are outside the scope of this specification.
>
> Proposal: Remove /s:Envelope/s:Body/*/wse:Delivery/@Mode from the  
> specification
> and all references to Push Mode. A simple explanation of the  
> delivery idea and
> a pointer to some of the techniques available will be needed.
>
>
> --
> Configure bugmail: http://www..w3.org/Bugs/Public/userprefs.cgi? 
> tab=email
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug.
> You are the assignee for the bug.
>
>