EDABlog

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.