This chapter describes how to install Orber in an Erlang Environment.
To begin with, you must decide if you want to run Orber as a:
domain
, communicate via the Erlang distribution protocol.
For all other Orber instances, i.e. not part of the same domain
,
and ORB's supplied by other vendors, the OMG GIOP protocol
is used.
Which approach to use is highly implementation specific, but a few things you should consider:
You also have to decide if you want Orber to store internal data using
disc_copies
and/or ram_copies
. Which storage type you should
depends if/how you intend to use Mnesia in your application. If you
intend to use disc_copies
you must start with creating a Mnesia
schema, which contain information about the location of the Erlang nodes
where Orber is planned to be run. For more background information,
see the Mnesia documentation.
In some cases it is absolutely necessary to change the default configuration
of Orber. For example, if two Orber-ORB's shall be able to communicate
via GIOP, they must have a unique domain
domain. Consult the
configuration settings
section. If you encounter any problems; see the chapter about
Debugging in this User's Guide.
The easiest way to start Orber is to use orber:jump_start(Port)
,
which start a single-node ORB with (most likely) a unique
domain (i.e. "IP-number:Port"). This function may only be used
during development and testing. For any other situation, install and
start Orber as described in the following sections.
The listen port, i.e. iiop_port configuration parameter, is set to
the supplied Port.
![]() |
How Orber is configured when using |
Since a single node Orber communicate via the OMG GIOP protocol it is not
necessary to start the Erlang distribution (i.e. using -name/-sname
).
If we use ram_copies
there is no need for creating a disc based
schema. Simply use:
erl> mnesia:start(). erl> corba:orb_init([{domain, "MyRAMSingleNodeORB"}]). erl> orber:install([node()], [{ifr_storage_type, ram_copies}]). erl> orber:start().
If you installation requires disc_copies
you must begin with
creating a Mnesia schema. Otherwise, the installation is similar
to a RAM installation:
erl> mnesia:create_schema([node()]). erl> mnesia:start(). erl> corba:orb_init([{domain, "MyDiscSingleNodeORB"}]). erl> orber:install([node()], [{ifr_storage_type, disc_copies}, {nameservice_storage_type, disc_copies}]). erl> orber:start().
You can still choose to store the IFR data as ram_copies, but then
the data must be re-installed (i.e. invoke orber:install/2
)
if the node is restarted. Hence, since the IFR data is rather static
you should use disc_copies
. For more information see the
orber
section in the reference manual.
If you do not need to change Orber's configuration you can skip orb_init/1. But, you should at least set the IIOP timeout parameters.
![]() |
When starting Orber as lightweight, mnesia and |
Within a domain Orber uses the Erlang distribution protocol. Hence, you must start it first by, for example, using:
hostA> erl -sname nodeA
In this example, we assume that we want to use two nodes; nodeA
and
nodeB
. Since Mnesia must know which other nodes should a part
of the distribution we either need to add the Mnesia configuration
parameter extra_db_nodes
or use mnesia:change_config/2
. To
begin with, Mnesia must be started on all nodes before we can install
Orber:
nodeA@hostA> mnesia:start(). nodeA@hostA> mnesia:change_config(extra_db_nodes, [nodeA@hostA, nodeB@hostB]).
After that the above have been repeated on nodeB
we must
first make sure that both nodes will use the same domain name, then
we can install Orber:
nodeA@hostA> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]). nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB], [{ifr_storage_type, ram_copies}]). nodeA@hostA> orber:start().
Note that you can only invoke orber:install/1/2
on one of the
nodes. Now we can start Orber on the other node:
nodeB@hostB> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]). nodeB@hostB> orber:start().
As for RAM based multi-node Orber installations, the Erlang distribution must be started (e.g. erl -sname nodeA). The major difference is that when it is disc based a Mnesia schema must be created:
nodeA@hostA> mnesia:create_schema([nodeA@hostA, nodeB@hostB]). nodeA@hostA> mnesia:start().
In this example, we assume that we want to use two nodes; nodeA
and
nodeB
. Since it is not possible to create a schema on more than
one node. Hence, all we have to do is to start Mnesia (i.e. invoke
mnesia:start()
) on nodeB
.
After Mnesia have been started on all nodes, you must confirm that all nodes have the same domain name, then Orber is ready to be installed:
nodeA@hostA> corba:orb_init([{domain, "MyDiscMultiNodeORB"}]). nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB], [{ifr_storage_type, disc_copies}]). nodeA@hostA> orber:start().
Note that you can only invoke orber:install/1/2
on one of the
nodes. Now we can start Orber on the other node:
nodeB@hostB> corba:orb_init([{domain, "MyDiscMultiNodeORB"}]). nodeB@hostB> orber:start().
If you intend to run Java clients and your Java ORB does not support the Interoperable Naming Service (INS), a specific
<OTP_INSTALLPATH>/lib/orber-<current-version>/priv
must be added to your CLASSPATH variable to allow Orber support for the initial references. For more information about INS, see the Name Service chapter in this User's Guide.
The following configuration parameters exist:
^G
(i.e. \007
).
iiop_connection_timeout
as well. Otherwise, connections
no longer in use will block further communication. If one use, for
example, erl -orber iiop_out_ports "{5000,5020}"
, Orber
will only use port 5000 to 5020 when connecting.
SSL do not support this feature. Hence, one MAY NOT
combine these settings.
infinity
. This option should be set if objects are started
using the option {persistent, true}
.
The value is integer()
seconds.
erl -orber giop_version "{1,2}"
COMM_FAILURE
system exception if no replies are delivered
within the given time limit.
erl -orber interceptors "{native, ['myInterceptor']}"
,
Orber will use the supplied interceptor(s) for all inter-ORB
communication. 'myInterceptor'
is the module name of the
interceptor. For more information, see the interceptor chapter
in the User's Guide and the Reference Manual.
orber:resolve_initial_references_remote/2
argument. The list must
contain Orber nodes addresses, to which we have access and are not started
as lightweight.
erl -orber orbInitRef [\"NameService=corbaloc::host.com/NameService\"]
,
will alter the location from where corba:resolve_initial_references(Key)
tries to find an object matching the given Key. The keys will also appear when
invoking corba:list_initial_services()
. This variable overrides
orbDefaultInitRef
orbInitRef
is not
found, and this variable is set, it determines the location from where
orber:resolve_initial_references(Key)
tries to find an object
matching the given Key. Usage:
erl -orber orbDefaultInitRef \"corbaloc::host.com\"
error_logger
,
for abnormal situations. It is not recommended to use this option
for delivered systems since some of the reports is not to be considered
as errors. The main puropse is to assist during development.
IC supply the compile option ic:gen(IdlFile, [{timeout,"module::interface"}])
,
which allow the user to add an extra timeout parameter, e.g.,
module_interface(ObjRef, Timeout, ... Arguments ...)
, instead of
module_interface(ObjRef, ... Arguments ...)
. If, a stub is compiled
with the timeout option, the extra Timeout argument will override the
configuration parameter iiop_timeout
. It is, however, not possible
to use infinity
to override the Timeout parameter. The Timeout
option is also valid for objects which resides within the same
Orber domain .
The iiop_setup_connection_timeout
, iiop_timeout
and
iiop_connection_timeout
variables should be used. The specified values
is implementation specific, i.e., WAN or LAN, but they should range from
iiop_setup_connection_timeout
to iiop_connection_timeout
.
IIOP communication only occurs between different Orber domains and therefore, if IIOP communication is required between two Orber domains, their domain names must be set to different values.
The following options are the possible configurations when using Orber with secure IIOP. Orber currently only supports security with the help of SSL and not SECIOP. To get more information about the SSL read the SSL application manual. The security chapter later in this manual describes how to get security in Orber and how the options are used.
To change these settings in the configuration file, the
-config
flag must be added to the erl command. See the
Reference Manual
config(4) for further information. The values can also
be sent separately as
options to the Erlang node when it is started, see the Reference
Manual
erl(1) for further information.