Steve Graham wrote:
I scanned your summary. I need
to spend more thoughtful time with it. However, one point I do quibble
with:
You're quite right. Thanks for catching that.
>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.
|