Java Reference
In-Depth Information
Given these properties, and the fact that mobile agents are designed for the Internet age, it is
clear that they deal with the software deployment issue. Particularly, we are interested in the
word
mobile
, which is the capability that this kind of technology has to transfer itself and oper-
ate on platforms different from the original one.
Given these definitions, it is clear that Java is the perfect implementer's choice. Java is plat-
form-independent, so what could be better suited in moving from one host to another? Next, it
can make use of many handy features, such as dynamic class loading, reflection, and so on.
But what is more important is its intrinsic security, so that remote hosts can receive mobile
agents without fear of malicious behavior.
We will examine the Aglet case, developed by IBM and available from their Web site. As the
terms indicate, Aglets are thought of as a mix between the applet concept and that of a mobile
agent, as described before. We can think of
Aglets
as
mobile applets
that have a well-defined
lifecycle that involves their own deployment to Aglet-enabled hosts spread over the network.
Aglets can move themselves from one host to another one, or they can be taken from some-
body outside them. Aglets interact through the use of messages, both synchronously and asyn-
chronously. The Aglet model uses the
context
concept. Contexts remain permanently on the
host where they were created; aglets travel from one context to another.
3
The Aglet lifecycle comprises events for each stage that allow developers to plug into their
own event-listener classes and to take advantage of the Java class framework implementing the
Aglet concept, together with the other classes that loosely resemble the Applet-related classes.
Let's have a closer look at what we are interested in: the Aglet deployment process.
Aglets are transferred from one context to another by means of an Aglet Transfer Protocol
(ATP) that conceptually performs the following operations:
1.
The Aglet is serialized.
2.
The serialized Aglet and its bytecode classes are physically transferred to the destination
context.
3.
The two byte streams are reconstructed at the destination host site.
4.
The Aglet is brought to life again, by launching its bytecode classes and restoring its pre-
vious state.
All this is obtained with a single method, belonging to the
Aglet
class:
myAglet.dispatch(new URL(“atp://marinilli.com/main_context”));
Note that here the proposed deployment process has an important property: It preserves the
state
of the
object
being deployed. That is important. We basically deployed classes, in Chapter
