Getting Started

We assume that you have installed the user-leve code and C++ libraries, and the Orbacus libraries and executables. The following are steps that are performed infrequently as opposed to every time you run S or R.

It is useful to have the following environment variables set. Since they are used when by the CORBA facilities in S and R, it would be simplest to set them in your .cshrc/.tcshrc/.bashrc/.profile initialization file.
VariableSuggest ValueExplanation
OMEGA_HOME ..../org/omegahat where ... is the full path to where the Omegahat source code was untarred.
ORBACUS_CONFIG $OMEGA_HOME/Interfaces/CORBA/CORBAConfig/Orbacus.config Edit this to specify the machine and port for the different CORBA service applications - naming service, interface repository and potentially the event channel server.
LD_LIBRARY_PATH $OMEGA_HOME/lib:location of Orbacus libraries location to find shared libraries against which the S.so and R.so files are linked. These include the shared libraries distributed with (or compiled from) the Omegahat distribution and the Orbacus libraries (libOB.so, libCosNaming.so).
Assuming you have the LD_LIBRARY_PATH and ORBACUS_CONFIG variables set correctly, then we can start the different CORBA services.

The naming service is where objects are registered by name in different "directories".

 nameserv &

The Interface Repository (IR)

 irserv &
 irfeed -I$OMEGA_HOME/include/IDL Omega.idl 

Running S or R

At this point, you can use the facilities in S or R.

% S
> attach("$OMEGA_HOME/S/CORBA")
Next we have to initialize the C++ code. This is done automatically via the .on.attach() in S4/Splus5.0 and .First.lib in R. (This is currently not done yet. At this point, give the command
> get(".First", pos=2)()
)

At this point, you can find CORBA objects registered with the naming service via the command > namingServiceContents() This returns a named vector of logical values. The names are those registered with the top-level naming service. Values which are TRUE indicate the that name is associated with another/nested naming context. Values which are FALSE are regular CORBA objects.

To find the available methods an object has to offer, we can query the interface repository. (This assumes that the IDL has been registered with it using the irfeed executable) Let's assume that we have a CORBA-aware version of XGobi running (see XGobi) registered with the naming service as "XGobi". Then we can find the IDL interface that this server implements via the expression:

> idlType("XGobi")
[1] "IDL:XGobi/XGobi:1.0"
The argument is the name of the CORBA object.

With this, we can find the "contents" of this interface using

> x <- idlInterface(idlType("XGobi"))
x is now a list containing information about the interface:
  • operations
    named list of the operation descriptions for the methods defined just in this interface, providing the return type and the different parameters, their types and whether they are in, inout or out. To get all the methods available, query the super-classes recursively.
  • attributes
    named list of IDL attributes in this interface providing the type of each and whether it is read-only or not.
  • superclass
    a character vector of the IDL types which this interface extends or inherits.
  • idltype
    the name of this interface's IDL type.

  • Duncan Temple Lang <duncan@research.bell-labs.com>
    Last modified: Sat Aug 28 09:30:19 EDT 1999