- From: Doug Davis <dug@us.ibm.com>
- Date: Mon, 30 Mar 2009 13:14:05 -0400
- To: Asir Vedamuthu <asirveda@microsoft.com>
- Cc: Bob Freund <bob@freunds.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <OF89D088C3.EDAE3E82-ON85257589.005E7224-85257589.005EB049@us.ibm.com>
Or, you could complete your AI from last week [1]
ACTION: Wu and Asir We need to use use cases for Mode not equal to
Push Mode to better understand why it is needed.
and provide a use case to show that it can not be supported w/o a Mode
attribute.
[1]: http://www.w3.org/2002/ws/ra/9/03/2009-03-24.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.
Asir Vedamuthu <asirveda@microsoft.com>
03/30/2009 12:46 PM
To
Doug Davis/Raleigh/IBM@IBMUS, Bob Freund <bob@freunds.com>
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@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 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.
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, 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.
Received on Monday, 30 March 2009 17:15:13 UTC