Using the Java Messaging Service (JMS) interface, you can develop
event consumers that receive event notifications asynchronously from JMS queues
or topics.
An event consumer can be implemented as a standard Java class
or as a Message-Driven Bean (MDB).
By using the JMS interface, you can implement your event consumer using
standard Java tools and programming models, and you can avoid the performance
disadvantages of directly querying the event data store. Instead of interacting
with the Common Event Infrastructure directly, your event consumer subscribes
to JMS destinations (queues and topics) and receives event notifications in
the form of JMS messages.
The Common Event Infrastructure organizes events in event groups, which
are logical collections of events defined in the Common Event Infrastructure
configuration. A particular event consumer typically needs to receive only
events from specific event groups.
The configuration profile for each event group associates that event group
with one or more JMS destinations through which notifications related to that
event group are distributed. The relationships between event groups and JMS
destinations are as follows:
- An event group can be associated with multiple queues.
- An event group can be associated with only one topic. (Multiple event
consumers can subscribe to the same topic, so publishing the same event group
to more than one topic is redundant.)
- A JMS destination (queue or topic) should typically be associated with
only one event group.
To receive messages from an event group, a JMS consumer subscribes to the
appropriate destination. Each time an event matching the associated event
group is created, modified, or deleted, a notification is delivered in the
form of a JMS message containing an event notification. The content of the
notification depends upon its type:
- For a new or modified event, the notification includes the complete event
data, which can be converted into a CommonBaseEvent instance.
- For a deleted event, the notification includes the global instance identifier
of the event that has been deleted.
In addition to the standard JMS interfaces, a JMS event consumer interacts
with a facility called the Notification Helper. The Notification Helper translates
between Common Event Infrastructure entities (events and event groups) and
equivalent JMS entities (messages and destinations). The Notification Helper
provides the following functions:
- It identifies the JMS topic or queues associated with a specified event
group. Your event consumer can then use the appropriate destination to create
subscriptions.
- It converts event notifications for new and changed events into instances
of CommonBaseEvent.
- It can provide filtering of events at the consumer. Each Notification
Helper can be associated with an event selector specifying which events should
be returned to consumers. When a consumer uses the Notification Helper to
convert an event notification into an event instance, the event instance is
returned only if it matches the specified event selector.
Note: The notification
helper uses the Apache JXPath component to process XPath event selectors.
If Java 2 security is enabled, you must modify your policy file to include
the following entries:
permission java.util.PropertyPermission "*", "read";
permission java.io.FilePermission
"${was.install.root}${/}java${/}jre${/}lib${/}jxpath.properties",
"read";