Standardizing Agent Technology

Transcription

1 Standardizing Agent Technology Sankar Virdhagriswaran CRYSTALIZ, INC. Damian Osisek and Pat O Connor IBM NETWORKING SOFTWARE DIVISION, IBM Agent technology is being explored as the basis of a whole new generation of information systems. Efforts based on agent technology range from building massively distributed information systems (over the Internet and WWW) to building mobile information systems, intelligent workflow systems, and agile corporation information infrastructure. Because agent technology has such a wide-ranging impact, it is important to standardize architectures, mechanisms, and protocols. Development of agent related standards commenced in the late 1980s, with a focus on knowledge sharing. In the recent past, the agent field has broadened considerably to include workflow systems, mobile agents, World Wide Web-based information discovery systems, and electronic commerce systems. This article presents an overview of the history and current state of standardization with a focus on Object Management Group efforts. I nterest is mounting rapidly in agent technology. As wide-area information services have become widespread, the use of agents to delegate tasks has caught the interest of developers. Second, because the new generation information services have to integrate existing legacy systems, the use of agent technology to wrap them has also garnered the interest of developers. Third, because traditional, synchronous, connection-oriented distributed computing infrastructures are inadequate for the highly unreliable, bandwidth-limited networking environment present in mobile computing, efforts are under way to use agent technology to build distributed mobile information systems. Finally, as groupware systems become widespread, the use of agents to automate tasks, to represent organizational roles (e.g., receptionists), and to represent organizational knowledge is also becoming commonplace. It is clear from these efforts that agent technology actually refers to an umbrella term that covers a whole range, including technologies and design paradigms. In this it shares the same advantages and disadvantages as the object technology, multimedia, and graphical user interface areas. How important is it to standardize agent technology, given the state of the technology? Because distributed interoperation between products developed with agent technology is essential for widespread adoption of this technology, standardizing architectures, mechanisms, and protocols is essential. In addition, a good time to introduce standards is in the early stages of market penetration of a technology rather than later. Recognizing these needs, several companies are collaborating under the auspices of the Object Management Group (OMG) standardization process. This effort is focused on standardization that is required to make products developed with agent technology work together. Hence the initial focus is on the interaction aspects of agent technology. In this article we present the current state of that process. First, we explain the motivation by providing a historical overview of agent technology development and the current state of practice. This is followed by a presen- 96 StandardView Vol. 3, No. 3, September/1995

2 Because distributed interoperation between products developed with agent technology is essential... standardizing architectures, mechanisms, and protocols is essential. tation of a straw man reference model being developed to help standardize the technology and a comparison of existing agent technology-based products against this reference model. Finally, we present the status of the standardization process at OMG. Historical Overview Agent technology has been evolving in the marketplace since artificial intelligence (AI) technologies hit the marketplace in the early 1980s. At that time, agent technology was used in two different domains. System vendors such as Apple Computer, Inc. and Hewlett-Packard Company concentrated on using agent technology to automate repetitious user tasks. Also, knowledge-based system vendors implemented expert system agents that automated the domain expert by capturing and representing the expert s domain knowledge. These agents never interoperated with each other. The late 1980s saw a major effort funded by ARPA to develop knowledge-sharing standards. This effort, called the Knowledge-Sharing Initiative, was targeted at knowledge-based system interoperation. In addition, because distributed interoperation was becoming commonplace, this effort looked at knowledge sharing in the context of distributed infrastructures. Particular attention was paid to the concept of autonomous interoperation in order to support massive distribution of components that shared knowledge. This technology was extended during the early 1990s to support wrapping of existing legacy applications and interoperation between them. Interoperation is achieved by understanding the capabilities of legacy applications at a high semantic level and synthesizing new applications using knowledge of these capabilities. A language and protocol called Knowledge Query Manipulation Language (KQML) to support interoperation between knowledge-based systems was developed in this effort. KQML made several key contributions in the area of interaction between agents, including: a protocol that was defined as a language, thereby supporting extensibility within a semantic framework; a protocol that assumed asynchronous connectionless interoperation (as compared to RPCs and ORBs, which assume a synchronous interoperation); a set of message types that supported sending and receiving of programs (mobile code) asynchronously; a set of message types that supported brokering of mobile programs, given the capabilities of servers that would evaluate the programs; and a set of messages that allowed wide-area deployment of many servers by supporting a distributed directory service. The early 1990s saw agent technology bloom in several directions in addition to knowledge sharing. First, system vendors such as Apple Computer and Microsoft Corporation committed themselves to support the component software market by providing underlying technology to create components. In this architecture, applications are made up of components whose interfaces are described using facilities provided by the platform vendors. Users create custom agents by combining components using scripts that are executed by interpreters. These agents would contain domain-specific expertise (e.g., financial planning) and would use the services of the components (e.g., text formatting, equation solving) to perform some of the actions. Second, the Internet community and General Magic, Inc. independently started exploring the use of programs that can be shipped across a network to support the notion of traveling agents. General Magic s Telescript supports sending program segments with local state to remote machines and receiving responses asynchronously. Several languages including Scheme-48 from MIT, Safe TcL, and others are being offered to the WWW community to support agent shipping. Most recently Andersen Consulting, Stanford University, and their partners are exploring the use of agent technology to support electronic commerce. Another direction in mobile code is being pursued by Sun Microsystems Inc. and their partners. They have developed the Java language, which can be used in combination with the Hyper-Text Markup Language (HTML) used in WWW. With the added power provided by Java, publishers can send animation encoded as programs to WWW browsers that can interpret the Java language. Third, intelligent help agents that correct user s mistakes and assist them by providing context-sensitive help were also developed during this time. Fourth, groupware vendors started exploring the use of agents to automate organizational roles and encapsulate organizational knowledge. These vendors offered the capability to develop agents that act as receptionists and help in meeting scheduling, or agents that automate the routing and merging of workflow. StandardView Vol. 3, No. 3, September/

