SOA and EDA

So far I've posted a large amount of material on SOA, pushing very heavily for an event driven approach - with specific attention to business services, where business-relevant events are surfaced as event messages published over a service bus.

There has been an ongoing discussion in the public forum around the relationship between SOA and EDA (Event Driven Architecture). Are they in fact separate architectural styles? Are they separate concerns? Do they complement each other? Does SOA subsume EDA?

SOA and EDA are in fact separate architectural styles. However they describe different concerns of an architecture. They each bring their own benefits. As such, it is possible (and in fact good practice) for the two styles to overlap. An architecture can indeed both be service oriented and event driven. Likewise it is possible for an architecture to be service oriented but not event driven, or event driven and not service oriented. This is illustrated below.


An architecture consisting of services with no endpoints with a publish-subscribe binding conforms to the service oriented style of architecture, but is not event driven. An architecture consisting of messages published over topics, but where there is no notion of services is event driven, but not service oriented. For example, EAI can be achieved by having a number of applications publishing and subscribing over a set of topics, without explicitly defining any services, endpoints or service contracts.

Where SOA and EDA come together, a topic corresponds to a specific endpoint of a specific service. A topic cannot be shared between endpoints or services, and messages published onto a topic must conform to an explicitly defined service contract. SOA brings benefits to EDA and vice versa. Therefore we get the best result when the two architectural styles are combined.