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