CORBA is the core technology on which teh distributed computing system
for the PHENIX computing system is build. CORBA provides a sound
standards-based technology for building distributed systems. However, CORBA
does not impose a design architecture on the distributed system.
That is left up to the system designer.
Every distributed computing system must provide a means for locaating and obtaining references to remote objets, invoking remote methods and delivering client data to server components, and managing the life cycle of objects in the computing system. Three main system services and components were developed in the PHENIX computing system to provide these functions. These are the naming service, the event notifier and the object manager component.
The nameserver provides a location independent means to gain access to components in the Phenix architecture. The nameserver will return a reference to an object when given an ASCII name for a component object. The nameserver provides methods to register objects with and delete objects from the server. The list of registered objects can be obtained from the server. Upon termination of a server in which a registered object originated, the nameserver will delete the object reference via a callback mechanism.
|
This is a CORBA server provides asynchronous delivery of messages between CORBA objects. This server provides an implementation of a publish / subscribe design pattern. Objects register their interest in receiving events which contain messages that are relevent for that object.
|
This component is responsible for the management of CORBA objects within a CORBA server. This component provides functions to create, destroy, access an object reference and obtain information about the number of active objects
|
A naming service provides access to ONCS services by associating a character
string name with an object reference. ONCS system software will register
with the name service, an object reference and the character name by which
this object is known to the ONCS system. Client applications can retrieve
the object reference from the name service which can then be used to invoke
an ONCS service. The name service itself resides at a well known location.
It is the key to gaining access to ONCS services. The name service has
methods for registering objects with the name service as well as for resolving
an object reference when given the character name string for an object.
The interface and the public methods of the name service is defined in
the Interface Definition Language (IDL) file.
To use the name service a client first binds to the name service server
using the Orbix supplied bind function. The bind function returns a reference
to the name server. Then the name service method ResolveName is invoked
to obtain a reference to a registered remote service. In the example given
below, a reference to the Event Notifier service which has the name identifier
of "eventnotifier" is obtained from the name server. The Event Notifier
will have been registered with the name server when the server first starts
up. Once this object reference is obtained, methods of this remote object
can be invoked directly. An example of using the name service to obtain
an object reference is given below.
// declare and bind to the ONCS name server
nameserv_ptr pnameservice;
pnameservice = NameServer::_bind(":NameServ"," ");
//Obtain a reference to the remote object "eventnotifier" from the name server
CORBA:: Object_ptr pobject;
EventNotifier_ptr pevnot;
// resolve the remote object name from the name server
pnameservice->ResolveName("eventnotifier",pobject) ;
pevnot = EventNotifier::_narrow(pobject);
// invoke a method on the remote object obtained from the name server
pevnot->sendevent(pevent);
The Event Notifier works by first having an object that has an interest
in receiving an event to be registered with the event Notifier. Registering
an object to receive an event results in the creation of a mapping between
the object character name and the CORBA object reference. This mapping
is maintained by the Event Notifier. Once an object is registered, the
event Notifier can look up, and associate its character name identifier
with the reference to the object. When an object is registered with the
Event Notifier, an event list is submitted with the request for registration.
The event Notifier will use this event list to filter events, and to only
pass along those events for which the object wishes to be notified of.
Applications use the Event Notifier by first obtaining a reference to it
from the ONCS Name Service which will be described below. Once a reference
to the Event Notifier has been obtained, a client application can send
a command to any registered object by invoking the sendevent method of
the Event Notifier. The sendevent method takes as an argument a structure
which contains the identity of the destination object, an event identifier
and any auxiliary data which is required by the destination object for
this command.
The Event Notifier has public methods to register, and remove an object as well as to send events to any registered objects. These public methods are defined in the Interface Definition Language (IDL) file for the Event Notifier and is given below.
The Event Notifier is modeled after the OMG CORBAservices Event Services
[5]. This is a service which is defined by the OMG to provide indirect
communication between event producers and consumers. This service employs
a construct called an event channel. The event channel appears to be an
object which implements either a push or pull model of events. That is,
event generators can push events into the event channel and events are
pushed on to the event receiver. Alternatively, an event receiver can request
or pull events from the event channel and the event channel will in turn
pull any pending events from the event supplier. The ONCS Event Notifier
mechanism is patterned after the push event model.