Introduction:

The Vision: Wide-area Ubiquitous Computing

Many current researchers in the mobile computing arena share the same vision: ubiquitous access to information, data, and applications. Ubiquitous access refers to the ability for users to access to these computing resources from almost any terminal, whether personal or public.

Recent developments of the Internet are establishing solid foundations for wide-area ubiquitous computing systems. The recent development of cross-platform languages, the most important of which is Java™, enable the deployment of computing systems that span multiple computing platforms and communication networks. Java provides a means of building applications which are accessible from virtually any Internet-connected terminal. This is true since the only requirement for running Java programs (or applets) is a Java-enabled Web browser, which is now a desktop fixture on computers worldwide.

Further evolution of Internet technologies will yield a wide-area network based on component-oriented, dynamic applications, which will support efficient, scalable resource sharing for a large number of mobile and nomadic users. As users gradually grow to rely on the Internet as an indespensible tool of the workplace and home, most users will become mobile or nomadic users, or both. While mobile users access the Internet from a portable computer, nomadic users may move from terminal to terminal. In either case, ideally a user would be able to accomplish the same tasks with the same amount of effort from any location on either his portable computer or any Internet-connected terminal. For example, a user may begin updating his checkbook at the workplace, continue the task on his laptop, and finish the task later on his home computer. This requires management of distributed data and application resources over a wide-area, including automated replication and consistency management.

Requirements for this Vision

To deploy a large-scale ubiquitous computing system, a system to manage shared distributed resources over a wide-area, fault-prone network is required. End-user requirements of this system include:

Network, distribution, and location transparency: To the end-user, the entire network and any terminal attached to it is one large virtual host. The end-user does not care how or where the data and applications are stored

To achieve the above end-user requirements, several matching technical requirements are warranted. Technical requirements include:

• distributed, network-centric data and application hosting: Distribution transparency over a wide-area, mobile network calls for network-centric data and application hosting, that is, distributed hosts on the fixed network collaborate to provide data and application hosting for individual users.
• replication and consistency management: With data scattered over a wide-area network, redundancy of data for high availability, fault-tolerance, and security are very important. The system should integrate replication and consistency management of data as a fundamental feature.

Flexibility, mobility, openness, and dynamism: A wide-area network such as the Internet, especially with mobile hosts, is subject to frequent shifts in topology and network conditions. Such volatility in topology is attributed to 1) frequent changes in the availability of various intermediate network hosts, 2) mobility of mobile hosts such as laptops, and 3) general shifts in network usage patterns which may affect bandwidth and host availability.

What’s Wrong with Current Approaches

Although existing frameworks and distributed systems for mobile computing, such as Bayou [1] and Rover [2], tackle distributed consistency and replication management, their communication models and programming models are unsatisfactory. The communication paradigms used in these systems are evolved from artifacts of the conventional client/server model, such as RPCs. These mechanisms rely on fixed, well-defined clients and servers, and do not have enough flexibility to deal with the fluidity of wide-area mobile networks.

Agent-based Communication

Agent-based communication paradigms have shown enormous potential for operating in unpredictable, metamorphic environments, as is the case with wide-area mobile computing networks.

An example high-level distributed task that can be accomplished by agents is the processing of an electronic transaction. Several authorities may need to be contacted before a transaction can complete. For example, to buy a software product electronically, one needs to obtain verification of the user's credit card number, debit the user's credit card account, credit the merchant's account, and deliver the software product back to the user. Such tasks require a series of read/write operations at various nodes, where strict causal dependencies must be enforced (e.g. funds are received by the merchant before the product is delivered.)

Much like the current omnipresence of Web browsers, a pervasive presence of agent platforms would be required to support the deployment of agents and agent-based applications over a wide area.

Why build an agent based OS?

Agents exhibit the following distinguishing characteristics suitable for a wide-area mobile networking environment:

Mobility: Mobile computing exhibits an inherently transient nature, i.e. host locations constantly change, and transactions span many nodes and are short-lived. The ability of agents to carry code and data across network nodes underlines their suitability to a transient environment.

Flexibility: Agent algorithms may be dynamically modified according to pertinent environmental conditions, i.e. network congestion, node failures, user movement.

Concurrent problem solving: Agents provide a clear, natural paradigm for performing tasks which may have several concurrent aspects.

