Event Driven SOA

Service Oriented Architecture (SOA) is here. It's now. And it's evolving. While the first wave focused on services that interact via a request/response protocol, the next wave of SOA will be powered by event data. This is what's known as "Event Driven SOA".

SOA replaces monolithic applications with a collection of loosely coupled services. In the first wave of adoption, most of the focus was on web services and standards such as XML and SOAP. The request/response paradigm, while very powerful, does not address all the needs of a distributed, loosely coupled architecture. There are many cases where a service produces data without knowing who may need that data or what action may need to be taken because of it.

Enter events. With events, a service doesn't need to know who is interested in what it has done but simply that someone might be. To that end, it emits an event. Any other service that is interested can subscribe to the relevant event stream(s). This is the nature of a decoupled system: an emitter of event data doesn't need to know who the recipients are. Events are produced and consumed by whatever services need to know about them.

While decoupling in the form of pub/sub messaging has been around for a long time, tools to analyze the event data in real-time, applying business logic to monitor and respond to changing conditions has been missing. This is the function of Event Processing technology and the core of the Aleri Streaming Platform.

Whether referred to as Advanced SOA (Gartner), SOA 2.0 (Oracle) or Event Driven SOA, the next wave of SOA is here. This is not a change to SOA, but a natural progression toward full achievement of the goals of SOA.

Contact us to learn how Event Processing technology and the versatile, high performance characteristics of the Aleri Platform can help lay the foundation for your SOA strategy and infrastructure evolution.

Use Event Processing within a Service Oriented Architecture to:

• Gather information about individual services

  - Normalize, filter, and aggregate the information; and deliver it to other services that only require summary data.

• Monitor services to detect situations that require a response

  - Automatically initiate the response or alert someone that a response is required.

• Synchronize distributed services

  - Ensuring that changes in the state of one service are communicated as needed to other services.

• Capture event data across a collection of services

  - Recording the data an event history and/or providing a single point for determining the current state of the system.