Re: WS-Eventing issue

public-ws-resource-access-request@w3.org wrote on 01/05/2011 04:48:51 AM:
> Hi everybody,

Hi David,

> I'm new to this mailing list. I come from Germany, institute of
> telematics at the University of Lübeck. I'm working with WS-Eventing and
> got some problems while reading the specification. Recently I had talked
> to Wu regarding to the missing wse:Identifier in the current working
> draft (http://www.w3.org/TR/2010/WD-ws-eventing-20100805). Wu told me
> that the wse:Identifier was removed because it is inconsistent with the
> WS-Addressing principle that reference parameters should be opaque.
> Instead of using wse:Identifier, the event source should provide an
> unique subscription manager EPR for every event subscription.

Correct - each Subscription Manager EPR should be unique - if there
is a need to know which one is being addressed.  There may be cases where
one EPR (SubMgr) is all that's needed but I think those are pretty rare.

> First it would be useful if the foregoing information is emphasized
> within the WS-Eventing specification. After reading the "2.4
> Subscription Managers" section
> (http://www.w3.org/TR/2010/WD-ws-eventing-20100805/#SubMgr) again,
> together with Wu's background knowledge, the subscription manager
> behaviour mentioned above would be clear. What's your opinion?

While I think the uniqueness aspect/requirement of the EPR is implied,
it can't hurt to be a bit clearer about this in 2.4.

> The method above works very well with one exception (may be I've not
> understand the reasonable cause behind the subscription end message): if
> an event source wants to quit a subscription by using a subscription end
> message, no subscription manager EPR is given to indicate the terminated
> subscription. If you take a look at the 2006' WS-Eventing submission, a
> subscription manager EPR is transmitted (comparing
> 
http://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/#Subscription_End
> with
> http://www.w3.org/TR/2010/WD-ws-eventing-20100805/#SubscriptionEnd).
> What's the reason for this modification? Should a subscription end
> message only be sent when every subscription is terminated? Otherwise,
> wow does an event sink know which subscription is terminated?

The SubscriptionEnd message will be sent to the NotifyTo EPR of that 
subscription.
This means that multiple SubscriptionEnd messages can be differentiated 
the same
way multiple Notifications messages (from differing subscriptions) are 
differentiated.
And this is done via the same mechanism that differentiates SubMgr EPRs. 
In other words,
when someone subscribes, and provides a NotifyTo EPR, they are expected to 

make it unique enough so that messages (notifications or SubEnd msgs) will 
be 
distinguishable from messages from other subscriptions.  This will 
typically mean
they will include a unique ref-parameter.  Its worth noting that, just 
like in the
SubMgr EPR case, if a subscriber doesn't care to make this distinction 
then they
are not required to make each NotifyTo EPR unique - its up to them.

You are correct that ws-e used to include the SubMgr EPR in the SubEnd 
message but
this was problematic because there was no well-defined EPR comparison 
algorithm
defined.  So, w/o that there was no guaranteed way to check which SubEnd 
msg came
from which subscription.  But, since each Notification msg might need to 
be linked
to its subscription as well and we do that linking through unique NotifyTo 
EPRs
it made sense to use the same mechanism for the SubEnd msg.

Does this help or make sense?

-Doug


> Thanks in advance for your hints und helps,
> 
> David Gregorczyk
> 
> -- 
> Dipl.-Inf. David Gregorczyk
>     Wissenschaftlicher Mitarbeiter
> 
> 
> UNIVERSITÄT ZU LÜBECK
>     INSTITUT FÜR TELEMATIK
> 
>     Ratzeburger Allee 160
>     23562 Lübeck
> 
>     Tel +49 451 500 5386
>     Fax +49 451 500 5382
>     gregorczyk@itm.uni-luebeck.de
> 
>     www.itm.uni-luebeck.de
> 
> 
>