![]() |
![]() |
![]() |
![]() |
![]() |
• System-defined events—which are situations (primarily failures) defined by the Oracle Tuxedo system, such as the exceeding of certain system capacity limits, server terminations, security violations, and network failures.
• Application-defined events—which are situations defined by a customer application, such as the ones listed in Table 5‑1.
Table 5‑1 Application-defined 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.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.
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 name of the affected machine, as specified in the T_MACHINE class, with all the attributes of that machine
• Some event attributes that identify the event as machine partitionedYou 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.Figure 5‑1 shows how the EventBroker handles event subscriptions and postings.Figure 5‑1 Posting and Subscribing to an EventAs 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.Figure 5‑2 Supported Notification Methods
• 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 e-mail message. This process must be executed through the MIB.
• Write messages to the user log—when events are detected and matched by the EventBroker, the specified messages are written to the user log, or ULOG. This process must be executed through the MIB.Table 5‑2 shows the severity levels of system events.
Table 5‑2 Severity Levels of System Events INFO (short for “Information”) WARN (short for “Warning”)
• Anonymous communication—the Event Broker enables Oracle Tuxedo programs to subscribe to events in which they are interested and it keeps track of all subscriptions. Therefore, a subscriber to one event does not need to know which programs subscribe to the same event, and a poster of an event does not need to know which other programs subscribe to that event. This anonymity allows subscribers to come and go without synchronizing with posters.
• Decoupling of exception conditions—a publish-and-subscribe communication model allows the software detecting an exception condition to be decoupled from the software handling the exception condition.
• Tight integration with the Oracle Tuxedo system—the EventBroker retains functionality such as message buffers, messaging paradigms, distributed transactions, and ACL permission checks for event postings.
• Variety of notification methods—when a client or server subscribes to a system event (such as the termination of a server) or an application event (such as an ATM machine running out of money), it specifies an action that the EventBroker should take when it is notified that the target event has occurred.
• “Subscribing, Posting, and Unsubscribing to Events with the ATMI and the EVENT_MIB” on page 6‑3 in Introducing Oracle Tuxedo ATMI
• EVENT_MIB(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference
• tpsubscribe(3c) in the Oracle Tuxedo ATMI C Function Reference
• tpunsubscribe(3c) in the Oracle Tuxedo ATMI C Function Reference