Agent Development

Developing a Concordia Agent is a fairly straightforward process. In many ways, it is no different than developing a non-mobile program. However, it is possible to partition the work that an agent accomplishes into smaller tasks, and then perform each task on the machine on the network where it can be most efficiently accomplished.

Consider the example of using an agent to query a remote database. In traditional client-server database programming, a client-side API would be used to remotely access the database. Potentially, every call into the client side API could result in network traffic since it might require some sort of communication with the database server.

In using an agent to access the database, we have an advantage over the client-server solution: the agent can actually travel to the machine where the database server resides and access the database locally. The agent can travel to the database server, query the database, and intelligently perform calculations and optimize the results. All of this work takes place on the database server and avoids the network overhead associated with the database client API. The agent can then travel back to the user and report the results.

It is important to note that the agent approach mentioned above will only be more efficient than the client-server approach if the network overhead needed to transport the agent from the user's machine to the database server is less than the overhead required to access the database remotely via its client side API. To transport an agent, Concordia's AgentManager must transport both the agent's data and its code. A few rules should be followed to gain the most advantage from the agent approach:

1. Agents should be small, specialized pieces of code. Programmers should remember that an agent's bytecodes may have to be transported with the agent. For maximum efficiency, programmers should design their agents to be specialized components of a larger distributed application. For example, if the programmer's purpose is to gather information from some corporate data source and then display the data to the user in some Java-based graphical user interface, it is not desirable to include the code that creates and manages the user interface in the agent. A better approach would be to use the agent to retrieve and compile the information and then have the agent hand the information off to another class which is responsible for displaying it to the user. This accomplishes the same end result, but does not require that the GUI code be unnecessarily sent with the agent to the database server.
2. Agents should be designed to intelligently manipulate data when they are located at the data's source. For example, there is no real advantage to using an agent to retrieve a muti-megabyte file from a server. In either the client-server case or the agent case, the entire contents of the file must be transmitted across the network. However, if the goal was to search a multi-megabyte file for a few records of interest, and then retrieve those records, it would be more efficient to send the agent to the server, have the agent search the file locally on the server, and then have the agent bring back a few interesting records, than to either download the entire file from the server to the client and then perform the search or to perform the search via a network file system.

Next, we will adapt a non-mobile database access program and turn it into a Concordia Agent.