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

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
> 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. 
> ------------------------------------------------- 
> 
> ______________________________________________________________________
> 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.