This topic includes the following sections:
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 Oracle 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 Oracle Tuxedo EventBroker component.
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 Oracle 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 Oracle Tuxedo system.
The Oracle 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 ( . ).
The Oracle Tuxedo EventBroker is a tool that provides asynchronous routing of application events among the processes running in a Oracle 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” in Tutorials for Developing Oracle 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.
The Oracle 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.
As the administrator for your Oracle 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.
The EventBroker subscription specifies one of the notification methods shown in the following diagram.
tpsubscribe()
function to provide the name of the service to be called.ULOG
. This process must be executed through the MIB.The EventBroker assigns one of three levels of severity to system events such as server terminations or network failure.
If the subscriber is an Oracle Tuxedo client, it can do one of the following at the time it subscribes:
If the subscriber is an Oracle Tuxedo server, it can do one of the following at the time it subscribes: