The Event Service package provides a facility that de-couples the communication between objects. It provides a supplier-consumer communication model that allows multiple supplier objects to send data asynchronously to multiple consumer objects through an event channel. The supplier-consumer communication model allows an object to communicate an important change in state, such as a disk running out of free space, to any other objects that might be interested in such an event.
|
Figure 27
|
The event channel is both a consumer of events and a supplier of events. The data communicated between suppliers and consumers is represented by the Any class, allowing any CORBA type to be passed in a type safe manner. Supplier and consumer objects communicate through the event channel using standard CORBA requests.
Consumers and suppliers are completely de-coupled from one another through the use of proxy objects. Instead of interacting with each other directly, they obtain a proxy object from the EventChannel and communicate with it. Supplier objects obtain a consumer proxy and consumer objects obtain a supplier proxy. The EventChannel facilitates the data transfer between consumer and supplier proxy objects. The figure below shows how one supplier can distribute data to multiple consumers.
|
Figure 28
|
The Event Service provides both a pull and push communication model for suppliers and consumers. In the push model, supplier objects control the flow of data by pushing it to consumers. In the pull model, consumer objects control the flow of data by pulling data from the supplier.
The EventChannel insulates suppliers and consumers from having to know which model is being used by other objects on the channel. This means that a pull supplier can provide data to a push consumer and a push supplier can provide data to a pull consumer.
|
Figure 29
|
The EventChannel is shown above as a separate process, but it may also be implemented as part of the supplier object's process.
The push model is the more common of the two communication models. An example use of the push model is a supplier that monitors available free space on a disk and notifies interested consumers when the disk is filling up. The push supplier sends data to its ProxyPushConsumer in response to events that it is monitoring.
The push consumer spends most of its time in an event loop, waiting for data to arrive from the ProxyPushSupplier. The EventChannel facilitates the transfer of data from the ProxyPushSupplier to the ProxyPushConsumer.
The figure below shows a push supplier and its corresponding ProxyPushConsumer object. It also shows three push consumers and their respective ProxyPushSupplier objects.
In the pull model, the event channel regularly pulls data from a supplier object, puts the data in a queue, and makes it available to be pulled by a consumer object. An example of a pull consumer would be one or more network monitors that periodically poll a network router for statistics.
The pull supplier spends most of its time in an event loop waiting for data requests to be received from the ProxyPullConsumer. The pull consumer requests data from the ProxyPullSupplier when it is ready for more data. The EventChannel pulls data from the supplier to a queue and makes it available to the ProxyPullSupplier.
The figure below shows a pull supplier and its corresponding ProxyPullConsumer object. It also shows three pull consumers and their respective ProxyPullSupplier objects.
|
Figure 30
|
To create an EventChannel, connect a supplier or consumer to it and use it:
Only one instance of the EventChannel is supported. All binding to the EventChannel is done through the call to orb.resolve_initial_references("EventService"), where EventService is the hardcoded EventChannel name.
This section describes the example of the push supplier and the consumer applications.
This section describes the example push supplier and consumer applications. When executed, the supplier application prompts the user to enter data and then pushes the data to the consumer application. The consumer application receives the data and writes it to the screen.
The push supplier application is implemented in the PushModel.C file and the push consumer is implemented in the PushView.C file. These files can be found in the <install_dir>/examples/vbe/events directory.
The first step in implementing a supplier is to derive our own PushModel class from the PushSupplier interface, shown below.
The code sample below shows the PushModel class, implemented in C++. The disconnect_push_supplier method is called by the EventChannel to disconnect the supplier when the channel is being destroyed. This implementation simply prints out a message and exits. If the PushModel object were persistent, this method might also call deactivate_obj to deactivate the object.
The first portion of the supplier implementation is fairly routine. After doing some initialization, a local scope is set, resulting in a locally-scoped PushModel object.
The example uses command line options to implement the PushSupplier. When the command line option is m, it initializes and instantiates the PushModel object.
If the command line option is p, the example binds to the EventChannel and obtains a SupplierAdmin object from the EventChannel. Note that the application could specify an object name for a specific EventChannel. In a real implementation, the object could be passed as an argument to the application or obtained from the naming service (VisiNaming), if it is available. For more information, go to , “Using the VisiNaming Service.” Next the SupplierAdmin object is used to obtain a proxy for the pushConsumer object from the EventChannel.
A different thread of the supplier application prompts the user for a string, waits for a string to be entered and converts the string to an Any object. Lastly, the data is “pushed” to the consumer proxy object.
The code sample below shows the first part of the supplier application, which defines a PushView class that is derived from the PushConsumer interface, shown below.
module CosEventComm {
exception Disconnected();
interface PushConsumer {
void push(in any data) raises(Disconnected);
void disconnect_push_consumer();
};
};
exception Disconnected();
interface PushConsumer {
void push(in any data) raises(Disconnected);
void disconnect_push_consumer();
};
};
The push method receives an Any type and attempts to convert it to a string and print it. The disconnect_push_supplier method is called by the EventChannel to disconnect the consumer when the channel is destroying itself.
If the command line is v, then the PushConsumer object is instantiated and activated. Different command line options cause it to bind to the EventChannel, obtain the supplier proxy object and connect to the consumer object and wait to receive push requests.
In some environments, consumer applications may run slower than supplier applications. The maxQueueLength parameter prevents out-of-memory conditions by limiting the number of outstanding messages that will be held for each consumer that cannot keep up with the rate of messages from the supplier.
If maxQueueLength is not specified or if an invalid number is specified, a default queue length of 100 is used.
Windows applications need to be linked with the cosev_r.lib (cosev_r.dll) library.