Sunday, 16 September 2007

SOA, EDA, and Hybrid Architectures

There is so much buzz around the Service Oriented Architecture (SOA) and the Event Driven Architecture (EDA), up to the point that it's hard to understand the real functional distinction between them. Let me state it simply and clearly. These are two different views of the electronic world, which can be assumed by a system depending on the purpose of its existence.

Service Oriented Architecture
If the system is supposed to be active (i.e. it or its users want to do some actions like booking a hotel or making a trade) then it needs to view the world according to SOA, where each of the interacting systems can be represented as a service:

The "result" part of the call is optional depending on the requirements for a particular interaction. The calls can also be asynchronous, making it possible to check if the request has been completed by using special dedicated methods of a service.

Event Driven Architecture
If the system is supposed to be passive (i.e. it is used to observe the actions of the external systems as, for example, in the case of the monitoring and surveillance applications) then it needs to view the world according to EDA, where each of the systems can be represented as a source of events:

In addition, each of the systems can produce its own events based on the analysis of the incoming events. This is what I understand to be the essence of the words "complex event processing" (though there are other views, see complexevents.com for more info).

Hybrid Architecture
Finally, many applications will need to adopt the hybrid architecture, which requires viewing the world differently by the subsystems depending on their purpose. Such complex systems, in particular, emerge in the areas of algorithmic trading, where some parts of the system are busy monitoring the market and raising derived events, while the other parts provide the means of acting on a particular event, e.g. by making a trade:

Note the "auto" node on the diagram: this is where an algorithmic trading system becomes automatic algorithmic trading system, i.e. some actions can be delegated to the decision making algorithm which is allowed to perform automatic actions, e.g. trades. In the other application areas, similar systems provide automatic feedback on such events as fire alarms, intrusion detections, situational events, temperature and humidity measurements, etc. The logic which controls the actions of the automatic decision maker can, for example, be expressed in terms of the fuzzy associative matrix or one of the many other approaches to automatic decision making.

When designing a complex system like this, it is very important to understand the nature of each interaction present: is it a subscription type communication (EDA) or a request/response bus (SOA)? In particular, classifying the communication channels is important when deciding which fault tolerance mechanisms to use. I hope to expand on this and other topics in the future. Thx!

No comments: