|
|
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
Page 3 of 6
Before it is serialized, an aglet must place on the heap everything it will need to know to be resurrected properly as a newly activated aglet, a freshly dispatched aglet, or a clone. It can't leave any of this information on the stack, because the stacks won't be reproduced in the aglet's new life. As a result, the aglet host informs an aglet that it is about to be serialized so that the aglet can prepare itself. When the aglet is informed of an impending serialization, it must place onto the heap any information it will need to continue its execution properly when it is resurrected.
From a practical standpoint, the inability of an aglet to migrate with its execution stacks is not an unreasonable limitation. It simply forces you to think a certain way when you write aglets. You can look at an aglet as a finite state machine with the heap as the sole repository of the machine's state. If at any point in an aglet's life you can know what state it is in by looking at its heap, then it can be serialized at any time. If not, then you must have a way to record sufficient information on the heap just prior to serialization such that you can continue properly when the aglet is resurrected.
Also, even though the inability to serialize execution stacks necessitates giving aglets a warning prior to serialization, such warnings probably are a good idea anyway. It is difficult to think of a case in which an aglet wouldn't want to know it was about to be serialized and why. It may need to finish some incomplete process before allowing the serialization, or it may want to refuse the action that requires the serialization. For example, if an agent is told it is about to be serialized and dispatched to an aglet host in Silicon Valley, it may refuse and decide instead to dispatch itself to a host on an island in the South Pacific.
The process of writing an aglet is in many ways similar to the process of writing an applet. To create an applet, you subclass
class Applet. To initialize an applet, you override the init() method, the starting point for any applet. You can use init() to build the user interface of the applet. If you wish, you can fire off other threads from init(). If you do this, you also may override stop() and start() to stop and restart your threads when the browser leaves and returns to the Web page. If you don't create any threads in
init(), your applet likely will get at least one thread just because class Applet descends from class Panel. The AWT user-interface library of which Panel is a part will provide whatever threads are needed to run the user interface you create in init().
The aglet development and run-time environments provide a library of Java classes that support the creation and running of
aglets. To create an aglet, you must subclass class Aglet, which includes several methods you can override to customize the behavior of your aglet. The aglet's counterpart to the
init() method of applets is the onCreation() method. To initialize an aglet, you override onCreation(). The onCreation() method is invoked only once in an aglet's lifetime and should be used only for initialization.
Archived Discussions (Read only)