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.
SOA EDA Web Services
In this day and age, enterprise applications have already begun the transition from user interface driven applications to assemblies of interoperable services that are also reusable. Such services are representative of the easy business functions that are intended to be assembled together in the form of new applications.
One of the main advantages of such a change in application architecture is that services can now be reused in the evolution of business processes. At the same time, users should keep in mind that such an approach to the construction of composite applications and business processes will not work in the absence of a standards compliant platform for the construction of such services. Interoperability can be quite a challenge owing to the fact that Web services protocols for such activities as messaging, optimization, and reliability can be quite complicated.
Services may in fact be hosted across a number of different platforms. Without a platform that has been designed around standards and targeted towards achieving interoperability, it may not be possible to quickly weave services together as a means of meeting rapidly evolving business requirements.
One type of middleware developed by Oracle, Oracle Fusion Middleware, has been constructed on a common service infrastructure. It is designed to utilize industry standards for all its SOA capabilities. Service quality protocols and optimization of messages are provided as a means of improving functionality. Such tools can be utilized outside of business logic as well as the implementation strategy for services.
Businesses will also benefit from standards that describe not merely how applications cooperate, but how they are constructed. Through the usage of SOA standards, businesses can escape platform lock-ins, while developers will be brought up to speed with skills that are easily transferable. In short, the next generation of development standards are going to focus on two main areas:
- the providing of a common model for the control of relationships among services;
- allowing developers to implement robust web services utilizing familiar Java objects.
One question that people commonly ask after being introduced to SOA concepts is, why haven’t people been using this for the last twenty years?
People tend to forget that one of the main things you need in order to build a system out of parts is a standard method of representing software parts. If no such standard exists, then things can be incredibly difficult. SOA is not exactly a new thing. Businesses have spent the last fifteen years trying to come up with a set standard. While CORBA and DCOM have been in existence for a while, they never became world wide standards. It is the Internet that has in many ways set up standards – namely HTTP and HTML – that link together people all over the globe. Businesses witnessing the growth and the development of the Internet decided to use similar strategies to link their own computer systems together.
Such businesses first came up with Web services standards. Such services are based on technologies that originated on the Internet and make use of such technologies as XML and HTTP as a means for representing software parts and linking together a number of different computer systems.
In recent years, there has been an adoption of web services as the standards upon which to base Service Oriented Architecture. Software vendors such as webMethods have brought out on to the market a variety of products that have made SOA quite useful.
Granularity
Why is SOA promoted at such a level of granularity? The answer is fourfold.
1. SOA tends to be considered in terms of web services.
2. Web services technology on the performance level is currently inappropriate at the lower levels of granularity.
3. Web services come from request and reply patterns; thus, they tend to be associated with command and control solutions.
4. EDA models are still not well known – people only look for solutions in more commonly known domains. It is an unfortunate fact that the command and control pattern is inappropriate at this level.
SOA 2.0 can be a good idea in the middle layers of functional composition when it is based on synchronous web services. In those situations, the command and control type of interaction will typically be required, and may in fact be in good balance with the performance of web services.
