perform speci c search and transaction services as needed, end users could dispatch agent programs to the various database sites involved in arranging a va-.
Distributed Management by Delegation In Proceedings of the 15th International Conference on Distributed Computing Systems, June 1995
German Goldszmidt and Yechiam Yemini Computer Science Department, Columbia University New York City, NY 10027
Abstract
and so forth. Executing the search at the end user workstation will require massive transfers of data. Such transfers may be inhibited by bandwidth constraints, storage limitations, transfer time costs, and data ownership considerations. If the database services could be programmed to perform speci c search and transaction services as needed, end users could dispatch agent programs to the various database sites involved in arranging a vacation. These agent programs would search, transact and report to the user the results of their computations. Such personal intelligent agents have recently attracted great interest [10]. Dynamic extensibility of distributed applications is required in numerous other scenarios. For example, consider a distributed manufacturing line where sensors collect data that must be analyzed to control the real-time operations of robots and manufacturing processes. The sensor processes act as servers rigidly programmed to provide certain data reports. If the analysis of this data is performed remotely from the sensors, an analysis process would need to retrieve and process this data in real-time. A more e ective approach is to dispatch the analysis program to the sensors and execute it there. That is, extending the sensor server to provide real-time data analysis as needed by the speci c manufacturing control task. This paper introduces delegation agents technologies to support dynamic extensibility of distributed processes. An elastic process runtime environment provides a software \backplane" where delegated programs are loaded and execute as threads in a shared address space. It supports translation and dynamic linking of delegated code, a multithreaded execution environment, dynamic resource allocation, and interprocess communications. A Remote Delegation Protocol (rdp) provides mechanisms to delegate a program (agent) to a remote elastic process, link it with its runtime environment and execute it under local or remote control. Perhaps the simplest form of delegation agents is
This paper introduces a novel approach to distributed computing based on delegation-agents, and describes its applications to decentralize network management. Delegation agents are programs that can be dispatched to remote processes, dynamically linked and executed under local or remote control. Unlike scripted agents, delegation agent programs may be written in arbitrary languages, interpreted or compiled. They can thus be more broadly applied to handle such tasks as real-time monitoring, analysis and control of network resources. Distributed management by delegation (MbD) uses this to manage remote elements and domains. MbD provides a paradigm for distributed, exible, scalable and robust network management that overcomes the key limitations of current centralized management schemes.
1 Introduction Current distributed computing mechanisms involve a rigid Client/Server (C/S) paradigm that associates functionality with servers rigidly at their design time. A client can only invoke a xed set of prede ned services exported by each rigid server. These services remain constant until its interfaces are redesigned, and until the server is compiled, installed, and instantiated anew. Emerging networked systems often require servers that may be dynamically extended by remote applications. Consider for example the booking of a vacation over a future network connecting reservation databases of airlines, hotels, car-rentals and other companies. These heterogeneous databases were not designed to provide the type of access required to perform arbitrary vacation arrangements. The search process, for example, may require scanning through large databases subsets, contacting competing providers, 1
provided by scripts dispatched to a remote language interpreter. A remote execution mechanism permits an application to dispatch and sequentially execute a script at a remote interpreter. Such scripted agent mechanisms have been recently popularized by Telescript [12], a language to script network agents. Scripted agents, however, are limited in a number of ways. First, there are many applications, e.g., distributed real-time manufacturing control, where interpreted programs are inadequate. Second, servers are typically organized to support concurrent execution of services invoked by multiple clients. Concurrent execution of scripted agents is inecient as it require each agent to execute its own copy of the interpreter as a separate process. Alternatively, the scripting language and interpreter would have to be designed to permit multi-threaded execution. Third, scripted agents require the availability of a standard scripting language across multiple platforms with its corresponding support tools and environment. This paper pursues the design of technologies that permit agent programs to be developed in arbitrary interpreted or compiled languages. Instead of focusing on language-dependent agents, it suggests minimal extensions of run-time execution environments that permit any process to be organized as an elastic process and any program to be organized as a delegated agent. These programs can include personal agents, coded in C or C++ possibly with embeded SQL, that transact with remote databases. They may also include real-time programs to analyze manufacturing line sensor data. Moreover, one could delegate the very interpreter of languages such as Tcl [9] or Telescript to a remote environment and then delegate and execute scripts. Delegated agents are particularly useful in supporting a new paradigm for automated distributed management of networked systems. A typical network management system is organized as a two layer hierarchy, with a platform manager executing at a workstation and agents embedded within networked elements. Management agents are responsible for monitoring and controlling their devices, and collecting data in Management Information Bases (mibs). Management applications use a protocol (primarly snmp [2]), to retrieve mib data, and to direct the agents (e.g., how to handle fault scenarios). This data is displayed by the platform to support operations sta who are responsible to monitor, analyze and control the network. snmp agents are rigid servers that provide standardized access to operations data in mibs. The platform-centered paradigm is based on remote
polling of mib data and stretching control loops from network elements to a centralized platform and back. Current management systems pursue a platformcentered paradigm that separates applications from the data and services that they need. This centralized, labor-intensive management paradigm has been stretched to its limits by emerging large scale, complex, multi-domain networks. There is a growing need for new technologies that can automate and distribute management functions to accomplish scalable and robust operations. For example, a program that monitors and xes virtual circuits at an ATM switch must poll mib tables, analyze them at the platform and then set mib variables to activate the control xes. Both the data provided by a mib as well as the control functions that it supports are rigidly built-in at mib design time. The platform clients must poll and process large amounts of mib data (the virtual circuit mib table can include thousands of entries) at a fast pace. Delegation can be used to move management functions to the data rather than move data to these functions. For example, an agent can be delegated to the ATM switch to monitor and analyze the virtual-circuit tables and execute xes locally. This agent can access the mib data more eciently and reliably than a remote platform. It can be used to implement a local control loop, rather than stretch it over the network. The MbD paradigm provides an architecture for distributed automated management of networked systems of arbitrary scale and complexity. The rest of this paper is organized as follows. Section 2 introduces elastic processing, Section 3 presents some of the problems of network management systems, Section 4 describes MbD, Section 5 compares elastic processing with other related work, and Section 6 concludes.
2 Elastic Processing A process instance, f ; g, is an executing incarnation of a program, de ned by its program code , and its current state . is the program code that can invoke, including program fragments explicitly programmed for it, and imported library routines that are linked to it. consists of the set of threads f i g that execute as part of , and all the data associated with its address space. In a traditional C/S process interaction, a client process C remotely requests a service from a server process S . After such an interaction, the individ-
ual process states p may have changed, but p remains unchanged. An elastic process instance " f " ; " g, is an executing incarnation of a program that can be modi ed, extended and/or contracted during its execution.
2.1 Remote Delegation Protocol (rdp). rdp is an application-layer protocol used by delegators to transfer code to an elastic process and to control its execution. rdp supports the following action operators: Delegate (delete), instantiate (terminate), suspend (resume), getstate (setstate). For example, in a delegate process interaction a delegator process D can remotely request that a delegated program (DP) be incorporated by an elastic process " . Delegate("; DP ) :: f "g 7! f " [ DP g. Similarly, a remote process can cause the deletion of code previously delegated to an elastic process. Delete("; DP ) :: f "g 7! f " ? DP g. The instantiate service allows processes to remotely instantiate a new thread r from a previously delegated DP inside the address space of an elastic process. Instantiate(" ; DP ) :: f" g 7! f" [ DP g. The terminate service aborts an existing thread. Terminate("; DP ) :: f" g 7! f" ? DP g. rdp allows remote processes to exercise scheduling control to suspend and resume the r execution. rdp also supports communications between delegating processes and the r which they have created. The instantiated threads can establish bindings to exchange messages or to make calls to either the delegator, the elastic server, or other threads. Delegating processes can also obtain information about the execution state of these threads, and modify their state. An elastic server is an elastic process that exports a dynamically changing interface. This interface is a collection of service procedures, (s1 ; s2 ; ) that can be remotely invoked by its clients. Some of these si procedures could have been remotely delegated. A typical scenario of the basic use of delegation is shown in Figure 1. A delegator processes, D is transferring a delegated agent program (DA) to an elastic server (ES ). For example, D can be a manager process sending a monitoring program to an ATM switch as described in the Introduction. If DA is accepted by the elastic server at the switch, D receives a handle that can later be used to instantiate threads inside the environment of ES .
Delegation Protocol RPC Delegated Agent
Clients D DA
Elastic Server
Elastic Runtime
Elastic Process
C
ES
Figure 1: Delegating to an Elastic Server
2.2 Applications Elastic processing provides a framework for building interoperability in heterogeneous distributed systems. For example, a security monitoring application may need to analyze data which is encoded in different representation protocols, e.g., NDR, XDR, and BER. Providing xed support for all possible combinations of protocols will result in large additions of code, whether it will be used or not. An application gateways can be dynamically delegated into an executing monitoring server, augmenting it to support new data representation protocols as needed. For instance, if an application nds that a security attack is being performed using BER encoded packets (e.g., snmp packets), it may delegate to distributed monitoring servers a corresponding lter. Many distributed applications execute over hosts with insucient computing resources, such as small mobile devices and over low bandwidth networks such as phone lines or wireless connections. Elastic servers permit exible incorporation of functionality to handle computational resource availability. For instance, consider a high-bandwidth distributed application (e.g., a Web server) accessed over a low bandwidth wireless link. The server may delegate special compression algorithms to reduce the interaction bandwidth requirements when the contention is high. Consider a factory oor process control environment. Within a manufacturing line, a device agent may need to react to a fault in real time. If the logic to handle the fault is centralized in a client, the corrective action may miss deadlines due to unpredictable network delays. Elastic servers enable clients to delegate the instantiation of time critical functionality, reducing the need for interaction. Elasticity supports dynamic software upgrading without process shutdown. Designers of long lived
distributed applications can not anticipate all functional upgrades and customizations that will be required after their software has been installed at each site. Upgrading software typically requires shutting down processes and replacing them with newly compiled versions. In many cases, e.g., phone switches, the expenses of bringing the system down are substantial. Elastic servers enable software upgrades during execution without requiring rebooting. Elasticity is also useful to customize the services provided by a process, e.g., replace a given formatting algorithm by another, and to add speci c services, e.g., add a function to remind a naive user of certain features of the server. Delegation can also be used to add threads for debugging distributed applications [4], or to replace functions as they are being developed.
2.3 Performance Implications As seen from the above examples, delegation accomplishes signi cant performance improvements in bandwidth and latency for distributed applications. In the future, distributed applications that follow the traditional C/S interaction paradigm will spend an increasingly larger portion of their time waiting for remote responses. Indeed, traditional distributed computing paradigms do not scale well to environments where network delays are relatively long. As computers are getting faster, network latency is becoming the most signi cant bottleneck for distributed applications. Transmission delays in networks have latencies in the order of 10?7 to 10?3 seconds, which are bound by the network topology and the speed of light. The performance of microprocessors has been increasing at very fast pace1 . Distributed programs that follow the traditional client/server interaction paradigm will increasingly spend a larger portion of their time waiting for remote responses. For instance, a database client process executing on a fast processor that requests some data records from a remote database will often have to wait the time equivalent of 104 instructions waiting for the data to arrive. Performance imbalances such as these are often handled by caching mechanisms. Yet caching cannot properly support highly volatile distributed data. For instance, measurements from remote monitoring instruments change frequently making the cache inconsistent. Delegation supports an \inverse-caching" ap1 Workstations have been improving their SPEC benchmarks performance by an average yearly factor of 1.54 between 1987 and 1992 [6].
DPIs RDP
Delegation Backplane OS Portable Services Operating System
Figure 2: Elastic Process Runtime Layers proach, to move the applications closer to the location of their resources. Many factors contribute to the overall execution time of a distributed application. Thus a detailed model and analysis is complex and beyond the scope of this paper. Relevant factors include the relative cpu speeds of the interacting hosts, their current loads, their operating system overhead (e.g., context switching), the cost of marshalling and unmarshalling rpc parameters, and many others. Delegating a procedure to an elastic process can signi cantly decrease the overall performance overhead of communications. For example, consider a management procedure Mr which scans large ATM tables, as described in the Introduction. Delegating Mr to an elastic process to the ATM switch can signi cantly reduce the costs of each invocation of Mr . The overhead cost of delegating Mr is paid once, and is o set by the elimination of large table transfers.
2.4 Architecture of Elastic Processes This section outlines the software architecture of the runtime environment, which is organized in layers as shown in Figure 2. A more detailed description of its design and implementation can be found in [3]. The delegation backplane layer of the elastic process runtime provides support for rdp to store and access DPs, ensure that DPs are legal, and integrate them into the executing process. The underlying layer supports a portable common API for instantiation and remote control of delegated program instances (dpis), and communication between them and the external environment. The architecture de nes an execution environment which provides IPC, memory management, thread management, and I/O services, masking the under-
DPI
DPI DPI
Delegation Protocol
DPI
Controller
IPC
DPI
Repository
Translators
Manager
Dynamic Load Names Scheduler
DP Executables
Figure 3: Elastic Process Runtime Environment lying operating system services. The runtime protects concurrent accesses to critical regions, and traps and properly handles all asynchronous events and signals. For most of the operating system level services POSIX [7] semantics are assumed. Figure 3 depicts the internal structure of the runtime environment and the relationships between its main components, the Controller, Delegation Protocol, Repository, Translator, dpi-Manager, Name Service, IPC, and Scheduler. The Controller initializes the runtime environment, disposes of unused resources, and implements policies which are invariant for the lifetime of the process, such as for authentication or accounting. The Delegation Protocol component implements the rdp services. The Repository allows storing and retrieving of DPs from which the dpis can be instantiated. The Translator component ensures that a delegated DP is compliant program of a given language. DPs can be delegated in source code format, which may require compilation and dynamic linking (or interpretation), or as object code that requires only dynamic linking. If a DP violates any of a set of de ned rules for the given language of the program the translator will reject the DP. For example, an MbD elastic process agent supports a speci c subset of the C language which restricts DPs on their ability to bind to external functions. If a DP invokes an arbitrary external function, which is not listed in a prede ned set of allowed func-
tions then the DP is rejected. A language compliant DP is dynamically link-edited into the address space of the executing process. The lower layer of the runtime environment consists of several threads and shared libraries. The Scheduler provides a programmable, preemptive multitasking scheduling facility. The dpi manager allows to instantiate, kill, suspend, resume, retrieve, and modify information regarding the status of dpis. The IPC facility supports ecient asynchronous communications between dpisover shared memory. The I/O Controller provides services that allow threads to share access to I/O facilities, and the naming service provides a private mechanism to associate names with dpis.
3 Network Management Current management systems pursue a platformcentered paradigm that separates applications from the data and services that they need. An extended presentation of the problems induced by this paradigm can be found in [3]. The following is a brief outline of some of these management barriers, using snmp as a representative protocol. The discussion, however, is equally valid for cmip [13]. snmp's minimal requirements resulted in the rapid and ubiquitous deployment of its agents. Despite its success in allowing remote data access, however, snmp has not yet provided the ability to really manage an internet. For instance, to use the collected data to make automatic control decisions that proactively respond to network problems. Most management logic is performed in a central station on data collected from physically separated agents. For example, an snmp agent within a router collects information about trac and routing tables in a mib. A management application retrieves this data via snmp, and uses it to display a map of the network's topology and trac. snmp agents are rigid servers that provide data access capabilities to platform clients. Their mibs and services have been de ned at their design time, often by a standards organization. This interaction paradigm concentrates most processing into a single manager client, which often interacts with a large number of rigid agent servers. De ning rigid agents limits network manageability. For example, there is a limit on how many variables can be polled by a central platform and how often [1]. If data analysis is only conducted at the platform, it will require data access and processing rates that do not scale up for large and complex networks.
Because managers can only invoke agent services de ned in general purpose interfaces, many management procedures require a large number of micromanagement interactions. That is, central platform processes control the remote execution of management procedures by taking the agents through the steps themselves. Micromanagement occurs because management applications are unable to compose primitive management actions in a exible and ecient fashion. Management applications are therefore limited to trivial tasks such as mib browsing. Since platform centered management leads to high levels of platform-agent interactions, it results in ine ective and costly systems. Since functions are centralized into the platform, the manager station is most vulnerable, as even simple failures could load its bandwidth and cycles. If the manager is down or overloaded, local agents cannot accomplish recovery, because they must wait for instructions. Thus, even a minor malfunction may potentially lead to an avalanche breakdown of the entire management system. Alternatively, if agents are organized as elastic servers, applications to analyze mib data may be delegated to the devices, relieving polling and processing from the platform. Presently, and even more so in the future, the embedded resources that can (and should) be allocated to management exceed those assumed by the minimalist approach of snmp. For instance, network hubs often come equipped with risc microprocessors dedicate to support management functions. It is wasteful to limit their use just to move mib data, when they can also be used to process and analyze this data.
4 Management by Delegation MbD improves network manageability by dynamic distribution of intelligence to networked devices through the use of elastic processes as agents. Instead of bringing data from the devices to platform-based applications, parts of the management applications themselves are delegated to the devices. MbD seeks to address the above limitations of centralized management, and is orthogonal to the choice of methods to collect, organize and access managed data. Management processes can delegate to MbD agents the execution of management programs that can monitor and control local managed objects e ectively without unnecessarily involving the remote managers. An MbD agent is implemented as an elastic process whose role is a hybrid combination of a proxy agent
MbD Protocol
SNMP
SNMP
Interface
Interface Elastic Process Runtime Support
MIB
MIB Instrumentation Real Devices (a) SNMP Agent
Instrumentation Real Devices (b) MbD Extension of SNMP Agent
Figure 4: Extending A Network Management Agent and a hierarchical manager. It supports interfaces to the device operations, permitting access by delegated agents to local data and functions. These interfaces need not be standardized, nor do they have to be uniformly accessible to all delegated agent instances. MbD can inter-operate with and extend current network management protocols, thus standard management applications can also reap many of its bene ts. For instance, MbD can be used to dynamically extend the capabilities of an snmp agent. Figure 4 (a) shows an snmp agent, which includes an interface that supports the snmp protocol, the implementation of an mib, and the instrumentation to obtain data from real devices. Figure 4 (b) shows an MbD agent that augments the same snmp agent. Using the MbD agent, a manager process can dynamically delegate interfaces, mibs and instrumentation functions. For example, a network manager may delegate a procedure that implements ltering over an snmp mib. A manager process may dynamically delegate a ltering program which locally stores the ltered values in a mib table, which can then be retrieved in order by any snmp manager. This routine may later be invoked by the delegating manager and by other clients. MbD simpli es the handling of semantic heterogeneity across devices. Delegated management programs may be designed to handle the speci c operational environment and distinct features of speci c resources. They require neither a uniform semantic model of device data nor adaptation to di erent platform environments. For instance, delegated applications can automate management functions reducing the load on operations centers personnel. In networks where management communications bandwidth is scarce, device au-
tonomy may be increased. Management logic can be executed in close proximity to the managed devices, ensuring a much faster and reliable response in the event of faults. Applications can use MbD to exibly control the granularity of their manager-agent interactions, avoiding micromanagement. Developing e ective technologies to support compression of real-time management information is a central problem of network management. A health function [5] provides such ecient compression by combining managed data into a single index of network state. Health functions cannot be included as part of a static mib design, as they may vary from site to site and over time. Nor can they be usefully computed at centralized management platforms, since this can result in excessive polling rates, lead to errors due to perturbations introduced by polling, and miss the goal of compressing data at their source. MbD can support exible and e ective evaluation of health functions and linear threshold decisions at devices. For example, a delegated program in a hub can check the status of a port and disconnect it when its load exceeds a threshold designated by the delegator. Use of MbD enables devices to acquire autonomous management capabilities. For example, when communications are lost with managing entities, a device may activate management programs that provide it with pre-de ned management instructions for autonomous operation. Several other examples of the application of MbD to management problems are described in [8].
5 Related Work Remote evaluation, rev [11], allows a program expression to be transferred from a client computer to a server computer. The server host interpreter evaluates it and the results are returned to the client. rev overcomes the problem of xing all the server procedures that can be invoked remotely at the design time of the server. However, the execution of the evaluated program is synchronous with the invocation by the caller, and the rev client has no control over its execution. For example, it may not cancel the evaluation of a long computation. rev's design and implementation is programming language and machine speci c. That is, programs can be exchanged only between computers
of the same architecture that support the same language environment. Delegation to an elastic server is a process-toprocess communication, while rev is a computer-tocomputer communication. A delegated procedure becomes an integral part of the receiving server, so that it has access to the process global scope and external environment. Invocations of delegated procedures may result in independent threads executing inside the elastic process. rev goes a step further than synchronous rpc in permitting the dynamic transfer of programs to remote execution. However, both rpc and rev models involve synchronous interactions whereby the agent executes the management program upon invocation. Then, the caller is blocked until the completion of the invocation, and/or it can not exercise any control over it. Thus neither rpc nor rev are adequate mechanisms for distributed management. General Magic's \Remote Programming" [12] requires using a specialized language, Telescript to construct agents which are transferred to remote interpreters for execution. In contrast, delegation provides a language-independent approach for programming agents, allowing programmers to reuse existing code and tools. Indeed, one can take any program and with minimal modi cations turn it into a delegated agent. One can even delegate an interpreter for an arbitrary language and then delegate scripts to it. Many tasks cannot be e ectively handled by an interpreted language. For example, operations management often involves real-time tasks. Telescript has no support for transactions, synchronization, or realtime actions. Telescript agents can not directly examine or modify the physical resources of the computers on which they execute. Telescript requires a reliable transport protocol between interpreters. This is not acceptable for many network management applications that need to operate over unreliable transports, i.e., when connections are lost. These limitations eliminate it as a potential candidate for the applications which require such facilities. Delegation agents can be eciently linked and executed as integral components of a remote process environment. Elastic processing provides a minimal extension of that environment, which allows delegated agents tailored access to the facilities that they need. rdp permits e ective control of agent execution, and does not require a reliable transport. Telescript agents need to explicitly negotiate security permits when they move, following a \one-size- tall" security policy. Similar issues and problems apply
to accounting and reliability. In contrast, delegation provides remote execution control over agents and enables them to have customized security services. Telescript agents can only \extend the functionality
of communication services to which they have access, provided those services are implemented using Telescript technology" [12]. Remote delegation to elastic processes
was designed to interact with other communication services, such as network management protocols.
6 Conclusions The traditional C/S interaction model enforces a rigid association of function with servers, that often results in an abnormal distribution of functionality between clients and servers. The concentration and centralization of application logic results in inecient and unreliable distributed systems. As computing processing and network bandwidth are becoming abundant, faster and cheaper, latency becomes the most critical performance problem for distributed applications. Rigid C/S distributed computing does not scale well to environments where network delays are relatively long compared with their local computations. Elasticity provides an e ective way to overcome network delays, by taking advantage of cpu cycles and bandwidth to move computations closer to the resources that they need to access. Remote delegation to an elastic process is the inverse of data caching, that is, moving code closer to the data that it needs. Current management systems pursue a platformcentered paradigm which is unscalable, introduces micro-management, exposes the semantic heterogeneity of devices, and re ects obsolete performance tradeo s. An MbD agent's dynamicity permits applications to con gure their processes and allows exible distribution of management responsibilities in a distributed environment. Thus it addresses the fundamental limitations of platform-centered management. An MbD prototype was implemented, and several applications were written to demonstrate its capabilities. A commercial version developed by a startup company is currently being used by several sites as a platform to develop management applications.
References [1] A. Ben-Artzi, A. Chadna, and U. Warrier. Network Management of TCP/IP Networks: Present
[2]
[3] [4]
[5]
[6]
[7] [8]
[9] [10] [11]
[12] [13]
and Future. IEEE Network Magazine, July 1990. Je rey D. Case, Mark S. Fedor, Martin L. Scho stall, and James R. Davin. A Simple Network Management Protocol (SNMP). RFC 1157, May 1990. German Goldszmidt. Distributed Management by Delegation. PhD thesis, Columbia University, New York, NY, 1995. In preparation. German Goldszmidt, Shmuel Katz, and Shaula Yemini. High Level Language Debugging for Concurrent Programs. ACM Transactions on Computer Systems, 8(4):311{336, November 1990. German Goldszmidt and Yechiam Yemini. Evaluating Management Decisions via Delegation. In The Third International Symposium on Integrated Network Management, San Francisco, CA, April 1993. John L. Hennessy and David A. Patterson. Computer Organization and Design The Hardware / Software Interface. Morgan Kaufmann Publishers, 1994. Donald Lewine. POSIX Programmer's Guide. O'Reilly & Associates, Inc., 1991. Kraig Meyer, Mike Erlinger, Joe Betser, Carl Sunshine, German Goldszmidt, and Yechiam Yemini. Decentralizing Control and Intelligence in Network Management. In The Fourth International Symposium on Integrated Network Management, May 1995. John K. Ousterhout. Tcl: An Embeddable Command Language. In Proceedings of the 1990 Winter USENIX Conference, 1990. Doug Riecken. Intelligent Agents. Communications of the ACM, 37(7):18{21, July 1994. James W. Stamos and David K. Gi ord. Remote Evaluation. ACM Transactions on Programming Languages and Systems, 12(4):537{565, October 1990. James E. White. Telescript Technology: The Foundation for the Electronic Marketplace, 1994. General Magic White Paper. Yechiam Yemini. The OSI Network Management Model. IEEE Communications Magazine, pages 20{29, May 1993.
