Featured White Papers

• Java Web Hosting | DailyRazor.com - Over 10yrs Of Java Web Hosting Exp!

Sponsored Links

• Java out of memory error? Use heaps up to 512GB without GC pauses. Click here for pauseless GC white paper.

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

Agents on the move

Bolster your client apps by adding agent mobility

By Todd Sundsted, JavaWorld.com, 07/01/98

Recall that agents typically possess one or more of the following characteristics; they can be:

• Autonomous
• Adaptive/learning
• Mobile
• Persistent
• Goal oriented
• Communicative/collaborative
• Flexible
• Active/proactive

We've got a lot of ground to cover, so we'd best get started. We're going to start our agent adventure with an up-close look at agent mobility. Agent mobility provides a good starting point because the problems associated with mobile (and potentially untrustworthy) code are well-known, and robust solutions are readily available. In addition, Java (via remote method invocation -- or RMI -- and object serialization) provides prefabricated tools that make the job of moving objects easier.

Location, location, location

To better understand mobile agents and their behavior, we must first look briefly at traditional network architectures. The following figure illustrates the network behavior of a typical client/server application.

A client/server application typically consists of two pieces: a client piece and a server piece. Often, the client and server pieces are on separate machines and they communicate over a common network. When the client needs data or access to resources that the server provides, the client sends a request to the server over the network. The server in turn sends a response to the request. This "handshake" occurs again and again in a traditional client/server architecture. Each request/response requires a complete round trip across the network.

Now compare the client/server architecture I just described to the mobile agent architecture illustrated in the next figure.

Just as in the client/server architecture, there is a client piece and a server piece. The difference lies in how the two communicate. When the client in the mobile agent architecture needs data or access to a resource that the server provides, the client doesn't talk to the server over the network. Instead, the client actually migrates to the server's machine. Once on the server's machine, the client makes its requests of the server directly. When the entire transaction is complete, the mobile agent returns home with the results.

A mobile agent's travel habits

One distinguishing characteristic of a mobile agent architecture is (surprise, surprise) the mobility of the code. However, while this characteristic is necessary, it alone is not sufficient. That's because the idea of moving code and computation to the location of the data and resources is not unique to the mobile agent architecture. In fact, such mobility has been a feature of many commercial databases for some time. In the database world, mobile code goes by the name of a stored procedure. A stored procedure is a piece of client code that executes on the server. In some applications, the client piece of the application can dynamically upload stored procedures to the server. Once there, they can do their work and return the results of their calculations back to the client.