EDABlog

WOW  , I got a very polite response from an issue I reported ( see earlier article in Blog) with WS-Eventing. I wish work related bugs reports were handled so nicely.

I do disagree however it would have been nice to at least add this as Optional to the standard , though hope is not lost for a standard fast WS-Eventing as they may introduce it for WS-Topics. All it needs is a comment and then vendors will implement it as at the moment they do their own thing.

Here is the transcript.

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 .