Autonomous security model: Each agent is assigned a privilege level while agent platforms execute agents run in a "sandbox," governed by the least-privilege principle, i.e., grant the agent only as much privilege as it needs. Agents may also delegate, or transfer, user or system privileges.

Proxy handling: agents can behave simultaneously as server proxies or client proxies at any node. Server proxies emulate the functionality or presence of a server while client proxies emulate the functionality or presence of a client (typically a mobile or nomadic client).

Potential Contributions to Mobile Computing Research

We have identified the following issues as the most pervasive and widely-studied problems in mobile computing research. The use of a mobile agent paradigm to address these issues will not only contribute new solutions to these problems, but also present a uniform platform and methodology for building mobile systems.

Distributed, shared data consistency: Maintaining consistency of replicated, interdependent data across distributed sites. Conventional solutions use explicit data synchronization messages for consistency and replica management. An agent-based solution allows the responsibility of consistency management to be assigned to mobile agents.

Dynamic proxy server and proxy client management: Emulation of servers and clients to accommodate server failures and client disconnections, and to decrease latency and improve performance. Agents may behave as proxy clients, proxy servers, or both.

Disconnected operation: Enabling operation of applications on mobile hosts while they are disconnected from the backbone network. Agents allow for transfer of data and code en masse in preparation for disconnected operation or upon reconnection.

Intelligent query processing: Performing a complex query task from a mobile host, with the query possibly executed across multiple nodes and with multiple strategies. Complex query logic may be embedded in agents, which are naturally tailored for moving among various nodes.

Secure, distributed transactions: Guaranteeing security and integrity of database transactions in a mobile environment.

Performance and Overhead Considerations

Bytecode Interpretation

First generation Java has been known to run slow due to interpretation overhead associated with Java interpreters. However, recent research and development of just-in-time compilers (JITs) [3] promises to deliver compiled-code performance to Java while maintain cross-platform portability. Just-in-time compilers dynamically compile bytecodes into native machine instructions during execution. Code that is repeatly executed (e.g. kernel code) will approach the speed of compiled code.

Latency associated with code transport

Transmitting the agent code across the network eliminates the conventional client/server communication. In mobile and wide-area network environments, aggregating multiple messages into one transmission is more efficient than disjoint multiple transmissions, due to the often high cost of connection setup and tear-down. Agents may also carry only code that is essential for its operation. Pieces of code could be dropped during its trip when they are no longer needed.

AgentOS is an OS "of agents, for agents, and by agents"

System functions, such as resource management, are carried out by agents, hence an operating system of agents.

Agents will be organized into several levels. There will be agents which manage the decomposition of user commands into system commands, and agents which decompose system commands into low-level messages.

With a system full of agents, including system, application, and user agents, we need an operating environment and to manage these agents, hence, an operating system for agents.

When a user, application, or system agent needs to accomplish a task, it generates and sends out mobile agents to contact other agents. Underlying protocols is partially generated by agents.

Research Goals

An efficient OS for mobile applications can be built using agents.

Concurrent, mobile agents represents the most suitable paradigm for developing and deploying mobile computing applications.

Agent-based protocols are ideal for consistency management, network fault detection, intelligent/adaptive routing.

Agent-based systems are applicable to real-life applications, such as factory equipment monitoring, electronic transactions.

Related work

The related projects fall into three categories: Operating systems for the Internet, mobile computing support systems, and mobile agent systems. The AgentOS project takes a unique approach by uniformly using the mobile agent paradigm to implement an operating system for the mobile-enabled Internet.

Operating systems for the Internet is a relatively new concept. Inspired by the proliferation of Java VMs in Web browsers, the "Internet OS" attempts to define a set of basic services essential to a migratory, cross-platform Internet application. The JavaOS, by Sun Microsystems, is slated to be used in network computers, which embraces the concept of the network as an OS. However, network computers nevertheless adopt the client/server model AgentOS, on the other hand, embraces a mobile agent model. Apple has recently described the concept of an operating system for the Web, which in their view, is merely the aggregation of browser-embedded Java VMs viewed as a virtual OS. AgentOS extends the VM concept beyond the browser, and to intermediate nodes on the network and mobile nodes such as portable computers and wireless devices.

