Using OpenFusion RTORB Ada Edition
The Ada95 Object Request Broker


orbriver is either a server and a library orb. This means that there is a standalone program capable to provide the orb functionality to several services or clients, or they can embed their own orb. This is opposed to pure library orbs, where each client or service must embed its own orb.
The OrbRiver server orb may start in any directory. It logs its output in a file named $ORBRIVER_DIR/etc/orbriver_<Id>.log, where <Id> is the identity number of the ORB.
orbriver embeds the Interface Repository, the Implementation Repository and the Naming service. It also embeds the PrismTech producer specific license service. These services and their contents are persistent and their state are saved in dedicated files in the $ORBRIVER_DIR/etc directory.
This also means that the daemon "$ORBRIVER_DIR/bin/orbriver" must be running at all times on a machine on the network (and, first of all, the License_Server daemon) if any OrbRiver CORBA clients and services are to use the services it embeds.
Client and services can run on any machine providing that they can physically connect to an orbriver daemon from this machine if they need it.
orbriver uses GIOP (the standardized protocol between ORBs) to communicate with its connected clients and services.

OrbRiver limitations

OrbRiver does not support the "server per method" activation policy.
It can only start local services (services which run on the same host as the orb), but it can start a script which can itself start a remote service.
Persistence of objects must be managed by their implementation.

Objects life cycle

The Life Cycle service is not yet implemented. Services are responsible for the life cycle of the objects they manage (see Building a service).

OrbRiver configuration

The command line environment variable ORBRIVER_DIR must be set and contain the name of the directory where OrbRiver is installed. The file Orbs in the etc directory of the ORBRIVER_DIR directory contains the list of the known orbriver daemons.
There should be at most one daemon definition per line and an ORB definition should fit in one line.
Several names may have the same definition. In this case, these different names are aliases of the same orbriver daemon, which then can be accessed with any of the aliases.
Comment lines start with -- and blank lines are allowed.
ORB names are not case sensitive.
There should exist a daemon named License_Server with "TCP=6060" which will be used as the license server for CORBA PrismTech tools (like orbriver and idl2ada).
OrbRiver hangs if the daemon named "License_Server" is not running or if no license token is available.
The format of the Orbs file is:
<Orb_Name> ID=<Orb_Id> HOST=<Host_Name> TCP=<TCP port>

There should be no space on any side of the = sign. Example

OrbRiver_1 ID=1 HOST=localhost TCP=6060
License_Server ID=1 HOST=localhost TCP=6060
OrbRiver_2 ID=2 TCP=6061

OrbRiver switches


To start the daemon named OrbRiver_1 as defined in the Orbs example file above, do (it will be also viewed as License_Server)
$ORBRIVER_DIR/bin/orbriver -ORBName OrbRiver_1 # Unix systems
%ORBRIVER_DIR%\bin\orbriver -ORBName OrbRiver_1 !! rem Windows-Nt systems

Stopping OrbRiver with stop_orb

stop_orb is the client to cleanly stop the daemon. This means that the contents of the Interface Repository, the Implementation Repository and the Naming service are then saved into files so that they can be automatically reloaded when the daemon restarts. Connected services will be informed and time will be left for them to save their state.
$ORBRIVER_DIR/bin/stop_orb -ORBName OrbRiver_1 # Unix systems
%ORBRIVER_DIR%\bin\stop_orb -ORBName OrbRiver_1 !! rem Windows-Nt systems

The detailed orb termination scheme is the following:

The daemon first forbids any new connection, The daemon informs the object adapters that it will stop,
The root POA stops the CORBA main loop of all the connected services,
The daemon leaves time for the different services to clean themselves,
When all are stopped, or if not, after a certain time, the daemon sends a GIOP CloseConnection message to all the still connected services and clients,
The daemon closes all the connections,
The daemon exits.

Email Micro Focus support

Copyright Micro Focus 2002-2014. All rights reserved.