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
From: Steve Graham
[mailto:sggraham@us.ibm.com]
Sent: 24 September 2004 14:52
To: David Hull
Cc: wsn@lists.oasis-open.org
Subject: Re: [wsn] Comparison of
WSN and WS-Eventing
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/>
++++++++
David Hull
<dmh@tibco.com>
09/23/2004 11:53 PM
|
To
|
wsn@lists.oasis-open.org
|
cc
|
|
Subject
|
[wsn] Comparison of WSN and WS-Eventing
|
|
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.