3 Considering that all these activities are varied in nature, is it possible to think about developing standards for agent technology? Fortunately, this type of problem is not new. We can learn from successful efforts in other areas. For example, before the OMG s Object Management Architecture (OMA) was widely adopted, various competing efforts, investigating overlapping aspects of distributed object-oriented technology, were being conducted by system vendors, universities, and others. The OMA provided a reference model within which these efforts could be rationalized. The object management group is launching such an effort in the context of the Common Facilities Task Force. As part of this effort, a straw man reference model has been developed to provide an architecture under which the agent technology can be standardized. The next section describes the reference model. Reference Model The reference model for agent technology is described in terms of entities that make up the model and ways in which their relationships are supported. The entities are agents and agencies. The relationship involves their interaction models and control of their interaction through policies. Agents are programs that contain knowledge in order to perform one or many tasks. These tasks may have been delegated to them (e.g., personal valet) or the agents may undertake the tasks autonomously (e.g., expert systems). This knowledge may be represented procedurally or declaratively. The primary role of an agency is to be the place in which agents perform their function. In order to perform this role, agencies provide an execution engine for agents. In addition, they may contain policies that are used to represent active behavior by the agencies. Three types of interactions are possible between agents and agencies: agents can interact with other agents; agents can interact with agencies; and agencies can interact with other agencies. Policies are used to manage and control the interactions. AGENTS Properties of agents can be grouped along certain dimensions in the context of the interactions previously defined. The first is their capability, which can vary from simple task execution to inferencing, planning, learning, pattern matching, the ability to create progeny, and so on. The second is the type of interactions agents can have with other agents and agencies by exchanging data, information (data plus metadata), other agents, or application-specific semantic requests (e.g., closed bid). Agents interact with agencies by using the agencies as execution engines. All these interactions may be synchronous or asynchronous. The last axis is the type of movement agents can have: they may be static, mobile without carrying local state of execution, and mobile carrying local state of execution. AGENCIES Agencies are also characterized by their capabilities and the type of interactions they can have with agents and other agencies. A primary capability of an agency is to be the execution engine for agents. Although recent activity in agent technology has focused on interpretive languages, we do not limit the execution engine of an agency to be an interpreter. We use the broader notion that agencies are places where agents perform their functions. The important capabilities of agencies with respect to supporting agent technology are: support for simultaneous and concurrent execution of many agents; support for security; integration with system services such as data exchange; support for allowing agents to carry their state with them as they move; and support for externalization and serialization of state information in a way that can be understood by agencies. Interactions between agents and agencies and between agencies and agencies are different in nature. As described earlier, agencies are the place for agents to perform their functions. Because agencies are active entities in themselves, they can implement different policies on the functioning of agents in their execution engines. Next, agency-to-agency interaction can happen at different levels of complexity. At the simplest level, an agency may use the services of another using remote evaluation. At the next level, it may communicate with a group of agencies, one of which may handle the request for remote evaluation. A third level is to use an intermediary to discover and broker an agency based on the semantics of the request (i.e., a directory service). In order to support these types of interactions, the encoding of the agent programs as they are shipped around the network needs to be a well-understood and public protocol. Agencies may also be grouped in different ways. Several agencies may be part of a group where one member of the agency plays the role of a receptionist. Furthermore, agencies may be nested within other agencies. Finally, a virtual network of agencies is also possible. INTERACTION MODEL From the preceding descriptions, it is clear that agencies and agents can have complex interaction patterns. For example, the interaction between agencies and agents can be 1 to 1, 1 to n, or n to n. In addition, agencies can be distributed across networks, and a virtual network of these agencies can be set up (e.g., to support that 1 to n interaction style). Further- 98 StandardView Vol. 3, No. 3, September/1995

