OrbixEvents Programmer's Guide

Chapter 1 Introduction to the CORBA Event Service

The CORBA Event Service specification defines a model of communication that allows an application to send an event that will be received by any number of objects. The model provides two approaches to initiating event communication. For each of these approaches, event communication can take two forms. This chapter introduces the terminology and concepts that are used throughout this guide.

OrbixEvents implements the CORBA Event Service specification. This specification defines a model for communications between ORB applications that supplements the direct operation call system that client/server applications normally use.

This chapter introduces the basic concepts of the CORBA Event Service communications model. Later chapters will describe the programming interface in detail and show how to implement applications that use the CORBA Event Service using OrbixEvents.

Communications using the CORBA Event Service

Figure 1.1 illustrates the standard CORBA model for communication between distributed applications.

Figure 1.1: CORBA Model for Basic Client/Server Communications

In this model, a client application calls an IDL operation on a specified object in a server. The client waits for the call to complete and then receives confirmation of the return status. For any operation call there is a single client and a single server, and each must be available for the call to succeed.

This simple, one-to-one communication model is fundamental to the CORBA architecture. However, some ORB applications need a more complex, indirect communication style. The CORBA Event Service defines a communication model that allows an application to send a message to objects in other applications without any knowledge about the objects that receive the message.

The CORBA Event Service introduces the concept of events to CORBA communications. An event originates at an event supplier and is transferred to any number of event consumers. Suppliers and consumers are completely decoupled: a supplier has no knowledge of the number of consumers or their identities, and consumers have no knowledge of which supplier generated a given event.

In order to support this model, the CORBA Event Service introduces to CORBA a new architectural element, called an event channel. An event channel mediates the transfer of events between the suppliers and consumers as follows:

The event channel allows consumers to register interest in events, and stores this registration information.
The channel accepts incoming events from suppliers.
The channel forwards supplier-generated events to registered consumers.

Suppliers and consumers connect to the event channel and not directly to each other (Figure 1.2). From a supplier's perspective, the event channel appears as a single consumer; from a consumer's perspective, the event channel appears as a single supplier. In this way, the event channel decouples suppliers and consumers.

Figure 1.2: Suppliers and Consumers Communicating through an Event Channel

Any number of suppliers can issue events to any number of consumers using a single event channel. There is no correlation between the number of suppliers and the number of consumers, and new suppliers and consumers can be easily added to the system. In addition, any supplier or consumer can connect to more than one event channel.

A typical example that uses an event-based communication model is that of a spreadsheet cell. Many documents may be linked to a spreadsheet cell and these documents need to be notified when the cell value changes. However, the spreadsheet software should not need knowledge of each document linked to the cell. When the cell value changes, the spreadsheet software should be able to issue an event which is automatically forwarded to each connected document.

CORBA defines the Event Service at a level above the ORB architecture. Suppliers, consumers and event channels may be implemented as ORB applications, while events are defined using standard IDL operation calls. Suppliers, consumers and event channels each implement clearly defined IDL interfaces that support the steps required to transfer events in a distributed system.

Figure 1.3: An Example Implementation of Event Propagation

Figure 1.3 illustrates an example implementation of event propagation in a CORBA system. In this example, suppliers are implemented as CORBA clients; the event channel and consumers are implemented as CORBA servers. An event occurs when a supplier invokes a clearly defined IDL operation on an object in the event channel application. The event channel propagates the event by invoking a similar operation on objects in each of the consumer servers. To make this possible, the event channel application stores a reference to each of the consumer objects, for example, in an internal list.

This is not the only way in which the concept of events can map to a CORBA system. In particular, the CORBA Event Service identifies two approaches to initiating the propagation of events, and these affect the implementation architecture. "Initiating Event Communication" on page 5 addresses this topic in detail.

"Types of Event Communication" on page 9 discusses how events can map to IDL operation calls, and describes how you can associate data with an event using IDL operation parameters.

Initiating Event Communication

