Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
Tuxedo Doc Home   |   Administration   |   Topic List   |   Previous   |   Next   |   Contents

   Administering a BEA Tuxedo Application at Run Time

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.

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.

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

• Notify a client-The EventBroker keeps track of a client's interest in particular events and notifies the client, without being prompted, when such an event occurs. For this reason, this method is called unsolicited notification.

• Invoke a service-If a subscriber wants event notifications to be passed to service calls, the subscriber process should invoke the tpsubscribe() function to provide the name of the service to be called.

• Enqueue message to stable-storage queues-For subscriptions with requests to send event notifications to stable-storage queues, the EventBroker will obtain a queue space, queue name, and correlation identifier. A subscriber specifies a queue name when subscribing to an event. The correlation identifier can be used to differentiate among multiple subscriptions for the same event expression and filter rule, that are destined for the same queue.

• Execute a command-When an event is posted, the buffer associated with it is transformed into a system command that is then executed. For example, the buffer may be changed to a system command that sends an email message. This process must be executed through the MIB.

• Write messages to the userlog-When events are detected and matched by the EventBroker, the specified messages are written to the userlog, or ULOG. This process must be executed through the MIB.

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 . . .
ERROR	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.