Overview of Events


	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 \| Programming \| Topic List \| Previous \| Next \| Contents

Programming a BEA Tuxedo Application Using COBOL

Overview of Events

Event-based communication provides a method for a BEA Tuxedo system process to be notified when a specific situation (event) occurs.

The BEA Tuxedo system supports two types of event-based communication:

Unsolicited events
Brokered events

Unsolicited Events

Unsolicited events are messages used to communicate with client programs that are not waiting for and/or expecting a message.

Brokered Events

Brokered events enable a client and a server to communicate transparently with one another via an "anonymous" broker that receives and distributes messages. Such brokering is another client/server communication paradigm that is fundamental to the BEA Tuxedo system.

The EventBroker is a BEA Tuxedo subsystem that receives and filters event posting messages, and distributes them to subscribers. A poster is a BEA Tuxedo system process that detects when a specific event has occurred and reports (posts) it to the EventBroker. A subscriber is a BEA Tuxedo system process with a standing request to be notified whenever a specific event has been posted.

The BEA Tuxedo system does not impose a fixed ratio of service requesters to service providers; an arbitrary number of posters can post a message for an arbitrary number of subscribers. The posters simply post events, without knowing which processes receive the information or how the information is handled. Subscribers are notified of specified events, without knowing who posted the information. In this way, the EventBroker provides complete location transparency.

Typically, EventBroker applications are designed to handle exception events. An application designer must decide which events in the application constitute exception events and need to be monitored. In a banking application, for example, it might be useful to post an event whenever an unusually large amount of money is withdrawn, but it would not be particularly useful to post an event for every withdrawal transaction. In addition, not all users would need to subscribe to that event; perhaps only the branch manager would need to be notified.

Notification Actions

The EventBroker may be configured such that whenever an event is posted, the EventBroker invokes one or more notification actions for clients and/or servers that have subscribed. The following table lists the types of notification actions that the EventBroker can take.

EventBroker Notification Actions

Notification Action
Description

Unsolicited notification message

Clients may receive event notification messages in their unsolicited message handling routine, just as if they were sent by the TPNOTIFY routine.

Service call

Servers may receive event notification messages as input to service routines, just as if they were sent by TPACALL.

Reliable queue

Event notification messages may be stored in a BEA Tuxedo system reliable queue, using TPDEQUEUE(3cbl). Event notification records are stored until requests for contents are issued. A BEA Tuxedo system client or server process may call TPDEQUEUE(3cbl) to retrieve these notification records, or alternately TMQFORWARD(5) may be configured to automatically dispatch a BEA Tuxedo system service routine that retrieves a notification record.

For more information on /Q, see Using the BEA Tuxedo /Q Component.

Notification Action	Description
Unsolicited notification message	Clients may receive event notification messages in their unsolicited message handling routine, just as if they were sent by the TPNOTIFY routine.
Service call	Servers may receive event notification messages as input to service routines, just as if they were sent by TPACALL.
Reliable queue	Event notification messages may be stored in a BEA Tuxedo system reliable queue, using TPDEQUEUE(3cbl). Event notification records are stored until requests for contents are issued. A BEA Tuxedo system client or server process may call TPDEQUEUE(3cbl) to retrieve these notification records, or alternately TMQFORWARD(5) may be configured to automatically dispatch a BEA Tuxedo system service routine that retrieves a notification record. For more information on /Q, see Using the BEA Tuxedo /Q Component.

In addition, the application administrator may create an EVENT_MIB(5) entry (by using the BEA Tuxedo administrative API) that performs the following notification actions:

Invokes a system command
Writes a message to the system's log file on disk
Note: Only the BEA Tuxedo application administrator is allowed to create an EVENT_MIB(5) entry.

For information on the EVENT_MIB(5), refer to the BEA Tuxedo File Formats and Data Descriptions Reference.

EventBroker Servers

TMUSREVT is the BEA Tuxedo system-supplied server that acts as an EventBroker for user events. TMUSREVT processes event report message records, and then filters and distributes them. The BEA Tuxedo application administrator must boot one or more of these servers to activate event brokering.

TMSYSEVT is the BEA Tuxedo system-supplied server that acts as an EventBroker for system-defined events. TMSYSEVT and TMUSREVT are similar, but separate servers are provided to allow the application administrator the ability to have different replication strategies for processing notifications of these two types of events. Refer to Setting Up a BEA Tuxedo Application for additional information.

System-defined Events

The BEA Tuxedo system itself detects and posts certain predefined events related to system warnings and failures. These tasks are performed by the EventBroker. For example, system-defined events include configuration changes, state changes, connection failures, and machine partitioning. For a complete list of system-defined events detected by the EventBroker, see EVENTS(5) in the BEA Tuxedo File Formats and Data Descriptions Reference.

System-defined events are defined in advance by the BEA Tuxedo system code and do not require posting. The name of a system-defined event, unlike that of an application-defined event, always begins with a dot ("."). Names of application-defined events may not begin with a leading dot.

Clients and servers can subscribe to system-defined events. These events, however, should be used mainly by application administrators, not by every client in the application.

When incorporating the EventBroker into your application, remember that it is not intended to provide a mechanism for high-volume distribution to many subscribers. Do not attempt to post an event for every activity that occurs, and do not expect all clients and servers to subscribe. If you overload the EventBroker, system performance may be adversely affected and notifications may be dropped. To minimize the possibility of overload, the application administrator should carefully tune the operating system IPC resources, as explained in Installing the BEA Tuxedo System.

Programming Interface for the EventBroker

EventBroker programming interfaces are available for all BEA Tuxedo system server and client processes, including Workstation, in both C and COBOL.

The programmer's job is to code the following sequence:

A client or server posts a record to an application-defined event name.
The posted record is transmitted to any number of processes that have subscribed to the event.

Subscribers may be notified in a variety of ways (as discussed in "Notification Actions"), and events may be filtered. Notification and filtering are configured through the programming interface, as well as through the BEA Tuxedo system administrative API.