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.
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.
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.
The EventChannel is shown above as a separate process, but it may also be implemented as part of the supplier object's process. See
“Starting the Event Service” for more information.
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.
See “In-process event channel” for more information about how to start the event service in Java.
To create an EventChannel, connect a supplier or consumer to it and use it:
where <channelName> is the user-specified object name of the event channel and
<iorFilename> is a user-specified filename of the file to which the
ior of the object is to be written.
PushModelChannel first creates an EventChannel and publishes its ior to the file
<iorFilename> given by the user. Other clients (for example, PushModel) can then bind to the EventChannel by using the initial reference.
This section describes the example of the push supplier and the consumer applications.
This section describes the example push supplier and consumer applications. The files
PullSupply.java and
PullConsume.java implement the supplier and consumer. These files can be found in the
<install_dir>/examples/vbroker/events directory.
To run these examples, you need a supplier-consumer pair. You can pair a consumer of type Push or Pull can be paired with any supplier of type Push or
Pull. The order in which you invoke the supplier and consumer does not matter. However, the event channel must be the same object instance.
prompt> vbj -DORBInitRef=EventService=file:<fullpath of iorFilename> PushModel
Select e to bind to an event channel,
p to get a proxy to a push consumer from the event channel,
m to instantiate a PushModel, and
c to connect the event channel.
Continuous sentences indicating the content of the message being pushed to the EventChannel will be displayed. You can continue to make selections regardless of what is displayed on the screen. You can specify the number of seconds between events using the
s option. Lastly, select
d to disconnect and
q to quit.
prompt>vbj -DORBInitRef=EventService=file:
<fullpath of iorFilename> PushView
Select e to bind to an event channel,
p to get a proxy to a push supplier from the event channel,
v to instantiate a PushView,
c to connect the event channel,
d to disconnect and
q to quit. To run this example, a supplier of type
Push or
Pull must be running on another terminal, continuously sending data to the same event channel in order for
PushView to receive the data. The supplier and consumer can be started in any order.
prompt> vbj -DORBInitRef=EventService=file:
<fullpath of iorFilename> PullModel
Select e to bind to an event channel,
p to get a proxy to a push consumer from the event channel,
m to instantiate a PullModel,
c to connect the event channel,
d to disconnect and
q to quit.
prompt>vbj -DORBInitRef=EventService=file:
<fullpath of iorFilename> PullView
Select e to bind to an event channel,
p to get a proxy to a push supplier from the event channel,
v to instantiate a PushView,
c to connect the event channel. Then select
a to pull asynchronously or
s to pull synchronously. To exit, select
d to disconnect and
q to quit.
To run this example, a supplier of type Push or
Pull must be running on another terminal, continuously sending data to the same event channel in order for
PullView to receive the data. The supplier and consumer can be started in any order.
The PullSupply class is derived from the
PullSupplierPOA class and provides implementations for the
main,
pull and
try_pull methods. The
pull method, shown below, returns a numbered “hello” message. The
try_pull method always sets the
hasEvent flag to true and calls the
pull method to provide the message. Once a
PullSupply object is connected to an
EventChannel, these methods are used by the channel to pull data from the supplier.
The main method, shown below, performs the usual VisiBroker ORB and POA creation, connects to the specified
EventChannel, obtains a
ProxyPullConsumer from the
EventChannel, instantiates a
PullSupply object, activates the PullSupply object on the POA, then connects this pull supplier to proxy pull consumers.
After compiling PullSupply.java and starting the Event Service, described in
“In-process event channel”, you can execute the supplier with the following command:
The PullConsume class is derived from
PullConsumerPOA class and provides a command line interface for pulling data from the
PullSupply class. The code sample above shows how the application connects to any available EventChannel, obtains a
ProxyPullSupplier, connects to the channel, and displays a command prompt. The table below summarizes the commands that may be entered.
After compiling PullConsume.java and starting the Event Service, described in
“In-process event channel”, you can execute the consumer with the following command:
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.
In addition to running an EventChannel as a separate, stand-alone server, the Event Service allows you to create an
EventChannel within your server or client application. This frees you from having to start a separate process to provide the
EventChannel for your supplier or consumer applications.
For Java applications, an EventLibrary class is provided that provides methods for creating an
EventChannel which, in turn, handles the loading of the necessary classes. To create an in-process
EventChannel object within a supplier/consumer application, make the following call:
So, to create a channel named MyChannel with debugging off and a maximum queue length of
100, you would write:
The ior_filename specifies the name of the file to which the ior string of the channel will be written.
PushModelChannel is a push supplier. You can connect either a push consumer or pull consumer to the event channel created in
PushModelChannel:
where <fullpath of ior_filename> is the full path of the ior filename passed into
PushModelChannel and
EventService is the name (or identifier) bound to the ior contained in
<ior_filename>. From within
PushView, you can bind to the event channel as follows:
The file PushModelChannel.java implements a push supplier that uses an in-process event channel. This application presents a command prompt and allows you to enter one of the commands shown below.
|
|
|
|
|
|
|
|
|
Creates a PushModelChannel and activates it on the POA.
|
|
|
|
|
|
|
The code sample below contains an excerpt from PushModelChannel.java that shows how you can use the
ChannelLib.create_channel method.