Archives
What's New
Site Map
Subscriptions

Home
NetFlash
This Week
Forums
Reviews/buyer's guides
Net Resources
Industry/Stocks
Careers
Seminars and Events
Product Demos/Evals
Audio Primers

IntraNet Toolkit


Error 404--Not Found

Error 404--Not Found

From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.

















For more info:

Programming Mobile Agents in Java
IBM's Aglet page, includes a downloadable copy of the Aglet Workbench alpha.

Agents: Not just for Bond anymore
Learn what agents are and how to create them using IBM's Aglet Workbench. JavaWorld, 4/97.


Did you say aglet?

Will up-and-coming mobile agents, such as IBM's aglets, become slaves on your intranet?

By Mark Gibbs
Network World, 10/16/97

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.


Feedback | Network World, Inc. | Sponsor index
How to Advertise | Copyright

Home | NetFlash | This Week | Industry/Stocks
Buyer's Guides/Tests | Net Resources | Forums | Careers
Seminars & Events | Product Demos/Info
Audio Primers | IntraNet