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