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

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

From: Chou, Wu (Wu) <wuchou@avaya.com>
Date: Tue, 5 May 2009 11:46:47 -0400
Message-ID: <F81BDFA28AE48D4793E253362D1F7A740112ABA2@300813ANEX2.global.avaya.com>
To: "Gilbert Pilz" <gilbert.pilz@oracle.com>
Cc: <public-ws-resource-access@w3.org>, <member-ws-resource-access@w3.org>, "Asir Vedamuthu" <asirveda@microsoft.com>, "Bob Freund" <bob.freund@hitachisoftware.com>, "Li, Li (Li)" <lli5@avaya.com>
We implemented this. - WC

________________________________

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Tuesday, May 05, 2009 10:49 AM
To: Chou, Wu (Wu)
Cc: public-ws-resource-access@w3.org; member-ws-resource-access@w3.org;
Asir Vedamuthu; Bob Freund; Li, Li (Li)
Subject: Re: [Bug 6692] New: Remove Mode from the specification


You didn't answer my question. Has anyone actually implemented this?

- gp

Chou, Wu (Wu) wrote: 

	It is a real use case, and it cannot be put into the Delivery
extension because the subscriber expects a WS-E fault if not supported.

	Removing Mode and using SOAP extensions with mU (mustUnderstand)
header is not a good option to us. Admittedly, we hope the same WS-E
semantics can be used in a non-SOAP and non-EPR environment (so does the
TAG of W3C), and removing Mode will create a gap. 

	But a more practical issue with using SOAP header is: business
processes, e.g. WS-BPEL, etc., are typically specified and designed at
the abstract service level, and binding to SOAP or to other transports
is at the late stage by an almost automatic process. 

	Using SOAP header extensions will take away this WS-E Mode
semantics from the abstract level, making it only available after SOAP
binding. Unfortunately, SOAP header extensions are not very friendly to
many design tools today. It is much easier to design, mock, visualize,
test and verify the services at the abstract level by those tools, and
it is much more difficult when SOAP header extensions, and bindings are
involved. For example, SOAP header extensions handling is still a
headache for many WS-BPEL engines and business process (BP) design tools
today.

	Thanks,

	- Wu Chou


________________________________

	From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
	Sent: Thursday, April 30, 2009 1:42 PM
	To: Chou, Wu (Wu)
	Cc: public-ws-resource-access@w3.org;
member-ws-resource-access@w3.org; Asir Vedamuthu; Bob Freund; Li, Li
(Li)
	Subject: Re: [Bug 6692] New: Remove Mode from the specification
	
	
	Wu,
	
	I'm trying to clear something up, and I was wondering if you
could help me. Has the "concrete use case" you discuss below actually
been implemented by anybody, or is it a hypothetical, concrete use case?
	
	- gp
	
	Chou, Wu (Wu) wrote: 

		+1
		Asir: Many thanks for sharing your thoughts on this
issue.  And I attach one of our use cases of Mode in WS-E Delivery
below. 
		 
		- Wu Chou
		 
		Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs
Research | AVAYA | 233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920
| Voice/Fax: 908-696-5198 / 908-696-5401 | wuchou@avaya.com
<blocked::mailto:wuchou@avaya.com> 
		 
		------Use Case of MODE in WS-E Delivery -----
		 
		Here is a  concrete use case where the  subscriber
requests the event source to push the  event  notifications through a
proxy, obtained either through an out-of-band channel (not specified in
the Subscribe request, e.g. the enterprise registers a special event
notification proxy with the service provider) or dynamically specified
in the Subscribe request. Certainly this behavior cannot be conveyed by
the wse:NotifyTo. This critical use case thus justifies the need for the
Mode attribute  in WS-E Delivery. 
		 To indicate the use of an out-of-band proxy, the
Subscribe request body looks like this:

		<wse:Subscribe>

		            <wse:Delivery Mode="urn:push_thru_proxy" >

		                        <wse:NotifyTo>...</wse:NotifyTo>

		            </wse:Delivery>

		</wse:Subscribe>

		 To indicate the use of a dynamic proxy, the Subscribe
request body looks like this:

		 <wse:Subscribe>

		            <wse:Delivery Mode="urn:push_thru_proxy" >

		                        <wse:Notifyto>...</wse:Notifyto>

		                        <ext:Proxy>...</ext:Proxy>

		            </wse:Delivery>

		</wse:Subscribe>

		

		"Mode=urn:push_thru_proxy" cannot be put into the
