Mobile Agents on the Internet - Aglets SDK (II) (EN)

This is the second article in a 3-part series. See the 1st and 3rd parts.

In the previous article, we talked about Autonomous Mobile Agents. We saw that, after all, they are not so terrible and that, moreover, they can be very useful in the emerging field of massively distributed computing. In this article, we will present the approach to the world of AMAs that IBM Japan has made on the Java platform: Aglets.

Now that we are familiar with the concept of an Autonomous Mobile Agent (AMA) and have sufficient knowledge of how they work and what they are developed for, we probably want to continue our journey by doing some tests with mobile agents. We may even have a really interesting application in mind that could be developed using this new technology. In either case, we will most likely decide to use one of the AMA development and execution platforms available on the Internet.

A good point of reference to know the State of the Art in agents in general is the main page of the Agent Society¹. In particular, we find there information about the available platforms for the development of AMAs. The most important ones that we can download and use freely (under the license conditions, as always) are described in the box DEVELOPMENT AND EXECUTION PLATFORMS FOR AMAs. Among them, the Aglets SDK will be the platform chosen to introduce the reader to the exciting universe of mobile agents.

DEVELOPMENT AND EXECUTION PLATFORMS FOR AMAs

The Agent Society informs us of the availability of the following platforms for the development of mobile agents:

• Aglets: Developed by IBM Tokyo Lab², it presents its product as “Mobile Java objects that can run on a host, stop their execution suddenly, be dispatched to a remote host, and resume their execution there”.

• Concordia: Developed at Mitsubishi Electric’s Horizon Systems Labs³. Described as a “Complete environment for the development and management of applications for efficient use of the network, based on mobile agents that access information at any time, place, and device that supports Java”.

• Odyssey: Developed by General Magic⁴, and described as an “Agent system implemented as a set of Java class libraries that provide the necessary support to develop mobile distributed applications”.

• Voyager: Developed by ObjectSpace⁵, and described as “The first Object Request Broker (ORB) enhanced for the use of 100% Java agents. It combines the power of autonomous mobile agents and remote method invocation (RMI) with full CORBA support”.

Aglets SDK

Aglets is a project, still in constant development, an initiative of the IBM Tokyo Lab (IBM’s R&D center in Japan) [2]. Its objective: to create an environment for the development, control, and execution of AMAs on the Java platform (the AMAs are known within the project as Aglets, according to a logical play on words with the already familiar Applets). In essence, the Aglets SDK (that is, what you can download from the main page) is the set of tools necessary to develop your own Aglets and HOST applications for Aglets, providing a whole set of Java APIs that obviate the complex aspects of security, transport, and communications between agents. Of course, it also includes a fully functional HOST application (called Tahiti) so that we can easily get started in the world of autonomous mobile agents.

The idea of Aglets was the brainchild of Danny Lange (curiously, he is now a member of General Magic, the company that promotes Odyssey); when he, the inventor of Aglets, was asked about his creation, he said: “When I invented aglets, I was looking for a higher level of abstraction for distributed computing. For me, aglets were an answer to some questions I had been asking myself since I was 15: what comes after object-oriented programming?, what is the next paradigm?”. Of course, what Lange was thinking when he created his aglets was not something new; what was truly new was that he planned to build his work on Java, capable of obviating (to a certain level) the classic problems of mobile agents: platform independence and security aspects.

We can get the most up-to-date Aglet SDK (ASDK) directly from the Aglets main page [2]. At the time of writing this article, the Aglets team has not released a stable version 1.1, so all the information we will handle will be from version 1.0.3 of the ASDK. It will be more than enough for our purposes.

We now start both host applications for Aglets (Figure A). Each one will run in its own execution process and will have its own subprocesses. The first will have a daemon Thread constantly listening to port 434, waiting for the arrival of some Aglet. The second will listen to TCP/IP port 500.

c:\Aglets1.0.3\bin\agletsd.bat and as a parameter of this
–port 434 to the first and –port 500 to the second.

In either of the two Tahiti hosts, for example, the one listening to port 434, we will press the Create button. We will be given the option to create one of the example Aglets.

We will choose examples.hello.HelloAglet as the first Aglet. The Tahiti window will show information about the newly created agent and, after a few seconds, its dialog window will appear. In it, the agent will ask us to write a greeting and an address. This address will be of the form atp://our_address:500 (which in my case could be atp://mike:500), where we have told it to use the Aglets transport protocol (atp), and to connect to our computer on port 500, where we have the other host application waiting. In a few moments, the Aglet disappears from the first window and reappears in the second, showing the greeting we previously gave it. After a few seconds, the Aglet finishes its task and returns to its home host.

Listing 1 – Definition of the HelloAglet agent

public class HelloAglet extends Aglet {
  transient Frame my_dialog = new MyDialog(this);
  String message = "Hello World!";
  String home = null;
  SimpleItinerary itinerary = null;