4 more, brokered interaction between agencies may also take place. Finally, the interactions can be synchronous or asynchronous. However, not all agencies or agents will need to support all these interactions. Therefore, the reference model specifies a rationalized model of interaction in order to support smooth integration among various agents and agencies in a wide area or local area networked infrastructure. The interaction between agencies and/or agents can be organized along the following nonorthogonal dimensions: (1) type of interaction, (2) cardinality of interaction, (3) role of intermediary, and (4) dialogue management. Type of interaction refers to the paradigm used by the agencies or agents to interact with each other. The most popularly available interaction paradigms are: (1) synchronous connection-oriented (e.g., a oneon-one conversation between two agents or agencies); (2) asynchronous connection-oriented (e.g., interaction of monitoring agencies); and (3) asynchronous connectionless (e.g., when the other agency is time and connection dependent). Cardinality of interaction refers to whether one entity is interacting with another (1 to 1), one entity is interacting with a group (1 to n), or a group is interacting with another group (n to n). The third dimension along which interactions between agents or agencies can be partitioned is whether an intermediary is used to broker, facilitate, or mediate the interactions. A broker provides separation between a reference held by a consumer and the provider of the reference. A broker locates a provider at the time of invocation by a consumer. If the provider is unavailable, then an error is returned to the consumer. A facilitator adds more in terms of the content of the request to be processed and in terms of supporting a more dynamic configuration of providers. When a facilitator is used, the consumer does not have a direct reference to the provider. The consumer asks the facilitator for a reference at the time of invocation. Because the facilitator understands some key characteristics of the request (excluding its contents) such as the language of the request or the vocabulary needed to process the request, it can locate the appropriate provider of the service. Furthermore, providers can register and deregister with a facilitator dynamically. Therefore, the facilitator will provide the reference to the currently available and most appropriate provider who can service the request. A mediator adds more to a facilitator in terms of understanding the semantics of the request. Because a mediator can process the semantics of a request, it can perform fine-grained selection of providers and semantic unification of responses. Dialogue management refers to the control of interaction between agents or agencies such that the goal of that particular interaction session is met. This can range from flow control to session management to transactions. POLICIES Policies can be defined in terms of the agent, the agency, or their interactions. Examples of agent policies are responsiveness (an agent guarantees that it will eventually respond to every received request for which a response is expected), parsimony (an agent will respond with the most optimal response), verboseness (an agent will respond with all possible responses), and so on. Agencies may implement agency-wide policy without regard to visiting agents or to interaction with other agencies. These policies often involve controlling resource allocation, information dissemination, and the like. Interaction policies control the type of interaction that agents and agencies can have with each other. Some example interaction policies are conditions under which: synchronous vs. asynchronous type of interaction will be supported by agencies; agencies will host traveling agents; remote evaluation will be supported by an agency; group-based interaction will be used; and facilitation will be performed by agencies for other agencies. Comparison In order to make this reference model concrete and to show that various agents and agencies today vary in their capabilities and interaction models, a comparison is presented in Tables One and Two. These agents and agencies were selected based on their familiarity to the authors. The key objective of this section is to show that a rationalized reference model can assist in developing standards for agent technology interoperation. BargainFinder 1 is a shopping agent developed by Andersen Consulting. Based on a high-level request from a user for a CD album, it queries participating stores and selects the store with the best price. Dynamo 2 is a concurrent engineering system where many agents are used to support collaborative development of electromechanical products. Dynamo is being developed at Crystaliz Inc. Finally, we also pre- 1 Information on BargainFinder can be found at 2 For more information on Dynamo, contact Crystaliz Inc., 696 Virginia Road, Concord, MA StandardView Vol. 3, No. 3, September/

