Azure & .NET services

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.

OSLO to be or not

Ben Kloosterman — Thu, 12 Feb 2009 03:05:49 GMT

Based on the limited information so far .

Im not really sure about Oslo ( as opposed to Dublin and Azure which i think will be big hits) it reminds me a LOT of UML and associated higher end tools which manage synch the UML to code and database schemas.

For a start we have to learn a new language ( ok its similar but there are a lot of differences) that immediately has to be a barrier to entry . In return it doesn't make anything easier it just unifies a lot of different thigns under a bigger umbrella which so far i dont think will overcomes peoples natural resistance to change unless it provides some benefit.

However i wonder if Dublin will require some of the Oslo meta data im still waiting to see that.

Is it really worth it ?

.Net services message persistance

Ben Kloosterman — Mon, 09 Feb 2009 01:02:58 GMT

Well looks like .Net services doesn't have persistant messaging ( no queues or persistance of subscriptions ) . This will probably be address in v2 . There is a 30 second message buffer for polling replies but this is not the same.

This is especially an issue for mobile computing ( PDAs , phones etc which are often offline) and for wrapping legacy systems. Though its unlikely that legacy systems will be wrapped by .Net services ( more likely the service bus will redirect it to locally hosted services) .

Im not a big fan of queues however. See post.

What is Azure Services ?

Ben Kloosterman — Sat, 07 Feb 2009 02:21:46 GMT

Are Azure services a cloud or are they an ESB ?

While Azure does not have this it has FAR more than most ESB in terms of connecting clients to services. Sure it has router support

Azure >> ESB (Internet hosted , with integrated internet security , scalable)
Azure >> Cloud computing ( not just Client - Service routing and hosting but also it has sender-receiver relay , multicast , firewall pass through , and enterprise-cloud security integration)

The big thing is people see it as a cloud .. however i think the biggest thing is it can redirect clients requests into your internal systems ( or partners!) in a secure manner with a global logon. Or facilitate secure communication between clients and companies ( as well as B2B)

A lot of people say the Enterprise will not put services in the cloud - i dispute this. VPNs are used to drive many branch offices which was not done earlier its a question how comfortable they are with the management and security. Like outsourcing to india.