wsn message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsn] Comparison of WSN and WS-Eventing
- From: Steve Graham <sggraham@us.ibm.com>
- To: David Hull <dmh@tibco.com>
- Date: Fri, 24 Sep 2004 09:52:28 -0400
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]