Skip navigation.

Administering a Tuxedo Application at Run Time

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

About the EventBroker

This topic includes the following sections:


What Is an Event?

An event is a state change or other occurrence in a running application (such as a network connection being dropped) that may require intervention by an operator, an administrator, or the software. The BEA Tuxedo system reports two types of events:

Application events are occurrences of application-defined events, and system events are occurrences of system-defined events. Both application and system events are received and distributed by the BEA Tuxedo EventBroker component.


Differences Between Application-defined and System-defined Events

Application-defined events are defined by application designers and are therefore application specific. Any of the events defined for an application may be tracked by the client and server processes running in the application.

System-defined events are defined by the BEA Tuxedo system code and are generally associated with objects defined in TM_MIB(5). A complete list of system-defined events is published on the EVENTS(5) reference page. Any of these events may be tracked by users of the BEA Tuxedo system.

The BEA Tuxedo EventBroker posts both application-defined and system-defined events, and an application can subscribe to events of both types. The two types of events can be distinguished by their names: the names of system-defined events begin with a dot ( . ); the names of application-specific events cannot begin with a dot ( . ).


What Is the EventBroker?

The BEA Tuxedo EventBroker is a tool that provides asynchronous routing of application events among the processes running in a BEA Tuxedo application. It also distributes system events to whichever application processes want to receive them.

The EventBroker performs the following tasks:

Note: For a sample application that you can copy and run as a demo, see Tutorial for bankapp, a Full C Application on page 3-1 in Tutorials for Developing BEA Tuxedo ATMI Applications.

The EventBroker recognizes over 100 meaningful state transitions to a MIB object as system events. A posting for a system event includes the current MIB representation of the object on which the event occurred and some event-specific fields that identify the event that occurred. For example, if a machine is partitioned, an event is posted with the following:

You can use the EventBroker simply by subscribing to system events. Then, instead of having to query for MIB records, you can be informed automatically when events occur in the MIB by receiving FML data buffers representing MIB objects.


How the EventBroker Works

The BEA Tuxedo EventBroker is a tool through which an arbitrary number of suppliers of event notifications can post messages for an arbitrary number of subscribers. The suppliers of such notifications may be application or system processes operating as clients or servers. The subscribers of such notifications may be administrators or application processes operating as clients or servers.

Client and server processes using the EventBroker communicate with one another based on a set of subscriptions. Each process sends one or more subscription requests to the EventBroker, identifying the event types that the process wants to receive. The EventBroker, in turn, acts like a newspaper delivery person who delivers newspapers only to customers who have paid for a subscription. For these reasons, the paradigm on which the EventBroker is based is described as publish-and-subscribe communication.

Event suppliers (either clients or servers) notify the EventBroker of events as they occur. We refer to this type of notification as posting an event. Once an event supplier posts an event, the EventBroker matches the posted event with the subscribers that have subscribed for that event type. Subscribers may be administrators or application processes. When the EventBroker finds a match, it takes the action specified for each subscription; subscribers are notified and any other actions specified by subscribers are initiated.

The following diagram shows how the EventBroker handles event subscriptions and postings.

Figure 5-1 Posting and Subscribing to an Event

Posting and Subscribing to an Event


As the administrator for your BEA Tuxedo application, you can enter subscription requests on behalf of client and server processes through calls to the T_EVENT_COMMAND class of the EVENT_MIB(5). You can also invoke the tpsubscribe(3c) function to subscribe, programmatically, to an event by using the EventBroker.

Event Notification Methods

The EventBroker subscription specifies one of the notification methods shown in the following diagram.

Figure 5-2 Supported Notification Methods

Supported Notification Methods


Severity Levels of System Events

The EventBroker assigns one of three levels of severity to system events such as server terminations or network failure.

The level of severity is . . .

When the EventBroker is informed of . . .


An abnormal occurrence, such as a server being terminated or a network connection being dropped.

INFO (short for "Information")

A state change resulting from a process or a change in the configuration.

WARN (short for "Warning")

The fact that a client has not been allowed to join the application because it failed authentication. A configuration change that threatens the performance of the application has occurred.


What Are the Benefits of Brokered Events?

See Also


Skip navigation bar  Back to Top Previous Next