Author: Giovanni Rimassa (University of Parma), Tiziana Trucco (CSELT S.p.A.)
Date:
Java platform: Sun JDK 1.2 Windows
JADE version 2.1
IOR: addresses
corbaloc: addresses
corbaname: addresses
When a JADE container is started, it is possible to activate one ore more communication endpoints on it.
The following line activates a
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
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
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.
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).
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.
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.
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:
corbaname:
addresses, you also have to include in your CLASSPATH the file OBNaming.jar
(ORBacus COS Naming Service, available from www.ooc.com
For corbaloc:
address:
-mtp orbacus.MessageTransportProtocol(corbaloc:iiop:hostname:port/name)
corbaloc:
address: -mtp orbacus.MessageTransportProtocol(corbaname::NShostname:NSport/NSname#objBinding)
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.
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.
jade.mtp.iiop.MessageTransportProtocol
as the class name and nothing as the address.
orbacus.MessageTransportProtocol
as the class name and
(if the endpoint had to be deployed at host sharon.cselt.it on the TCP port 1234 with an object ID jade)
corbaloc:iiop:sharon.cselt.it:1234/jade
as the transport address.