How to use Orbacus ORB in JADE

Author: Giovanni Rimassa (University of Parma), Tiziana Trucco (CSELT S.p.A.)

Date: December 18, 2000

Java platform: Sun JDK 1.2 Windows

JADE version 2.1



Since JADE 2.1, FIPA-compliant Message Transport Protocols can be plugged and activated at run-time on any JADE container. By default, the ORB implementation of Sun is launched on the Main Container of the platform. However, in alternative, the ORBacus implementation is also available. This tutorial describes how to install and use this ORBacus implementation in JADE. The ORBacus based IIOP MTP supports three kinds of addresses, corresponding to three different ways to describe a CORBA Object Reference in String form.

  1. IOR: addresses
    These addresses have the form:
    IOR:Hex digits
    where the hexadecimal digits are simply a string representation of the memory dump of a CORBA data structure, containing all the information needed to find and contact a CORBA object. This address kind is the most widely supported, and it's the most complete one (it can contain multiple transport profiles, character set informations, and so on). Its only disadvantage is not being human readable: in particular, in a TCP/IP environment, special utilities need to be used to extract the host name and port number from an IOR (which could be useful for network configuration purposes).

  2. corbaloc: addresses
    These addresses have the form:
    corbaloc:proto:hostname:port/objectID
    and try to represent a CORBA Object Reference just like an HTTP URL. They can be easily read, but they lose a lot of information with respect to IOR form, and they make only sense in a TCP/IP environment. The proto part denotes the transport protocol to be used, and it's optional, defaulting to 'iiop'; the hostname and port parts define the IP host and the TCP port where a suitable IIOP message must be sent in order to contact the CORBA object. The objectID part identifies a specific CORBA object (usually, selecting the host and the port will at most select an object adapter). Supporting this kind of addresses breaks the server-side source code portability that wasthe ultimate goal of the POA specification, because there is no concept of 'port' in the POA, to keep transport protocol independence: so, this ORBacus based MTP uses ORBacus-specific extensions to select the TCP port when requested, and creates a different POA for each TCP port.

  3. corbaname: addresses
    These addresses have the form:
    corbaname::NShostname:NSport/NSName#objBinding
    and use the CORBA COS Naming Service as an indirection level, to reach a CORBA object that was previously bound into a COSNaming Server. The NShostname and NSport parts define the IP host and TCP port where an implementation of the COSNaming::NamingContext IDL interface is listening. The NSName identifies the specific implementation (it defaults to "NameService"). The objBinding part, then, describes the binding in the NamingContext object, from where the actual CORBA object implementing the FIPA::MTS interface can be retrieved. Following the CORBA Interoperable Naming Service specification, the objBinding string can contain '.' and '/', to specify the 'id' and 'kind' fields of a COSNaming::NameComponent, and to describe paths of COSNaming::NameComponent objects. When activating a corbaname: address, this MTP implementation creates a new FIPA::MTS object and binds it into the given Naming Server. Likewise, when deactivating the corbaname: address, the binding is removed from the Naming Server.

When a JADE container is started, it is possible to activate one ore more communication endpoints on it.
In order to use ORBACUS ORB the following steps must be performed:

At this point in time, an IIOP endpoint that uses an ORBacus-based IIOP MTP can be activated. There are two ways available to activate it: For corbaloc: and corbaname: addresses, the IIOP address where the platform must listen to incoming FIPA messages or the COSNaming Service can be found can be specified. This has the big advantage that the address of the platform can be selected by the user and, eventually, might be published on your business card. In other words, there is no more any need to publish the IOR of the agent platform. When activating a corbaname: address, take care that a COSNaming Service implementation is actually running at the NSHostname:NSport address, with the NSname Object ID, or the MTP activation will fail.

When a container starts, it prints on the standard output all the activated MTP addresses, separated by a carriage return. Moreover, it writes the same addresses in a file, named: MTPs-Container Name.txt.

Using the -mtp command line option, a transport endpoint lives as long as its container is up; when a container is shut down, all its MTPs are deactivated and the AMS information is updated accordingly. The JADE RMA console enables a more flexible management of the MTPs, allowing to activate and deactivate transport protocols during normal platform operations.

Configuring MTPs from the graphical management console.

Select a container from the GUI, click the right button of the mouse and a popup menu appears. Choose the Install a new MTP option and a dialog will be shown. Here the following information can be set: the container to install the new MTP on (if different from the selected one), the fully qualified name of the class implementing the jade.mtp.MTP interface, and (if it is supported by the chosen protocol) the transport address that will be used to contact the new MTP.

For example,

Choosing Uninstall an MTP shows a dialog where the user can select from a list one of the currently installed MTPs and remove it from the platform.


JADE is a trademark of CSELT. JADE has been developed jointly by CSELT and the Computer Engineering Group of the University of Parma