Event-Driven Architecture and Service-Oriented Architecture

I've talked about what Event-Driven Architecture and Service-Oriented Architecture are.

EDA and SOA

I've read some stuff that says that SOA and EDA go together nicely, and some other stuff that says that they're competing technologies, that you either have to do one or the other. I believe that there's a lot of synergy between SOA and EDA, and that for a sufficiently complex application, or composite application, or set of applications, you might well use both architectures. For some communication, you want to do it in an SOA sort of way, and for some of it you want to do it in an EDA sort of way.

So when do you do which? With SOA, if you know exactly what service you want to get run, and you want to have it done exactly one time, and you want to be sure that it gets done, and that you get the results of it, then you're going to call a service directly and that's SOA. That's the classic SOA
interaction of a consumer invoking a provider.

With EDA on the other hand, it's more of a one-way communication that you don't really know who the handlers are or what they're doing, and whether or not they actually do anything. And it's a one-to-many communication, where there may be lots of handlers, and the emitter doesn't know how many of them there are. And the emitter doesn't expect a result; it just wants to provide notification.

A place where I think there's a lot of overlap between SOA and EDA and why there's no point in getting real religious about deciding which one to do when exactly, is I think about the way an event handler is going to work, and what an event handler is going to do is once it decides that it recognizes the event and it's interested, to handle the event what it's going to turn around and do is invoke a service.

The handler itself doesn't really know what to do with the event as far as updating the calendar, or rescheduling a car, or whatever needs to be done. There's a service that does that sort of thing. The handler just needs to kick off the service saying, cancel this hotel reservation, or whatever the case may be.

So either way, you're implementing services, it's just a matter of how the services get invoked. Do they get invoked in a rather direct SOA sort of fashion where the consumer invokes the provider directly? Or is it in a much more abstract and indirect sort of way where an event causes a handler to invoke the service?

Programming Techniques

Either way, I believe you're implementing services, reusable business tasks. Then it's just a matter of how you're going to kick them off.

So one thing that's different is that there's a pattern I reference a lot, that's in one of my books, called Service Activator. And the Service Activator receives a service request and then invokes a service and then optionally sends the response. So it's a piece that sits in front of the service to enable the service to be invoked in an SOA kind of style.

Well, then there's an event handler which is a different thing that sits in front of the service that is something that listens for events and filters them and decides which ones are actually important. When it decides that a particular event is important, that it turns around and invokes a service.

So for one service implementation, one particular provider that you've implemented and deployed, you might want to put a service activator in front of it so that you can invoke it SOA style. And you might want to also put an event handler in front of it so that you can invoke it EDA style. So I think there are a lot of analogies between the two technologies and the way they fit together, and the kind of a yin and yang that allows both parts to go together.

ESBs

An enterprise service bus (ESB) can and should be used to connect event emitters and event handlers, just like its used to connect service consumers and service providers.

In general in the last couple of years we've been talking about the ESB in terms of how it fits into an SOA, that basically you had the service consumers on one side of the bus and the service providers on the other side of the bus. And when the consumers want to invoke a service, then the bus connects the consumers to the providers.

What does this mean for EDA? Does this mean we don't need the ESB anymore? No. With EDA
you've got these event emitters and event handlers, and again, they have to be connected somehow, maybe by like a JMS topic in a messaging system. That ends up being an ESB; the emitters and handlers don't need to know about each other directly; they just need to be connected to the bus. When an emitter is ready to post an event, it just sends it out on the bus and then the bus connects it to the appropriate handlers which receive the event and then can react accordingly.

So the bus is really useful both for direct services invocation SOA style, and for indirect event notification EDA style.