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 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.
The Life Cycle service is not yet implemented. Services are responsible for the life cycle of the objects they manage (see Building a service).
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>
<Orb_Name> indicates the name of the ORB (may be put in ORBRIVER variable)
<Orb_Id> indicates the identification number of the ORB
<Host_Name> indicates the host where the ORB runs
<TCP port> indicates the TCP port for IIOP connections to the ORB
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 HOST=omg.org TCP=6061
-ORBName <orb name>
name to identify the orbriver daemon in the Orbs file, default is the command name. When started under a particular name, the daemon will behave as if it was started with any of the names having the same definition. If this switch is set several times, only the first is taken into account.
number to identify the daemon (used also in the Orbs file)
(each orb must have a different id on the network)
port to wait for TCP connections, default is 6059 + <Id>
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
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.