Time For Event-Driven SOA

Experts agree that Service Oriented Architecture (SOA) is the best approach for new enterprise architecture development. It is also possible that your company has already started working towards it. But the question is ‘Are you implementing the right SOA keeping long-term objectives in mind?’ You may not be if you have not coupled Event Driven Architecture (EDA) with your SOA implementation. This article talks about the necessity and key benefits of the marriage of SOA and EDA.

Necessity

Companies face a large number of complex events every day and responses are expected in real time. Few examples include real-time trade settlement systems, flight reservation system, real-time vehicle-location data for transportation and logistics companies, streaming stock data for financial services companies etc. Companies handle large volumes of complex data in real time to simply operate.

SOA is good if the requirement is just to send requests and receive responses synchronously but not good enough to handle real-time events asynchronously. Event-Driven SOA combines SOA’s request–response and EDA’s event publish-subscribe paradigms. This new Event-Driven SOA architecture (also referred as Business Driven Architecture) allows system designers to support both events and services. Also, it enables designers to map the application design to the business problem, which consists of both events and requests/responses. This results in extreme agility enabling enterprises to conduct business at light speed.

Service Oriented Architecture (SOA)

Service oriented architecture is essentially a collection of services, which communicate with each other. The communication can involve either simple data passing or it could involve two or more services co-ordinating some activity. Service communication is made possible using technologies like Web services.

SOA is based on a conventional request-response mechanism. A service consumer invokes a service provider through the network and has to wait until the completion of the operation on the provider’s side. Replies are sent back to the consumer in a synchronous way.

One of the most important advantages of SOA is to get away from an isolationist practice in software development, where each department builds its own system without any knowledge of what has already been done by others in the organisation. This approach leads to inefficient and costly situations where the same functionality is developed, deployed and maintained multiple times. SOA is based on a service portfolio shared across the organisation and it provides a way to efficiently reuse and integrate existing assets.

Event Driven Architecture (EDA)

An event is a notable thing that happens inside or outside of your business. An event may signify a problem, an opportunity, a deviation, or a threshold. Each event occurrence has an event header and an event body. The event header contains elements describing event occurrence details like specification ID, event type, name, creator, time stamp etc. The event body describes what happened. For example, if an Integrated Flight Booking system specified a ‘Flight Delayed’ event, the event body would contain the information to communicate, which flight is delayed and by how many hours etc.

The event body should be fully described so that interested parties can use that information to take necessary action like re-booking the transit passengers, who are on the delayed flight to another available flight automatically. If the event is not fully described, interested parties might have to communicate with the source system to get the required information. So it is always suggested to describe the event occurrence fully.

In an event-driven architecture, an event happens inside or outside of your business, which disseminates immediately to all event subscribers. Event subscribers then evaluate the event and take appropriate action. This action could include invocation of a service, triggering a business process etc. Event-driven architecture is extremely loosely coupled and highly distributed. The creator of the event only knows how the event transpired. The creator has no knowledge about the event’s subsequent processing. Thus, event-driven architectures are best used for asynchronous communication.

Event-Driven SOA

The occurrence of an event (which could have been initiated inside or outside of your business) can trigger the invocation of one or many services. Upon generation, the event is notified to all interested parties. The interested parties evaluate the event and optionally take an action. The action may include invocation of service(s). Those services may perform a simple action or an entire business process. This interaction between events and services is commonly referred to as Event-Driven SOA.

EDA does not replace SOA, but rather, complements it. While SOA is generally a better fit for a request/response exchange, EDA introduces long-running asynchronous process capabilities. Moreover, an EDA node posts events and does not depend on the availability of a published service. It is really decoupled from other nodes.

An Enterprise Service Bus (ESB) combines event-driven and service-oriented approaches to simplify integration of business units, bridging heterogeneous platforms and environments. The ESB acts as an intermediary layer to enable communication between different application processes. A service deployed onto an Enterprise Service Bus can be triggered by a consumer or an event. It supports synchronous and asynchronous communication, facilitating interactions between one or many stakeholders. So the ESB provides all the capabilities of both SOA and EDA paradigms. An ESB is today’s most effective way to address complex integration challenges and is the technical solution that provides business flexibility and efficient connectivity between dissimilar applications.

Conclusion

There are a lot of similarities between SOA and EDA, but at the same time there are certain differences. It’s about how we think about solving a given problem. In service oriented architecture, you have a request that you send and you control what happens. But in the case of event-driven architecture, you react to things as and when they happen. Both have similar underlying infrastructure to talk to various systems, to carry information from one place to another, to transform messages that are flowing through and to process business rules.

An optimised business needs to handle both services and events to enable extreme transaction processing. Event Driven SOA (also referred to as Business Driven Architecture) combines the capabilities of both SOA and EDA to address all the capabilities needed to respond to real-time business dynamics.

Bonthala is senior project leader with ADP Private Ltd.