EDA

WS-Eventing

Ben Kloosterman — Thu, 06 Aug 2009 15:59:20 GMT

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 .

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

Why should you use an Event Driven Architecture (EDA)?

Ben Kloosterman — Fri, 27 Mar 2009 02:14:01 GMT

There is a lot of documentation on EDA and people working with SOA and call backs will naturally gravitate to EDA , but i have often wanted a simple reason why. Here i will attempt this and focus on service based EDA's.

1. It Naturally mirrors organisations.

High level EDA events are business events. With EDA anybody may receive these events and act accordingly. This means extending events to new applications is a trivial excercise.

2. Low integration costs

Integration expenses are massive, EDA makes it really easy for systems to communicate even more so than SOA's which require writing a system to interact with the appropriate services. With an EDA an admin can add a subscription and the appropriate messages will be sent to new system

3. Lower hardware costs

Sure machines are cheap but for large scale systems ( where EDA's shine) going from 500 servers to 10,000 servers is a big hit.

4. It is simpler. Information which EDA's are good at often have to be polled .

EDAs are often used for live events , when something happened with simple SOA services or with Databases this requires frequent polling. Polling results in significant overheads and thare a few issues to ensure you dont get duplicate data.

5. Information is live. Anybody including clients can get information as soon as the company receives it . eg Bank transfers , courier scannings,share quotes etc

6. It brings organisations and their IT systems together.

The easier integration and the capturing of real business events mean other IT teams are more likely to use them , this results in less duplication and technology islands. ( Though see below)

7. It allows groups to be autonomous and still work with enterprise events.

One of the big issues with SOA /large DB systems is its big centralised IT. You sometimes need to meet standards etc . These standards are required since a single consumer can bring down the whole DB , With EDA down stream system systems provided little or no impact and hence can go unrestricted. This allows quick and dirty systems needed for a new startup within the company to see if it is viable etc. Futhermore you have a lot less restriction on the data you get , you are not required to use certain Service operations or stored procs. You can use any Xpath query and have the information you need in real time and can then store and use it yourself.

8. Strong EDA's can result in smaller duplicated Data stores.

In small organizations EDA will result in single data storage , in larger ones duplicate data will normally evolve , these will not have the same information but there will be overlap. This is good as it allows the appropriate business to manage the data.

9. Creating a good EDA can be easier to implement than good SOA's.

Creating a good SOA is hard , you need to consider Data ( multiple service access ?? ) , orchestration , polling ,Service Bus , Data ware housing etc

With an EDA based SOA the focus is on Events and hence has a looser policy on SOA's , things like Data storage are up to the individual team who may or may nor share.

The key point here is the focus is and remains on the important part of the architecture the actual business events. SOA systems tend to wonder as vendors write many pages on their products and people spend a lot of time learning them and debating technical issues.

10. Completely loosely coupled

The sender knows nothing about the receiver and hence dependencies do not form.(Which also leads to lower integration costs above) .

Weaknesses

1. Not suitable for most small companies

Like SOA's its pointless using EDA for a small part of the enterprise. Its like designing a big building but make 1 apartment have full height curved windows. The one exception is companies with lots of monotoring systems as these are by definition event driven and hence map well to EDA's (Stock Brokers , Couriers , Police /Security , Military ,Aviation etc)

2. No Shared Data .

EDAs dont have any form of data storage and hence you still need these in your EDA . However they work well with Data warehouses which can store the data from the events it receives. EDAs dont work well for firms with massive data processing ( eg Credit card bonus point provider).

3. All data is live ,so bad for partially connected systems like mobile phones.

Partially connected systems need a store retrieve mechanism ( Note our EDA system EDAM provides this)

4. Need capability to receive events

Receiving events requires a dynamic subscription or a fixed Ip address. Dynamic subscriptions in WS-Eventing are a bit clumsy . Note EDAM has a Windows Communication Foundation interface to make this easy. .Net services ESB also helps get through firewalls to receive events.

EDA vs Cloud storage

Ben Kloosterman — Fri, 27 Mar 2009 00:55:33 GMT

Cloud storage promises a lot of the things that EDA does namely almost unlimited scaling however EDA implemented in the Cloud has significant advantages.

Firstly while Cloud storage Data may scale extremely well , it does so by using masses amounts of caching or disk spindles. In itself this is not an issue but if you have say 1,000,000 users querying/polling a 10 Gig Table While the performance is likely to be good the CPU usage will be massive and this is where cloud computing bites you - in the pocket. And the situations will get worse as data increases.

However EDA implemented in the Cloud immediately gives you a massive reach and can be combined with a Bus like the .Net Services bus to control access and get through firewalls.

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.