orbriver and idl2ada execution is protected by
license keys which are stored in the file
$ORBRIVER_DIR/etc/top_graph_x.lic. This file is read by the orbriver
daemon named License_Server which should be described in the
$ORBRIVER_DIR/etc/Orbs file (see Configuration).
Each license key is specific to the host where the license server runs and to the licensed tool, and may have an expiration date. Execution of the licensed tool is allowed on any machine capable to connect to the license server, providing that the number of simultaneous runs does not exceed the number of license tokens. The behaviour of the tool in case of license enfringements is tool dependent.
If you will use a single license server:
first execute $ORBRIVER_DIR/bin/machine_id on the computer which will run the license server. Email the result of this command and the host name to Top Graph'X support, you will receive the license keys in return.
If you have several licenses and want to run a
license server on several hosts, do the following for each such host:
write the result of $ORBRIVER_DIR/bin/machine_id on
this host
write the number of orbriver licenses assigned to this
host
write the number of idl2ada licenses assigned to this
host
Email the result to Top
Graph'X support, you will receive the license keys in return.
If
you need more licenses, ask Top
Graph'X.
The instructions to install the license keys will be
provided by Top Graph'X with the license keys.
The tool
$ORBRIVER_DIR/bin/add_license will be used for this purpose. When
adding licenses, add_license first tries to update the running
license server, then it updates the file
$ORBRIVER_DIR/etc/top_graph_x.lic. If it cannot connect to the
license server, a warning message is displayed (this generally means
that the license server is not running). When installing OrbRiver for
the first time, you cannot run any daemon before installing a valid
license key.
The command line environment variable ORBRIVER_DIR
must be set and must contain the name of the directory where OrbRiver
is installed. This installation in a production (not a development
one) environment can be limited to the 'bin' and 'etc' and optionally
'doc' directories.
The daemon topology must be set up in the
$ORBRIVER_DIR/etc/Orbs file (see Configuration).
Different
switches can be set when launching the orbriver daemon (see
Switches).
When the daemon
starts, it tries to connect to the daemon named License_Server in
order to get a license token. The daemon hangs if it cannot get this
token.
The command line environment variable ORBRIVER_DIR
must be set and must contain the name of the directory where OrbRiver
is installed. The command line environment variable ORBRIVER may be
set to the name of the daemon to connect to.
Different
switches can be set when launching the client (see Client
and Service switches).
To apply methods on a CORBA object,
the client application should get the reference of the object. This
reference can be obtained by several means described in Getting
object references.
Services can be launched
manually or directly by the orbriver daemon on request of another
client or service.
When they are launched manually, the
command line environment variable ORBRIVER_DIR must be set and must
contain the name of the directory where OrbRiver is installed. The
command line environment variable ORBRIVER may be set to the name of
the daemon to connect to. Different switches can be set when
launching the service (see Client and Service
switches).
The registration of a service at the Implementation
Repository may be needed for the service to work correctly (see
Editing with impl_editor).
The way
a service can be launched depends on the activation policy of the
required service.
- persitent servers must be launched 'manually'
as the daemon is not allowed to do it
- shared servers can be
launched either 'manually' or by the daemon (if registered by
'impl_editor')
- unshared servers can be launched either
'manually' or by the daemon
For servers launched by the daemon,
'impl_editor' must be used in order for the daemon to know the
server. In the other case, it is not necessary. Anyway, the first
time a server starts, it may do the registration if it is not yet
done.
An server for which several instances are to be created
by clients must be an unshared server, must be registered by
'impl_editor' and must not be launched manually.
When a
service is launched by the daemon, the command line environment
variable ORBRIVER is inherited from the daemon and the proper command
line switches are automatically set. Console output is redirected to
the null device. To get console input, it is necessary to run the
service from an intermediate shell window. This shell must then be
declared as the command line for the service in the
CORBA.Implementation_Repository.Register operation. This shell can
also runs the service on another host (using a remote execution
command), providing that the command line parameters passed to the
shell are also passed to the effective service.
In order for
clients to access directly the service (request and replies do not go
through orbriver, but use the library orb instead), it can be useful
to associate the POA name with a TCP port and to register it in
$ORBRIVER_DIR/etc/Poas.
The root POA name is by default "RootPOA".
It can be changed by running the service with the '-OAName <Root
POA name>' switch (service specific)
In $ORBRIVER_DIR/etc/Poas, each full POA name is
associated a TCP port or port range by the following syntax:
<POA
name> TCP=<TCP port>
<POA name> TCP=<TCP port
range>
There must be no space at the beginning of any line.
Empty lines and lines beginning with '-' are ignored.
POA names in
a POA hierarchy must be separated by '/'.
Example:
--
Standalone services
Echo TCP=7060
RootPOA
TCP=10000-10999
RootPOA/Persist_Factories TCP=12000
The
RootPOA TCP port may be passed on the command line by using the
'-OAport <Root POA TCP port>' switch (service specific). These
arguments can also be passed in the Args parameter of
Corba.Orb.Orb_Init.
Each request is executed by an agent task.
The stack size of such tasks can be adjusted to fullfil the needs of
the service. This can be done by creating a file named "Agents"
in $ORBRIVER_DIR/etc for global settings, or in the current directory
of a service for its particular needs. To change the stack size, put
the line "STACK_SIZE=<size in bytes> in the "Agents"
file, with no intervening blanks. The default stack size is 65536
bytes.
Example:
STACK_SIZE=48000
To find which orbriver daemon an application must connect to, the parameter passed to Corba.Orb.Orb_Init is first taken into account. If it is the null string, several switches are defined (ORBRIVER variable can also be used).
The command line can contain either
-ORBIdentity <Id>
or the pair -ORBHostname <hostname> -ORBTcpport
<port>
or -ORBName <ORB name>
-DebugName
-OAName
-OAport
-IMPLId
-ORBVersion
The meaning of these switches is the following:
-ORBIdentity <Id>
Used to find the orbriver
daemon to which the application must connect
-ORBHostname <hostname>
name of the host where
the orbriver daemon runs (used with -ORBTcpport)
-ORBTcpport <port>
port to connect for TCP
connections, no default (used with -ORBHostname)
-ORBName <Daemon name>
Name of the orbriver
daemon to which the application must connect
-DebugName <Debug name>
to indicate the name
of the application to the OrbRiver debugger
-OAName <POA name>
to indicate the name of the
root POA
-OAport <TCP port>
to indicate the TCP port of
the root POA
-OAport <TCP port min value>-<TCP port max
value>
to indicate the TCP port range of the root POA
-IMPLId <Impl Id>
used internally by the
Implementation Repository
-ORBVersion
to display the OrbRiver library version
used in the application
These switches can be overridden by arguments passed
to Corba.Orb.Orb_Init.
The switch -DebugName <process
name> provides a way to run a process (client or service) in debug
mode so that CORBA requests and replies from or to this process can
be displayed by the OrbRiver debugger.
Copyright
Micro Focus 2002-2014. All rights reserved.
