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

Separation of concerns seems to be a good goal rather than overloading  
one attribute IMO.
Backward compatibility might be maintained through appropriate  
extensibility points at least as far as the document format and schema  
is concerned.
-bob




On Mar 30, 2009, at 8:50 AM, Doug Davis wrote:

>
> But, the real question to me is whether any of the things mentioned  
> in Asir's note can not be achieved thru the use of the NotifyTo EPR,  
> the new Format element, the Notification WSDL [1] and WS-Policy.  It  
> sure seems like it can.  Before we invent something new (and leave  
> the boundaries of our existing infrastructure) I'd like to have a  
> clear use-case that can not be supported.  Saying we have to keep  
> Betamax  around just because its there isn't much of a selling  
> point  :-)
>
> [1] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0127.html
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
>
> Bob Freund <bob@freunds.com>
> Sent by: public-ws-resource-access-request@w3.org
> 03/30/2009 07:31 AM
>
> To
> Asir Vedamuthu <asirveda@microsoft.com>
> cc
> "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> Subject
> 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.
>
>
>