EDABlog

While WS-Eventing has no support for Topics ( see last post) it is almost essential for efficient  processing of messages if you have a large amount of subscriptions.

Consider the case of 10,000 Subscriptions for 10,000 Notification you are looking at 10^8 expensive xPath comparisons which will bring many servers down to its knees.

With EDA we can easily solve this problem ( compare to an overloaded DB) .

Lets say we have a Topicless share pricing feed  something like

<Trades>
<Trade>
<Symbol>BHP</Symbol>
<Price>38.12</Price>
<Volume>10000</Volume>
<Exchange>ASX</Exchange>
</Trade>
</Trades>

Now WS-Eventing has a really nice feature in that subscriptions can force notifications to contain a header this header can be a Topic. Even better the EndTo can be another WS-Eventing server.  With EDAm this is even easier as this subscription can be loaded in the configuration of the Notification server.
So we create subscriptions and organise the data  eg  by exchange then by group.

What we want is

ShareData
ShareData.Exchange.Group. Symbol.

That way actual clients can subscribe to the specific information they need ( most likely Symbol or Group )



Main Server (where the original feed enters) 
Topicless (Default mode)

2nd Server ( Runs in Must have topic and server always loads all subs from Topic)
Subscriptions in the config file ( or Data ) break the data down

Subscription for Exchange add topic

eg Xpath filter =  /Trades/Trade/Exchange="ASX"   Header in subscription
 <Topics> ShareData.ASX</Topics>

we add one subscription for each exchange
We add subscription for each  group and each code.


eg Xpath filter =  /Trades/Trade/Exchange/Symbol="BHP"   Header in subscription
 <Topics> ShareData.ASX.MetalsAndMining</Topics>


We now have 2 services ( the 2nd one can become many services if the load justifies it  ( not needed for a cloud) )  and people can make a subscription based on the Topic and get just the data they require  Better yet they can make subscription based on a cheap topic filter which would be orders of magnitude faster than xPath ( and is easier for the engine to index) . .

Lets have a look at the data , lets asume all these subscriptions are group subscriptions  ( 20  groups * 500 subscriptions)   , now each Group will have 500 Notifications . The engine now only has to process  each of those notifications for 500 subscriptions  so we have 20 * 500 * 500  = 5,000.000 operations ( a 20 fold reduction) . O ( n* m) vs  O( n * m/log(n) )  . Taking into account the difference in performance between a simple topic filter and Xpath you would be looking at 2-3 orders of magnitude improvement. which could correspond to 1 server instead of 200.

This translates into a simpler , more responsive and more cost effective system. With EDA ( and especially EDAM ) this reconfiguration could be done with no changes in code.