A quick review
Part 1 of this series presented the theoretical background for the creation of an enterprise event management framework (EEMF) to allow the generation of unique events with a well-defined vocabulary. The framework required five core features, as shown in Figure 1:
- The definition of a defined event taxonomy to allow uniform hierarchically related event types
- A unique composite propagating global identifier to facilitate reconstruction of the full event tree from any member of that tree
- A transport mechanism to allow disparate systems to emit uniform events to a common processing engine
- An extensible event payload structure to define the content of different event messages
- A persistence mechanism to allow asynchronous generation and consumption of event messages
Figure 1. Core features of an event management framework
This article discusses the design and implementation of a demonstration system illustrating these necessary features. The full source code for the prototype is available for download as a compiled set of web archive (WAR) and Java™ archive (JAR) files that you can deploy to an application server and test using a client application.
Figure 2 illustrates the basic system layout. The
framework design has two main components: the web services tier and the
message middleware tier. The key web services to support client
applications (that is, the event transport layer) are shown as the
get event globally unique identifier (GUID) and
post event services. The first service
allows the client application to obtain a new GUID or to obtain a new
composite GUID if the application is being called by another (which has
passed a composite GUID of its own). The second service is provided to
allow asynchronous posting of an event message that can be constructed
from Java Architecture for XML Binding (JAXB) objects generated from the
defined event taxonomy. The system clients can use a utility library
(telecomevent.jar) to facilitate the generation of event messages and
validate these messages before invoking the web service. The web service
provides a validation check of its own based on the XML schema for the
taxonomy before processing the event. (View a larger version of Figure 2.)
Figure 2. Web service and messaging middleware deployment diagram
post event service, after message
validation, connects to the preconfigured message queue server. The
message queue provides the event persistence mechanism discussed earlier
and allows for asynchronous consumption of events. In this example, a
simple direct queue called event is defined for the service, but
in a more full-featured framework, a message topic is used for
Any consumer of events (such as a business intelligence application or a
complex event rule engine) can be pointed to the event queue (or specific
topic) to consume messages as they are posted. By using a high-performance
messaging queue, the system allows near-real-time delivery of events, even
when one or more of the consuming systems are offline (that is, guaranteed
delivery). In the provided test application, a thread is spun from the
MainWindow class to create an
EventMessageReceiver listening on the
event queue for event messages.
The advantages of this architecture are seen in the ability for any system that can use simple web services, such as hypertext transfer protocol (HTTP) or web services description language (WSDL), to generate valid event messages that are held until the event consumers are prepared to process them. Client applications are not dependent on any particular libraries but can include the framework's utility library to facilitate the creation of well-defined events and posting to the event services.
The services component
The framework service layer is implemented using Spring-WS and has two
critical components: the
GUIDService and the
PostEventService. Both services are illustrated
in Figure 3 and are designed similarly. Each service
has a defined endpoint that provides for the necessary Spring annotations
and configurations to create the web service mappings. Each service has a
defined handler method that parses the incoming XML message and forwards
the request to the service implementation for processing. (View a larger version of Figure 3.)
Figure 3. The two elements of the services component
The GUID service takes a blank string (in the case where the event is at the top of the business workflow) or a valid composite GUID string (from a previous event post in the workflow). The service then generates a new GUID, appends it to the previous one (if supplied), and returns the entire string as an XML message to the service caller.
The Post Event service is a bit more complex. In this case, the client creates a well-defined XML-based event request (containing the event payload) and posts it to the service. The Post Event service then parses the event XML and forwards the event message to the RabbitMQ message queue, currently named event, as a defined queue.
The eemf-ws-servlet.xml Spring configuration file indicates that the configuration for the services is driven by annotations, and the Spring-WS framework scans the base code package for the web service definitions. At this point, the services are simple, non-validated calls. As noted in eemf-ws-servlet.xml (Figure 4), though, an interceptor is defined for message validation. In a future version of the framework, this functionality allows checking of the message structures passed to each of the EEMF frameworks services. Finally, the Spring-WS framework automatically generates the service WSDL based on the eemf.xsd schema for messages. The Spring-WS user guide recommends using automatic generation of WSDL until the service development is complete and then deploying a well-defined WSDL as part of the final delivery. (View a larger version of Figure 4.)
Figure 4. The eemf-web-servlet.xml file
The web services are deployed to an instance of an Apache Tomcat server
using a standard WAR deployment package. The server-side application
contains a web.xml file to describe all the necessary Tomcat
configurations and servlet mappings—in particular, the Spring-WS
MessageDispatcherServlet used to forward all
requests to the properly mapped web service (Figure
5). (View a larger version of
Figure 5. The web.xml file
The event message structure
The event message structure is built directly from the well-defined taxonomy, as described in the event XML schema (TelecomEventTaxonomy.xsd). This approach allows for a single point of definition (and extension) for all event taxonomies. In the case of the prototype, JAXB is used to generate an object hierarchy that can be used directly by Java coders to create properly formed event messages.
The Object Factory (automatically created by JAXB) and the first level of
the event message structure are shown in Figure 6. In
this case, the top of the payload structure is based on the
Customer element with several possible sub
elements (such as
To use these objects, you must include a library in the client application that has the generated JAXB classes. In the case of the prototype, the Apache ANT build script for the server-side application contains a JAXB task to create a JAR file called telecomevent.jar that contains all the necessary client-side code.
Figure 6. The Object Factory message structure
The client application
To test the EEMF, a Swing-based application is provided that allows the creation of several events (including the automatic assignment of a GUID), posting of those events to the web services, retrieval of the event from the RabbitMQ message queue, and display of the posted event in the UI.
As with all Swing applications, the GUI client has a
MainWindow (Figure 7) that
contains a group of radio buttons (to select the proper sample event
type), a button to post the event, and two text fields to display the
service reply message and the event retrieved from the message queue.
(View a larger version of Figure
Figure 7. The client's main window
Two request client classes manage the web service requests:
GUIDRequestClient. The first client calls the
second to get a GUID for the event that is then posted to the EEMF
EventMessageReceiver is running on
a separate thread to listen on the event queue of the RabbitMQ message
queue. When a message is received, it is written to the Event
Message Listener text field for display. The full UI for the
client application is shown in Figure 8.
Figure 8. The client application's UI
The framework in its current state does quite a few useful things, such as provide a JAXB object structure for building and marshaling event messages, deploying a pair of web services to a J2EE server to allow posting of messages, and a default configuration for the message queue running on RabbitMQ. Many features, however, have been left out to illustrate the core functionality of the framework.
The current framework defines an interceptor for XML messages sent to the EEMF services to validate against a defined XSD file. To facilitate development, that feature is currently turned off. In a production-quality framework, though, this feature of Spring-WS is enabled to allow for validation of event messages directly against a version of a XSD file that defines the taxonomy. This functionality prevents the posting of invalid messages (either incomplete or malformed messages) and ensures that the data that the framework provides is consistent and correct.
Robust client utility (Java and Microsoft® .NET)
To facilitate the use of the EEMF, a client utility is provided to make the creation of events—and the posting of those events—as simple and error free as possible. The current design calls for a set of client-side utility objects that can be configured in a similar way to logging (for example, log4j) to define the server address hosting the EEMF services. Event creation is facilitated by the JAXB classes and a set of methods for creating events by type (using the classic Builder pattern). The client utilities are implemented in both Java and Microsoft® .NET to facilitate the use of the EEMF on both platforms. Additional language support will be considered later.
Exceptions for XML validation or other server processing are enhanced to allow the client to correct and resubmit events. In particular, the validation messages that the framework returns indicate the exact problem with the event message so that corrections can be made.
Topic Pub/Sub message handling
To foster a broader use of the events that the EEMF generates, a Topic
queue is defined to allow for the posting of messages to specific
event-type topics. As discussed in Part 1, each event type has a specific identifier built to mirror
the construction of the taxonomy tree. For example, the
Customer event has
taxonomy-id="A", while the next event type in
taxonomy-id="A1". This behavior allows for the
configuration of multiple event topics based on the
taxonomy-id, such that an event consumer
(topic id = A.A1) events
can listen on the appropriate topic queue.
Event database structure
The value of business events is two-fold. First is the ability to respond in near-real time to a variety of event types (such as a customer purchase event or a fraud/intrusion detection); second is the business intelligence that can be realized in after-the-fact reconstruction of daily, weekly, or monthly business operations. To gain the greatest benefit from the EEMF, a database structure for event storage and analysis is provided. This database design takes advantage of both the defined event taxonomy structure and the XML-encoded messages to permit long-term storage of event information for future use.
The EEMF represents a well-defined mechanism for the generation and management of business events. Businesses that can take advantage of the wealth of knowledge represented by the myriad of day-to-day activities and events will be well positioned to respond quickly to changes in the marketplace. Moreover, by understanding the details of a particular customer's interaction with the business, an organization can provide better support and establish a long-term relationship with its customers, thus enhancing customer value and retention.
The prototype framework that accompanies this article illustrates the implementation of the key features of the EEMF, including the taxonomy, unique propagating composite identifiers, a transport mechanism, the event payload structure, and persistence of event messages. Future implementation will allow deployment of the framework not only to new development but also for integration with legacy systems.
|EEMF client GUI client source code||EEMF-GUI-Client_source.zip||4MB|
|EEMF GUI client compiled code||EEMF-GUI-CLIENT-JAR.zip||4MB|
|EEMF server side source code||EEMF-server_source.zip||27MB|
|EEMF server side compiled code||eemf-server-war.zip||13MB|
- Spring website: Learn more about Spring and Spring-WS.
- IBM developerWorks XML zone: Find the latest XML technology information for developers, including many articles on JAXB.
- Java Architecture for XML Binding (JAXB): Read about using JAXB for XML message construction.
- developerWorks technical events and webcasts: Stay current with technology in these sessions.
- developerWorks on Twitter: Join today to follow developerWorks tweets.
- developerWorks podcasts: Listen to interesting interviews and discussions for software developers.
Get products and technologies
- Rabbit MQ documentation: Find instructions for installing and managing the RabbitMQ message server.
- IBM product evaluation versions: Download or explore the online trials in the IBM SOA Sandbox, and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
- developerWorks blogs: Check out these blogs and get involved.