System support issues in mobile computing, especially replicated data management and disconnected operation, have been addressed by verious projects. The notable projects, Bayou by Xerox PARC and Rover by MIT, have approached the issues in the same general fashion: by extending the client/server model to accommodate the peculiarities of mobile computing, such as extending RPCs to support queueing and callbacks, and using dynamically migratible objects to facilitate caching for disconnected operation. AgentOS takes an innovative approach by abandoning the client/server paradigm and uniformly adopting the mobile agent paradigm to implement solutions for mobile computing data and resource management.

The mobile agent paradigm has been introduced for several years. The pioneering projects in the mobile agent paradigm include Telescript and Messengers. Since the introduction of this paradigm several other projects have surfaced, including CyberAgent, by FTP Software, and Aglets, by IBM. CyberAgent is a framework also written in Java, but its primary focus is on intranet network management. CyberAgent’s execution model assumes one agent, rather than a cooperating group of agents. IBM’s Aglets defines a general-purpose mobile agent framework, but lacks essential functionality such as merging and splitting, dynamic agent generation and spawning, and inter-agent communication.

related project	focus	advances Made by AgentOS
JavaOS/HotJava	Small footprint OS; Dynamic Browser Extensibility	Mobile/Nomadic Computing Features
Java Beans	Flexible Component Architecture	Agent-oriented
"Operating system for the Web’’ (Apple Computer)	Safe environment for component-oriented, Internet based applications	Mobile computing features, agent-oriented framework
Telescript	Agent Language, Platform, Communication, and Management	Focus on system agent management
Mobile Service Agents	Proxy client for mobile hosts to interface with existing servers	lightweight, multi-faceted agents
Bayou/Rover	Optimistically Replicated Data Sharing	Agent-implemented, adjustable consistency level
CyberAgent	Agent Framework for Network Management	Multi-agent management
Aglets/Mobile Agent Framework	Agent Framework	Merging/Splitting; Dynamic Agent Generation; Inter-Agent Communication
Messengers	Agent Framework for Distributed Simulation	Use of Java as underlying platform for wider compatibility

Requirements

The following are features which we have determined as required for an agent-based operating system tailored for mobile computing.

Mobile Agent Framework

Agent Execution Model:

These requirements pertain to the basic agent execution model.

• Unique Naming:	Ensure global uniqueness of agent ID.

• Migration: Agents execute their code as they migrate from node to node. Migration may be self-initiated or initiated by the node.

• Dynamic Capabilities Discovery and Invocation: Agents discover and use the services of other agents without compile time knowledge.

• Inter-agent Communication:	Agents hold conversations in agent groups. Agents may communicate with newly discovered agents without prior compile-time knowledge.

• Spawning: An agent may construct and send off a sub-agent.

• Splitting and Merging: An agent may clone itself, and the clones may merge later

• Rollback, recovery, and backtracking: An agent may revoke to a previous state of its execution. The restored execution state may include the state of agent data and network location.

Agent Management

• Naming and Directory Services: Provide intra-node and inter-node (location-transparent) directory services for locating and discovering agents.

• Security: Implement multi-level security policies according to the least-priviledge principle. Implement guards against Trojan horses and denial of service (resource saturation) attacks.

• Scheduling: Based on agent priorities, task and data dependencies, allocate appropriate CPU resources to agents within the node.

Mobile computing and data management services

• Distributed content-addressable memory: Provide persistent storage of data indexed by name and content.

• Object replica synchronization: Implement cache invalidation schemes using agents.

• Dynamic and adaptive resource distribution: Dynamically allocate mobile computing resources, such as server processes (stationary agents), based on usage patterns.

• Network monitoring: Monitor link and node conditions in real time to allow agents to adapt to current topographical information.

• Adaptive, intelligent routing: Intelligently route agents based on current network and node conditions.

End-user Capabilities

• Task decomposition: Interpretation and refinement of user requested high-level tasks into system-level operations and procedures.

• Dynamic agent composition: Composing low-level agents together to form an appropriate customized agent for the requested task.

Mapping of Traditional OS functions to AgentOS functions

IO

In AgentOS, the entire network is viewed as a collective virtual machine. I/O is defined at a more abstract level than the traditional device input and output services of an OS. In AgentOS, the inputs to the system are tasks (e.g., a criteria-based search request), and the outputs are the results of the tasks (e.g., a search result list).

Memory Management

The notion of memory management needs to be reexamined on two levels. Memory required by the agent is allocated on the current local node, and as the agent travels, the memory requirements are carried along to subsequent nodes. A potential problem arises when subsequent nodes cannot satisfy the memory requirements of the incoming agent. Measures to "borrow" memory from other nodes must be taken.

