6 Future Work

"Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and perhaps weigh 1½ tons" - Popular Mechanics, March 1949

6.1 Framework Implementation

The first step in developing a prototype is to build the framework for mobile agents to execute within. It is envisaged that this prototype framework will be implemented in two phases. The first phase will implement the core infrastructure of agents (mobility, communication, integration) and the second stage will deal with the aspects of distributed information management of both mobile and static agents.

6.1.1 Agent Framework Architecture

The framework described in chapter 5 was not designed around any one mobile agent implementation. This decision was made so that, theoretically, any of the mobile agent architectures described could be adopted and modified to support mobile agents for distributed information management.

For this reason, a choice needs to be made; whether to advocate the use of an existing mobile agent system (such as Agent TCL), or whether to develop a new mobility infrastructure from scratch. The arguments for reusing an existing system are persuasive, since the underlying migration and communication layers are already developed and available. However, the system that is chosen should exhibit the following characteristics:

State-oriented migration. The reduction of migration to a single instruction that packages the agent automatically, transfers the agent and restarts the agent on the instruction after the movement imperative.
Extensible architecture. To allow new features to be added, for example, extended security and other communication models. Additionally, the system chosen should allow new protocols and languages to be integrated seamlessly; unlike Telescript which only supports the Telescript language.
Flexible security model. To allow the security model to change according to the environment. Since this is primarily a research exercise, a heavy security model imposed from the outset, as employed by Telescript for example, would hinder the development of the framework.
Inherent heterogeneity. To allow the mobile agent framework to be accessible on as many platform types and across as many networks as possible, but some platforms may not possess the ability to support all features of the framework. Indeed, for platforms which cannot maintain a rigid security model, provision needs to be made within the framework to accommodate them, albeit at a very low security level.

The development of the framework from scratch also has a number of advantages: more control over the system and its implementation and the ability to tailor the framework closely to the problem being solved. However, it would a considerable task to develop a migration policy and determine a heterogeneous data format that would allow mobile agents to be migrated transparently.

Instead, it would make more sense to take advantage of existing technology in this area, namely Distributed Object Management (DOM). With such systems, an object (in this case an agent, its data and its knowledge-base) could be distributed automatically by a DOM sub-layer. Examples of such systems are DMeroon (Queinnec, 1995) and HORB for Java (Satoshi, 1996). They present an attractive alternative and would considerably ease the development of the framework from scratch.

6.1.2 Agent Programming Language

Once an architecture has been selected, then a programming language will need to be chosen to implement the framework. It is commonly accepted that interpreted languages, often referred to as scripting languages, represent the best implementation to achieving heterogeneity and enforcing validation principles. This helps to make the agents of the infrastructure portable and dynamic, and gives the system greater control over their execution. Languages that are compiled to the machine code of a specific system (for example, C) are difficult to make dynamic and portable to other platforms and languages that are interpreted direct from source code present a potential security risk.

The following is a brief summary of the current interpreted languages that hold the most promise for developing the agent framework:

