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>
where
<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.
-ORBIdentity <Id>
number to identify the
daemon (used also in the Orbs file)
(each orb must have a
different id on the network)
-ORBTcpport <port>
port to wait for TCP
connections, default is 6059 + <Id>
Example:
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.
Example:
$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.
Copyright
Micro Focus 2002-2014. All rights reserved.