The Event service allows programmers to subscribe to information channels. Suppliers can generate events without knowing the consumer identities and the consumer can receive events without knowing the supplier identity. Both push and pull event delivery are supported. The Event service will queue information and processes.
The CORBA Event service provides a flexible model for asynchronous, decoupled communication between objects. This chapter outlines communication models and the roles and relationships of key components in the CosEvent service. It shows a simple example on use of this service.
There are five components in the OMG CosEvent service architecture. These are described below:
There are four general models of component collaboration in the OMG CosEvent service architecture. The following describes these models: (Please note that proxies are not shown in the diagrams for simplicity).
Notifier
.
Thus, active suppliers use EventChannels to push data to passive consumers that
have registered with the EventChannels.
Procurer
since it procures
events
on behalf of consumers. Thus, active consumers can explicitly pull
data
from passive suppliers via the EventChannels.
Queue
.
Thus, active consumers can explicitly pull data deposited by active
suppliers via the EventChannels.
Intelligent Agent
. Thus, active EventChannels can pull data from
passive suppliers and push that data to passive consumers.
To be able to use the cosEvent application supplier and consumer objects must be implemented, which must inherit from the appropriate interface defined in the CosEventComm.idl specification.
We start by creating an interface which inherits from the correct interface, e.g., CosEventComm::PushConsumer. Hence, we must also implement all operations defined in the PushConsumer interface. The IDL-file could look like:
#ifndef _MYCLIENT_IDL #define _MYCLIENT_IDL #include <CosEventComm.idl> module myClientImpl { interface ownInterface:CosEventComm::PushConsumer { void ownFunctions(in any NeededArguments) raises(OwnExceptions); }; }; #endif
Run the IDL compiler on this file by calling the ic:gen/1
function.
This will produce the API named myClientImpl_ownInterface.erl
.
After generating the API stubs and the server skeletons it is time to
implement the servers and if no special options are sent
to the IDl compiler the file name is myClientImpl_ownInterface_impl.erl
.
Below is a short transcript on how to run cosEvent.
%% Start Mnesia and Orber mnesia:delete_schema([node()]), mnesia:create_schema([node()]), orber:install([node()]), mnesia:start(), orber:start(), %% Install cosEvent in the IFR. cosEventApp:install(), %% Register the application specific Client implementations %% in the IFR. 'oe_myClientImpl':'oe_register'(), %% Start the cosEvent application. cosEventApp:start(), %% Start a channel using the default configuration Ch = cosEventApp:start_channel(), %% ... or use configuration parameters. Ch = cosEventApp:start_channel([{pull_interval, 10}, {maxEvents, 50}]), %% Retrieve a SupplierAdmin and a ConsumerAdmin. AdminSupplier = 'CosEventChannelAdmin_EventChannel':for_suppliers(Ch), AdminConsumer = 'CosEventChannelAdmin_EventChannel':for_consumers(Ch), %% Use the corresponding Admin object to get access to wanted Proxies %% Create a Push Consumer Proxy, which the Client Push Supplier will push %% events to. ProxyPushConsumer = 'CosEventChannelAdmin_SupplierAdmin':obtain_push_consumer(AdminSupplier), %% Create a Push Supplier Proxy, which will push events to the registered %% Push Consumer. ProxyPushSupplier = 'CosEventChannelAdmin_ConsumerAdmin':obtain_push_supplier(AdminConsumer), %% Create application Clients. We can, for example, start the Clients %% our selves or look them up in the naming service. This is application %% specific. Consumer = myClientImpl_ownInterface:oe_create(), Supplier = ... %% Connect each Client to the corresponding Proxy. 'CosEventChannelAdmin_ProxyPushConsumer': connect_push_supplier(ProxyPushConsumer, Supplier), 'CosEventChannelAdmin_ProxyPushSupplier': connect_push_consumer(ProxyPushSupplier, Consumer),
The example above, exemplifies a event system, i.e., the Canonical Push Model, where the Supplier client in some way generates event and pushes them to the proxy. The push supplier proxies will eventually push the events to each Consumer client.