SOA & Event Driven Architecture Steve Else, Ph.D., Certified Enterprise Architect, SOA COP Srinidhi Boray, Certified Enterprise Architect, Ingine, Inc.

Background Event driven is nothing new. It has existed ever since computing began. But then the emphasis was not architectural. As the technologies advanced; especially in the control engineering where ‘sensors’ based application is prevalent; Event driven design became a paradigm. The ferocity of the competition in the market has created a greater need for interdependencies among the systems. Event Driven Architectures, complementing SOA & BPM ensures to achieve such a system.

……background 1989 – OMG was Born To facilitate interdependencies among the businesses architectural frameworks were sought; such as ‘Common Object Request Broker Architecture’. The motive then was to promote object oriented programming and distributed architecture to achieve greater functional interdependencies. However, the functions still remained quite tightly coupled in most cases.

….background This addressed better design management, but the inherent problems that were in CORBA did not go away. Although some loose coupling occurred – Model Driven Architecture Introduced Motive was to achieve –a better holistic design, –while promoting better use of strong notation (UML) –better ‘separation of concerns’ –Platform Independent Model –Platform Specific Model –model transformation and engineering change management

Systems into Software As software architectures evolved, the designs moved from hardware into software. Telecom is a classic example. The architecture that was tightly coupled to the hardware gradually moved the management functions embedded in the hardware into the software. Almost all the embedded engineering is ‘event dependent’. This means a paradigm shift in the software architecture approach to incorporate the functions migrated from the hardware.

The SOA Buzz… During late 2000s SOA has taken center seat.. –SOA relies on Loose Coupling Coarse Grain This means the atomic structure of the ‘services’ is lot more larger than the object oriented ‘function’ Furthermore, the services are brought together to instantiate business processes by another component - ‘orchestration’. The design of the ‘orchestration’ layer creates a greater need for an architecture that is ‘event driven’ such that this layer is service/function independent.

Enterprise Service Bus To achieve a coherent model, the event driven design paradigm requires being shifted from the level of services into the orchestration component of the architecture framework. This requires creating another layer called ‘Enterprise Service Bus’ The ESB concept is a new approach to integration that can provide the underpinnings for a loosely coupled, highly distributed integration network that can scale beyond the limits of a hub-and-spoke EAI broker. An ESB is a standards-based integration platform that combines messaging web services data transformation and intelligent routing to reliably connect and coordinate the interaction of significant numbers of diverse applications across extended enterprises with transactional integrity. Ref: David Chappell

Definition of a ‘Service’ What are Services Services are request/response mechanisms. A service consumer makes a request and a service provides a response. Essentially, a service consumer calls the service operation of a service and the information flows through the service interface. Then the service implementation processes the request and provides the information to the service interface that responds.

Event Driven Architecture When Services do not act as requestors but instead Events trigger a complex array of interdependent business processes to respond to a condition, the design paradigm shifts to : Event Driven Architecture (EDA) In an EDA, a complex array of business processes turns into a non-hierarchical net-centric structure

EDA & SOA While EDA is fundamentally different from SOA, the two styles are not contradictory and, in fact, they work together well. EDA is a request/response architecture Service consumers make requests of services and wait for responses The idea of EDA is "fire and forget." Systems are constructed to respond to events that occur in software or in the real world. Once an event has occurred, a cascading process begins in reaction to the event. Ref: Enterprise SOA: Designing IT for Business Innovation By Dan Woods; Thomas Mattern

State Space – Time Domain Approach Field Events Event Sampling & Management Event Processing Event(s)/Response Event Decision Management Event in SpaceEvent in Time

Business Activity Monitoring Correlation Technology Sense / Interpret Event in Space Event in Time Interpret & Response Knowledge Management System Event Data Base Rules Engine Event Handler Event Disseminator Event Assimilator Event Controller Sequential Date Aggregator Pattern Logistics Stream Complex Stochastic Discreet Event Modeling Probabilistic Modeling Field Events Event Sampling & Management Event Processing Event/s Response Event Decision Management Event Listener Event Correlation Engine