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, 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.