JADE OsMoSes Wiki

OSGi based Mobility Services for the JADE mobile agent framework

Status: Pre-Alpha

Brought to you by: msanmartin

components

Authors:

Attachments

OsMoSes_Components_Architecture.png (29565 bytes)

Table of Contents
About this page
About Components
Components
Architecture Diagram

About this page

In this page you will find the description of the main components of OsMoSes.

About Components

Each of the described components has is distributed in its own JAR file, some of which are OSGi bundles.

All of these are necessary in order to run JADE using OsMoSes.

Components

JADE OSGi Based Mobility Service

This can be considered the heart of OsMoSes, this service is the one that makes the integration between JADE and OSGi and handles all other components.

The logic of this service is essentially the same as the intra-platform mobility service offered by default in JADE, the main difference comes in the handling of classes definitions.
JADE uses one classloader associated to a pair [agent name, source container id] to be able to avoid conflicts between classes of different agents. While this approach allows to prevent conflicts among classes from different agents, it also fails to take advantage of already transmitted definitions and, also, prevents an agent to change the definition of a class already transmitted.
To solve the aforementioned limitations, OsMoSes uses the power of OSGi to handle classes versions. Instead of explicitly maintaining multiple classloaders, OsMoSes includes with the agent transmission the pair [bundle symbolic name, bundle version] to indicate the bundle that defines the agent being migrated. Then, using other components of OsMoSes, the mobility service makes sure that the agent's bundle can be resolved and completes the migration. This way, OSGi is in charge of making sure the agent is using the correct class (version) and OsMoSes doesn't care if the bundle was previously transmitted as part of other's agent migration process or the same one, bundles already transmitted don't need to be transmitted again.

This service is like any other service of JADE. To use it instead of JADE's default mobility service, you only need to tell JADE so.

Configuration Properties

Refer to the JADE OSGi Based Mobility Service Configuration Properties page for the list of available configuration properties.

Transport Connection Definitions

OsMoSes needs to transmit some information in order to be able to determine which bundles are necessary to resolve the one defining the agent to migrate and, once identified which ones are needed, to send those bundles to the destination container. To allow the use of an efficient channel for that purpose, it was a design decision to distinguish the channel used for that information exchange from the one used for JADE's administration (IMTP).

The transport connection definitions component defines a common interface that all OsMoSes communication channels must implement. By depending only on that interface, the JADE OSGi Based Mobility Service component is able to use the channel without needing to care about how the data transmission is being carried on.

TCP Transport Connection Implementation

A TCP based simple implementation of the interface defined by the Transport Connection Definitions is provided in the same bundle.

This implementation transmits the data provided by upper layers (other components of OsMoSes) directly (without adding any extra information) over a TCP connection.

Configuration Properties

Refer to the TCP Transport Connection Implementation Configuration Properties page for the list of available configuration properties.

JADE IMTP Transport Service

An implementation of the interface defined by the Transport Connection Definitions that transmits data using the platform IMTP.

IMTP (Internal Message Transport Protocol) is the way different (JADE) containers in a platform communicates to each other. Each service in JADE transmits its related information to others by means of IMTP.
You may want to transmit OsMoSes related information mainly for two reasons:

You don't need any additional permissions than the ones required by JADE itself to work. Using, for example, the TCP based implementation you will need to be able to use the ports in which that implementation receives connections.
You don't need any extra configuration. Once you have IMTP up and running (necessary for a JADE platform to work correctly), OsMoSes can transmit its data. Contrast this against the fact that, for example, the TCP based implementation may require that you specify the ports for each container in the platform.

The caveat is that this channel has a little overhead in transmission, since it adds to the OsMoSes data some extra information needed for IMTP to work.

This communication channel is implemented as a separated JADE service for two reasons:

In order to be able to make the mobility service usage transparent for the (JADE) platform, it wasn't possible to modify its interface. Thus, no extra commands to send OsMoSes related information could be added to the service. So, the solution was to add another service in which all the necessary commands could be included.
The functionality implemented by this service (send information over IMTP like if it was a TCP connection) may be used by any third party not interested in OsMoSes, so, by making it an independent service, anyone can use it whether they want to use also OsMoSes mobility service or not.

Logger

A simple logging interface and service implemented to avoid adding a whole logging framework as a dependency in OsMoSes.

As OsMoSes mature this component probably is going to change a lot or disappear.