|
|
| ||
|
||
Did you say aglet? Will up-and-coming mobile agents, such as IBM's aglets, become slaves on your intranet?
By Mark Gibbs
The idea of mechanical slaves that do our bidding and free us for more
productive endeavors is one of the enduring dreams of science fiction.
While mechanical robots are far from doing anything terribly well, software robots that operate in network systems are proving useful. For example, your e-mail program might use a robot, or static agent, to retrieve and process messages on a schedule.
Alternatively, mobile agents can transfer themselves from one location,
such as a server, to another location, either on user command or when the
agent determines the need to do so. For example, an agent might determine
it is more efficient to conduct a database search on the machine holding
the database rather than across a network. By dispatching itself to the
database server, running the search and returning with the results, it can
operate in a faster and more resource-efficient manner.
Developers have theorized about mobile agents for some time and are now
demonstrating prototypes.
Using mobile agents
Mobile agents could be beneficial when you want to render an animation of
a new product, calculate a complex spreadsheet or run a sort operation on a
massive database. You would simply instruct a mobile agent to take the
re-quired code to an authorized agent server with the required compute
capability.
Mobile agents also could improve the method of collecting information from
databases or other information sources. Even though the information
extraction task might be simple, the overhead of performing the work across
an intranet might be much greater than if agents dispatched to each
database did the same job.
IBM's 1-year-old tool set, Aglets Workbench, is one framework for mobile agents. This still is unstable alpha software, but it can be used to demonstrate principles.
IBM calls its mobile agents "aglets," a play on the words "agent" and
"applet." IBM writes in Java because it provides a security framework to
protect systems running aglet servers from potentially hostile aglets.
IBM's Java Aglet API (J-AAPI) provides all of the functions of aglets and
the services they use. The J-AAPI is embodied in a set of Java classes that
are compiled into the aglet and provide all of the support services for
moving from server to server and for communications between aglets, servers
and users. Aglets Workbench includes the aglet components and a stand-alone
aglet server.
Central to the aglet architecture is the context, or the server environment in which the aglets execute. A single server might host multiple contexts, each with different security constraints.
Each aglet is named by an identifier that lasts throughout its lifetime.
Aglets collaborate and exchange information by sending and receiving
messages.
An aglet go-between
A proxy handles message transfer between aglets or between an aglet and a
user. Proxies hide the location of an aglet to prevent direct access to its
code and access by other aglets.
Aglets are run by a new aglet object being executed in a context or by
being cloned from an existing aglet. An aglet can instigate cloning so it
can dispatch duplicates of itself to other locations to carry out work.
When an aglet is dispatched to an-other server, its code and data is moved
to the new context and deleted from the old context. When moved, aglets can
do whatever the new context allows.
Aglets are sent from one context to another by IBM's Agent Transfer
Protocol. This is a platform-neutral, application-level protocol that uses
URLs to locate agents and servers.
When an aglet has finished its work in a context, it might push itself to
another context or to the context from which it originated. Aglets also can
be pulled back to a context. This means you can dispatch an aglet and leave
it collecting data until you want it to return results.
Aglets also can deactivate themselves or be deactived by a server and
moved from a context to storage. Activation will restore the aglet in the
context from which it was deactivated.
Disposal of an aglet halts its execution and removes it from its context.
If this sounds complex, it should. Creating a functionally rich and secure
system for mobile agents requires an extensive architecture. But IBM's
Aglets Workbench shows that such a system can be built.
Make no mistake, mobile agents such as aglets are not something that will
appear on your intranet tomorrow. But they may appear sooner than you think.
How to Advertise | Copyright
Home |
NetFlash |
This Week |
Industry/Stocks
|