RE: Options on "Wrap" and "Unwrap" formats for WS-Eventing

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
The more I'm around some people, the more I like my dog.



Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 
12/17/2010 07:10 PM

To
Gilbert Pilz <gilbert.pilz@oracle.com>, "Chou, Wu (Wu)" <wuchou@avaya.com>
cc
Bob Freund <bob.freund@hitachisoftware.com>, 
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, 
"public-ws-resource-access-request@w3.org" 
<public-ws-resource-access-request@w3.org>, Doug Davis/Raleigh/IBM@IBMUS, 
"tom@coastin.com" <tom@coastin.com>
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] 
Sent: Friday, December 17, 2010 12:13 PM
To: Chou, Wu (Wu)
Cc: Bob Freund; public-ws-resource-access@w3.org; 
public-ws-resource-access-request@w3.org; Doug Davis; Ram Jeyaraman; 
tom@coastin.com
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.
-------------------------------------------------