Understanding 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 adheres to the event message specification. (For details about the event message specification, see the SAS Foundation Services class documentation for the Event Broker Service.) 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 adhere to the event message specification. For unstructured events, the entire event is parsed as the message body.

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

For details about the event message specification, see com.sas.services.events.broker in the Foundation Services Class Documentation.

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

The Event Broker Service works as follows:

1. 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 (remote method invocation) registry to locate the Event Broker Service in order to send events
     • Java clients that are listening can use the appropriate RMI (remote method invocation) registry to locate the Event Broker Service and register to listen for particular events.
   • HTTP: the HTTP transport listens for events sent from HTTP clients. Clients can also be SOAP-enabled.
   • JMS: the JMS transport listens for events 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: the MQJMS transport listens for events sent from WebsphereMQ (formerly MQSeries) messaging clients.
   • JMQ: the JMQ transport listens for events sent from SunONEMQ (formerly iPlanet Message Queue) messaging clients.
   • Mail: the mail transport listens for events sent to IMAP or POP3 mail servers.
   • IOM: the IOM transport listens for events sent from SAS servers.
2. 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.
3. Forwards the event to the appropriate event handling agent(s) 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.
4. 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.

   Important Note: Unstructured event requests are automatically assigned a response type of none. Therefore, for event definitions that will be used to handle unstructured event requests, you must configure the response type as broadcast.

   Important Note: An event is completely qualified by its name and type. Therefore, the Event Broker Service will view 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, an error is returned.

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

• transport monitors
• RMI (remote method invocation).

Overview of Event Broker Discovery Service

The Event Broker Discovery Service provides the ability to locate one or more Event Broker Services that can process a particular event.

By default, an Event Broker Discovery Service can locate any Event Broker Service that is part of its same deployment. However, to locate an Event Broker Service outside of its deployment, the Event Broker Service must be remote-accessible and its location must be defined to the Event Broker Discovery Service. You can define Event Broker Service location information as part of the Event Broker Discovery Service configuration. Format the configuration with XML initialization data as follows:

<EventBrokers>
   <Location url="//host:port/name"/>
   <Location url="//host:port/name"/>
                      ...
</EventBrokers>