Chapter 2. Platform Adapters

Jadex is realized as pure reasoning engine. This means that Jadex agents can potentially run on any middleware platform that fulfills some basic services concerning agent management and messaging. Currently, adapters for Jadex have been realized for the agent platforms JADE , for a Standalone platform and an experimental (not released) adapter for Diet.

Note

There is currently no dedicated manual availabe explaining how to build a new middleware adapter. If you are interested in developing a new adapter consider looking into the jadex.adapter package, which contains a handful of interfaces that every adapter has to implement. If you have any problems feel free to contact us directly. The same applies if you already developed a new adapter. We would be glad to know about it and possibly getting the chance to announce/link it on the Jadex web site.

In the following it is explained how you can configure and start Jadex using the Standalone and the JADE adapter.

2.1. The Jadex Standalone Adapter

The Jadex Standalone adapter is a fast and efficient execution environment for Jadex agents with a small memory footprint. The Standalone adapter is already contained in the normal Jadex distribution and needs to be put into the classpath (jadex_standalone.jar).

2.1.1. Starting the Jadex Standalone Adapter

You can start the Standalone adapter via the following command line:

java jadex.adapter.standalone.Platform [-conf filename] [-transport classname:port] [-notransport] [-nogui] [-noamsagent] [-nodfagent] [-autoshutdown]

Alternatively you can also use the following command to start the platform directly from the jar:

java -jar jadex_standalone.jar [options]

-conf: The property -conf can be used to configure the Jadex system. Per default it will search the current directory for the file jadex.properties and if not found the classpath will be searched (in each adapter jar a configuration is contained).

-platformname: The unique platform name. If more than one Jadex platform should run on the same machine it is useful to start them with different platform names (and with transports at different ports).

-transport: The standard transport mechanism for remote communication. As value the Java class name of a class that implements jadex.adapter.standalone.ITransport should be supplied. Optionally the port for this transport can also be supplied. As an example one could start Jadex with the "nsmt" (TCP/IP) based transport layer at port 9876 via -transport jadex.adapter.standalone.transport.nsmt.NSMTransport:9876

-notransport: Starts the platform without a remote transport mechanism.

-nogui: Starts the platform without user interface and the corresponding Jadex Control Center agent.

-noamsagent: Starts the platform without creating an Agent Management Service (AMS) agent. Note, this does only prevent remote agent access to the AMS as the AMS service is always available.

-nodfagent: Starts the platform without creating a Directory Facilitator (DF) agent. Note, this does only prevent remote agent access to the DF as the DF service itself is always available.

-autoshutdown: Automatically shut down the platform when the last agent is killed.

2.2. The JADE Adapter

The JADE adapter is not contained in the standard Jadex distribution and needs to be downloaded separately from the Jadex sourceforge download page. It contains the adapter jar (jadex_jadeadapter.jar) that should be added to the classpath. In addition (compatibility tested) official JADE jars (Base64.jar, http.jar, iiop.jar, jade.jar, jadeTools.jar) and additionally Crimson (crimson.jar) are contained and should be also added to the classpath.

2.2.1. Starting the JADE Adapter

You can start Jadex with JADE simply by starting JADE with a modified Remote Management Agent (RMA) instead of using the -gui option which activates the default JADE RMA you should use:

java [-Dconf=<conf.properties>] jade.Boot [JADE options] [rma:jadex.adapter.jade.tools.rma.rma]

Alternatively you can also start the platform from jar via:

java -jar jadex_jadeadapter.jar [JADE options] [rma:jadex.adapter.jade.tools.rma.rma]

The system property -Dconf can be used to configure the Jadex system. Per default it will search the current directory for the jadex.properties and if not found the classpath will be searched (in each adapter jar a configuration is contained).

2.2.2.  Agent Migration and Persistence

Among the nice features of JADE is the ability to migrate agents between hosts, and to persist the state of an agent such that it can later be restored. These features are based on Java's serialization mechanism. Jadex has been designed in order to support serialization of agents at runtime. Nevertheless, there are some issues, the application developer has to be aware of:

  • Only mobile plans are supported for agents which need to be serialized for migration or persistence. Standard plans are backed by separate threads for each plan, and therefore cannot be serialized.

  • All objects that are used from plans or stored as facts in the beliefbase or as parameters (e.g., in goals) also have to be serializable.

  • Due to a bug in JADE, you cannot use basic Java types such as int or arrays (e.g. Object[] or String[]) as class of your beliefs or parameters. For details on the bug or to see if it has been fixed, have a look at its entry in the JADE bug database. A simple workaround is to use the wrapper types such as java.lang.Integer instead of the basic types, and Object instead of array types (or even better, use a belief set instead of an array).

    <!-- This does not work. -->
    <belief name="my_int_belief" class="int">
        <fact>42</fact>
    </belief>
    <belief name="my_stringarray_belief" class="String[]">
    	<fact>new String[]{"value1", "value2"}</fact>
    </belief>
    
    <!-- This works. -->
    <belief name="my_integer_belief" class="Integer">
        <fact>42</fact>
    </belief>
    <belief name="my_arrayobject_belief" class="Object">
    	<fact>new String[]{"value1", "value2"}</fact>
    </belief>
    <beliefset name="my_string_beliefset" class="String">
    	<fact>"value1"</fact>
    	<fact>"value2"</fact>
    </beliefset>
  • If you want to use SL-based communication or the DF or AMS capabilities (which use SL-based communication internally), you need to update to the latest development version of JADE, available from the JADE subversion repository. The reason for this is, that some bugs in the serialization, e.g., of the SLCodec and SearchConstraints classes have only been fixed after the last version of JADE (3.3) was released.

The Jadex distribution contains two larger examples which explicitly support migration: Cleanerworld and Puzzle. See packages jadex.examples.cleanerworld.multi.cleanermobile and jadex.examples.puzzle.mobile. For a simple example supporting migration see the ping example (package jadex.examples.ping.mobile).

2.2.3.  Using JADE Behaviours

If you have some legacy JADE code that you want to use in a Jadex agent, but you do not want to convert your JADE behaviours to Jadex plans, you can still use them in the old fashioned way. From a plan, you can get a reference to the jade.core.Agent which is executing the BDI reasoning engine. You may add your own additional JADE behaviours to this agent, which will then be executed concurrent to your BDI goals and plans. Note, that this programming style is meant for easy porting of legacy JADE applications. In general, you should avoid hybrid JADE/Jadex agents, because the these mixed-style agents may easily become incomprehensible. Moreover, hybrid agents will not be portable to other middleware platforms.

To add a behaviour to a Jadex agent just call the addBehaviour() method of the JADE agent, which is accessible using getScope().getPlatformAgent(), and casting the result to jade.core.Agent:

// Add a JADE behaviour to the agent from a plan.
jade.core.Agent agent = (jade.core.Agent)getScope().getPlatformAgent();
agent.addBehaviour(new MyJADEBehaviour());

Per default all incoming messages are handled by Jadex. To enable custom JADE behaviours to handle incoming messages, these have to be ignored by the Jadex system. You can specify a message template as an agent property in the ADF to identify those messages that should not be handled by Jadex:

<agent ...>
    ...
    <properties>
        <!-- Setup a filter for messages which are handled by JADE behaviours. -->
        <property name="jadefilter">
            MessageTemplate.MatchPerformative(ACLMessage.QUERY_REF)
        </property>
     </properties>
    ...
</agent>