RE: Response to Issue 6917 - WS-Eventing: Performance Flaw

Hi David , 

 

That's for your courteous reply .

 

I note your comment that "WS-Topics spec was written as if it was meant to
be used only with WS-Notification" 

 

I note  the weather sample  message in the WS-Eventing specification uses
custom topics

 

(06)   <s12:Header>

(07)     <wsa:Action>

(08)       http://www.example.org/oceanwatch/2003/WindReport

(09)     </wsa:Action>

(10)     <wsa:MessageID>

(11)       uuid:568b4ff2-5bc1-4512-957c-0fa545fd8d7f

(12)     </wsa:MessageID>

(13)     <wsa:To>http://www.other.example.com/OnStormWarning</wsa:To>

(14)     <ew:MySubscription>2597</ew:MySubscription>

(15)     <ow:EventTopics>weather.report weather.storms</ow:EventTopics>

(16)   </s12:Header>

 

And vendors need this and have implemented some Topic capability however its
proprietary Roman Kiss implementation uses  this style topics , Microsoft
have introduced a MicrosoftTopicFilter in one of their implementations. As
these filters are proprietary   WS-Eventing cant talk efficiently between
vendors unless you srite a filter for each platform. 

 

I agree this can be raised with WS-Topics it only requires a single line and
an optional requirement note. Its important enough for vendors that they
will adopt it. 

 


Regards, 

 

 

Ben Kloosterman 

 

From: David Snelling [mailto:David.Snelling@UK.Fujitsu.com] 
Sent: 06 Augustus 2009 11:33 PM
To: bklooste@gmail.com
Cc: public-ws-resource-access@w3.org
Subject: 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
>
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/>
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>
http://www.example.org/oceanwatch"
 
 
(43)           Dialect=" <http://www.example.org/topicFilter>
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/EventFi
l>
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.