Understanding the Event Broker Service

Overview of the Event Broker Service

The Event Broker Service enables you to receive external event notifications and process them based on the name of the event that is received. Events can be structured or unstructured as follows:

A structured event is specified as well-formed XML and conforms to the event message specification. (For details about the event message specification, see the SAS Foundation Services class documentation for the Event Broker Service at http://support.sas.com/rnd/javadoc/93.) It contains information such as the name of the event, the associated properties, and the message body.
An unstructured event must also be specified as well-formed XML. However, it does not conform to the event message specification. For unstructured events, the entire event is parsed as the message body.

Note: The Event Broker Service handles unstructured events only if default event handlers have been configured.

For details about the event message specification, see the class documentation for com.sas.services.events.broker in the SAS Foundation Services class documentation at http://support.sas.com/rnd/javadoc/93.

The following figure shows the components of the Event Broker Service:

Components of the Event Broker Service

The Event Broker Service works as follows:

Listens for incoming events via transports or applications. The Event Broker Service can monitor for and receive events via the following transports:
RMI

If the RMI transport is enabled, the Event Broker Service registers itself to one or more RMI registries.

To enable the event broker service to be accessed via RMI, you must enable remote access in the service configuration. Enabling remote access registers the service to the RMI Registry. Remote access to the Event Broker Service enables the following:

Java clients that are sending can use the appropriate RMI registry to locate the Event Broker Service in order to send events.

Java clients that are listening can use the appropriate RMI registry to locate the Event Broker Service and register to listen for particular events.
HTTP

listens for events that are sent from HTTP clients. Clients can also be SOAP-enabled.

JMS

listens for events that are sent from any JMS-compliant messaging client. This transport uses administered objects to isolate client applications from the proprietary aspects of a provider. When you configure this transport, you specify whether the administered objects are on the local file system or an LDAP directory server. The transport then uses JNDI to look up the administered objects on the local files system or LDAP directory server.

MQJMS

listens for events that are sent from WebsphereMQ (formerly MQSeries) messaging clients.

JMQ

listens for events that are sent from SunONEMQ (formerly iPlanet Message Queue) messaging clients.

Mail

listens for events that are sent to IMAP or POP3 mail servers.

IOM

listens for events that are sent from SAS servers.
Determines the event name to use for event configuration information. The Event Broker Service parses the event XML to determine the event name (or names if a naming hierarchy is used) to use for event configuration information. If an unstructured event is received, the Event Broker Service uses the service configuration information to map the unstructured event to a default event name.
Forwards the event to the appropriate event handling agents, based on the configured event type. The Event Broker Service uses configuration information defined for the event name or default event names to determine appropriate actions to take for the event.

For a broadcast event type, the Event Broker Service notifies all handling agents (process flows and listening applications) of the event as follows:
- If an application is a registered listener for an event, the Event Broker Service notifies the listening application of the event.
- If the event configuration contains process flows, the Event Broker Service instantiates a flow engine for each configured process flow in order to process the event message.
For a request/response event type, the Event Broker Service notifies only one handling agent (listening application or process flow) as follows:
- If an application is a registered listener for an event, the registered listener has precedence over a process flow. Only one process flow can be defined for request/response types. Therefore, the Event Broker Service forwards the event to the listening application.
- If the event configuration contains a process flow and there is no application that is a registered listener, the Event Broker Service instantiates a flow engine to process the event message.
Sends a response based on the event response type. The Event Broker Service uses the event configuration to determine whether to send a response to an event.
- If the event sender does not require a reply, the event request should specify a response type of none or ack (acknowledge). To configure an event for no response or acknowledge, you specify broadcast as the event type. For acknowledge response types, the Event Broker Service sends an acknowledge receipt to the event sender.
- If the event sender requires a reply, the event request should specify a response type of result. To configure an event for a response, you specify request/response as the event type. For request/response types, the Event Broker Service sends a response to the event sender.
Note: Unstructured event requests are automatically assigned a response type of none. Therefore, for event definitions that are used to handle unstructured event requests, you must configure the response type as broadcast.

Note: An event is completely qualified by its name and type. Therefore, the Event Broker Service views events as separate events if they are sent or configured with the same name, but different event types. For example, if you send an event named AlertHigh with a response type of none to an event broker that contains an event definition named AlertHigh that is configured as a request/response type of event, then an error is returned.

Applications can send and receive events using either of the following:

transport monitors
RMI