Delivery extension. This is because if the source cannot support
"push_thru_proxy", it must fault as defined by Mode in Delivery, and the
subscriber expects a standard wse:DeliveryModeRequestedUnavailable
fault. And there is no standard WS-E fault for items in the Delivery
extension.

		----------

		 
		From: Asir Vedamuthu <asirveda@microsoft.com
<mailto:asirveda@microsoft.com?Subject=RE%3A%20%5BBug%206692%5D%20New%3A
%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253CD46B7A44F
5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft
.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40N
A-EXMSG-C118.redmond.corp.microsoft.com%253E> > 
		Date: Sun, 29 Mar 2009 19:59:23 -0700
		To: "public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=RE%3A%20%5BBug%206692%5
D%20New%3A%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253
CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp
.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098
DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E> "
<public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=RE%3A%20%5BBug%206692%5
D%20New%3A%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253
CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp
.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098
DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E> > 
		Message-ID:
<D46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7@NA-EXMSG-C118.redmond.corp..
microsoft.com>
<mailto:D46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7@NA-EXMSG-C118.redmond
.corp..microsoft.com>  
		
		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-MetadataEx
change-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-200
60315/> 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?Subject=R
E%3A%20%5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specific
ation&In-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-E
XMSG-C118.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C
4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%
253E>  [mailto:public-ws-resource-access-notifications-request@w3.org
<mailto:public-ws-resource-access-notifications-request@w3.org?Subject=R
E%3A%20%5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specific
ation&In-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-E
XMSG-C118.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C
4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%
253E> ] On Behalf Of bugzilla@wiggum.w3.org
<mailto:bugzilla@wiggum.w3.org?Subject=RE%3A%20%5BBug%206692%5D%20New%3A
%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253CD46B7A44F
5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft
.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40N
A-EXMSG-C118.redmond.corp.microsoft.com%253E> 
		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=RE%3A%20%
5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specification&In
-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C11
8.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D6
9E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E> 
		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
<mailto:public-ws-resource-access-notifications@w3.org?Subject=RE%3A%20%
5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specification&In
-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C11
8.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D6
9E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E>
<mailto:public-ws-resource-access-notifications@w3.org
<mailto:public-ws-resource-access-notifications@w3.org?Subject=RE%3A%20%
5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specification&In
-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C11
8.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D6
9E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E> >
		
		        ReportedBy: david.Snelling@UK.Fujitsu.com
<mailto:david.Snelling@UK.Fujitsu.com?Subject=RE%3A%20%5BBug%206692%5D%2
0New%3A%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253CD4
6B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.mi
crosoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF
4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E>
<mailto:david.Snelling@UK.Fujitsu.com
<mailto:david.Snelling@UK.Fujitsu.com?Subject=RE%3A%20%5BBug%206692%5D%2
0New%3A%20Remove%20Mode%20from%20the%20specification&In-Reply-To=%253CD4
6B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.mi
crosoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF
4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E> >
		
		         QAContact:
public-ws-resource-access-notifications@w3.org
<mailto:public-ws-resource-access-notifications@w3.org?Subject=RE%3A%20%
5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specification&In
-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C11
8.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D6
9E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E>
<mailto:public-ws-resource-access-notifications@w3.org
<mailto:public-ws-resource-access-notifications@w3.org?Subject=RE%3A%20%
5BBug%206692%5D%20New%3A%20Remove%20Mode%20from%20the%20specification&In
-Reply-To=%253CD46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7%40NA-EXMSG-C11
8.redmond.corp.microsoft.com%253E&References=%253CD46B7A44F5BD0C4A96D7D6
9E31C51D6B5098DCF4A7%40NA-EXMSG-C118.redmond.corp.microsoft.com%253E> >
		
		
		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.
		  
		 
		Wu Chou, IEEE Fellow, Ph.D. | Director |Dialogue System
Research | AVAYA | 233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920
| Voice/Fax: 908-696-5198 / 908-696-5401 | wuchou@avaya.com
<blocked::mailto:wuchou@avaya.com>  
		 
Received on Tuesday, 5 May 2009 15:47:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:17:59 GMT