In a broader sense, memory management can be considered as the management of distributed data throughout the wide-area network. The collective sum of files, databases, etc. across the entire network comprises the system’s memory. This amount is obviously undeterminable. The notion of memory allocation can be likened to finding a place on the network to store data.

Process Management

Process management involves management within a node and throughout the network. Within a node, process management corresponds to managing currently executing agents, including their scheduling and resource allocation, based on priority. Across the network, process management may involve migrating active agents for load balancing purposes.

Security

Traditional OS security services, like user authentication, file access control, must be extended to agents. In AgentOS, agents may be delegated the privileges of the user. For example, an agent who performs a search request on behalf of a user will carry the user’s privileges. Access control must be extended to objects distributed throughout the network. Heterogeneous security and authentication protocols across a wide-area network presents a real challenge.

• 
  Figure 1: Mapping of Traditional OS Functions to AgentOS Functions

Architectural Design

An AgentOS system is a dynamic collection of nodes which have the AgentOS kernel installed. The system is dynamic in that the number of AgentOS-enabled nodes may increase or decrease, even during runtime. Any node on a wide-area network which has the AgentOS kernel installed will be able to receive and send agents. Thus, the system boundary is highly malleable and unpredictable.

AgentOS Nodes

An AgentOS node consists of a kernel running system agents, and zero or more agent groups running user agents. System agents manage system services, such as agent directory services, network monitoring, etc. User agents run in dynamically created agent groups, which are abstractions to allow group communication within a group of agents.

Agents may also communicate with agents in other groups, including system agents. However, all communication must taken place within the same node.

All communication between agents is performed through a node-wide event pool, which provides different forms of the push and pull event model. The four forms of event communication include:

• active push from agent to event pool: agent puts an event into the event pool, directed at one or more agents.

• active pull by agent from event pool: agent waits for an event based on some criteria, e.g. event type, event source.

• passive push from event pool to agent: agent registers an event handler callback; system calls agent’s event handler when event occurs

• passive pull by agent from event pool: agent reads a shared variable from a variable table.

Each agent runs in an agent context. An agent context is the execution context of the agent, and is therefore responsible for the instantiation, invocation, replication, splitting, merging, and destruction of agents. The agent context also provides all run-time services to the agent.

Agent Execution Model

When the agent context invokes the agent, the start() method of the agent is invoked. The start() method is the entry-point into the agent, and this method may either invoke a manager agent which then invokes a base agent, or it may invoke the base agent itself. Manager agents monitor the execution of base agentsand perform run-time modification of the base agent algorithm. This run-time modification may involve adding (hiring) more base agents, removing (firing) base agents, and replacing base agents. The notions of manager and base agents are internal to the agent package

Agent Transport

Agents reside in an agent package, used for transporting between nodes. The agent package contains a package index, which lists all components inside the agent. Package components include agent properties, agent data, and agent classes (explained below). All package components are optional except a primary agent class which provides the entry-point start() method.

Agent properties are system variables attached by the agent context to the agent for system bookkeeping purposes. Agent properties contain information such as the globally unique agent identifier, intended destination of the agent, and routing hint information. Agents do not have direct access to agent properties, except via services provided by the agent context. Access to agent properties is under the discretion of the agent context.

Agent data are variables maintained by the agent itself. Two forms of agent data are available. Agent data may reside within the classes that comprise the agent itself. These take the form of normal class instance variables (or data members). The agent transport mechanism will automatically handle the retention of class instance variable states during transport. Agent data may also reside in a data area managed by the agent context. The advantages of the external data area include the ability to dynamically create/destroy variables, and the ability to share variables with the agent context or other agents.

Agent classes include the actual class bytecodes comprising the agent. Note that not all required classes may reside in the agent classes area. The index file may specify that a certain class resides in a remote location, and should be fetched only when needed.

	Design

Synopsis

An AgentOS system is a dynamic collection of nodes which have the AgentOS kernel installed. The system is dynamic in that the number of AgentOS-enabled nodes may increase or decrease, even during runtime. Any node on a wide-area network which has the AgentOS kernel installed will be able to receive and send agents. Thus, the system boundary is highly malleable and unpredictable.



AgentOS Nodes

