| Issue 1, 2012 |
What do these things have in common? An order is placed for a new product, an airplane lands, a credit card is used. If you guessed that these are examples of business events, then you guessed correctly. Events like these happen all the time in business, and are often the backbone of an organization. Unfortunately, these events are often stuck in stovepipe systems and never exposed to other systems that could use them. Over the last decade a silent revolution has been taking place that has focused on liberating these events and making them useful in innovative ways. The foundation of this change is an architectural style called Event-Driven Architecture.
Event-Driven Architecture (EDA) refers to a style of software architecture based on real-time flows of (you guessed it) events. EDA is a buzzword pushed by Gartner as far back as 2003. At that time Roy Schulte of Gartner went so far as to say, that in Service-Oriented Architectures (SOA), connecting services occurs in a linear, predictable sequence, whereas an event-driven architecture allows for multiple, less predictable, asynchronous events to happen in parallel and trigger a single action.
The many benefits of an EDA approach include:
Dynamic Determinism. EDA enables the enterprise to react to events in accordance with a dynamically changing set of business rules or conditions.
Data Correlation. EDA enables correlation of data for analytics and business process modeling, management, and governance.
Real-time Agility. EDA enables agility in realizing business analytics and dynamically changing analytic models based upon real-time environmental data.
Operational Agility. EDA enables agility in operational change management.
Awareness. EDA brings greater consciousness of events to the enterprise nervous system.
In order to understand EDA and why it is important, you must first understand what an ‘event’ is. An event is a significant change in state. When a plane lands for example, the plane’s state changes from ‘in flight’ to ‘landed’. The airport system produces a ‘plane landed’ event that is then consumed by any other system impacted by that event and kicks off a whole chain of events. The ‘plane landed’ event could trigger an announcement to the entire airport that the plane has landed which in turn triggers many simultaneous actions such as:
- The baggage handlers start moving to the gate to remove baggage.
- A person at the gate heads to a shop to quickly buy water.
- A person far from the gate starts running toward the gate area.
- The gate agent starts prepping the outbound passengers to board.
When applied to IT systems, EDA offers an amazing amount of power and flexibility. Imagine that a ‘fraudulent credit card’ event was emitted from a system. Immediately the following processes could kick off simultaneously: the credit card is placed on hold, the nearest authorities are alerted, and the card owner is alerted. Each of these individual processes only needs to listen for a ‘fraudulent credit card’ event.
EVENT CONSUMERS, FORMAT AND DISTRIBUTION
An important characteristic of EDA is that the producer of the event has no knowledge about the consumer of the event. In the previous example, the ‘plane landed’ announcement went out to the entire airport whether or not anyone was listening. The producer of the event merely produces the event regardless of the consumer.
Another characteristic of EDA is that the producer and consumer of the events know the format of the event. It some ways this is like a contract between the producer and consumer. In the airport example, the ‘plane landed’ event might contain information such as the time, flight number, departure city and the arrival gate. The consumer of the event is expecting this information and would not be able to operate if it were absent. Think what would happen, for example, if the arrival gate information was missing; everyone’s process would be stalled until that information is gathered and provided.
We have established thus far that event producers emit relevant events no matter if there is an interested consumer of the events and that the events that they produce are of a specific, pre-established format. The third important characteristic of EDA is a common event distribution channel or event bus. The event bus is what the event producer uses to distribute its events and where the event consumer goes to consume the events. There is great flexibility in what medium is used as the event bus. In the airport example, the event bus was the public announcement system. In today’s IT systems the event bus is typically JMS or broker-based.
EDA IN WEBMETHODS
Software AG has a long history of providing EDA-based services and the story gets better and better in every release. Software AG’s webMethods suite is a pioneer in the field of EDA with one of the industries first successful broker technologies that followed a pub/sub model of event distribution. Seeing the vast potential of EDA, Software AG did not stop with its initial event bus. In the 8.0 release of the webMethods suite, new EDA features were introduced:
- Virtually all products were enhanced with the ability to both produce and consume events.
- The event bus was enhanced to use virtually any available JMS transport.
- An event type editor was introduced to make it easy to create events types.
- An event type store was created that all products share for a common event definition.
- A Complex Event Processing (CEP) engine was brought to market to make it easy to understand complex correlations among event streams.
- An EDA Orchestrator component was created to make it easy for non-Software AG systems contribute to EDA.
- Event types were integrated with Centrasite to allow enterprise-wide event type governance.
- New IS services were introduced that make it trivial to move between internal document types and EDA event types.
These features make it possible to completely rethink how applications and integrations are architected and implemented. For example, knowing that an application will emit events in a common way makes it possible to easily grab these events for display on a dashboard in ARIS MashZone, or use webMethods Business Events to understand the complex correlations among the events, or even use BPM to listen for specific events and then start a process when it sees them. The decoupled and highly flexible nature of EDA makes the integration of these systems more of an assembly exercise rather than an integration or development exercise.
CONCLUSION
Software AG continues to invest in its industry-leading EDA capabilities by adding an enterprise event store that can be used to capture, reuse, analyze and report on events. We will also introduce a new architectural component called NERV that will allow the event bus to greatly expand from JMS and broker to over a hundred other transport protocols at very high speeds.
While EDA is a concept that has been around for a decade, the industry is just beginning to understand the power and flexibility it offers. Software AG is helping drive this awakening by investing heavily in EDA as a core part of its ongoing product offering.
Learn more about webMethods Business Events at:
www.softwareag.com/corporate/products/wm/events/
And join the new section for webMethods Business Events on the Software AG Tech Community at:
techcommunity.softwareag.com/webmethods/products/business-events