- From: Chou, Wu (Wu) <wuchou@avaya.com>
- Date: Mon, 3 Jan 2011 16:25:37 -0500
- To: <david.snelling@uk.fujitsu.com>, <public-ws-resource-access@w3.org>
- Cc: <public-ws-resource-access-request@w3.org>, "Doug Davis" <dug@us.ibm.com>, "Gilbert Pilz" <gilbert.pilz@oracle.com>, "Li, Li (Li)" <lli5@avaya.com>
- Message-ID: <F81BDFA28AE48D4793E253362D1F7A740112B5C4@300813ANEX2.global.avaya.com>
David,
Requiring event sink supports both wrap and unwrapped event delivery may
not make sense for the following reasons:
1. According to WS-E, it is the event subscriber/sink determines the
event delivering format (wrapped or unwrapped) in its subscription
message. It is not the other way around.
2. It is better for event source to meet the needs of various types of
potential event subscribers (one-to-many), vs. requiring every event
sink to implement additional options (many-to-one).
3. Event sinks typically have much less resources than event source, and
moreover, their options are limited by various application environments,
e.g. mobile, etc.
Some of the reasons/benefits of using wrapped event sink are:
1. One interface for all types of events
2. Loosely coupled programming model
3. Good for event proxy applications, where it needs to handle all types
of events, including some new types of events that may add/occur in the
future.
4. Save power, using wrapped event sink - multiple events can be
delivered in one notification message, whereas using unwrapped event
sink - every single event requires one dedicated notification message
(critical for mobile and resource constrained devices).
Regards,
- Wu Chou.
Avaya Labs Research
________________________________
* Related messages: [ Next message
<http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Dec/0
036.html> ] [ Previous message
<http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Dec/0
034.html> ] [ In reply to
<http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Dec/0
034.html> ] [ Next in thread
<http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Dec/0
036.html> ] [ Replies
<http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Dec/0
035.html#replies> ]
From: David Snelling <david.snelling@uk.fujitsu.com
<mailto:david.snelling@uk.fujitsu.com?Subject=Re%3A%20Options%20on%20%22
Wrap%22%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=%
253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&Reference
s=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> >
Date: Mon, 20 Dec 2010 15:46:47 +0000
CC: Doug Davis <dug@us.ibm.com
<mailto:dug@us.ibm.com?Subject=Re%3A%20Options%20on%20%22Wrap%22%20and%2
0%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=%253C9B335D3F-2B
EA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&References=%253C9B335D3F
-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> >,
"public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=Re%3A%20Options%20on%20
%22Wrap%22%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-T
o=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&Refere
nces=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> "
<public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=Re%3A%20Options%20on%20
%22Wrap%22%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-T
o=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&Refere
nces=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> >
Message-ID: <9B335D3F-2BEA-453C-A30A-E04838868931@uk.fujitsu.com>
To: Gilbert Pilz <gilbert.pilz@oracle.com
<mailto:gilbert.pilz@oracle.com?Subject=Re%3A%20Options%20on%20%22Wrap%2
2%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=%253C9B
335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&References=%253
C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> >
Gil,
[Again, I'm not sure I like this suggestion, it is just an option.]
On 20 Dec 2010, at 15:05, Gilbert Pilz wrote:
> I'm not sure I understand your last paragraph. Are you suggesting that
we require Event Sinks to support both wrapped and unwrapped and allow
the Source to dynamically pick which one it wants to use at runtime?
Yes, you do understand the proposal.
> If this is your implicit proposal, I have to say that I don't see the
point. All of the arguments for using either wrapped or unwrapped deal
with the way the Sink receives and processes Notifications and how you
go about building the code that performs these functions base on your
understanding (or lack thereof) of the structure of the Notifications.
>From my perspective, this is not hard to deal with. If the notification
message's outermost element is <wse:NotifyEvent/>, the message is
wrapped, otherwise it's not. The SOAP envelope handles the
intermediaries and the final recipient can handle the above simple
choice easily.
>
> ~ gp
>
> On 12/20/2010 12:56 AM, David Snelling wrote:
>>
>> Doug,
>>
>> I agree. Even where lightweight devices are managed externally, the
few bytes to add a wrapper in the name of actual interoperability seems
worth it.
>>
>> One other alternative, which I don't know if I like or not. We could
require the event sink to always understand both. They are trivial to
tell apart (wse:NotifyEvent is NS qualified) and the sinks tend to be
smarter anyway. Also, we could then make the sources even simpler.
>>
>> On 18 Dec 2010, at 15:34, Doug Davis wrote:
>>
>>>
>>> While I don't think it would be accurate to claim that support for
both (option 4) is cost-free, given everything else that an event
source/subMgr needs to do I have my doubts that supporting wrapped will
push an implementation over the edge. When we consider the cost of
managing subscriptions, possibly filtering, timeouts, etc.... these
seem much heavier than supporting wrapped. To me it comes down to a
boolean (wrapped vs unwrapped) per subscription and then a few lines to
code to add an extra wrapper to the Body. Of course people's mileage
may vary, but if it requires a whole lot more than that I think the
implementation may have more serious things to worry about. :-)
>>>
>>> thanks
>>> -Doug
>>> ______________________________________________________
>>> STSM | Standards Architect | IBM Software Group
>>> (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
<mailto:dug@us.ibm.com?Subject=Re%3A%20Options%20on%20%22Wrap%22%20and%2
0%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=%253C9B335D3F-2B
EA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&References=%253C9B335D3F
-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E>
>>> The more I'm around some people, the more I like my dog.
>>>
>>>
>>> Ram Jeyaraman <Ram.Jeyaraman@microsoft.com
<mailto:Ram.Jeyaraman@microsoft.com?Subject=Re%3A%20Options%20on%20%22Wr
ap%22%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=%25
3C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&References=
%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> >
>>> 12/17/2010 07:10 PM
>>>
>>> To
>>> Gilbert Pilz <gilbert.pilz@oracle.com
<mailto:gilbert.pilz@oracle.com?Subject=Re%3A%20Options%20on%20%22Wrap%2
2%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=%253C9B
335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&References=%253
C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> >, "Chou,
Wu (Wu)" <wuchou@avaya.com
<mailto:wuchou@avaya.com?Subject=Re%3A%20Options%20on%20%22Wrap%22%20and
%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=%253C9B335D3F-
2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&References=%253C9B335D
3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> >
>>> cc
>>> Bob Freund <bob.freund@hitachisoftware.com
<mailto:bob.freund@hitachisoftware.com?Subject=Re%3A%20Options%20on%20%2
2Wrap%22%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=
%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&Referenc
es=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> >,
"public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=Re%3A%20Options%20on%20
%22Wrap%22%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-T
o=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&Refere
nces=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> "
<public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=Re%3A%20Options%20on%20
%22Wrap%22%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-T
o=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&Refere
nces=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> >,
"public-ws-resource-access-request@w3.org
<mailto:public-ws-resource-access-request@w3.org?Subject=Re%3A%20Options
%20on%20%22Wrap%22%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In
-Reply-To=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253
E&References=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%
253E> " <public-ws-resource-access-request@w3.org
<mailto:public-ws-resource-access-request@w3.org?Subject=Re%3A%20Options
%20on%20%22Wrap%22%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In
-Reply-To=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253
E&References=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%
253E> >, Doug Davis/Raleigh/IBM@IBMUS, "tom@coastin.com
<mailto:tom@coastin.com?Subject=Re%3A%20Options%20on%20%22Wrap%22%20and%
20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=%253C9B335D3F-2
BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&References=%253C9B335D3
F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> " <tom@coastin.com
<mailto:tom@coastin.com?Subject=Re%3A%20Options%20on%20%22Wrap%22%20and%
20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=%253C9B335D3F-2
BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&References=%253C9B335D3
F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> >
>>> Subject
>>> RE: Options on "Wrap" and "Unwrap" formats for WS-Eventing
>>>
>>>
>>>
>>>
>>>
>>>
>>> My preference is option (2) below.
>>>
>>> On option (4) - requiring support for both formats is a problem for
resource-constrained low-powered devices. In constrained environments,
implementations are usually up against the wall in terms of what they
can build into resource-constrained devices. Supporting features those
devices would never use is an unnecessary burden. Usually such
implementations carefully avoid all unnecessary features so as to save
precious battery life and to improve efficiency. For WS-Eventing to be
useful in such environments, it is important to keep the specification
generic enough so those specialized environments can use and specialize
the specification for their own needs; otherwise, such implementations
may be forced to invent their own eventing solutions. Hence, it is
important to require only those features in the specification that are
absolutely essential and leave room for variability/optionality.
>>>
>>> From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com
<mailto:gilbert.pilz@oracle.com?Subject=Re%3A%20Options%20on%20%22Wrap%2
2%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=%253C9B
335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&References=%253
C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> ]
>>> Sent: Friday, December 17, 2010 12:13 PM
>>> To: Chou, Wu (Wu)
>>> Cc: Bob Freund; public-ws-resource-access@w3.org
<mailto:public-ws-resource-access@w3.org?Subject=Re%3A%20Options%20on%20
%22Wrap%22%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-T
o=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&Refere
nces=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E> ;
public-ws-resource-access-request@w3.org
<mailto:public-ws-resource-access-request@w3.org?Subject=Re%3A%20Options
%20on%20%22Wrap%22%20and%20%22Unwrap%22%20formats%20for%20WS-Eventing&In
-Reply-To=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253
E&References=%253C9B335D3F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%
253E> ; Doug Davis; Ram Jeyaraman; tom@coastin.com
<mailto:tom@coastin.com?Subject=Re%3A%20Options%20on%20%22Wrap%22%20and%
20%22Unwrap%22%20formats%20for%20WS-Eventing&In-Reply-To=%253C9B335D3F-2
BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E&References=%253C9B335D3
F-2BEA-453C-A30A-E04838868931%40uk.fujitsu.com%253E>
>>> Subject: Re: Options on "Wrap" and "Unwrap" formats for WS-Eventing
>>>
>>> Wu,
>>>
>>> Overall it seems that there are 4 ways we can address this issue:
>>>
>>> 1.) Allow Event Sources to optionally support either wrapped,
unwrapped, or neither (state of the current draft).
>>>
>>> 2.) Require Event Sources to support unwrapped; allow optional
support of wrapped.
>>>
>>> 3.) Require Event Sources to support wrapped; allow optional support
of unwrapped.
>>>
>>> 4.) Require Event Sources to support both wrapped and unwrapped.
>>>
>>> Oracle cannot accept (1) due to the interoperability issues with
mis-matched delivery formats. Oracle also cannot accept (3) because of
the issues we have with wrapped notifications [1]. Oracle would prefer
option (2), but we could live with option (4).
>>>
>>> [1]
http://blogs.oracle.com/wsinterop/2009/02/the_problem_with_wrapped_notif
.html
>>>
>>> ~ gp
>>>
>>> On 12/16/2010 1:25 PM, Chou, Wu (Wu) wrote:
>>> Bob,
>>>
>>> Here is our study on Wrap and Unwrap delivery format options for
WS-Eventing.
>>>
>>> It is enclosed here for information sharing as some food of thought,
because this can be a major decision and deserves a deeper study.
>>>
>>> Many thanks,
>>>
>>> - Wu Chou.
>>>
>>> Avaya Labs Research
>>>
>>> ------------------
>>> Background - WS-Eventing specifies two delivery formats - wrap and
unwrap. Both have critical use cases and widely used.
>>> Question - Should "wrap" event delivery format be optional or
should both "wrap" and "unwrap" formats be required features for an
event source implementation.
>>> Observation - After some study, we think - both wrap and unwrap
delivery formats should be required features for WS-Eventing
implementation (Doug's proposal) - is a better one for
the following reasons.
>>> 1. Maximizing the interoperability of WS-E implementation
>>> When both wrap and unwrap delivery formats are required for an event
source implementation, it eliminates the interoperability issue caused
by having "wrap" delivery format as an option. This
interoperability issue is acute, as a client with a "wrap" event sink
cannot receive events from a source that does not support "wrap" event
delivery.
>>>
>>> 2. Maximizing the benefits of WS-E client (event subscribers)
>>> One event source can have thousands of event subscribers (clients)
from various environments that subscribe to it. When both "wrap" and
"unwrap" formats are required, a client can have its own choice on which
format is best for its needs and application.
>>>
>>> If "wrap" format is optional, then the event source may terminate at
will the support of "wrap" event delivery for new event subscription
request. As a consequence, every client has to prepare a
separate "unwrap" event sink as a backup at all times, in case that
during the next subscription to the same event source, the "wrap" option
is terminated. This is going to be a huge problem and cause many
applications to break - making the WS-E client based on "wrap" event
delivery not workable.
>>>
>>> 3. Maximizing the application scope of WS-E
>>> This "wrap" delivery format specified in WS-E provides a standard
generic event sink to receive events from various sources. This
decoupling - provided in "wrap" format delivery - allows a client to
develop its event sink in a distributed fashion, and use one event sink
for all events, including some new event sources that may be yet to
occur, e.g. event sink that acts as a proxy for all interested events
from all sources - a typical case for both resource constrained devices
or event sink gateway.
>>>
>>> 4. Negligible implementation cost
>>> The implementation overhead from supporting "unwrap" to supporting
both "wrap", and "unwrap" delivery format is negligible (e.g. in the
interceptor chain architecture), as the only thing involved is to add a
standard element wrapper on the notification message.
>>>
>>> Summary
>>> "wrap" event delivery format is better to be a required feature for
an event source implementation due to the following reasons:
>>> 1. Maximizing the interoperability
>>> 2. Maximizing the benefits of WS-E client implementation
>>> 3. Maximizing the application scope of WS-E
>>> 4. Negligible implementation cost.
>>>
>>> Without "wrap" event delivery as a required feature, the "wrap"
delivery format is broken - redundant, unreliable, not interoperable,
tightly coupled programming model, unfit for event proxy applications,
resource waste for WS-E client implementation for using wrapped
delivery, etc.
>>> -------------------------------------------------
>>>
>>>
______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security
System.
>>> For more information please visit http://www.messagelabs.com/email
>>>
______________________________________________________________________
>>
>> Take care:
>>
>> Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
>> Fujitsu Laboratories of Europe Limited
>> Hayes Park Central
>> Hayes End Road
>> Hayes, Middlesex UB4 8FE
>> Reg. No. 4153469
>>
>> +44-7590-293439 (Mobile)
>>
>>
>>
______________________________________________________________________
>>
>> Fujitsu Laboratories of Europe Limited
>> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
>> Registered No. 4153469
>>
>> This e-mail and any attachments are for the sole use of addressee(s)
and
>> may contain information which is privileged and confidential.
Unauthorised
>> use or copying for disclosure is strictly prohibited. The fact that
this
>> e-mail has been scanned by Trendmicro Interscan does not guarantee
that
>> it has not been intercepted or amended nor that it is virus-free.
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
Fujitsu Laboratories of Europe Limited
Hayes Park Central
Hayes End Road
Hayes, Middlesex UB4 8FE
Reg. No. 4153469
+44-7590-293439 (Mobile)
Received on Monday, 3 January 2011 21:26:48 UTC