| Previous | Table of Contents | Next |
When an application requires a CORBA environment it needs a mechanism to get the ORB pseudo-object reference and possibly
an OA object reference (such as the root POA). This serves two purposes. First, it initializes an application into the ORB
and OA environments. Second, it returns the ORB pseudo-object reference and the OA object reference to the application for
use in future ORB and OA operations.
The ORB and OA initialization operations must be ordered with ORB occurring before OA: an application cannot call OA initialization
routines until ORB initialization routines have been called for the given ORB. The operation to initialize an application
in the ORB and get its pseudo-object reference is not performed on an object. This is because applications do not initially
have an object on which to invoke operations. The ORB initialization operation is an application’s bootstrap call into the
CORBA world. The ORB_init call is part of the CORBA module but not part of the ORB interface.
Applications can be initialized in one or more ORBs. When an ORB initialization is complete, its pseudo reference is returned
and can be used to obtain other references for that ORB.
In order to obtain an ORB pseudo-object reference, applications call the ORB_init operation. The parameters to the call comprise
an identifier for the ORB for which the pseudo-object reference is required, and an arg_list, which is used to allow environment-specific
data to be passed into the call. PIDL for the ORB initialization is as follows:
// PIDL
module CORBA { typedef sequence <string> arg_list; ORB ORB_init (inout arg_list argv, in ORBid orb_identifier);
};
The identifier for the ORB will be a name of type CORBA::ORBid. All ORBid strings other than the empty string are allocated
by ORB administrators and are not managed by the OMG. ORB administration is the responsibility of each ORB supplier. ORB suppliers
may optionally delegate this responsibility. ORBid strings other than the empty string are intended to be used to uniquely
identify each ORB used within the same address space in a multi-ORB application. These special ORBid strings are specific
to each ORB implementation and the ORB administrator is responsible for ensuring that the names are unambiguous.
If an empty ORBid string is passed to ORB_init, then the arg_list arguments shall be examined to determine if they indicate
an ORB reference that should be returned. This is achieved by searching the arg_list parameters for one preceded by “-ORBid?
for example, “-ORBid example_orb? (the white space after the “-ORBid? tag is ignored) or “-ORBidMyFavoriteORB? (with no white
space following the “-ORBid? tag). Alternatively, two sequential parameters with the first being the string “-ORBid? indicates
that the second is to be treated as an ORBid parameter. If an empty string is passed and no arg_list parameters indicate the
ORB reference to be returned, the default ORB for the environment will be returned.
Other parameters of significance to the ORB can also be identified in arg_list, for example, “Hostname,? “SpawnedServer,?
and so forth. To allow for other parameters to be specified without causing applications to be re-written, it is necessary
to specify the parameter format that ORB parameters may take. In general, parameters shall be formatted as either one single
arg_list parameter:
–ORB<suffix><optional white space> <value>
or as two sequential arg_list parameters:
-ORB<suffix>
<value>
Regardless of whether an empty or non-empty ORBid string is passed to ORB_init, the arg_list arguments are examined to determine
if any ORB parameters are given. If a non-empty ORBid string is passed to ORB_init, all ORBid parameters in the arg_list are
ignored. All other -ORB<suffix> parameters in the arg_list may be of significance during the ORB initialization process.
Before ORB_init returns, it will remove from the arg_list parameter all strings that match the -ORB<suffix> pattern described
above and that are recognized by that ORB implementation, along with any associated sequential parameter strings. If any strings
in arg_list that match this pattern are not recognized by the ORB implementation, ORB_init will raise the BAD_PARAM system
exception instead.
The ORB_init operation may be called any number of times and shall return the same ORB reference when the same ORBid string
is passed, either explicitly as an argument to ORB_init or through the arg_list. All other -ORB<suffix> parameters in the
arg_list may be considered on subsequent calls to ORB_init.
Note – Whenever an ORB_init argument of the form -ORBxxx is specified, it is understood that the argument may be represented
in different ways in different languages. For example, in Java -ORBxxx is equivalent to a property named org.omg.CORBA.ORBxxx.
4.5.1.1 Server ID
A Server ID must uniquely identify a server to an IMR. This specification only requires unique identification using a string
of some kind. We do not intend to make more specific requirements for the structure of a server ID.
The server ID may be specified by an ORB_init argument of the form
-ORBServerId
The value assigned to this property is a string. All templates created in this ORB will return this server ID in the server_id
attribute.
It is required that all ORBs in the same server share the same server ID. Specific environments may choose to implement -ORBServerId
in ways that automatically enforce this requirement.
For example, the org.omg.CORBA.ServerId system property may be set to the server ID in Java when a Java server is activated.
This system property is then picked up as part of the ORB_init call for every ORB created in the server.
4.5.1.2 Server Endpoint
The server endpoint information is passed into ORB_init by an argument of the form
-ORBListenEndpoints <endpoints>
The format of the <endpoints> argument is proprietary. All that is required by this specification is that each time ORB_init
is called with the same value for this argument, the resulting ORB will listen for requests on the same set of endpoints,
so that persistent object references for the ORB will continue to function correctly.
4.5.1.3 Starting Servers with No Proprietary Server Activation Support
Any server started with the flag:
-ORBNoProprietaryActivation
shall avoid the use of any proprietary activation framework.