W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > April 2009

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

From: Tom Rutt <tom@coastin.com>
Date: Thu, 02 Apr 2009 12:29:05 -0400
Message-ID: <49D4E7D1.90407@coastin.com>
To: Asir Vedamuthu <asirveda@microsoft.com>
CC: Doug Davis <dug@us.ibm.com>, Bob Freund <bob@freunds.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Asir Vedamuthu wrote:
my comments inline
>> 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.
>   
I think my term "non-standard" is too strong, I meant it would not be 
good (in my opinion) that
each spec which uses ws-eventing (standard or otherwise)  defines its 
own Mode extension
rather than getting the functions required by composing with ws* standards (
such as make connection, reliable messageing)

>   
>> 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.
>   
While I am a member of the ws man wg, this is not an official position 
of the wg.   However,
there is a strong expectation by ws-man members that the ws man v2 would 
be based on the w3c recs which will result from this w3c ws-ra group and 
other ws-* standards from oasis.
Tom
> 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



essage removed
Received on Thursday, 2 April 2009 16:30:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:48 UTC