| Issue 2, 2012 |
Implementing an Event-Driven Architecture (EDA) can give amazing productivity gains and lead to a very flexible and scalable heterogeneous integration environment. Like any worthwhile endeavor, the rewards are high but so are the implementation costs unless you have the right set of tools to help you. In TECHniques Issue 1 2012 (techcommunity.softwareag.com/techniques), I gave you a brief overview of Event-Driven Architecture (EDA) and how it can significantly enhance how you build integrated heterogeneous systems. In this article, I will examine some of the tools that Software AG offers that make it easy to move to an EDA.
One of the fundamental aspects of EDA is that there exists a commonly understood event-type definition between all EDA participants. This ensures that both the emitters (producers) and the receivers of events know exactly what to expect from each other. In some ways, this can be thought of as a contract between them. Those of you who read my previous article might question this statement since in theory the producer of an event has no knowledge of the receiver and emits events regardless of the receiver. In reality, the producer typically tries to emit events that are relevant to the perceived recipients so that that the events can be easily used.
Under the premise that an EDA includes a set of event-types that everyone knows, then the following requirements for a well-run EDA are easy to understand:
- An event bus
- A way to model event-types
- A common place to store event-types so that participants can find them
- A way to easily get events onto and off of the event bus
- A way to visually see events on the event bus
- A way to govern events (optional)
- A way to produce events for testing (optional)
Let’s look closer at how Software AG’s tools help you create a well-run EDA environment with minimum implementation costs.
Event Bus
Following industry standards, Software AG supports JMS as its primary event bus. We, of course, use the webMethods Broker as the transport, but all components of the WebMethods suite have been created in such a way that virtually every JMS provider can be used. While JMSs can support both queues and topics, JMS topics are the preferred transport mechanism. Choosing topics over queues allows for easy distribution of events without the data storage issues that typically occur with JMS queues. Learn more about Software AG's high speed event bus, Nirvana, in Jonathan Heywood's article "A New Era in Messaging: webMethods Nirvana Messaging” in this issue of TECHniques.
Event-Type Editor
In order to make the modeling of events as simple as possible, Software AG created the Event-Type Editor which has been available for download via the Software AG Installer since webMethods 8.0. This editor is an Eclipse plug-in within webMethods Designer that supports drag-and-drop field assignment for greater ease-of-use and flexibility. By using this tool, it is virtually impossible to create an invalid event-type. You only need to create the fields that you want passed and the header information is taken care of for you.
Technical note: Event-Type definitions are in standard XSD format. While you don’t have to use Software AG’s Event-Type Editor, it makes things a lot easier.
Event-Type Store
Event-types are stored in a new directory under the Software AG install directory called “\Software AG\common\EventTypeStore”. Out-of-the-box, this directory is pre-populated with standard events used in Software AG products. This is also where you will place event-types that you create with the Event-Type Editor. Every EDA participant knows about the Event-Type Store so they know where to look for standard definitions. We chose to use a standard directory as the Event-Type Store for simplicity. Every operating system understands the directory hierarchy so there is no additional software to install. It is also possible to use standard replication techniques to keep the directories in sync.
Sending And Receiving Events
EDA is of little use if there is not an easy way to get events onto and off of the event bus. In webMethods Integration Server 8.2, we introduced two new services: EDA:send and EDA:eventToDocument. With these services, it is possible to easily connect to a JMS topic and interact with typical webMethods Integration Server flows. These services are located within the standard WmPublic package in the pub:event:eda folder. Both packages interact using the standard Integration Server Document type and need knowledge of the Event-Type Store as indicated above.
Event Bus Console
In order to make sure that everything is working correctly, it is often necessary to tap into the event bus and visually inspect the events that are flowing through it. We made this easy for our users by building an Event Bus Console directly into the webMethods Designer. With it, you can select the transport then the topic and see every event that is present on that topic in real-time. This plug-in is accessible once you install the Continuous Query Development perspective. If there is ever an issue with EDA, the first place I turn is to the Event Bus Console to inspect the events in real-time.
Event Governance
As I stated earlier, the event-type is often thought of as a contract between the event-producer and the event-consumer. Both are aware of the event-type, and both rely on specific fields being there in order to work correctly. But what happens if the event-producer decides to change the event-type without alerting the consumer of the event? It is very possible that the downstream consumers will experience an issue that will have to be reconciled.
Within Software AG, we believe that event-types need to be governed in very much the same way that web services need to be governed in a Service-Oriented Architecture. To govern event-types, we have integrated EDA event-type information into Centrasite. This allows easy identification and full governance of deployed event-types. This new integration leverages industry-leading Centrasite capabilities to make sure that the defined event-type lifecycle is followed and has management overview. While event governance is not a requirement, it will make your life much easier as your EDA grows in complexity.
Event Generation (For Testing)
Ok…so you have your event-bus established; you have topics ready to receive and distribute events; you have designed event-types; and you have services ready to act on the events. The next hurdle is to actually start sending events and monitor how the system reacts.
Of course, it is possible to create a flow within the webMethods Integration Server that leverages the aforementioned EDA:Send to generate events, but that would require you to create all of the logic from scratch. To make developers’ work easier, we created a free utility called the Event Generator. With this utility, it is possible to create very sophisticated event-flow patterns and rates based upon your defined event-types and connections. The Event Generator is a free tool that can be downloaded from the Software AG Tech Community.
While wading into an Event-Driven Architecture may be intimidating, it can be relatively pain-free with the right set of tools and the results that you will gain are well worth the effort. Software AG is continually developing its EDA toolset and features to make establishing an EDA as easy as possible.