Is EDA the way to go?

Tuesday 01 July, 2008 (Architecture | EDA | SOA)

I have been reading a lot about Event Driven Architecture (EDA) in relation to SOA recently and while the ideas are very interesting and the benefits are alluring it adds an additional complexity and uncertainty to the overall behaviour. Two good articles on EDA are http://martinfowler.com/eaaDev/EventCollaboration.html and http://eaipatterns.com/docs/EDA.pdf

From my view the main problem is that when implementing a business process that spans several services (for example entity services) we do not generally want the entity services to react to events and then store or retrieve data based on the events because this means that the services need to have some kind of knowledge of the expected behaviour relating to the process - generally seen as a bad thing in SOA, as the northbound - southbound dependencies get reversed. We also want to have some stability from a callers perspective that the overall flow will be moved forward, traditionally done by issuing a command. If events get turned into commands then I believe we will have problems coordinating the different actors (presuming that the command event was only meant to be acted on once). Jack Hof has an interesting take on the relationship between SOA and EDA especially his extended pdf version has some interesting ideas about how to realise SOA and EDA together which contains a potential solution to the problem, basically by just combining EDA and SOA and knowing when to implement which principles.

A related problem is what should our messages contain - are command messages even required? Two slightly different takes on the problem are presented here and here. Thinking about events and messages has lead me to attempt to create (a very crude) classification system for events that are related to a solution that I am developing for a client.

State-change events: no messages are published as long as the underlying values are not updated, the message is related to a specific instance of an entity or service. There is no expected behaviour for the recipient.
Scheduled events: messages are published at a certain frequency whether the values are updated or not, all available data should be published simultaneously within a single message or as multiple messages. There is no expected behaviour for the recipient.
Request or reservation events: these messages are requests for behaviour. A receiver may safely ignore the message, send a negative response if it cannot fulfil the request or a positive response if it can fulfil the request. The event needs to have a predefined response message which the event source can understand and the response needs to be able to be routed back to the source without the listener needing to have prior knowledge of all sources. This is basically an event which initiates a dialogue between two parties based on the reservation pattern. It is the requestors responsibility to coordinate the possible responses and outcomes. There is an expected behaviour for recipients who return a positive response but no prescribed behaviour for those who ignore the event or actively return a negative response.
Command events: This must be an anti-pattern since a command denotes that the sender expects the recipient to perform some specific task and thus exhibit an expected behaviour, which is impossible in a loosely coupled, event-driven, service oriented world since the sender does not know who is listening.

The first two event types are just statements, the third (reservation) is really just a variation of a state-change event with additional semantics attached to it. Using EDA the expected behaviour that is needed for a specific business process must be realised with the help of some kind of process controller (notification server in Jack Hof's world) which follows the traditional Command and Control (call stack) approach for coordination but uses events to track what stage the overall process or task is at.

« Remember to always have a static customErr... | Latest | SFTP Adapter authentication for BizTalk »