Configuration Options

The configuration options for CORBA brokers can be separated in three categories: those common for all OiL ORB that define how to create and assemble its internal components; CORBA related options that are valid for any instance of CORBA ORBs; and finally, options related to the specific GIOP implementation used. For the last group, we will present only the options specific to the IIOP, which is the one currently supported by standard OiL.

General Options

As described in section Initializing Brokers, the config argument of operation oil.init can define component instances that should be used to assemble the broker, as well as define the specific flavor that will define which component implementations will be used in the creation of the broker. Standard OiL defines only four standard flavors for creation of CORBA brokers, as listed below.

CORBA support without multithreading.
CORBA support with multithreading.
CORBA support without multithreading, but with support for invocation interceptions.
CORBA support with multithreading and support for invocation interceptions.

Basically, the rules to form a CORBA flavor is that the corba keyword must precede the type keyword because the implementation of the CORBA support depends on the features provided by the architectural Core Architecture. The use of the keyword cooperative is optional to define if the broker will provide support for multithreading. However, it is preferable that it come after the corba keyword. The intercepted keyword defines the support for interception of remote invocations (see section Intercepting Invocations) and must precede the corba keyword, because it defines alternative implementation of CORBA specific components. Finally, the base keyword must be present in all flavors because it defines the basic implementation of the core components of OiL ORBs. For more information about flavors, see section Flavors.

CORBA Options

The configuration table of CORBA brokers can define the specific GIOP implementation to be used. This is done by the field tag that shall contain the tag number of the GIOP implementation. Unfortunately, standard OiL currently supports only the IIOP implementation, which tag number, as defined by CORBA, is zero. This is also the default value for this field. Therefore, unless you have extended OiL with new components that implement other GIOP protocols, then your may not have to define a value for this field.

tag number [optional] Tag of the IOP protocol the ORB shall use. The default is 0 that indicates the Internet IOP (IIOP).

IIOP Options

When the IIOP protocol is selected, some additional options are available. They are used to set the host name or IP address and port that ORB must bind to, as well as the host name or IP address and port that must be used in creation of object references. These options may be shared by other GIOP implementations as well.

host string [optional] Host name or IP address. If none is provided the ORB binds to all current net interfaces.
port number [optional] Host port the ORB must listen. If none is provided, the ORB tries to bind to a port in the range [2809; 9999].
refhost string [optional] Host name or IP address informed in object references.
refport number [optional] Host port informed in object references.

Copyright (C) 2004-2008 Tecgraf, PUC-Rio

This project is currently being maintained by Tecgraf at PUC-Rio.