Response to Issue 6917 - WS-Eventing: Performance Flaw

Ben,

At our F2F meeting this week we had a chance to discuss this issue.  
Basically there are several ways to simplify subscriptions, which can  
remove some extra processing such as XPath matching. One I know well  
is WS-Topics and Gilbert Pilz proposed a simpler approach in Comment  
#2 against the Issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6917

In the end the WG decided to close this issue with no action, meaning  
we will not specify a specific simplified format for subscriptions.  
However, there are places in the subscription where WS-Topics could be  
used and some implementations might support them easily. Likewise  
other strategies, such as Gil's approach would also work. Therefore we  
will put discussion and advice into out primer to help people exploit  
this optimization strategy.

Lastly, we did look at how WS-Topics might be normatively referenced  
in WS-Eventing, but the WS-Topics spec was written as if it was meant  
to be used only with WS-Notification. Therefore, we felt that  
normative references to WS-Topics would cause more confusion than  
necessary. However, as one of the WS-Topics WG members, I believe WS- 
Topics will easily compose with WS-Eventing.

Thanks you for you contribution and let me or the other members of the  
WG know if there is anything else we can do for you.


This is probably too late but i posted this on my blog
(http://www.shanghai-software.com/blog/archive/2009/02/15/ws-eventing-flaw.a
spx) and someone said i should sent it to this list.





Just doing some work on eventing and having a look at a number of
implementations there is a pretty annoying feature / flaw .

By default the only filter supported is Xpath and the specification
specifically states that

This specification does not constrain notifications because any  
message MAY
be a notification. from http://www.w3.org/Submission/WS-Eventing/.
<javascript:void(0);/*1234671797014*/>

I have no issues for this - sometimes you want any message , however  
this is
a very expensive way to do this especially when you have a large  
amount of
events with different topics all coming through a single  notification
service ( load balanced) .

All the implementations i have seen ( including the sample in the
specification ) introduce the concept of a topic in the header to  
route the
data.

eg

Sample in spec uses a header

     <ow:EventTopics>weather.report weather.storms</ow:EventTopics>

and a custom filter

  <wse:Filter xmlns:ow="http://www.example.org/oceanwatch"


(43)           Dialect="http://www.example.org/topicFilter" >


(44)         weather.storms


(45)       </wse:Filter>



Look  at some implementations

MSE ( Managed Service Engine from Microsoft)  ,Uses a custom filter
http://services.microsoft.com/2006-07/ServicePlatform/MSE6/Eventing/EventFil
ter/    which includes topics in the body of their custom event message.



Roman kiss implementation includes a string topic in his subscribe  
message
and has one topic per notification end point.

The end result is everyone will build their own system and filters.

Basically all the authors recognize that  the default spec will have
performance issues and can be easily optimized ;



So why didn't the spec include an optional header on notifications and a
simple canonical topic/subtopic  filter ? This way the majority of  
eventing
systems can talk to each other without resorting to expensive XPath  
queries
.. Take the weather example would you like to handle weather messages  
from a
million subscribers using Xpath?  With such a filter you can quickly  
route
via the topic in the header to different eventing services ( or servers)
and then handle an xpath body query..





Regards,



Ben .



Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe Limited
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE
     Reg. No. 4153469

     +44-7590-293439 (Mobile)






______________________________________________________________________
                                        
 Fujitsu Laboratories of Europe Limited
 Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
 Registered No. 4153469
 
 This e-mail and any attachments are for the sole use of addressee(s) and
 may contain information which is privileged and confidential. Unauthorised
 use or copying for disclosure is strictly prohibited. The fact that this
 e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
 not guarantee that it has not been intercepted or amended nor that it is
 virus-free.