hile service-oriented architecture (SOA) seems to be on everybody’s lips these days, some vendors and analysts are proposing an alternative approach known as event-driven architecture (EDA). Some camps even go so far as to say that SOA and EDA are competitive, mutually exclusive concepts, and that enterprises have to choose between one or the other, casting fear, uncertainty, and doubt (FUD) into the decision-making processes of IT architectural committees far and wide. Well, if you have some of this FUD yourself, you can relax. ZapThink believes that for all practical purposes, EDA is not truly a separate architectural approach, but is actually core to how companies should implement a proper SOA, and distinguishing EDA as a separate architectural approach is nothing more than a straw man.
What Is Event-Driven Architecture?
To its proponents, EDA is an approach where events trigger asynchronous messages that are then sent between independent software components that are completely unaware of each other–in other words, decoupled, autonomous objects. An event source typically sends messages through some middleware integration mechanism like a bus, and then the middleware publishes the messages to the objects that have subscribed to the events. The event itself encapsulates an activity and is a complete description of a specific action.
SOA, on the other hand, is an architectural approach where software functionality is exposed as loosely coupled, location independent services on the network. While Web services are not necessary for SOA, SOA based upon Web services is the approach that ZapThink focuses on, and is the architecture that ZapThink believes encompasses EDA’s core concepts. In particular, ZapThink believes that SOAs should be asynchronous, because asynchrony is essential to the loose coupling between service producers and consumers, as well as being core to the fundamental nature of business processes.
Are SOAs Event-Driven?
To understand why EDA is a subset of SOA, you need to get into the details of the underlying standards, beginning with SOAP. SOAP supports four interaction patterns: request-response (client to server and back), notification-response (server to client and back), one-way from client to server, and notification from server to client. In this way, SOAP by itself is able to support both remote procedure call (RPC) and document-style interactions, in either a synchronous or asynchronous fashion. In particular, the event notifications core to EDA have been a part of SOAP from the beginning.
SOAP by itself, however, does not provide all the detail needed for a full event-driven publish/subscribe environment. As a result, there are several initiatives working their way through vendor groups and standards bodies meant to complete this picture: One camp is working on Web Services Notification (WS-Notification), Web Services Base Notification (WS-BaseNotification), Web Services Brokered Notification (WS-BrokeredNotification) and Web Services Topics (WS-Topics), while another camp is working on Web Services Eventing (WS-Eventing), Web Services Dynamic Discovery (WS-Discovery), Web Services Coordination (WS-Coordination), Web Services Metadata Exchange (WS-MetadataExchange), and Web Services Business Activity Framework (WS-BusinessActivity). Now, it’s obvious that much work remains to bring this laundry list of specifications into a single streamlined set of standards, but be that as it may, once the dust settles, SOA based on Web services will offer a complete, robust set of event-driven mechanisms.
More importantly, ZapThink discusses frequently in its research that as application logic and functionality becomes more coarse-grained, they become more “business-like” and less “API-like.” At the highest level, all of the details of how the company operates (its processes and services) are hidden from the service consumer. Invoking these services then becomes a matter of sending the right messages (or events) to trigger processes to occur that in turn generate subsequent events for further service processing.
Are All EDAs Service-Oriented?
If you’ve been reading this article closely up to this point, you will have noticed a subtle, but critical difference between SOAs and EDAs: SOAs should be loosely coupled, while EDAs can be decoupled to a much greater degree. In other words, in an SOA, Web service producers and consumers need have no knowledge of the workings of the other except what is expressed in the service contract (i.e., the WSDL file for the service), while in an EDA, there is no need for any such contract. The only connection between event producers and consumers are the publish and subscribe activities themselves.
The big problem with fully decoupled EDAs, however, is that they are not particularly good for application-to-application communication. This level of decoupling works for completely unstructured information, for example, textual information intended for human consumption. When one application publishes data for another application to consume, however, in the absence of a service contract, those data are necessarily fine-grained. In other words, a fully decoupled event might be an alert that a process is complete or might be some kind of acknowledgment, but the subscribing application would be hard pressed to make sense out of a complex, structured event in the absence of a service contract.
The bottom line, then, is that it’s possible for an EDA not to be service-oriented, but for most practical purposes, event-driven interactions in an EDA should be service-oriented. The distinction between the two approaches, therefore, is more of a technical detail than a difference that has any importance to the business. So, what we should be talking about is not a separate concept called EDA, but rather “event-driven SOAs” as a coherent melding of the two concepts.
So Why All the FUD?
To understand why this matter is an issue at all, it’s important to look to the human side of such discussions. For better or worse, SOA is getting more than its fair share of hype these days, so it’s natural for people to be skeptical and look for alternative approaches in order to let some air out of the SOA balloon. And while ZapThink is riding the SOA bandwagon, our loyal readers know full well we are all for letting air out of hype balloons, so the SOA/EDA hubbub does have an upside we can support.
It might also be argued that some of our fellow industry analysts have contributed to the FUD. It is the nature of the analyst business that every analyst wants a particular market category or issue that they can champion. If too many analysts are already on the SOA bandwagon, then maybe a different wagon would be less crowded. Unfortunately, such tomfoolery isn’t good for IT consumers who look to analysts for insight and direction.
