Corba Components and Servers


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.



 
NameServer

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.

 

Event Notifier Description

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. 

 

Object Manager

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

 


Name Server

The purpose of the name Server is to provide access to CORBA objects and services. This server provides the ability to bind an ASCII name string to an object reference.  Clients may retrieve an object reference by supplying the ASCII name string for the corresponding object.

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);

 IDL
 

Event Notifier

The Event Notifier is a CORBA compliant server that receives requests for and delivers events asynchronously to a destination object In addition to its routing and event delivery functions, the Event Notifier serves to decouple the event supplier from the event receiver. The event generator does not need any knowledge of the location or implementation of the object receiving the event. Thus the client application code is not linked to any object receiver implementation code.
 

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.
 
 

IDL

Object Manager

Objects in the ONCS software system are managed by an object called the object manager. The function of the object manager is to manage the creation, activation and removal of all objects that are known to a server. The object manager implements methods which will allow it to dynamically create or destroy objects in its local server. The object manager itself is a CORBA compliant object that is created in a server which is known to the ONCS Name Service. Once objects are created and maintained by the object manager, they become available to receive events from any client in the system via the Event Notifier. The object manager may also return a reference of any object known to the object manager to a requesting client application. This will allow an object's methods to be invoked directly by remote clients if desired.
 

Back To Top
 


  Home Page