Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

The architecture of aglets

Find out about the inner workings of aglets, IBM Japan's Java-based autonomous software agent technology

  • Print
  • Feedback

Page 4 of 6

The aglet also has a run() method, which represents the entry point for the aglet's main thread. This is similar to the main() method of a Java application, except that run() is invoked each time an aglet arrives at a new aglet host. For example, if you designed a CatAglet that visits nine different aglet hosts looking for MouseAglets, onCreation() would be invoked only once, when the CatAglet was first instantiated at its first host. Once onCreation() completed, run() would be invoked. Each time the CatAglet arrived at a new host, a method called onArrival() would be invoked to perform any initialization. Once onArrival() completed, run() would be invoked to get the aglet started again at the new host.

Starting run() again each time an aglet is brought to life illustrates the inability of aglets to transmit the state of their execution stacks. For example, imagine a HealthyAglet whose run() method periodically invokes a method named walk(). If, as it is walking, the HealthyAglet is serialized and transmitted to another host, it wouldn't by default continue executing where it left off in walk(). It would start over again at the beginning of run(). Thus, when the aglet is informed that it is about to be serialized, it would need to record on the heap that it is walking -- perhaps in an instance variable of HealthyAglet. That instance variable would be serialized and would migrate with the aglet. When run() is invoked to start the aglet's new life, the run() method would check the instance variable, see it was walking beforehand, and call walk().

The callback model

Before any major event in an aglet's life, a "callback" method is invoked to allow the aglet to prepare for (or refuse to partake in) the event. This is how an aglet learns that it is about to be serialized. For example, before an aglet is dispatched to a new location, the aglet's onDispatch() is invoked. This method indicates to an aglet that it is about to be sent to a new host, the URL of which is specified as a parameter to onDispatch(). In the body of onDispatch(), the aglet must decide whether or not to go. If the aglet decides it doesn't want to go, it throws an exception. If it decides to go, it must complete any unfinished business and prepare its state for serialization. When it returns from onDispatch(), its state will be serialized and all its threads terminated. The class files and serialized state will then be sent to the new host, where the aglet will be resurrected.

The method onDispatch() is a "callback" method because the aglet host invokes it some time after another method, dispatch(), is invoked. An aglet can invoke dispatch() on itself or on another aglet. This callback model for aglets is similar to that of windowing user interfaces. To repaint an AWT component, for example, you invoke the component's repaint() method. At some point later, the system calls back the component's update() method, which in turn calls paint().

The Aglet class defines these five callback methods, which you can override to customize the behavior of your aglet:

  • Print
  • Feedback

Resources
  • Previous Under The Hood articles:
  • The lean, mean virtual machine -- Gives an introduction to the Java virtual machine. Look here to see how the garbage collected heap fits in with the other parts of the Java virtual machine.
  • The Java class file lifestyle -- Gives an overview to the Java class file, the file format into which all Java programs are compiled.
  • Java's garbage-collected heap -- Gives an overview of garbage collection in general and the garbage-collected heap of the Java virtual machine in particular.
  • Bytecode basics -- Introduces the bytecodes of the Java virtual machine, and discusses primitive types, conversion operations, and stack operations in particular.
  • Floating Point Arithmetic -- Describes the Java virtual machine's floating-point support and the bytecodes that perform floating point operations.
  • Logic and Arithmetic -- Describes the Java virtual machine's support for logical and integer arithmetic, and the related bytecodes.
  • Objects and Arrays -- Describes how the Java virtual machine deals with objects and arrays, and discusses the relevant bytecodes.
  • Exceptions -- Describes how the Java virtual machine deals with exceptions, and discusses the relevant bytecodes.
  • Try-Finally -- Describes how the Java virtual machine implements try-finally clauses, and discusses the relevant bytecodes.
  • Control Flow -- Describes how the Java virtual machine implements control flow and discusses the relevant bytecodes.