- From: Doug Davis <dug@us.ibm.com>
- Date: Mon, 30 Mar 2009 14:45:24 -0400
- To: "Chou, Wu (Wu)" <wuchou@avaya.com>
- Cc: "Asir Vedamuthu" <asirveda@microsoft.com>, "Bob Freund" <bob.freund@hitachisoftware.com>, "Li Li" <lli5@avaya.com>, member-ws-resource-access@w3.org, public-ws-resource-access@w3.org, public-ws-resource-access-request@w3.org
- Message-ID: <OF93D59E6E.682F1EFF-ON85257589.0064D89E-85257589.00670C53@us.ibm.com>
Wu,
your use-case is a very interesting one. It shows one of the key points
that I've been trying to make - this isn't specific to WS-Eventing. The
need to send a message through a proxy (and have that proxy be defined by
someone other than the sending endpoint - the subscriber in your case)
could be just as meaningful to any EPR. For example, this could be needed
for uses of wsa:ReplyTo, or the registrationEPR in WSTX, or the AcksTo EPR
in RM. In all of these cases I believe this can be done by doing pretty
much what you've done below. That is, provide the ultimate destination
within the NotifyTo EPR but then use some extension mechanism to say "use
a proxy". In this particular case I would suggest that you define an
extension for the EPR structure - then this can be reused in _all_ WS-*
specs. For example:
<wse:NotfyTo>
<wsa:Address> http://avaya.com </wsa:Address>
<ext:Proxy> http://myproxy.com </ext:Proxy>
</wse:NotifyTo>
You can then also define a mU header that would require it to verify that
it will adhere to the extension. IMO, this will not only satisfy your
WS-Eventing needs but allow for this useful extension to be reused in lots
of places. I'm not keen on creating one-off type of solutions just for
certain WS-* specs - I think its a much better design to create reusable
components. For example, should RM create a "use a proxy" extension too
for its EPRs? Probably not when the above seems to work just fine for
both specs.
Its also worth pointing out that reusing the extensibility points of EPRs
is actually a far cleaner design. In the example you gave it looks like
the pub/sub code will need to understand this extension. While that is a
valid choice, it would be much less work for developers to have this
information encapsulated within the EPR itself. Then as this information
is moved through a system only one data structure needs to be passed
around - the EPR - and the pub/sub code might never actually need to know
about this extension at all. In your model below they would need to pass
around an EPR as well as the proxy information. And then when the next
extension comes along they'll need to add yet another. That a potentially
large code change each time. If, instead, they just knew about the EPR
structure then no code changes will be needed except down at the transport
layer of the product - where it should be. At that point they can examine
all of the bits of the EPR (including the proxy info) and take whatever
steps are necessary. This allows for an implementation to be designed
such that it isolates itself from areas of concern that are of no
consequence to it.
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.
"Chou, Wu (Wu)" <wuchou@avaya.com>
Sent by: public-ws-resource-access-request@w3.org
03/30/2009 02:12 PM
To
<public-ws-resource-access@w3.org>, <member-ws-resource-access@w3.org>
cc
"Asir Vedamuthu" <asirveda@microsoft.com>, "Bob Freund"
<bob.freund@hitachisoftware.com>, "Li Li" <lli5@avaya.com>
Subject
RE: [Bug 6692] New: Remove Mode from the specification
+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
------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>
Date: Sun, 29 Mar 2009 19:59:23 -0700
To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID:
<D46B7A44F5BD0C4A96D7D69E31C51D6B5098DCF4A7@NA-EXMSG-C118.redmond.corp.microsoft>
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] 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<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
------- 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
Received on Monday, 30 March 2009 18:46:44 UTC