Apologies
for the delay in making this
comment.
As an
extensive user of web services and
publish / subscribe mechanisms there is obvious benefit to having a
single standard
solution for ‘notification’ rather then two very similar
specifications, so we’d support the idea of investigating the merger of
WSE/WSN.
I personally
suspect however that the
biggest difference between WSE / WSN from a WSE authors perspective is
WSN’s
dependency on WS-RF? I know that questions have been raised about this
in
the TC already. Has anyone done a quick analysis of what WS-RF brings
to
WSN and the potential impact of its removal?
Chris Hipson
Web Services
Integration Team - British
Telecom
I scanned your
summary. I need to spend more
thoughtful time with it. However, one point I do quibble with:
>Subscription
End notification
>WSE subscriptions MAY
include a "party to notify in case of my demise" EPR, which MAY
be sent a message if the subscription must be terminated
>unexpectedly.
WSN does not yet provide such a facility.
Not
true. WSN "borrows" this facility from WS-ResourceLifetime. WS-RL
defines a "topic" for resource destruction that MAY be supported by the Web service (if
it allows
subscription on death notices for Ws-Resources it is associated with).
So if I
am a subscriber, holding an EPR
to a Subscription resource created by some previous Subscribe request,
then I
could inspect the Subscription to see a) If it supported
NotificationProducer
portType, and if so, if its wsnt:Topics resource property contained
the
'wsrf-rl:ResourceTermination"
topic, then I could send a subscribe request to that resource on the
ResourceTermination topic, and thereby receive notificaiton if the
subscription
is destroyed.
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
As has been noted, the latest draft of WS-Eventing is very similar in
structure
to WS-BaseNotification. The following is an attempt to characterize
the
similarities and the remaining differences between the two.
I apologize in advanced for the somewhat unpolished nature of this
summary.
I've been temporarily busy with various non-WSN matters, but wanted to
get something out to the list before the conference call. I believe
everything here is basically accurate, but there may be silly mistakes
or
omissions (which I will try to correct quickly, particularly if
notified of
them :-). I have checked my notes from previous comparison work, but I
haven't gone back to the documents to cross-check the details of this
message.
Terminology
The basic roles in WSN and WSE are not completely identical, but to a
first
approximation you can translate as follows:
|
Subscriber
|
Subscribing EventSink
|
|
Publisher
|
EventSource
|
|
NotificationProducer
|
EventSource
|
|
NotificationConsumer
|
EventSink
|
Both WSE and WSN allow for "indirect" scenarios, where the service
accepting
subscription requests may not be the party sending notifications.
The
Implied Resource Pattern
WSE essentially uses the IRP: A successful subscription produces an EPR which may be used to refer to the
subscription. This is a change from the previous draft, which had used
subscription IDs as explicit parameters in the control messages. The
WSE
spec spells out the semantic requirements of the IRP (mainly unique
addressability) without reference to the IRP per se, or to WSRF or WSRP.
The shift from subscription IDs to EPRs removes a major technical
barrier to
reconciling the two.
Degree
of
control over live subscriptions
WSN allows subscriptions to be paused and resumed, and also allows for
various
parameters such as topic filtering and even destination consumer to be
updated
on the fly. WSE simply allows an existing subscription to be renewed
or
canceled.
Resource-oriented
operations
Because WSE does not reference WSRF, it must define operations such as
destroy,
renew and get properties directly. In particular, WSE treats leasing
and
renewal (scheduled termination) as inherent to a subscription, while
WSE
inherits them from WSRF. The latter approach would allow WSN to
leverage
any refinements in resource management that WSRF may produce.
Filtering
and
Topics
WSE uses a simple model of filtering: a subscribe request may contain
an
arbitrary "filter" element, which could be, but need not be, used to
realize the three-level filtering of WSN. Unlike WSN, WSE does not
give
topics special status; there is no defined way to query an EventSource
for its
set of topics, because there is no set of topics per se. Similarly,
WSE
does not define GetNextMessage, as this is tied to a topic.
Delivery
modes
and subscription policy
WSE introduces the notion of a "delivery mode" to cover the various
parameters of message delivery, as distinct from the mechanics of
establishing
a subscription. While this is currently only defined for the usual
callback mechanism, it explicitly allows for pull-based delivery, and
presumably for all sorts of other parameters.
It is not immediately clear how this relates to the subscription policy
element
in a WSN subscribe request. Syntactically they are very similar, but
delivery modes appear broader. For example, WSE realizes
"useNotify" via delivery modes
Subscription
End notification
WSE subscriptions MAY
include
a "party to notify in case of my demise" EPR,
which MAY be sent a
message if
the subscription must be terminated unexpectedly. WSN does not yet
provide such a facility.
Normative
Description of SOAP
WSE gives direct normative requirements for SOAP
messages. WSN describes messages in more general WSDL terms, with
non-normative SOAP
examples.
There are, of course, differences in naming and structure between the
two, but these are symptomatic of the more basic differences.