An AgentOS node consists of a kernel running system agents, and zero or more agent groups running user agents. System agents manage system services, such as agent directory services, network monitoring, etc. User agents run in dynamically created agent groups, which are abstractions to allow group communication within a group of agents.

Agents may also communicate with agents in other groups, including system agents. However, all communication must taken place within the same node.

All communication between agents is performed through a node-wide event pool, which provides different forms of the push and pull event model. The four forms of event communication include:

• active push from agent to event pool: agent puts an event into the event pool, directed at one or more agents.

• active pull by agent from event pool: agent waits for an event based on some criteria, e.g. event type, event source.

• passive push from event pool to agent: agent registers an event handler callback; system calls agent’s event handler when event occurs

• passive pull by agent from event pool: agent reads a shared variable from a variable table.

Each agent runs in an agent context. An agent context is the execution context of the agent, and is therefore responsible for the instantiation, invocation, replication, splitting, merging, and destruction of agents. The agent context also provides all run-time services to the agent

.

• Figure 6: AgentOS Architecture

Lifetime of an Agent



Package Overview

The root package name is agentos. Subpackages of agentos with descriptions are listed below:

kernel: Represents the entry point of incoming agents, and the central manager of AgentOS resources, such as the registry, event pool, and agent contexts for user and system agents.

agent: All classes related to the agent execution model, including IAgent, AgentContext, and the agent API

event: All classes related to the event pool.

transport: Classes for packaging, transport, routing,

service: Auxiliary services, including the UUID gen service,

util: Generic utility classes, e.g., the name-value list (NVList)

Agent Execution Model

When the agent context invokes the agent, the start() method of the agent is invoked. The start() method is the entry-point into the agent, and this method may either invoke a manager agent which then invokes a base agent, or it may invoke the base agent itself. Manager agents monitor the execution of base agentsand perform run-time modification of the base agent algorithm. This run-time modification may involve adding (hiring) more base agents, removing (firing) base agents, and replacing base agents. The notions of manager and base agents are internal to the agent package.

AgentOS API

Abstractions

Node: a moveable abstraction on top of an URL

Itinerary: list of tasks

Task: an action (or a group of related actions) to be performed by an agent

Actions

dispatch(Node): move agent to the specified node

split(): split agent into two or more sub-agents

merge(): merge sub-agents back into parent agent

deactivate(): suspend to wait for sub-agents to report back

inquire(): Request response or recommendation from user

clone(): Copy the agent

spawn(): create a sub-agent based on a class

Agent Transport

Agents reside in an agent package, used for transporting between nodes. The agent package contains a package index, which lists all components inside the agent. Package components include agent properties, agent data, and agent classes (explained below). All package components are optional except a primary agent class which provides the entry-point start() method.

Agent properties are system variables attached by the agent context to the agent for system bookkeeping purposes. Agent properties contain information such as the globally unique agent identifier, intended destination of the agent, and routing hint information. Agents do not have direct access to agent properties, except via services provided by the agent context. Access to agent properties is under the discretion of the agent context.

Agent data are variables maintained by the agent itself. Two forms of agent data are available. Agent data may reside within the classes that comprise the agent itself. These take the form of normal class instance variables (or data members). The agent transport mechanism will automatically handle the retention of class instance variable states during transport. Agent data may also reside in a data area managed by the agent context. The advantages of the external data area include the ability to dynamically create/destroy variables, and the ability to share variables with the agent context or other agents.

Agent classes include the actual class bytecodes comprising the agent Note that not all required classes may reside in the agent classes area. The index file may specify that a certain class resides in a remote location, and should be fetched only when needed.

Agent Context Services

AgentManager Service

Hiring, firing, dispatching, splitting, cloning, merging, and management of itinerary and tasks.

Packaging Service

Takes classes and index file and assembles an agent package.

Takes a byte stream and reconstructs an agent package

 

AgentInfoCreator Service

Creates the AgentInfo, a set of user-modifiable properties exposed to other agents, and to visual agent-builder tools.

Class Factory Service

Dynamically compiles Java sources to produce class files.

UUIDGen Service

Generates a globally unique id for identification of agents.

Registry Service

Provides access to the node registry, which registers agents so that other agents can discover and communicate with them.

Directory Service

Provides a system wide directory service to locate other agents, by name, description, capabilities, etc.

Transport Service

Provides agent package transport services using various protocols, e.g. TCP/IP. May consider UDP/IP for small packages, such as basic network messages (which we consider degenerate agents)