CORBA specifies two approaches to initiating the transfer of events between suppliers and consumers. These approaches are called the Push model and the Pull model. In the Push model, suppliers initiate the transfer of events by sending those events to consumers. In the Pull model, consumers initiate the transfer of events by requesting those events from suppliers.

This section illustrates each approach in turn, and then describes how these models can be mixed in a single system.

The Push Model

In the Push model, a supplier generates events and actively passes them to a consumer. In this model, a consumer passively waits for events to arrive. Conceptually, suppliers in the Push model correspond to clients in normal CORBA applications, and consumers correspond to servers.

Figure 1.4 illustrates a Push model architecture in which push suppliers communicate with push consumers through an event channel.

Figure 1.4: Push Model Suppliers and Consumers Communicating through an Event Channel

In this architecture, a supplier initiates the transfer of an event by invoking an IDL operation on an object in the event channel. The event channel invokes a similar operation on an object in each consumer that has registered with the channel.

The Pull Model

In the Pull model, a consumer actively requests that a supplier generate an event. In this model, the supplier waits for a pull request to arrive. When a pull request arrives, event data is generated by the supplier and returned to the pulling consumer. Conceptually, consumers in the Pull model correspond to clients in normal CORBA applications and suppliers correspond to servers.

Figure 1.5 illustrates a Pull model architecture in which pull consumers communicate with pull suppliers through an event channel.

Figure 1.5: Pull Model Suppliers and Consumers Communicating through an Event Channel

In this architecture, a consumer initiates the transfer of an event by invoking an IDL operation on an object in the event channel application. The event channel then invokes a similar operation on an object in each supplier. The event data is returned from the supplier to the event channel and then from the channel to the consumer which initiated the transfer.

Mixing the Push and Pull Models in a Single System

Because suppliers and consumers are completely decoupled by an event channel, the Push and Pull models can be mixed in a single system. For example, suppliers may connect to an event channel using the Push model, while consumers connect using the Pull model as shown in Figure 1.6.

Figure 1.6: Push Model Suppliers and Pull Model Consumers in a Single System

In this case, both suppliers and consumers must participate in initiating event transfer. A supplier invokes an operation on an object in the event channel to transfer an event to the channel. A consumer then invokes another operation on an event channel object to transfer the event data from the channel. Unlike the case in which consumers connect using the Push model, the event channel takes no initiative in forwarding the event. The event channel stores events supplied by the push suppliers until some pull consumer requests an event, or until a push consumer connects to the event channel.

Types of Event Communication

The CORBA Event Service maps an event to a successfully completed sequence of operation calls. The operations and the sequence of calls are clearly defined for both Push and Pull models, and data about an event can be passed as operation parameters or return values. This data is specific to each application and is generally not interpreted by implementations of the CORBA Event Service, such as OrbixEvents.

Event communication can take one of the two forms, typed or untyped.

Untyped Event Communication

In untyped event communication, an event is propagated by a series of generic push() or pull() operation calls. The push() operation takes a single parameter which stores the event data. The event data parameter is of type any, which allows any IDL defined data type to be passed between suppliers and consumers. The pull() operation has no parameters but transmits event data in its return value, which is also of type any. Clearly, in both cases, the supplier and consumer applications must agree about the contents of the any parameter and return value if this data is to be useful.

Typed Event Communication

In typed event communication, a programmer defines application-specific IDL interfaces through which events are propagated. Rather than using push() and pull() operations and transmitting data using an any, a programmer defines an interface that suppliers and consumers use for the purpose of event communication. The operations defined on the interface may contain parameters defined in any suitable IDL data type. In the Push model, event communication is initiated simply by invoking operations defined on this interface. The Pull model is more complex because event communication is initiated by invoking operations on an interface that is specially constructed from the application-specific interface that the programmer defines. Event communication is initiated by invoking operations on the constructed interface.

The form that event communication takes is independent of the method of initiating event transfer. As a consequence, the Push model can be used to transmit typed events or untyped events, and the Pull model can be used to transmit typed or untyped events.