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

> non standard alternatives to composition of WS-* standards
> multiple willy nilly ad hoc solutions for these features

We are not sure how to respond to these. We do not know what these are and where they are from. Please advise if we can help any further.

> The next version of WS-Man will have available ws-rm, 
> ws-make connection, and the new features of ws-eventing

We assume that these are personal statements and not official statements on behalf of the DMTF WS-Management WG. Please advise if we misunderstood.

Regards,

Asir S Vedamuthu
Microsoft Corporation

-----Original Message-----
From: Tom Rutt [mailto:tom@coastin.com] 
Sent: Monday, March 30, 2009 8:11 PM
To: Asir Vedamuthu
Cc: Doug Davis; Bob Freund; public-ws-resource-access@w3.org
Subject: Re: [Bug 6692] New: Remove Mode from the specification

Asir Vedamuthu wrote:
>
> > But, the real question to me is whether any of the things
>
> > mentioned in Asir's note cannot 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.
>
I feel strongly that having the mode in ws-eventing will encourage use 
of non standard
alternatives to composition of WS-* standards.

The next version of WS-Man will have available ws-rm, ws-make 
connection, and the new features
of ws-eventing.

The ws-man non push modes can be accomplished with the following 
compositions of
ws-* infrastructure standards:
Pull->MC, PushWithAck->Push+RM, Batching->the new Format element.


I think we should avoid the view that "ws man uses mode today" but rather
spout the retort "ws man v2 will change for many reasons, this is just one"

By using standard ws specs to provide these orthogonal capabilities, we 
will avoid multiple
willy nilly ad hoc solutions for these features for every user of 
ws-eventing.

I do not think that citing the existing ws man standard qualifies as a 
valid use case for the
need for the mode in ws-eventing.
>
> Let us help you pushback more effectively ...
>
> That is, pushback and convince (a) hundreds of developers who 
> implemented and interop tested the WS-Eventing interop surface (b) 
> several communities (such as devices, management and telecom) that 
> have taken dependencies on WS-Eventing and (c) tens of W3C Member 
> organizations that discussed and agreed on the WS-RA WG charter. You 
> need to provide sufficient information to explain how all of the 
> delivery semantics can be represented in an EPR (or whatever metadata 
> languages that you may choose to). You should also provide some 
> evidence that you implemented WS-Eventing using the proposed mechanism 
> and interop tested it.
>
> Regards,
>
> Asir S Vedamuthu
>
> Microsoft Corporation
>
> *From:* Doug Davis [mailto:dug@us.ibm.com]
> *Sent:* Monday, March 30, 2009 5:50 AM
> *To:* Bob Freund
> *Cc:* Asir Vedamuthu; public-ws-resource-access@w3.org; 
> public-ws-resource-access-request@w3.org
> *Subject:* Re: [Bug 6692] New: Remove Mode from the specification
>
>
> 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 
> <http://www.w3.org/Submission/2008/SUBM-WS-MetadataExchange-20080813/>, 
> WS-Transfer 
> <http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060927/>, 
> WS-Eventing 
> <http://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/>and 
> WS-Enumeration 
> <http://www.w3.org/Submission/2006/SUBM-WS-Enumeration-20060315/> 
> 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> 
> [mailto:public-ws-resource-access-notifications-request@w3.org] On 
> Behalf Of bugzilla@wiggum.w3.org <mailto:bugzilla@wiggum.w3.org>
> Sent: Thursday, March 12, 2009 8:37 AM
> To: public-ws-resource-access-notifications@w3.org 
> <mailto: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 
> <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 
> <mailto:public-ws-resource-access-notifications@w3.org>
> ReportedBy: david.Snelling@UK.Fujitsu.com 
> <mailto:david.Snelling@UK.Fujitsu.com>
> QAContact: public-ws-resource-access-notifications@w3.org 
> <mailto: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 
> <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.
>


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

Received on Thursday, 2 April 2009 14:01:55 UTC