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

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.

-------------------------------------------------