Java (Gosling et al., 1995). Java, developed by Sun Microsystems Incorporated, is an object-oriented language that is very reminiscent of C++ but removes some of the more contentious issues, for example, pointer arithmetic. Java code is compiled to platform-independent byte code for portability, but migration and dynamic extensibility of byte code are not explicitly supported. The object-oriented nature of the language makes it highly desirable, since a generic agent class could be developed and other agent types (for example, a domain agent) could be specialisations upon that class, for example, the JavaAgentTemplate (Frost, 1996).
Telescript (White, 1995). The Telescript architecture, as developed by General Magic Incorporated, is also an object-oriented programming language. However, Telescript has inbuilt support for code migration and explicit support for the dynamic extensibility of objects. A compiler translates Telescript source code into an interpreted language that can be processed by Telescript engines, although the authors stress that it this not a scripting language in the traditional sense. The Telescript language is very useful, since generic agent types have already been created within the class hierarchy, so the development of new agents is relatively straight-forward.
Tool Command Language (Ousterhout, 1994). TCL (pronounced `tickle') was originally designed to perform the tasks of traditional scripting languages; the creation of macros or code segments that link compiled applications together. However, more recently, TCL has been proposed as a language for writing mobile agents (Gray, 1995; Gray, 1995b). Unfortunately, since TCL is a scripting language, its inherent support for migration and dynamic extensibility is non-existent. Also, since the language is interpreted directly from source code it is also disadvantaged, due to the fact that it may not be wise to allow other people to inspect the source code of agents. However, despite these disadvantages, TCL is being used and a proposal has been put forward for a safe version of the language, called Safe TCL (Ousterhout, 1995).
Obliq (Cardelli, 1995). Obliq is a lexically-scoped, interpreted language that supports distributed object-oriented computation. The language achieves distribution of network objects through distributed lexical scoping; the concept of binding network addresses and identifiers to their original network hosts, rather than the host upon which the object is currently executing. Obliq has intrinsic support for what it calls `agents': distributed computations that can be migrated across networks. However, as with TCL, agents are migrated as source code that is interpreted at remote engines.

It would appear then, that object-oriented languages which compile to a platform-independent byte code or an interpreted language hold the most promise for the future development of the framework implementation. However, although a very desirable language, Telescript is hampered by the fact that it cannot be used outside of the Telescript environment and it has no support for heterogeneous integration with user interface environments: an area where Java excels.

6.1.3 Agent Communication Language

It is important that all of the agents within the framework communicate in a single information representation and use a common communication mechanism (called an Agent Communication Language (ACL)). As has already been described in chapter 5, KQML (Finin et al., 1995) offers a standard communication language between agents and KIF (Genesereth et al., 1992) offers a standard information representation that agents can pass between themselves. This reduces the translators required to two types; resource agent to local information resource protocol (for example, KIF to WWW) and resource agent to user-readable format (for example, KIF to text).

Other ACLs that need to be investigated are:

AgenTalk (Kuwabara, 1995). AgenTalk is a coordination protocol description language for multi-agent systems which allows coordination protocols to be defined incrementally and to be easily customised to suit application domains by incorporating an inheritance mechanism.
Agent-Oriented Programming (Davies et al., 1994). AOP is a specialisation of object-oriented programming that supports three mental states; belief, capability and commitment which are represented by commitment rules. Message types (inform, request and unrequest) provide the mechanisms for agents to communicate. Once a rule is triggered within an agent (that is, when a match is made between a message type and the internal beliefs of an agent), the agent will generate a commitment to either do an action, refrain from doing an action or inform an agent of something.

Currently, the most promising ACL appears to be KQML, as it is developing as a standard and is also being adopted by a variety of agent development projects.

6.2 Distributed Information Management Agents

Once the initial framework is in place, then agents for distributed information management can be developed. These agents need to express some of the characteristics described in chapter 3 to ensure that they can fulfil their goals sensibly (intelligence), react to their environment (reactiveness), adapt to their environment (learning), take the initiative (autonomy and pro-activeness) and move closer to the distributed information resource (mobility). This will help to ensure that a trust relationship is developed with the user.

The knowledge-base of an agent will be written in a reusable knowledge format, such as KIF, and agents within the system will communicate through KQML performatives; this gives the added advantage that the framework will also be able to communicate with other KQML-based systems. It will be the task of the user interface agent and the resource agent to perform translations upon KIF information to convert it to and from the local protocol format; it will be the task of mobile agents to perform processing on information received from resource agents.

Agents, such as user interface agents, have the potential to be developed in a number of ways. Essentially, they could be implemented as an interface agent (chapter 3) which sits along side the user and `learns' from their actions; in this manner, the user interface agent can take the initiative and autonomously launch mobile agents of its own to perform functions that it thinks (hopes) will be of use to the user, dependent upon the actions that the user is performing or has performed or dependent upon changes in the user's environment (for example, the arrival of an email).

The user interface agent also has the potential to integrate with the user's desktop; this would give it the ability to coordinate its activities with other, non-distributed information resources that are available on the local network, for example, email, network news, etc. Moreover, the user interface agent could be written to integrate with a series of desktop applications (through interchangeable modules), for example Eudora, Netscape, Elm, etc.

Mobile agents for resource discovery can develop on the ideas that exist for current discovery mechanisms; mobile agents for navigation assistance can develop upon the ideas expressed by Wilkins (Wilkins, 1994); mobile agents for system integration can take the integration ideas expressed by Davis et al. (Davis et al., 1994) for integrating the Microcosm open hypermedia system into the desktop. However, mobile agents for information integrity will require more research, since information management in distributed information systems and on a global scale is limited at present.

[Top]

[Back]

[Next]

[Bottom]

EMail: jd94r@ecs.soton.ac.uk
WWW: http://www.ecs.soton.ac.uk/~jd94r