- From: Geoff Bullen <Geoff.Bullen@microsoft.com>
- Date: Wed, 29 Apr 2009 06:57:30 -0700
- To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <5AAAA6322448AA41840FC4563A30D6E843A0176D22@NA-EXMSG-C122.redmond.corp.microsoft>
Hi all,
As was decided in the WG meeting yesterday, we would like to drive the discussion around issue 6692 forwards, if we can, by trying to outline all the possible solutions. We are not wanting to debate the legitimacy of the proposals (as has already been done extensively on the list), merely to list them so that people can at least see them all and decide if they have value for their company or not. In the end, the idea is for people to be able to rate solutions and hopefully find some solution that everyone can live with. I am completely open for more solutions to be added in here, in the spirit of finding some kind of compromise. I am also open to changing the wording associated with solutions, if you think they do not adequately describe the solution.
I also understand that Doug and Gil have already started a Wiki on this, but it is not clear that is the best way to drive progress here, but I am open to suggestions, of course. Here is my current list including, I believe, the three current Wiki entries. This was my action item from the meeting.
First, can we agree the list is complete, or are there any other potential solutions that people want to put on the table?
(Again the aim in stage 1 is to be inclusive, you may think a solution on the list is invalid, that is fine, we will get a change to cull the list in stage 2).
If I hear nothing before end of Thursday, I will assume the list is complete.
Then we can move on to trying to reduce the size of the list to something more reasonable.
Hopefully, from that reduced list we can find one solution that everyone can live with.
--Geoff
Current Suggested Solutions
1) Use Delivery / Mode (in the eventing namespace) - this is the current solution.
[Body]
<wse:Subscribe ... />
<wse:Delivery mode="..." />
2) Use a single pre-defined SOAP header (in the eventing namespace). Delivery element deleted from the Eventing spec. Example:
[Header]
<wse:Delivery mode="PULL" mustUnderstand="1"/>
3) Use multiple predefined SOAP headers (in the eventing namespace), representing what used to be "mode". Delivery element deleted from the Eventing spec. Example:
[Header]
<wse:UsePULL mustUnderstand="1"/>
or
<wse:UsePUSH mustUnderstand="1"/>
4) Use no pre-defined headers or elements in the eventing namespace. NotifyTo EPR used to determine transport. Normal extension mechanism used to extend functionality. Delivery element deleted from the Eventing spec.
5) Insist every delivery mode has a unique header, but don't specify any of them in the spec. This is a half way house between 3 and 4.
6) Use solution 4 but include a backwards-compatibility feature to define a header to allow clients to specify that the event source MUST support the current Delivery element in the body. Example:
[Header]
<???:UseDelivery mustUnderstand="1"/>
[Body]
<wse:Subscribe ... />
<???:Delivery mode="..." />
7) Eventing spec defines WS-Policy assertions, possibly in NotifyTo EPR, to allow for runtime negotiation. Remove wse:Delivery.
8) WS-Policy assertions used for runtime negotiation, possibly in NotifyTo EPR, but not defined in Eventing spec. Remove wse:Delivery.
9) Remove @Mode, leave wse:Delivery with attribute and element extension. Example:
[body]
<wse:Subscribe wsman:NotifyAcks="1">
<wse:Delivery wso:Mode="..." />
...
10) Remove @Mode, leave wse:Delivery without attribute and element extension. Example (see 9, but without attributes)
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Monday, April 20, 2009 4:56 PM
To: Kemp, Devon
Cc: public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: [Bug 6692] New: Remove Mode from the specification
Devon,
please see http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0016.html - Mode is broken from a composibility and scalability perspective.
Also, as mentioned by Gil - the proposal does not remove ANY feature from WS-Eventing - its just a change to what the XML in the subscribe looks like - and this is done to align it with the rest of the WS-* stack - which, in the end, is a good thing.
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.
"Kemp, Devon" <Devon.Kemp@cda.canon.com>
Sent by: public-ws-resource-access-request@w3.org
04/17/2009 04:05 PM
To
<public-ws-resource-access@w3.org>
cc
Subject
RE: [Bug 6692] New: Remove Mode from the specification
Greetings-
Canon is also very concerned about the proposal to remove the Delivery Mode attribute, and defined delivery modes, from the WS-Eventing specification.
1) Canon has several products currently in the market that contain implementations of DPWS, which relies on the Push Mode of event delivery. Should the WS-Eventing specification remove the delivery mode, our investment in DPWS will be at risk.
2) It appears that you're not requiring any specific type of delivery mode. We have learned that in order to assure interoperability, there must be at least one defined type of delivery modes. Push mode has been used in several applications of DPWS and has proved (at least to us) to be an easy to implement, common denominator, for eventing messages.
3) The lack of a formal extension point ("Delivery Mode") prevents easy adoption by other specifications in the industry, reducing WS-Eventing's usability.
4) Nothing appears to be gained by the removal of the Delivery Mode attribute. (Don't fix something that isn't broken.)
We ask that you please reconsider your proposal to remove the Delivery Mode attribute, and keep this in the WS-Eventing specification.
Best Regards,
-Devon Kemp
Canon
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Asir Vedamuthu
Sent: Sunday, March 29, 2009 7:59 PM
To: public-ws-resource-access@w3.org
Subject: RE: [Bug 6692] New: Remove Mode from the specification
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<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<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.
Received on Wednesday, 29 April 2009 13:58:21 UTC