Active Kernel Services

Routing Service

An active system agent which monitors network topography (neighboring link conditions). This agent will accept dynamic topographical changes via a request from another agent.

Directory Service

An active system agent which maintains, using a lazy propagation protocol, replicated directories of all registered agents system-wide.

Project Status

The project is currently in the architectural design phase. We are identifying all necessary features and developing object-oriented designs of the AgentOS kernel. The implementation language for the project is Java™. We believe Java provides all the necessary language features to implement an agent system, including object-orientedness, built-in multithreading, platform independence, dynamic linking, dynamic compiliation, and introspection (or reflection). The aspects of Java which are superior to the next logical choice of implementation language, C++, include all of the above features.

A general project schedule is given in Appendix I.

Appendix I: Research Agenda

PHASE I: REQUIREMENTS SPECIFICATION / FEASIBLITY STUDY

Specify the requirements for the agent framework, keeping in mind that it needs to support the desired AgentOS functions. The AgentOS requirements are determined by the needs of wide-area, highly available mobile computing applications.

We’ve investigated the following issues for the agent framework so far:

• Dynamic network class migration and instantiation

• Dynamic capabilities discovery and dynamic method invocation

• Inter-agent communication

PHASE II: Mobile Agent Framework

Design mobile agent framework such that the mobile agent execution model is realized. Design the services of the kernel, and the transport and routing mechanisms. We are in the process of designing the agent framework system architecture.

PHASE III: MOBILE COMPUTING AND DISTRIBUTED DATA SERVICES

Design various distributed data services (e.g. replicated data management, disconnected operation management, distributed version control) and implement mobile services and algorithms using agents.

PHASE IV: MOBILE COMPUTING APPLICATIONS

Empirically evaluate the system by building sample mobile applications.

• Factory equipment monitoring

• Collaborative multi-user software development environment

• Nomadic, mobile personal applications

• Electronic commerce applications

PHASE V: USABILITY AND SCALABILITY

Simulate wide-area deployment. Get volunteer participants from the Internet.

Appendix 2: Glossary

agent: something or someone that can act on its own and produce changes in the world. (from Stanford)

capabilities discovery: dynamically searching and subsequently interacting or using the services of other agents without compile-time knowledge

denial-of-service: a method of attack where an intruding program depletes the resources of the victim

least-privilege: a security principle giving an untrusted program the minimal set of capabilities to get its job done

proxy server: a process which emulates the presence of another server process by duplicating its services , through code migration or delegation.

proxy client: a process which emulates the presence of a client, usually used to simulate the presence of a mobile host in the fixed network when the mobile host is disconnected

splitting: an agent algorithm primitive whereby an agent splits into two or more sub-agents, each performing similar tasks or parts of a subdivided task

merging: an agent algorithm primitive whereby two or more sub-agents merge back into one agent; the data is reintegrated according to an agent-specific algorithm

spawning: dynamically composing and deploying mobile agents at runtime, either by the system from by a parent agent

References

^{[1] Alan Demers, Karin Petersen, Mike Spreitzer, Douglas Terry, Marvin Theimer, Brent Welch. ``The Bayou Architecture: Support Data Sharing among Mobile Users.'' Proceedings of the Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, December 1994.}

^{[2] Anthony D. Joseph, Alan F. DeLespinasse, Joshua A. Tauber, David K. Gifford, and M. Frans Kaashoek. ``Rover: A Toolkit for Mobile Information Access.'' Proceedings of the Fifteenth Symposium on Operating System Principles, December 1995.}

^{[3] Franklin D. Reynolds. "Evolving an Operating System for the Web" IEEE Computer. Vol. 29, No. 9 (September 1996) pp. 90-92.}

^{[4] "Agents: An Undistorted View of Problem Structure"}

^{[5] Yoav Shoham. "Agent Oriented Programming" in Artificial Intelligence, Vol. 60 (1993), pp. 51-92.}

^{[6] J.E. White. "Telescript Technology: The Foundation for the Electronic Marketplace." White Paper, General Magic Inc., 1994.}

^{[7] "CyberAgent." White Paper, FTP Software, 1996.}

^{[8] Mobile Agent Facility Specification. OMG TC Document cf/96-08-01.}

^{[9] Lubomir Bic. ``Distributed Computing using Autonomous Objects.'' IEEE Computer, August 1996.}

^{[10] http://java.sun.com}