Enterprise event management framework, Part 2: A prototype implementation

Business events represent a vast untapped resource for many organizations. Capture of events generated by a diverse set of internal systems allows for creation of customer-individual profiles, business intelligence to guide decision making, and a mechanism for detection of fraud and security intrusions. Moreover, timely knowledge of particular business events allows an organization to respond quickly to customer actions, such as an online purchase of a product or a request to cancel service. In this article, we implement an enterprise event management framework demonstration application with open source services and a messaging framework.

Benjamin Lieberman , Ph.D., Principal Software Architect, BioLogic Software Consulting

author photoBen Lieberman serves as principal architect for BioLogic Software Consulting. He provides expertise in consulting and training on a variety of software development topics, including software architecture, requirements analysis, software analysis and design, configuration management, and development process improvement. Lieberman brings more than 10 years of software architecture and IT experience in various fields, including telecommunications, airline travel, e-commerce, government, financial services, and life sciences. His consulting services are based on the best practices of software development, with specialization in object-oriented architectures and distributed computing — in particular, Java™-based systems and distributed Web-site development (J2EE), XML/XSLT, Perl, and C++ based client-server systems. Lieberman has provided architectural services to corporate organizations, including EchoStar, Jones Cyber Solutions, Blueprint Technologies, Trip Network Inc., Galileo International; educational institutions, including Duke University and the University of Colorado; and governmental agencies, including the Mine Safety and Health Administration. He is also an accomplished professional writer with a book and numerous software-related articles to his credit. Lieberman holds a doctorate in biophysics and genetics from the University of Colorado, Health Sciences Center.

23 May 2011

Also available in

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
Event framework core features

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.

System overview

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 the 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
Web service and messaging middleware deployment diagram

The 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 Pub/Sub-type operations.

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 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 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.)

Figure 5. The web.xml file
The web.xml file

The event message structure

Deployment of the EEMF server application

The EEMF demonstration application is compiled into a deployable WAR file that you can copy into the webapp directory of a compatible Java 2 Platform, Enterprise Edition (J2EE) application server, such as Tomcat. The framework uses the standard WSDL mechanism over the Tomcat port 8080 for exposure of the web services. The server-side application connects at run time with a standard instance of RabbitMQ (see Resources for installation instructions) that requires no additional configuration over the default settings running on the local host. The graphical user interface (GUI) client is a self-contained executable JAR file that launches the test application using the standard Java execution syntax (for example, java -jar EEMF-GUI-CLIENT.jar). Note that the Event Message Listener attempts to connect to the RabbitMQ instance and needs to be manually connected using the supplied button if the message server instance is not running.

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 Purchase or Contact).

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 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 7.)

Figure 7. The client's main window
The client's main window

Two request client classes manage the web service requests: PostEventRequestClient and GUIDRequestClient. The first client calls the second to get a GUID for the event that is then posted to the EEMF service. The 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 client application's UI

Future direction

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.

Exception handling

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 the tree Purchase has taxonomy-id="A1". This behavior allows for the configuration of multiple event topics based on the taxonomy-id, such that an event consumer interested in Customer-Purchase (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 codeEEMF-GUI-Client_source.zip4MB
EEMF GUI client compiled codeEEMF-GUI-CLIENT-JAR.zip4MB
EEMF server side source codeEEMF-server_source.zip27MB
EEMF server side compiled codeeemf-server-war.zip13MB



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Business process management on developerWorks

Zone=Business process management
ArticleTitle=Enterprise event management framework, Part 2: A prototype implementation