5 Table One Properties Bargain Dynamo WorkGroup Finder Agent Task execution X X X Inferencing X X Learning Planning X Pattern-matching X Data exchange X X X Information exchange X Agent to agent high-level requests X X X Static X X X Mobile without state X Mobile with state Table Two Properties LogicWare Telescript Carnot Concurrency X X X Integration with system services X X Mobile closures X Externalization & internalization of state X X Interaction protocol X X Remote evaluation X X X Group oriented interaction (1 to n) X Brokered interaction X Networked X X X sent a product that integrates agent functionality with workgroup systems. The IBM WorkGroup Agent 3 facility is knowledgeable about user profiles, communication concepts, etc., supported by the IBM Work- Group product. Users can delegate communication and collaboration tasks to their agent. The agencies compared in Table Two include LogicWare 4 from Crystaliz Inc., Telescript 5 from General Magic, and the Carnot system [Singh and Huhns 1994] from Micro-Electronics and Computer Corporation. LogicWare is made up of a language subsystem, an agent interaction control subsystem, and gateways to system and information resources. The language, called SIMPLE, is an interpreted, procedural programming language based on MIT Scheme with extensions to support object-oriented programming and forward and backward chaining rules. The agent interaction facility is based on KQML, which was presented in the historical overview section. Several gateways including the interapplication communication gateway, database gateway, and so on are also part of LogicWare. Telescript from General Magic is an object-oriented language. A key feature of Telescript is the ability to ship in-progress program segments with their execution state around the network. Carnot is a research prototype. It is a flexible framework from which knowledge-based workflow systems can be developed. It provides an execution environment that uses AI-based techniques such as rules-based knowledge representation and truth maintenance techniques to support distributed agent execution. Many of the existing agents and agencies were developed without taking interoperation into consideration. In order to address this problem, a number of companies and research institutions are involved in 3 More information on IBM WorkGroup and WorkGroup Agent can be found at This and other IBM agent efforts are described in Atkinson et al. [1995]. 4 For more information on LogicWare contact Crystaliz Inc., 696 Virginia Road, Concord, MA More information on Telescript and General Magic can be found at developing standards for agent technology in the context of the preceding reference model. This activity is being conducted in response to a solicitation from OMG for standard specifications in this area. Currently, many of the services specified in the context of OMA provide a rationalized foundation that can be used by agents and agencies. In addition, these system services will be widely available on many platforms. Therefore, standardizing agent technology in the context of OMA provides, in many instances, a quick way for leveraging these capabilities without having to reinvent the wheel. The WWW community is also involved in discussing agents and related standards. There, several different languages have been proposed as a way to support mobile agents. These languages typically come in one integrated piece without the separations made in the reference model. 6 OMG STANDARDIZATION At OMG, agent technology standardization is part of a larger collection addressing task automation, an area within Common Facilities Architecture [Object Management Group 1995] of the OMA [Object Management Group 1993]. Task automation is made up of: (1) scripting, (2) automation, (3) rules management, (4) workflow, and (5) agent. The scripting facility refers to procedural interpretive languages. It is assumed that scripting languages interact with other OMA services and facilities. Automation refers to the facility that supports accessing of applications from the scripting or rules management facility. The key difference between an automation facility and an Object Request Broker (ORB) is that the objects accessed through the au- 6 For more information please refer to MobileCode/. 100 StandardView Vol. 3, No. 3, September/1995

6 tomation facility are typically large-grained objects within applications (e.g., a worksheet in a spreadsheet program) and the actions performed with those objects are semantically meaningful in the context of the application (e.g., evaluation of a spreadsheet formula). Also, an automation facility may provide support for scripting and rules for language processors to bind application data types and provide support for the compiling of scripts. The rules management facility refers to knowledge representation systems that support forward and backward chaining rules and other inferencing mechanisms. The workflow facility refers to systems that support modeling of organizations, their processes, and flow of work between different entities in the organizations. The agent facility maps to the agency entity described in the reference model. The agent facility will address the requirements for being an execution engine for agents as well as support for interaction between agencies. In addition, it is expected that the agent facility will use facilities presented here and other OMA facilities (e.g., compound document) to perform its function. Finally, the agent facility is expected to use services such as security, messaging, transactions, event service, naming, externalization, concurrency, and so on, of the OMA. Summary This article presents the history and current status of standardization of agent technology. In order to rationalize various agent technology efforts, the standardization activity is developing a reference model and is attempting to fit various components that make up the agent technology into the reference model. The standardization effort is currently being conducted under the auspices of the Object Management Group. We invite interested parties to contact the authors or OMG to find out more about the status of this activity. sv References ATKINSON, B.A. ET AL IBM intelligent agents. In Seminar: Agent Software: Proceedings (April 25 26), UNICOM Seminars, Ltd., OBJECT MANAGEMENT GROUP Object Management Architecture. Framingham, MA. OBJECT MANAGEMENT GROUP Common Facilities Architecture Document. Framingham, MA. SINGH, M.P. AND HUHNS, M.H Automating workflows for service order processing: Integrating AI and database technologies, IEEE Expert (Oct.). Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission ACM /95/ $3.50 StandardView Vol. 3, No. 3, September/