  /*Only called the very first time this aglet is created.*/
  public void onCreation(Object init) {
    itinerary = new SimpleItinerary(this);
    my_dialog.pack();
    my_dialog.resize(my_dialog.preferredSize());
    my_dialog.show();
    // Initialize the variables.
    home = getAgletContext().getHostingURL().toString();
  }

  /* Handles the message */
  public boolean handleMessage(Message msg) {
    if (msg.sameKind("atHome")) {
      atHome(msg);
    } else if (msg.sameKind("startTrip")) {
      startTrip(msg);
    } else if (msg.sameKind("sayHello")) {
      sayHello(msg);
    } else if (msg.sameKind("dialog")) {
      dialog(msg);
    } else {
      return false;
    }
  }

  /*Reports arrival home and disappears */
  public void atHome(Message msg) {
    setText("I'm back.");
    waitMessage(2 * 1000);
    dispose();
  }

  /*Starts the trip of this aglet to the destination.*/
  public synchronized void startTrip(Message msg) {
    String destination = (String)msg.getArg();

    try {
      itinerary.go(destination, "sayHello");
    } catch (Exception ex) {
      ex.printStackTrace();
    }
  }

  /* Say hello! */
  public void sayHello(Message msg) {
    setText(message);
    waitMessage(5 * 1000);
    // back home
    try {
      setText("I'll go back to.. " + home);
      waitMessage(1000);
      itinerary.go(home, "atHome");
    } catch (Exception ex) {
      ex.printStackTrace();
    }
  }

  /* Creates and shows the dialog window. */
  public void dialog(Message msg) {
    // check and create a dialog box
    if (my_dialog == null) {
      my_dialog = new MyDialog(this);
      my_dialog.pack();
      my_dialog.resize(my_dialog.preferredSize());
    }

    // show the dialog box
    my_dialog.show();
  }

}

Listing 1 shows the definition of the HelloAglet class, the class that defines the aglet we have just brought to life. As we will see later, following the typical Java event model, the HelloAglet agent begins its “life” when the runtime environment creates the Java object and calls its onCreation() method. At that moment (follow Listing 1), its first action is to create a SimpleItinerary object (a predefined itinerary object in the Aglets API) that will facilitate the task of traveling; its second, to show the dialog window that we already saw on the screen.

After entering the address, the greeting, and pressing the GO! button, the dialog window will pass the “startTrip” message to our HelloAglet agent. As an argument (or body), the message includes the address of the host to which it should take the greeting. The handleMessage() method of the newly created agent will receive this message, responding to “startTrip” with the call to the method of the same name and thus starting the trip to the destination specified by us. Thanks to the properties of the SimpleItinerary object, it will receive a message upon its arrival of the “sayHello” type.

Once the HelloAglet agent reaches the new host, in response to the “sayHello” message, it displays the message we originally gave it. After a few seconds, it will return to the home host, where it will receive a message upon its arrival of the “atHome” type; once at home, it will say goodbye and self-destruct in response to this message.

As we can see, the “logic” of programming an agent is surprisingly similar to the everyday development of tasks.

Aglets API Architecture

We will now see (although we already had a preview with Listing 1) how all the theory we have seen is embodied in fully functional and familiar Java classes and interfaces.

In Figure B, we can see the graphical representation of a first approximation to the architecture of the Aglets API.

As Aglet developers, this representation shows us very well the main elements with which we must become familiar.

First, we have the AgletContext, which, at this moment, will represent for us the Host application we have talked so much about.

On the AgletContext, we have the Aglets: mobile Java objects that inhabit it (and that we will create by extending the com.ibm.aglet.Aglet class). For the Aglet, only the AgletContext exists; it is its point of reference and its source of resources. When it wants to communicate, the Aglet asks the AgletContext for other Aglets that inhabit it. The AgletContext will inform it accordingly by returning a list of the Aglets found; a list of Java objects, of course. But, wait a minute! That’s dangerous! And not without reason, because if we are given direct access to the Aglet as a Java object, we could use introspection and runtime method activation: the agent would be naked before the first malicious aglet that appeared in the context. To avoid security problems, the ASDK architecture introduces AgletProxys, which are nothing more than wrapper objects for Aglets that perform a “mapping” of method calls: an Aglet invokes a method of the public interface of the AgletProxy and this, in turn, invokes the corresponding method of the Aglet it represents. In this way, the AgletContext only provides lists of AgletProxys; the Aglets work with representations or general interfaces of other Aglets and never with the latter, thus avoiding innumerable security problems.

Once an AgletProxy is obtained, the Aglet is able to communicate with it, as the representative provides methods for passing messages.

Conclusions

With this general description of the ASDK architecture, we should have a more elaborate idea of how AMAs work, and how IBM Tokyo Lab has implemented them in Java. If this has been achieved, let’s be satisfied.

In the next article, we will delve deeper into the Aglets API, and we will learn to program our own AMAs. Best regards.