WS Eventing performance flaw

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 .