Crystaliz Inc. Dr. Tom Mowbray Chairman, Common Facilities Task Force Object Management Group 492 Old Connecticut Path Framingham, MA 01701 Dear Dr. Mowbray: Here with I have enclosed the RFI submission for agent facilities. If you have any questions, please do not hesitate to contact me at 508 287 4511 or through email sankar@fcrao1.phast.umass.edu. I am new to the process of RFIs and RFPs of OMG, therefore any guidance you offer would be valuable. Thank you. Sincerely, Sankar Virdhagriswaran President enclosure: RFI response Response to RFI on Common Facilities - Common Intelligent Agent Services Specification (CIASS) This document is a response to the Request For Information (RFI) from the Object Management Group (OMG) in the area of Common Facilities. This document describes services for facilitating development of an agent oriented application infrastructure. The agent infrastructure is made up of Static Agents and Mobile Agents. Static Agents communicate with each other through mobile agents. Static Agents may themselves solve some problem (e.g. a mail sorting agent) or may be "wrapped" around existing application to provide new functionality (e.g. reservation agent that is "wrapped" around a flight schedule database system). Mobile agents represent the "intelligent message" concept. They are similar to mail messages. As such they may contain data, programs, procedure calls, query scripts, etc. In addition, they also contain administrative information to be used by static agents. Agent infrastructure will address a number of end user and developer problems in the emerging information highway. First, agents off-load book-keeping and cognitive loads from the end user1. Second, static agents can make it possible for existing legacy applications to be "face-lifted" with more capability2. This approach not only makes possible integration of legacy systems, but also allows development of large systems in an asynchronous and staged manner. Third, agent infrastructure can support mobile computing3 and dynamic configuration of operational systems used in military and civilian applications4. Agent infrastructure layers higher level semantics and dynamic, behavior based interaction on top of OMG's object based services. In addition, agent infrastructure supports interaction of mobile computing devices with land based computing devices. These functionalities are supported through a logical architecture that modularizes and separates the specification of services for the mobile and static agents. First, the services are modularized by grouping them as services that mobile agents offer and services that static agents offer. Second, within each of these modular specifications, services are layered. We describe those services in the next section. Service Description and Requirements - Mobile Agents The services of mobile agents are layered to support inter-operability between various types of static agents. First, in order to support integration of legacy applications into an agent network, the mobile agents provide a content service. The content service separates the specific content in the mobile agent from other networking and communication information that may accompany it. Applications attached to static agents usually deal only with the content. Second, it order to support peer to peer, asynchronous communication between static agents, mobile agents provide communication services. Finally, mobile agents also contain instructions and administrative information through the message service. Content service Mobile Agents provide a way for sending and receiving contents that are either processed by static agents or (usually) processed by other applications attached to the static agent. The content can be in ASCII or binary format. For example, a content in a mobile agent may be an SQL query (in ASCII) or a bitmap image to be analyzed. Communication service The communication service allows the mobile agent to identify the sender (a static or mobile agent), receiver (another static or mobile agent), and the mobile agent itself. These identification features support true asynchronous, peer to peer communication between static agents. Message service Since static agents may not wish to understand the contents of a mobile agent (in cases where the content is to be dealt with by an application attached to the static agent), the message service supports a way for the mobile agent to tell the static agent An action to perform (a performative - e.g. query, assert, etc.), and An optional service to describe the language of the content and the set of words used in that language (its data dictionary) The static agent will use this information to perform the correct meta level action. For example, a meta level action may be to invoke the services of the application attached to the static agent through CORBA messages. Another maybe to update the advertisement registry of CORBA. Service Description and Requirements - Static Agents In this section, we describe static agent services under two categories: Basic and Extension. Basic services are supported by all static agents. On the other hand, extensions are supported by agents performing various roles and need not be supported by all static agents. Static Agent's role is to process the performative in an mobile agent. The static agent keeps two types of information in its database: Its capabilities and services that it supports (information) Capabilities and services that have been assigned to it by other agents (goal) The static agent services are designed to support multiple conductivity, architectural, and communication choices that can be made by application developers. The static agent services support point to point conductivity, multi-casting conductivity, and broadcast type conductivity where the number of receivers is not known. Static agents can be accessed by other agents using explicit addressing (e.g. internet domain addressing scheme), symbolic addressing (e.g. OMG-KQML-AGENT), or using declarative addressing (e.g. agent most suited to dealing with queries on OMG's publications). Agent services can be implemented using blocking schemes (i.e. synchronous) or using non-blocking schemes (i.e. non synchronous). Finally, all static agents on a network maybe assumed to be known at boot-strap time by a static agent or the static agent may support dynamic addition and deletion of static agents on the network. The basic static agent services are designed to support an ordered model of interaction between static agents: Establish communication context by asserting and discovering the types of interaction that can be fruitfully had between the communicating agents. The basic information services support this need. Once context is established, query and respond to queries. Static agents may want to control this interaction. Basic and advanced query services, generation services, and assertion services address this step. In a complex architecture with multi-casting, point to point communication, etc. static agents may use the services of facilitators, routers, etc. Capability definition, Networking, and facilitation services support this need. Finally, a number of services are provided to support problems that happen in a dynamic architecture. These include database services, error correction services, etc. The services are described in-terms of types of performatives they deal with: Information services: Simple Query services Multi-response Query services Assertion services Generation services Capability definition services Notification services Networking services Facilitation services Database services Adaptation services (rate, interface, etc.) Error correction services Automatic re-transmission services Resource management services Interface services (stubs) Registration services (home and visitor) Security services Management services Services (1) through (7) are expected off of all static agents. Services (8) through (18) are extension services. Basic information services The static agent supports performatives that can be used to inform other static agents the contents of its information base. The static agents can tell that an information element is present in its information base, can deny , or untell when it denies an earlier tell. Simple Query services Second, an static agent supports the notion of responding to queries with only one answer (instead of a series of them). The server can be used to evaluate a query and simplify it; can be asked to reply to a query; can be ask(ed)-if the content in the mobile agent matches any of the items kept in the server's information base; can be ask(ed)-about all the items that matched the mobile agent's content; return the first set of schema variables of the static agent information base that matched the content of the mobile agent through ask-one; return all the schema variables of the static agent information base that matched the content of the mobile agent content; and return non completion status through sorry. Multi-response Query services Third, a static agent can return responses as a stream which when taken together make up the response. It can stream-about all the matches or stream-all the schema variables that matched. Assertion services Fourth, an static agent can be asked to achieve (make true) the contents of a mobile agent. Additionally, it can also be asked to unachieve (make un-true) the contents of an mobile agent. Generation services Fifth, static agents support performatives to deal with multiple responses. An static agent can ask another to standby after collecting the responses to a performative. Additionally, a server can be ready to respond to deal with requests for responses to a performative. Further, a server can be asked to send the next response or the rest. It can also be asked to discard responses that have been collected for a performative. Finally, a server can be asked to process a generator. Capability definition services Seventh, static agents can advertise their suitability to respond to particular performatives. Notification services Eighth, Static Agents can be used to notify other static agents to perform some function for them. Static Agents can subscribe to changes in response to a performative. Additionally, static agents can monitor other static agents. Networking services Ninth, static agents can network other static agents. They do this by register(ing) themselves and unregister(ing) with other static agents or by asking a responding server to forward performatives or by broadcast(ing) performatives with all the registered servers (multi-casting). Additionally, they can establish a pipe so that any performative coming to a static agent will go to the static agent piped to it. Finally, static agents can also break a pipe. Facilitation services Tenth, static agents can broker(one and all) other agents to respond to a performative. Additionally, they can recommend (one and all) other agents who are well suited for dealing with a performative and can recruit (one and all) other agents to deal with a performative. The static agent will forward all the performatives that the recruited agents are suited to processing to the recruited agent(s). Database services Eleventh, database services are provided to deal with agents that may not understand the notion of truth values. Insert adds the content of the mobile agent to the information base of an static agent. Delete removes the content of an mobile agent from the information base of an static agent. Adaptation services (rate, interface, etc.) Static Agents can use adaptation performatives to deal with different through put support provided by the underlying transport layers (e.g. SLIP vs. 100 MBit ethernet TCP/IP) and to deal with differing frame size requirements of the application (e.g. video data vs. SQL queries). Error correction services Static Agents can be instructed to adopt different error correction strategies for different types of mobile agents and different networking architectures. Automatic re-transmission services Static Agents can be asked a-priori or on demand to re-transmit responses to performatives. Along with the error correction service, this service supports agent communication with mobile receivers over land line and cellular networks. Registration service (home and visitor) Static Agents will support repositories that can be used by mobile agents to declare their home, current location, and their destination. This information will be used by the static agents to facilitate the appropriate mix of resources to address the needs of the mobile agents. Security services Static Agents support two different services for security. First, static agents can be asked to encrypt responses. Second, static agents will use the Registration Service to control the type of access mobile agents can have to computing resources. Management services Static agents may need to be managed as a computing resource by network administrators. Static agents will provide performatives to be managed by network managers (or software tools used by them). Roadmap We propose the following road map in the agent services development: Step 1: Request for Proposals (RFP) 1 for CIASS 1 - services (1) through (6) Step 2: RFP 2 for CIASS 2 - services (7) through (10) Step 3: RFP 3 for CIASS 3 - services (11) through (17) Related Standards and References Since mobile agents can contain various types of contents, the technical reference to cover those content languages can be extensive. Therefore, we have left those references out. However, we can produce a list, if there is a need. In the following, we have included the references that provide more background material on which this response is based. Agent Communication Language Specification: Agent Communication Language: "Knowledge Query Manipulation Language (KQML) Draft Specification", Draft, June 1993. Gio Widerhold, et. al., ARPA Knowledge Sharing Initiative - available via ftp from ftp.cs.umbc.edu in pub/kqml/kqml-spec.ps Background articles: "Software Agents", Mike Geneserth, Steven P. Ketchpel, Communications of the ACM, July 1994. "KQML - A Language and Protocol for Knowledge and Information Exchange", Tim Finin, et. al., Technical Report CS-94-02, Computer Science Department, University of Maryland, Baltimore. Available via ftp from ftp.cs.umbc.edu at /pub/kqml/kbks.htm and associated .gif files. Relationship to other Object Services, CORBA, and the OMG Object Model The services described above were based on an agent communication language and protocol called Knowledge Query Manipulation Language (KQML). In the following sub-sections, we assume KQML to provide detailed responses. However, the answer will also apply to other agent communication language and protocol that support the services described above. Possible interactions with (or relationship to) COSS-1 Event handling KQML servers (static agents) will be able to use the event handling facilities specified in COSS-1. Since the model of communication assumed in a KQML server is asynchronous, it will be able to use the services provided by the event handler. However, the KQML server will declare its own specialization of the events and event channels specified in COSS-1. KQML servers need to be implemented as UN-typed event channel objects. Naming and Object creation Static Agents nor mobile agents make any assumptions about naming or life cycle of objects. Therefore, they will be able to use naming and life cycle services of COSS-1. Possible interactions with (or relationship to) COSS-2, etc. This section contains speculations on how CIASS will interact with other proposed services offered by COSS that is not part of COSS-1. Since COSS-1 is the only stable portion of COSS, these ideas may change. Services that CAISS will use (without major extensions) Archive, Backup/Restore, instantiation and activation, Change Management, Implementation repository, Interface repository, Licensing, Replication, Security, and Threads. Services CAISS will use (with possible major extensions): Concurrency control, data interchange, externalization, data, operational control, properties, query, relationships, trader, transaction. Relationship to CORBA The preferred mode for KQML servers (static agents) to interact with CORBA is through the Dynamic Invocation Interface (DII). KQML messages (mobile agents) can be sent to KQML servers (static agents) through the Dynamic Invocation Interface Relationship to OMG Object Model As can be seen from above CAISS uses the COSS and CORBA services using an object oriented model. However, the exact profiles and components needed need to be studied further. Technical Issues Serial protocol: CAISS assumes that static agents communicate with each other through agents. Contents of mobile agents may contain data, programs or procedure calls (messages). In particular, mobile agents may carry messages that access services of COSS. This may imply that COSS (and other OMG services) may need to be specified using a serial protocol (as compared to an API). Transactions and concurrency control: Will the underlying concurrency control and transaction model used in COSS support mobile agent transactions correctly. The conconcept of concurrency control and integrity constraint management is not well specified for systems that are distributed and autonomous (which static agents are assumed to be). Only a loose notion of concurrency control and integrity constraint management can be supported for the agent interaction model. 1 "Software valets that will do your bidding in cyberspace", Evan I. Schwartz, The New York Times, 9 Jan 94 2"Toward mega programming", Gio Wiederhold, et. al., Communications of ACM, Nov. 1992. 3"The butlers of the digital age will be just a keystroke away", Barbara Kantrowitz, Newsweek, 17 Jan 94 4"Distributed Collaborative Enterprises", Robert Neches, White Paper, ARPA