Edam

Can EDA SOA eventing systems be fast

Ben Kloosterman — Fri, 10 Jul 2009 03:01:03 GMT

A lot of traditional eventing systems use C++ and are dubious about whether the Lego block style SOA can provide sufficient performance.

Again it boils down to design

WCF C# can process over 22000 small messeges per second on an average 2 year old quad server. http://msdn.microsoft.com/en-us/library/bb310550.aspx#wcfperform_topic4.

This is more than sufficient for most applications especially as with eventing systems you can add servers relatively simply , the algorithms which manage the propogation of subscriptions and the path are far more important . ( Distributed Event-Based Systems (Muhl , Fiege and Pietzuch) is a good book which covers the theory here .

The other big issue often sited is latency but EDAM ( which uses Windows Communication Foundation ) has sometimes achieved cross machine rates of 3ms again the design is critical here if you pass through 6 nodes each adding 20 ms it can become quickly unacceptable. Often people will use all the features of SOA such as queues , transactions , encryption etc yet wouldn't implement these on a typical C++ system these can be killers , don't use them unless you HAVE to and since most C++ eventing systems dont you better have a good reason. .

I would also add Network latency between companies , cities or even countries add far more significant delays. With human reaction being about 120ms (At best) the small delays these services add are insignificant.

The end result is you CAN build lego block style SOA , high speed eventing systems with a good a design and gain all the SOA benefits .

You could argue computer trading systems require better times but again i think the small differences you will get ( single figure ms at best ) are more than outweighed by a flexible design. eg instead of running the trades on the clients premises , critical trades can be uploaded to a providers machine near to the exchange this is often hard due to inflexible implementations . A strong and flexible design means more optomization can be made more easily eg message priritization , packing multiple data messeges for efficiency etc

Like premature code optomization the desire to be as fast as possible does not outweigh good progamming algorithms and design.

Ok i said it enough a flexible and strong design is far more important than premature optomization and making things as fast as possible,

EDAM -What is EDAM trying to do.

Ben Kloosterman — Sun, 05 Apr 2009 09:16:31 GMT

Just been working on EDAM ( my event driven architecture product) and wanted to note down and restate the long term goal (in addition to being a great eventing system).

The goal of EDAM is for people to be able to quickly add programs to the enterprise and to provide a fast event driven service to make this happen . Note i avoided the term framework as i want this to be usable with no dll linked though we will provide one later to make it even easier.

Remember when we used UNIX commands such as

cat file* | tr -cs '[A-Z][a-z]' '\012' | sort | uniq -c | sort -nr | more

these are incredibly powerful for experienced users and i wanted something similar so you could write enterprise applications and redirect them FAST.

What i want to do is something like

string ProcessOrder(Order order) { return order.ToXml()) <OrderService.NewOrderEvent("/orders/order[Customer=xyz]" > LogEvent(Cat = "Check For Orders from customer xyz" , result;

string ProcessOrder(Order order) { if ( order.Amount> 1000000) return order.ToXml(); else return null; ) <[OrderService].NewOrderEvent("/orders/order[Customer=xyz]" > [LogService].Log(Cat = "Check For Big Orders from customer xyz" , result; > [EmailService].Email(result , "LargeOrder receviec" ,"person who wanted to know"@nobody.com

Basically take the input from a specified event and send it to a dynamically service. The code would be compiled and loaded into a DB , a dynamic host would automatically load this service and keep it running,

With powershell ( and UNIX) adminstrators have been using this power for a long time ( more for reviewing data then events though ) extending it to business events is something else. It could lead to much quicker small applications being developed , the above example would normally require an application to be written but with some Enterprise infrastructure things could be written really quickly, This is not really posisble with tradition systems as DB access is normally tightly controlled ( for good reason) and there are no events to trigger things and polling would be inefficient . Note EDA does need protection against a loop

This would be bad.

Order ProcessOrder(Order order) { return order) <OrderService.NewOrderEvent("/orders/order[Customer=xyz]" > OrderService.AddOrder(result);

Filter and Replace

In many cases i thought the flexability of EDA can be very usefull in critical systems such as defence ,finance markets etc , remember in the first gulf war the Ewacs ( control planes for the whole air war) shut down because they were overload. They had people look at the bugs and uploaded a new version the next day ,but this sort of thing can cost the lives of many people .

Even if it is some sort of fundamental problem like the hardware cant handle the load ,with EDA i could have build a simple service that subscribed to requests from the first service and have all the systems point to the new service. This service would consist entirely of an xpath expression which would eliminate excess data by distance or some other dependency.

So we need to change the current event to move to a different port and put a new service which filters events to a new port.

Filter and Extend

Similarly to the above if you had extra computers and were overloaded you could add more with no impact on the system just some reconfiguration

Eventing with and without Topics

Ben Kloosterman — Sat, 21 Feb 2009 12:17:16 GMT

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.