[Top] | 
[Back] | 
[Next] | 
[Bottom] |
5 A Mobile Agent Framework to Support Distributed Information Management
"I had to quit my job to have time to read my email" - Adam Curry
5.1 Requirements
The last chapter has demonstrated that current mobile agent systems, whilst providing the necessary tools to support the migration of agents between network nodes and the communication between agents, do not provide a direct solution for addressing the problem of information overload.
Therefore, a framework is needed that will address a number of issues, simultaneously, to ensure that the requirements of a distributed information management system are met. This chapter presents the potential requirements of such a system in the context of a mobile agent architecture and also details the initial framework and components required to support mobile agents that perform distributed information management tasks.
5.1.1 Arbitrary Migration
To ensure that programmers are given the maximum flexibility in designing agents, the migration of agents should be transparent and reduced to a single instruction (for example, the go command as used in Telescript). Additionally, this instruction should be able to be issued arbitrarily and execution should continue with the command after the jump instruction. This means that the state of an agent must be encapsulate by this migration command, which will package the agent into a format suitable for network transmission. This will allow programmers to concentrate on the tasks of writing distributed information management agents.
With stateless migration systems, the burden of ensuring that the data that needs transferring with the agent is in a well-defined area (for example, a folder within a briefcase in TACOMA) lies firmly with the programmer of the agent. Even though stateless migration requires less effort on behalf of the migration mechanism, it is considered an undesirable requirement due to the fact that it places some of the migration task with the programmer.
5.1.2 Persistence
A key attribute of a mobile agent system is the concept of persistence; the longer an agent is active, the more nodes it can visit and the more influence it can have. Indeed, if an agent has the ability to learn and augment its knowledge-base, then as time moves forward, the agent will gain `experience'. As the agent gains more experience, the more valuable it becomes to the user, since it has useful knowledge about the nodes that it has visited.
For example, consider a resource discovery agent that visits nodes to find out about a particular subject. As the agent issues queries at each node, it can retain information about the range of facilities available, the number of query results found, the average response time, etc. When it is issued with a new request from its user, it can use this information to make a decision about which nodes might be worth visiting first.
The experience that individual agents gain might also be pooled into a collective experience-base that is stored at the node where a user launches their agents. In this way, new agents can be equipped with an existing knowledge-base with which to begin their search.
5.1.3 Fault Tolerance
As mobile agents move across networks and nodes to fulfil their goals, their `experience' and knowledge base may grow as will the data that they collect. To prevent this information from being lost, an agent must be protected from a number of situations that may occur in its lifetime:
- Network transmission fault. If an error occurs while the agent is in transit between nodes, then it must either be retransmitted or restarted at the side from which it was being transmitted. If it cannot be retransmitted or restarted, then it must be forwarded to the node where it originated, so that the information it contains can still be of use to the user or so that it can be restarted. Whatever the contingency plan, the data that the agent contains must be preserved in some manner.
- Node failure. If the agent is currently executing on a node that fails, then it should be possible to trace the agent back and retrieve a previous copy. This can be achieved by storing a copy of the agent at various nodes during its lifetime. This storage will obviously depend upon the facilities available at each node; some nodes may not desire versions of agents to be stored, especially if they are large. Another solution is for the agent to forward a copy of itself at regular intervals to the node where it originated. Node failure itself can be categorised as serious and non-serious. A serious node failure involves an unexpected error in the system which means that the node fails immediately and without prior warning: the result is that the agent's data is lost. A non-serious node failure is where there is prior warning of the node failing, for example a shutdown, and the agent has chance to migrate to another node (or it is automatically transferred to a backup node).
- Security violation. If an agent cannot be transmitted to a new location due to a security constraint (for example, the agent is not from a trusted node), then the agent should be restarted at the local node and given a chance to choose a new destination. This problem can be alleviated (but not totally solved) by requesting authentication in advance. For example, the agent might be rejected when it has been received and processed by some validation mechanism and the agent then attempts to execute a prohibited action. The action taken is the responsibility of the local node, since the agent might be a virus or a legitimate agent that has exceeded the bounds of its objectives. Potential solutions to this problem depend upon the severity of the security violation. If the agent attempts a prohibited action, it may be suspended and forced to execute in a very controlled environment so that it can choose another destination. However, if the agent fails a validation test, then is might either be destroyed (information and all), or destroyed and its information transmitted back to the node from where it originated.
5.1.4 Agent Communication Language
Agents should be able to communicate with other agents in a common language, which conveys meaning and represents information in a standard format. An example of such standards that are both part of the ARPA Knowledge Sharing Effort (Patil et al., 1992) are the Knowledge Query and Manipulation Language (KQML) and the Knowledge Interchange Format (KIF).
KQML (Finin et al., 1995) is a high-level protocol and language for agent to service and agent to agent interaction and communication, commonly termed Agent Communication Languages (ACL). It is based around a notion derived from speech act theory in linguistics (Austin, 1962) where messages that are communicated consist of performatives indicating what the receiver should do with the message, for example, tell. Currently, KQML provides performatives which deal with belief revision, querying, knowledge-base maintenance, actions and services. Also, KQML has the ability to nest performatives, such that more specialised performatives can be built from more general-purpose performatives.
KIF (Genesereth et al., 1992) is a rich language that provides a standard representation of information. It can express beliefs, rules, facts and partial descriptions of functions amongst other things. However, KIF is used for more than just a information representation; it also provides a central language for communication between other ACLs. Translating between n ACLs and a central information language such as KIF, reduces the number of translators required from O(n²) to O(n+1).
The advantages of using ACLs and standard information representations are clear; if all agents within the system conform to an interchange standard, then the amount of data translation is reduced and the introduction of translation errors into the data are lessened.
5.1.5 Communication
Another aspect that needs to be considered is how agents are to name and reference other agents? It is obviously not suitable to reference agents through network or machine address, due to the fact that they may move frequently. Additionally, some form of registration needs to take place when the agent moves, so that its current address can be resolved and located. Finin (Finin et al., 1995b) advocates the use of a hierarchical naming convention, not dissimilar to the Domain Naming Service (DNS). Each agent domain is responsible for maintaining a portion of the agent naming tree and addressing is resolved by agent name servers. More importantly, they illustrate the use of agent proxies to provide protocol gateways and firewalls.
The Heterogeneous Communication Model (Goose, 1995; Goose, 1996) provides a similar mechanism for agents to communicate with other agents through an addressing mechanism; as agents transport to a domain, they register their presence with a central router. The form of this registration determines which types of messages the agents is willing to receive: this is analogous to offering server-style functions to other clients. In an example scenario, an agent could register once to indicate that it had information on a particular subject and again to say that it required information on another subject. Due to the configurable and modular nature of the HCM, these concepts can be extended over domains by adopting a DNS-like architecture.
5.1.6 Heterogeneity
To ensure that a mobile agent system is generic enough to suit a wide range of applications, it must possess heterogeneity in the following areas:
- Platform. Architecture and operating system heterogeneity can be achieved by transmitting agents as source code and interpreting them at their destinations, or by pre-compiling them into byte code and interpreting the byte code at their destinations. The latter is more privacy-oriented, since it might not be prudent to allow the source code of an agent to be inspected. Also, byte code is less bulky than source code, can be interpreted faster and can be authenticated easier than either machine code or source code.
- Network. To ensure that the agent has access to as wide a range of resources as possible, it should support interchangeable network protocols. This can be achieved at a network level through the use of gateways, which equip agents with a suitable protocol module that allows them to exist on the other side of the gateway.
- Language. Agents should be able to be written in any language that is suitable to their task or with which the programmer is most familiar. However, to ensure that the agent offers the maximum flexibility, it must be transmitted in a form that can be interpreted rather than compiled. This has the implication that an interpreter has to be written or modified for each target language, to support the extra functionality of the mobile agent system. If this is not an option for some languages, then it may be that some will not be able to support all the features that are available, for example, an agent that has been written and compiled in C would not be heterogeneous enough to migrate to different platforms.
The advantages of heterogeneity for distributed information management agents are clear (White, 1994b); it broadens the scope of information resources that agents can access and control on behalf of their user and allows the agents to integrate with more distributed resources and applications.
5.1.7 Security
To ensure that agents can do no harm to their environment or to another agent, a number of security considerations need to be taken into account:
- Permission. The actions that an agent is able to perform should be regulated against a permission set for the intended recipient to ensure that they are allowed within the current context. This means that the permission set used to protect objects must be rich and flexible enough to ensure that its integrity is maintained from unauthorised accesses. Additionally, different nodes may assign different permission sets to similar objects, for example, on a node where security is very tight, all query accesses must be checked.
- Authentication. Before a permission system can be implemented, the identity of the agent must be confirmed and its point or origin established. If neither of these points can be determined, then the agent may be granted the lowest access permission or removed from the node, as detailed previously. However, authentication may be required once per access (for high security systems) or once per session (for lower security systems).
- Transmission. While the agent is in transit, it is vulnerable either to being modified in order to change its original purpose or to being duplicated to obtain its authentication signature. Therefore, when the agent is transmitted, it needs to be protected in some way. Encryption mechanisms such as PGP (Garfinkel, 1994) can be used to protect the agent at a data level, and mechanisms such as the Secure Sockets Layer (SSL)
(Freier et al., 1995) at a network level.
- Verification. When the agent arrives at a node, certain verification tests can be made upon its byte code to ensure that it will neither perform malicious acts nor prohibited acts. This type of verification is performed rigorously by Telescript engines and less complete security is provided by the validation component of a Java-aware browser.
- Charging. As an agent interrogates information, it may be charged for access on the amount of data it requests, or once per access. Either way, some system needs to be employed to ensure that the agent has funds to pay for services, that those funds belong to the agent and the agent belongs to the right user. Existing technologies, such as the Electronic Cash Unit (ECU) (Chaum, 1992) can ensure that mobile agents have to pay for the services that they use.
The discussion surrounding the security of mobile agents is currently a topic which generates much debate (Chess et al., 1995). There is genuine concern that mobile agents could present a fundamental problem to networks and systems unless their movement and execution are closely monitored and regulated. It is obvious that some forms of control will have to be implemented to ensure that mobile agents cannot execute on prohibited nodes, cannot monopolise resources or cannot perform malicious acts across network nodes.
One policy involves giving an agent exactly the right amount of permission required to complete its pre-authorised task. If an agent requires more permission, it must apply to the regulatory body of the node. Access or denial will depend upon a number of factors; the ability of the agent to pay for the new permission and the trustworthiness of the agent in the past, as examples.
5.1.8 Summary
The requirements that have been previously outlined are considered the minimum necessary to build an initial framework for mobile agents to support distributed information management tasks.
It is hoped that requirements such as arbitrary migration and ACLs will give the programmer flexibility when writing agents, heterogeneity and communication will allow an agent to reach as many distributed information resources as possible, and security and fault tolerance will make the mobile agent system both trustworthy and robust.
5.2 The Framework
The framework that is to be presented is based around an agent-oriented model; everything in the system is abstracted through agents (figure 5.1). The system is comprised of both static and mobile agents; static agents provide resources and facilities to mobile agents and mobile agents move between network domains taking advantage of these resources to fulfil their goals.
It is envisaged that mobile agents will migrate in a state-oriented fashion and be comprised of code, state and some form of knowledge base. The code segment of an agent will describe the functionality of the agent, for example a resource discovery agent or a link maintenance agent. The state segment will include the stack and local data that the agent is currently executing upon; this will be transferred with the agent transparently. Finally, the knowledge-base will contain the `intelligence' of the agent, that is, its experiences, its goals and its beliefs. This segment will also contain temporary information that the agent is working upon before it is returned to the user.
The manner in which mobile agents (and indeed, static agents) achieve the requirements identified earlier forms the discussion in chapter 6, Future Work. The next sections take each component of the framework and detail its general activities and purpose in the mobile agent infrastructure.
5.2.1 Domain Agent
A domain agent is a static agent that supervises the activities that occur within a domain; a domain is a logical boundary used to delimit nodes, agents and resources into manageable and distinct entities. The domain agent has a number of responsibilities to information resources, users and agents within a given domain:
- Providing a migration service to mobile agents wishing to leave the domain; the domain agent is responsible for ensuring that the mobile agent is transferred successfully. Upon valid exit, notification should be sent to the node which originally launched the agent, to enable a user to keep track of their mobile agents.
- Providing an authentication and validation check on mobile agents wishing to enter the domain; agents that cannot be authenticated or fail the validation check are rejected. Upon valid entry, notification should be sent to the node which originally launched the agent, to enable a user to keep track of their mobile agents.
- Launching received mobile agents in a suitable runtime environment, which will be related to the amount of trust given to an agent; agents from trustworthy nodes may be allowed access to more information resources than agents from unknown nodes. A suitable runtime environment will depend upon the language that the mobile agent is written in, the access level it is allocated and the functions it wishes to perform.
- Mediating global access to information resources; before a mobile agent can access an information resource it must obtain permission from the domain agent. Depending upon the policies imposed on the domain agent, public resources might grant read access automatically. However, for read access to restricted information or modification access, the domain agent must approve and grant access.
- Providing a central message router; all message interactions between static and mobile agents are routed through the domain agent. This allows agents to communicate in an asynchronous fashion. However, once two agents have become aware of each other's presence (through communicating initially through the domain agent), they can initiate a direct and synchronous communication between themselves, to transfer high-bandwidth data for example.
- Providing a central registration area where static and mobile agents can register and advertise their resources and interests.
- Ensuring that the domain does not become swamped by mobile agents. This can be achieved by limiting the amount of agents that can exist within the system at a given time and implementing a charge for processor cycles and resource access. This way, even if a mobile agent attempted to hog a resource, it could only do so for as long as its credit limited lasted.
- Advertising public information resources and the presence of mobile agents to enquiring agents. In this way, mobile agents can interrogate the contents of a particular domain before moving, to ensure that it contains information resources will help it to achieve its goals. It also provides a rudimentary mechanism for agents to locate each other.
- Periodically announce their presence (through broadcasting or multicasting) to the larger community of domain agents. This will allow each domain agent to maintain a list of other domains that is available for mobile agents to use in determining their next jump point.
The domain agent, then, is the key force within a domain and is ultimately responsible for ensuring that security is enforced within the domain and that agents can communicate with information resources and other agents.
5.2.2 Resource Agent
Resource agents are static agents that exist within a domain to provide a level of abstraction between mobile agents and the information resource to which they provide access. The purpose of a resource agent is to mediate access to a particular resource at a local level for an agent; the resource agent understands how to interrogate the resource and also understands the permission structures associated with the resource.
The resource agent has a number of functions to fulfil:
- To be fully conversant in the protocols of the information resource to provide complete access; the information resource should be completely accessible by agents, so that user intervention directly on the documents is not required. This would imply that the user has a set of distributed information management mobile agents that are able to manage and control their information resources through resource agents.
- To provide a standard and generic set of services which all mobile agents can utilise, for example,
query, get, delete, add, alter. The more specialist functions of an information resource, for example linking, would be handled by other service primitives that would imply that the mobile agent understood some of the functionality and capabilities of the information resource. It would be desirable to decouple this relationship entirely, that is, to provide an extensible set of services across information resources. This could be achieved by attributing the functionality of a service to an associated specification of its behaviour, rather than its descriptive title.
- To mediate access to the resource on a per agent basis; once an agent has been granted access to an information resource, it is the task of the resource agent to ensure that the integrity and privacy of the resource is maintained. To this end, once the agent enters the domain, the domain agent should allocate the mobile agent a permission set which is recognised locally by the individual resource agents.
- To provide conversion between the information representation of the mobile agent and the information representation of the information resource that the resource agent is managing.
- To advertise the presence of the information resource by registering the services available to the domain agent. In this way, mobile agents can be aware of what information resources are available within a domain (by querying the domain agent) before they arrive at a domain.
The interaction between resource agents and mobile agents will form the crux of the distributed information management aspect of the infrastructure. The flexibility that mobile agents are afforded in accessing these information resources and the manner in which they interpret the results will determine their usefulness to the user.
5.2.3 Mobile Agent
Mobile agents, as their name suggests, are the components within the framework which can migrate between network nodes. They are the mechanism by which the user exercises control over their own distributed information resources and gain access to other, shared information resources.
Mobile agents are equipped with a set of user-defined goals which describe the nature and limits of their functionality, for example, a resource discovery agent is a mobile agent with a different goal set than, say, a navigation assistant agent. It is probable that, in addition to the limits on the functionality that users place on their mobile agents, the mobile agents themselves will encounter limits (in the form of security, authentication and validation) that exist within domains. In some cases, these limits (for example, lack of funds to pay for resources) will compromise the goals that have been given to the mobile agent.
There are two general approaches to the coordination of mobile agents:
The essential functions of mobile agents will be delineated by the distributed information management tasks that they are allocated. However, they have the following interactions with the framework:
- Mobile agents determine where to migrate to next by initially querying the local domain agent for a list of domains of which it is aware. The mobile agent can then use this information to contact each domain agent and determine which one offers a compatible set of information resources.
- Mobile agents are authenticated by an electronic signature that they carry; this signature is encrypted and is verifiable with the host domain of the mobile agent (which implies that the host domain is also authenticated in some manner). Additionally, mechanisms must be employed to ensure that mobile agents are not compromised during transit or within a domain and that the behaviour of a given mobile agent is consistent with the behaviour that it was given when it was launched. Due to the fact that it is impossible to guarantee these requirements, since a malicious agent may be launched from an authentic domain, mobile agents should be taken on face value and given the minimum amount of permission possible.
- Mobile agents possess the characteristic of persistence; they use migration as a mechanism to achieve longevity. Mobile agents must learn from the domains that they visit, the actions that they perform and the results they receive by augmenting their knowledge-base accordingly. Therefore, the `older' a mobile agent is, the more `experience' it will have gained; this experience can become invaluable to new `raw' agents.
- Mobile agents may communicate with other mobile agents to achieve their goals. There are a number of advantages to this approach; in the global information space, certain mobile agents will be performing the same or similar tasks and therefore it makes sense if they can trade information. Additionally, mobile agent might trade other services, such as experiences of productive domains for electronic cash or information. However, the disadvantages of mobile agent communication rationalises to one of trust; is it possible to trust the information given by one mobile agent to another, especially when electronic cash is concerned?
- Mobile agents should transmit the results of their findings and actions regularly to their user on the host domain. This way, the user can ensure that the mobile agent is functioning correctly and also helps prevent the mobile agent from becoming too big (in terms of size, memory and processing requirements) to move or to process.
It is clear then, that mobile agents are the ultimate effector of change within a distributed information management environment, and as such, should be treated cautiously. The possibility for mobile agents to effect changes or gain access to private information must be closely monitored by the domain agent and the individual resource agents. A comprehensive authentication, validation and access permission system is vital to ensure that malicious agents can do no harm to a system and that legitimate mobile agents can fulfil their goals.
5.2.4 User Interface Agent
The user interface agent is an agent that resides within a domain and provides a level of abstraction for the user away from the details of the mobile agent framework. It is essentially an interface agent (see chapter 3) that needs to be capable of the following tasks:
User interface agents provide the user with a window onto their agents, their status, their results and the mobile agent framework. The creation of new distributed resource management agents could either be the task of the user to write (or reuse with different parameters), or the task of the user interface agent to interpret the requirements of the user and generate mobile agents to fulfil those tasks automatically. The latter approach is most desirable, but is still a long way off given the technology that exists currently.
5.2.5 Gateway Agent
A gateway agent is a static entity that resides within a domain and provides access to another network or to a restricted domain. Therefore, gateway agents need to provide the following services:
5.3 Summary
The framework that has been presented in this chapter has shown that there is much work that needs to be undertaken above and beyond what current mobile agent systems offer for distributed information management. The framework provides a network-wide environment in which users can manage, augment and integrate their existing distributed information systems, and also discover and incorporate additional bodies of information from other distributed information systems that have been made accessible by other users. The sharing permissions that these information resources are issued with will determine the level at which anonymous mobile agents can interact with foreign resources; the potential for cooperative working is obvious.
The realisation of this framework will take two stages; production of the infrastructure components and the development of a set of mobile agent-based tools to support the user in achieving distributed information management goals. The next chapter identifies some of these issues as future work and discusses their potential implementations.
[Top] |
[Back] |
[Next] |
[Bottom] |
EMail: jd94r@ecs.soton.ac.uk
WWW: http://www.ecs.soton.ac.uk/~jd94r
Copyright © 1996, University of Southampton. All rights
reserved.