SOA 2.0 Event Driven Architecture

There has been much negative press in recent years in regards to Oracle’s touting of SOA 2.0 as the next generation version of SOA. Its combination of Event Driven Architecture with SOA considers the first iteration of SOA to be a mere client-server drive. Despite the fact that it has been presented as a new term, a lot of critics claim that what this merger actually is an advanced SOA, rather than a 2.0 version. The truth is that a lot of pure play middleware vendors such as webMethods have had 2.0 attributes for many years now.

SOA 2.0 can thus be viewed as a marketing strategy rather than a novel approach to SOA. Other commentators in the industry have criticized the decision to attach a version number to an application architecture design approach. Still, others feel that the term “next generation” should be utilized to apply to the evolution of SOA techniques from IT optimization to the development of businesses. In this article, we will consider SOA 2.0 as an event driven architecture (EDA).

About Event Driven Architecture

Event driven architecture can be thought of a software architecture pattern that promotes the awareness of, production, consumption, and reaction to events.

An event, in this format, should be viewed as a major change in state. So, for instance, when someone buys a car, the state of the car switches from “for sale” to “sold.” The car dealer’s system architecture may then treat such a change in state as an event that should be detected, published, consumed, and produced by different applications within the system architecture.

Such an architectural pattern may be applied by the implementation and design of systems and applications that transmit events between services and loosely coupled software components. Event driven systems tend to consist of producers and consumers of events. The latter subscribe to an intermediary event manager, while the former publish to this manager. Thus, after receiving an event from a producer, the manager will then forward on the event to the consumer. If the consumer is not available at this point, then the manager will be able to store the event and attempt to forward it on at a later date. Such an approach to the transmission of events is called “store and forward” in message based systems.

The construction of systems and applications around event driven architecture allows for such systems and applications to be built in a fashion that facilitates more responsiveness, as event driven systems tend to be, in terms of design, a lot more normalized to unpredictable environments, as well as asynchronous ones.

Event driven architecture compliments service oriented architecture in that it allows for services to be started by such triggers as events.

Both computational machinery and sensory devices are able to detect changes of state within conditions and objects, while creating events that can subsequently be processed either through a system or service. Event triggers can be thought of as conditions that lead to an event’s creation.

Event Processing Styles

There are three main types of event processing – simple, stream, and complex. These three styles tend to be utilized together in mature event driven architecture systems.

Simple Event Processing

This style deals with events that are somehow directly related to particular, measurable condition changes. In such a style of event processing, a notable event occurs that initiates downstream actions. This style of event processing is typically utilized as a means for driving work’s real time flow. It effectively reduces both cost and lag time. Simple events, for instance, may be created through a sensor detecting changes in ambient temperature or tire pressures.

Event Stream Processing

When it comes to this style of event processing, both ordinary and notable events occur. Ordinary events, such as RFID transmissions and orders, are considered for notability and then streamed to info subscribers. This style of event processing is typically utilized as a means of driving the real time flow of data in and around a particular enterprise, which enables in-time decision making.

Complex event processing

This type of event processing lets patterns of ordinary, simple events be considered to infer that a complex event has taken place. Complex event processing tends to evaluate a confluence of events, then follows up by taking action. Such events, whether they be ordinary or notable, can cross event types and take place over a long duration of time. The correlation of events can be temporal, spatial, or casual. Complex event processing necessitates the employment of skilled event interpreters, event pattern matching and definition, as well as correlation techniques. Complex event processing is typically utilized as a means for detecting and responding to anomalies, threats, and opportunities in a business environment.