Using KADS to Build Agents for E-Commerce

Using KADS to Build Agents for E-Commerce Darryl N. Davis and Laetitia Cailleteau✠ Department of Computer Science, University of Hull, Kingston-upon-Hull, HU6 7RX, U.K. [email protected] Fax: +44 (0) 1482 466666

Abstract In this paper, we present a knowledge engineering perspective on a number of types of activities associated with building e-commerce systems. Through the use an appropriate methodology, a principled approach to designing a multiple agent framework results. Our analysis makes use of KADS to provide a number of levels of task definition. The task related models are mapped onto the IBM Aglets framework. The work addresses the activities associated with client, server and mobile agents. The agents communicate to each other using a well-defined agent communication language. The use of multi-attribute decision making enables the client agents to sort information according to the needs of the user. We suggest that such frameworks will play an important role in the development of e-commerce as the data available from the Internet continues to expand, while the time available to filter and sort it becomes more critical.

Keywords: E-commerce, Agents, Methodologies.

1.

Introduction

Software agents can help with many e-commerce activities. A software agent is an autonomous, reactive, goal directed and social computational system. Agents are autonomous, operating without direct interaction of others entities – they control their actions and their own state. An agent exists as part of a dynamic environment that they perceive and change; i.e. they are reactive. Agents not only react to their environment, but their decisions and actions are made in an attempt to satisfy their internal goals. Social agents communicate or interact in some other way with other agents [Ferber (1999)]. Different categories of agents can be devised according to the requirements of an application domain and the type of computational system needed.

✠

Now with Anderson Consulting, London. 1

Buyer agents work on the behalf of a procurer or consumer. Seller agents can personalise their service by taking in consideration the buying agent’s preferences and try to establish a long-term relationship. Seller agents can advertise around the web, exchange information with buying agents and attract them to their sites. Client agents can independently retrieve information and sort it according to user’s requirements. Agents can exchange information with other agents, enabling faster and more appropriate data access across the Internet. Agents can make comparisons and retrieve only the information needed. A mobile agent is not bound to the system on which it begins its execution; it can transport itself from one system to another in the network. This ability to travel allows agents to move to a system that contains services with which they want to interact with and then take advantage of being on the same host or network as that service. The use of mobile agents provides many advantages: •

Reduction of network load. A distributed system with static agents involves continuous traffic on the network. The use of mobile agents causes only an instantaneous load as the agent moves. Furthermore, as the computation of the information is done on the remote host, only the result of this computation needs to be transferred.

•

They overcome network latency. Agents are dispatched to remote hosts to execute their jobs. Most network troubles of continuous interaction and latency can be avoided. They can reconnect with their home only when they have completed their task providing better control of a real-time system.

•

They encapsulate protocols. As they execute asynchronously and autonomously, they do not need a permanent, expensive and sometimes unreliable connection with the “home” system. Tasks are embedded into the agent. Agents are therefore autonomous and independent of the creating process.

•

They are naturally heterogeneous. Mobile agents, at least at a theoretical level, are computer and transport layer independent. They depend only on their execution environment. They therefore provide optimal conditions for seamless system integration.

•

They are robust and fault tolerant. The ability of an agent to react dynamically to unfavourable situations and events make it easier to build robust and fault tolerant distributed systems. If an host is being shut down, all agents executing on that machine will be warned and given time to dispatch and continue their operation on another host on the network.

There are a considerable number of agent based e-commerce frameworks ranging from research mock-ups to academic-collaborative and commercial projects. The main principle of Kasbah [Chavaz and Maes (1996)] is the use of static software agents to negotiate a sale. The agents’ goal is

2

to make an acceptable deal in terms of price and date of delivery. AuctionBot [Wurman et al (1998)] uses a distributive negotiation principle. Users have a set of parameters to define the way their agent has to act, to bid. Buyers and Sellers can then bid according to the multilateral distributive negotiation protocols of the created auction. BargainFinder [Williams (1996)] was the first “intelligent” agent system to provide comparison shopping on the Internet. It was developed to demonstrate the impact of e-commerce on the retail industry; it also revealed how Web-based agents could provide tremendous power to consumers. A more recent commercial system from the same source is Oneswoop [Anderson (1999)]. There are a number of e-commerce projects supported by the European Union, predominantly addressing issues related to the establishment of new e-commerce protocols and standards. ABROSE (Agent Based Brokerage Service in Ecommerce) is a large-scale e-commerce project [Gleizes et al (2000)] that aims to create an agentbased brokerage service. The main features are dynamic knowledge capture using a multiple agent system. Agents are used to provide user support for requests and navigation, registration and propagation of information. They aim to demonstrate how agent technology helps to create customisable and adaptive applications in the information brokerage domain. In an attempt to overcome potential problems of interoperability between different e-commerce implementations the consortium is developing an object-oriented framework called Eco System. In order to ease interoperation between layers they are also developing a Common Business Language (CBL) with the aim that different application agents will be able to communicate with each other. Since many applications are being developed and few standards have dominance, it seems that application vendors in this area will achieve interoperability between systems through the agreement of metaprotocols. Essentially, systems will support multiple protocols and "negotiate" with each other to achieve interoperation.

2.

Why Use KADS for Agents in E-commerce

KADS is a methodology for knowledge-based systems [Schreiber et al (19990] which supports project management, organisational analysis, knowledge acquisition, conceptual modelling, user interaction, system integration, and design. This methodology describes systems development from two perspectives. From the result perspective, KADS provides the means for developing a set of models of different aspects of the system and its environment that are continuously improved during the life cycle. From a project management perspective, KADS provides a risk-driven generic spiral life-cycle model that can be configured into a process adapted to any particular project.

3

KADS is a cyclic methodology, requiring several encompassing passes of seven phases; each stage adding a degree of functionality or progress. The planning and organisational issues stage (phase 1) analyses the effects of the introduction of the system on the organisation and people. Subsequently, it defines the typical user profile and the way the system will change their traditional tasks. It brings an interesting human dimension to the system. The application analysis stage (phase 2) defines precisely the problem the system is going to solve. The task model (phase 3) consists of identifying and modelling the knowledge needed top build and run the system. It decomposes the application model into a series of tasks and sub-tasks. In phase 4 a model of co-operation is built. This relies on the task model to define how the user and the system will work together. The distribution of the tasks is defined and interfaces and interactions with the user are specified. The model of expertise (phase 5) also relies on the task model to specify the desired behaviour and the knowledge involved. The co-operation model and model of expertise can be designed in parallel. Together the model of expertise and the model of co-operation provide a conceptual model (phase 6) that specifies the behaviour of the artefact to be built. Conceptual models are abstract descriptions of the objects and operations of the system. The design model (phase 7) is the description of the computational and representational techniques that the artefact should use to realise the specified behaviour. In building a design model, the knowledge engineer addresses external requirements such as speed, hardware and software. The main principle is the evolutionary prototyping concept. The spiral life cycle allows greater flexibility with the management of the project. The main functions of the project can be developed at first, then improved in parallel as secondary requirements are addressed. Specifications are not static, and the system can be reviewed and improved over time, in response to the real and changing needs of the user. This feature is particularly powerful when developing systems in a new area. The Internet, its standards and e-commerce are changing so fast that a non-evolutionary life cycle is totally inadequate and can lead to a born-dead obsolete solution. It provides for shorter and more forgiving development. The evolutionary life cycle allows faster and easier recovery from mistakes and oversights. With a more traditional software and development life cycle, an error or oversight or change in the perceived requirements of the user obliges you to review the entire conception, which takes a lot more time and money. Overall it gives the developer more control and allows a more ambitious system design

4

3.

Example Scenario and Analysis

The example e-commerce scenario to which we applied KADS and agents dealt with flight tickets. For example, an Internet user wants to find information about alternative flights for a particular journey. As it is becomes more time consuming to find such information on the web, an intelligent buying agent is to be used. This intelligent agent knows of a few flight companies’ web sites and will go to visit them to collect information. It will learn from other agents different kinds of travelling information and new sites to visit. First generation e-commerce agents tend to rank information purely on one-dimension, for example prices. They do not take into consideration other factors, such as services. Here we try to reproduce real consumer behaviour by allowing multiattribute decision-making in our agent framework. Our system should be able to: •

Receive a user request that defines the flight ticket attributes

•

Collect the information related to this request from the network.

•

Compute a multi-attribute decision over the collected information.

•

Link the result to the related electronic web site.

•

Return the collated and classified result to the user.

3.1.

Requirements, task modelling and agent categorisation.

Here we detail the requirements for our prototype e-commerce framework and the agents within the framework. As we intended to simulate real scenarios, we required flight information sites distributed across a network, accessed by the user from a different site. The tasks in this framework can be complicated and are best modelled using different categories of agents. The agents in this framework can be categorised in a number of ways, and at a number of levels. We can for example differentiate between stationary and mobile agents as described above. We can differentiate between agents on the basis of their tasks at some generic (application and domain independent) level. A task agent is an agent that supports decision making by exchanging information with other software agent. An information agent is an agent that is able to answer queries from the user or other agent by collating and manipulating information. An interface agent is an agent that interacts with the user, receive user requests and delivers results. Hybrid agents of different natures are used for all the agents. The interface-task agent is static, and closer to a pure deliberative architecture than a pure reactive architecture. The information agent is mobile, often changing its local environment and its route plan if one of the servers is down or unavailable. It also needs to filter the incoming messages to store only useful information. Again a kind of hybrid architecture will be needed but this time closer to the reactive architecture. Figure 1 5

gives an example configuration of this framework. The Framework Manager and its task agent (Static1) manage services within the framework. These tasks include the supply of electronic addresses of the users to each other. All communication between users occurs via an agent transport protocol (ATP) that allows mobile agents to travel between compatible sites. ATPs exist between server sites and are maintained by the framework manager. Here a task agent (Home1) associated with Buyer One, responds to a specific user request by creating three mobile information agents, Mobile1, Mobile2 and Mobile3. A different task agent (unseen and unknown to Home1) has created Mobile4. Initially the Home1 knows of three flight companies (A, B, C), and dispatches mobile agents to these known information providers. Mobile1 has returned and relays its gathered information. Mobile3 is interacting (via KQML) with one of the known flight companies and Mobile2 is returning to Home1. Mobile2 has also sensed a mobile agent from an unknown source and communicates with it via KQML. In a benign situation, it discovers the address of Flight Company U. In non-benign situations, it runs the risk of compromising agent Home1’s task. Table 1. Specifications of the Home agent and the mobile agent. Attributes Autonomous Communication Epistemological Objectives Mobility Reactivity

Role Social ability

Master (Home Agent) It controls its actions and own state and cooperates with the mobile agent. It needs to communicate both with the user and its slave It needs to perform multi-attribute decision-making. Stationary. It is reactive to the environment especially the messages sent to show the progression of its mobile agent. Get the flight company information Display an updated user interface. It co-operates with the user and with the mobile agent to complete the goal.

Slave (Mobile Agent) It performs its task over the network by itself. It needs to communicate both with its master and the Flight Company agent It needs to analyse the flight company agent request and to modify its knowledge base. Mobile. It is reactive to its environment and can change its plan if one of the servers it is visiting is unavailable. Get the flight company information for its master. It co-operates with master and Flight Company agents to complete the goal.

We can differentiate between these agents in terms of their responsibilities at the domain level. At this level of analysis, there are three major classes of agent in this framework. Home (or client) agents that act on behalf a customer interested in making an air ticket purchase. Flight company agents that act on the behalf of different air flight companies. Mobile agents capable of travelling between the sites servicing the needs of the flight company and client agents. The Home agent is stationary and responsible for all interactions with the user and multi-attribute negotiation. It delegates the search for information to a mobile agent. The Home agent can allow the user to

6

continuously monitor the progress of the mobile agent. For instance, the mobile agent can regularly send progress reports - which will be displayed by the Home agent through a progress bar in the user interface. This solution allows extensions. The Home agent can perform several other tasks like looking for trains companies’ offers. It will only have to create another mobile agent for that subtask. The specification of our system on the client side is represented in table 1. Table 2: Specifications of the Flight Company Agent Attributes Autonomous Communication Epistemological objectives Mobility Reactivity Role Social ability

FlightCompany Agent It controls its actions and co-operates with mobiles It needs to communicate both with the incoming agent and the database. It needs to analyse the incoming request, build a corresponding SQL request and map all the result into an answer message. Stationary It needs to be reactive to the ODBC driver message and the incoming messages. Give the flight company information. It co-operates with the mobile agent.

On the flight company side, the task is much simpler. The FlightCompany agent just has to interpret the incoming requests, translate them into SQL, connect to its Database, get and map the result and send the answer. As these tasks are consecutive; there is no need to delegate any of them. Hence there is only one agent on the Flight Company server. The specification of the Flight Company agent is given in table 2. The Flight Company agent needs to analyse incoming requests, to build SQL requests and to map all the information into answer messages. It needs to be reactive to poor database connections and to incoming messages. 3.2.

Multi-attribute decision making

Making decisions is part of the daily life, and there are many criteria with which to define an optimal decision. The same is true in e-commerce. In many situations, the price of product is one among many attributes used in sorting options. The multiple-criteria decision model we adopted involves four important elements [Yu (1985)]: •

The set of alternatives X

•

The set of criteria f=(f1, f2, f3…) used to make a decision.

•

The outcome is measured in terms of value maximisation over the function Y=f(x) | x ∈X.

• The preference structures of the decision-maker. Decision making is easier if the preferences over the possible outcomes Y are clearly and perfectly specified.

7

This model tries to attach a value function to the possible decision outcomes and search for the best (highest) value. Three solution types are possible: •

Alpha: providing good and bad solutions

•

Beta: providing good, undefined and bad solutions

•

Gamma: extracting k better solutions from the set of possibilities

The gamma solution is the one adapted for the prototype because the user has a set of classified better solutions and is able to make a final choice – each solution can be reviewed in terms of the weight of each criterion. Such a model is understandable to the type of user expected to use the service. For the prototype system, the three criteria used are the price, the planning convenience and the services expected. Each criterion has a different importance represented by their weight defined on a 10 point rating scale. The price rate depends on prices offered by each company. The lowest price will have a rate of 10 and the most expensive a rate of 1. The planning convenience includes factors such as the time of the departure, the duration of the travel, the number of connections. All these different criteria have the own rating scale and the global rate is the average of each result. The service rate is evaluated as a function of eight criteria: reduction card; taxi waiting at the airport; hotel booking; youth price; children price; business class; car renting; disable facilities etc. The service rate is evaluated as a function of the number of services available. For instance, if company B provide all the services, it has a service rate of ten. Once each of these criteria is evaluated, the decision-making algorithm classifies the information and returns it to the user. Table 3 gives an example scenario, with each metric calculated using: mi= Σ (wi * xi) / Σ wi, where mi is the final value, wi is the weight, xi is the value attributed. Table 3: Example of the multiple attribute decision making. Option A B

Price Very Low Low

C

Medium

3.3.

Post-selling-service Bad (48 hour guarantee) Very good (exchangeable, refundable, guarantee) Medium (good guarantee)

Offers Bad (nothing) Medium (reduction on next purchase) Good (Buy one get one free, card)

Calculation (10*10 + 2*5 + 2*5) / (10 + 5 + 5) (10*10 + 2*5 + 2*5) / (10 + 5 + 5)

Metric 6

Rank 3

7.75

1

(5*10 + 6*5 + 10*5) / (10 + 5 + 5)

6.5

2

KADS Task Model

Figure 2 shows the KADS task decomposition model for the flight client side but does not relate tasks to agents. The model defines all the tasks and sub-tasks that have to be done by the system or the user. The first level of decomposition is relatively simple. Successive sub-tasks are: get user 8

request, get flight companies addresses, request each flight companies, compute the classified result, choice the desired flight ticket, order. At a more detailed level, tasks are: •

Specify travel information i.e. departure, destination, date, hour, eligibility etc.

•

Specify decision-making parameters i.e. the price, service and convenience weight.

•

Collect the flight company address.

•

Select the company address.

•

For each flight company address: Go on the flight company server. Request the flight company server. Store the result.

•

Compute a classified result with the multi-attribute decision-making parameters.

•

Select the desired solutions.

•

Go on the flight company web server.

•

Order the flight.

A similar task decomposition model can be produced for the Flight Companies in figure1. In this model, we have assumed all agents, even if competitive, are benign. The flight company task is to accept and communicate with an incoming mobile agent, requiring three sub-tasks: receive request from mobile, execute query associated with request, reply to mobile. Such task models define of the general nature of the framework. Once complete, these tasks can then be defined in terms of the different agents and the user. 3.4.

Co-operation Model

The co-operation model in figure 3 shows the distribution of each task of figure 2 between the user and the system. The system tasks are distributed between one task (Home) agent and information seeking (Mobile) agents. The user supplies travel information and the multi-attribute parameters through a request interface managed by the Home Agent. The Home Agent produces a set of flight companies (and their addresses) from its own database. This specific task can be broken down further. The flight company addresses are initially provided by the Framework Manager. The Home Agent is periodically informed by the Framework Manager as further flight companies are introduced into the framework. The Home Agent is opportunistically updated through its own mobile agents, for example Mobile2 in figure 1 (after its communication with Mobile4). The user is able to reduce this set of addresses – for example the user may not be interested in flying with specific companies. Mobile agents are responsible for the intermediate task sequence. They need to go to each flight company defined and collect the requested information. When these tasks are done, the mobile agents return home and pass the information to the Home agent. The Home agent

9

is then able to perform the multi-attribute decision making result and display the results to the user. The distribution of the tasks on the flight company side is simpler as there is no human intervention. In fact, in our prototype systems we decided to let one agent, the flight agent, to assume all the tasks of the flight company server. 3.5.

Agent Communication

An agent in e-commerce must be able to communicate with its environment and other agents. It is obvious that agents need a common language to communicate and understand each other, hence for example the ABROSE project’s attempt to define CBL. As we needed to use declarative communication protocols in other work on multiple agent systems, we decided to pursue our use of KIF-KQML [ARPA (1993)]. We require only a small part of KQML for this project. We retain the readability concept of KIF by using understandable performative name and structure, but limit the syntax of KQML language between agents to ensure privacy of internal data structures. As most of the flight companies have different databases, the Flight Company Agent will interpret the incoming message and translate it into its own database language (SQL most of the time). Therefore, the Flight Company does not have to notify external agents of its database structure but communication remains transparent. It is a good way also to avoid hacker troubles - nobody knows how information is stored. We are looking to develop this language further for other e-commerce scenarios [Liu et al, (2000)]. 3.6.

Agents, Processes and Architectures

Having produced our task and co-operation models we can move onto designing computational processes. In designing the agent architectures we considered the nature of the agent tasks as given by the KADS task and co-operation models. We then placed these tasks on a continuum moving from pure deliberative to pure reactive systems. Deliberative process models were chosen only when reactive process models were impossible. This resulted in the design (and implementation) of three hybrid agents. The home agent manipulates symbolic information from the user and communicates about it with the mobile agents that it spawns. The home agent makes use of default values but does require the user to supply the flight information i.e. the source, the destination, the date, the hour and the eligibility. Any changes to the default multi-attribute decision-making parameters are stored locally in the memory of the home agent. Having constructed a user request and profile from this interaction, a mobile agent is created and initialised. KIF-KQML is used to inform the mobile agent

10

of its task. The mobile communicates with its home agent as it moves around the Internet, providing progress report messages that are relayed to the user interface. The mobile, on completing its task, returns to its home agent, relays all its stored information via KIF-KQML and is then extinguished. The home agent runs its multi-attribute decision-making module on the information provided by the mobile, storing it in the home database and updating the user interface with the final result. The mobile agent on receiving its initial message, sorts its itinerary and the set of tasks. It then begins its journey over the Internet. Each time it arrives at a new destination, it sends a progress report message to its Home Agent. In our prototype system the reactive mobile agent is limited to two tasks. A generic task system is not used for reasons of computational compactness. On arriving at a Flight Company server, a mobile agent sends a FlightInformationRequest message related to the user request. In turn will receive a FlightInformationResponse message containing the information about the requested flight or an error message if the server is down or has any other kind of trouble. It will unpack the message content using a communication filter and store it in its database and then proceed to its next destination. This sequence of actions continues until the mobile agent arrives at its source of origin. The Flight Company agent on receiving a FlightInformationRequest from a mobile agent. unpacks the message content and frames it as a SQL request. It connects to its personal database and executes the query though a JDBC-ODBC driver. The information response is then mapped back into our subset of KIF-KQML. This mapping allows the system to use several kinds of databases such as ORACLE, Sybase, and Ingres as far as they are support ODBC. After the mapping of the data, it constructs the answer message and sends it to the mobile agent. 3.7.

Computational Platform

In our prototype system, the framework is modelled using the IBM Aglets software [Lange and Oshima (1999)]. This Java based agent toolkit also models the Framework Manager and the maintenance of ATP (Agent Transport Protocol) connections across a distributed system. ATP is a TCP/IP based protocol by which agents can be made mobile. In a more open system, there are a great number of other issues that need to be considered, including the nature of computational platforms across the framework and the type of agents that can be used. Our prototype implementation mixes Java and IBM Aglets. Pure Java presents some major technical disadvantages, especially for agent implementations. These include: •

Inadequate support for Resource Control resulting in for example deny of service.

11

•

No protection of references. For example there is no way that the agent can directly monitor and control which other agents are accessing its methods.

•

No support for the preservation and resumption of the execution state. It is currently impossible in Java to retrieve the full Execution State of an object. Information such as the status of the program counter and frame stack is permanently forbidden territory for Java programs. Therefore, for a mobile agent to properly resume a computation on a remote host, it must rely on internal attributes and external events to direct it. An embedded automaton can keep track of the agent’s travels and ensure that computations are properly halted and properly resumed.

•

Security. The Java commerce framework provides security protocols such as SSL (Secure Socket Layer) but other stronger standard protocols such as SET (Secure Electronic Transaction) are not available yet.

An Aglet is a mobile Java object that visits Aglet-enabled hosts in a computer network. It is autonomous, running in its own thread of execution after arriving at a host, and reactive. It provides developers a whole framework with the aim of resolving the problems associated with Java through the implementation of a number of agent-related concepts. A context is an Aglet’s workplace. It is a stationary object that provides a means for maintaining, managing and running a uniform execution environment where the host system is secured against malicious Aglets. One node in a computer network may host multiple contexts. A proxy is a representative of an Aglet. It serves as a shield for the Aglet that protects the Aglet from direct access to its public methods. The proxy also provides location transparency for the Aglet. That is, it can hide the real location of the Aglet. An identifier is bound to each Aglet. This identifier is globally unique and immutable throughout the term of the Aglet’s life cycle. This allows the design and implementation of mobile agents that can execute in a platform-specific independent way. An Aglet application is the only entity to choose where and when to move and it can suspend or resume its execution at a certain point. Finally, an Aglet can interact with other mobile agents in a synchronous or asynchronous way.

4.

Summary

This mobile agent e-commerce framework is a mix of traditional and nouvelle architectures. Many initially simplifying assumptions were made, including the absence of many attributes such as negotiation, or dynamic action-selection. It makes use of three agents: the stationary Home Agent is responsible for user interaction and multi-attribute decision making. It creates Mobile Agent to traverse the Internet and procure required information. The stationary Flight Company agents provide the interface between the agent framework and the flight companies’ databases. Each server 12

needs to run an Aglet server to embed Aglets and allow the Aglet transfer protocol. This feature can be avoided by using Remote Method Interface in Java. No communication between mobile agents has been implemented. They could have been able to communicate to exchange new flight company servers addresses. This extension would require an extension to the mobile agent model and the KIF-KQML language and would provide an interesting extension of the framework. Many of these inadequacies are being addressed in an ongoing e-commerce project related to stock trading.

5.

References

Anderson Consulting Ltd, (1999), Oneswoop Home Pages, http://www.oneswoop.com/index.htm Chavez, A. and Maes, P. (1996), Kasbah: An Agent Marketplace for Buying and Selling Goods. Proceedings of the First International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology. London, UK. Gleizes, M.-P., Glize, P. & Léger, A. (2000), Abrose : An Adaptive Brokerage Tool Based on Multi-Agent, IEEE Computer Communications. Lange, D. and Oshima, M., 1999, Programming and Deploying Java™ Mobile Agents with Aglets™, Addison-Wesley. Maes, P., Guttman, R. and Moukas, A. (1999), Agents that Buy and Sell: Transforming Commerce as we Know It. Communications of the ACM, March Issue, Schreiber, G., Akkermans, H, Anjewierden, A, de Hoog,R., Shadbolt, N., Van de Velde, W., and Wielinga, B. (1999), Knowledge Engineering and Management: The CommonKADS Methodology, MIT Press Williams, J., (1996), Bots and Other Internet Beasties, SAMS.Net publishing, Wurman, P.R. Wellman,M.P. and Walsh.W.E., (1998), The Michigan Internet AuctionBot: A configurable auction server for human and software agents. Second International Conference on Autonomous Agents. Yu, Y-L, (1985), Multiple-Criteria Decision Making,

13

Key: ATP

Buyer One Task Agent: Home1 Flight Company C Task Agent: JDBC+ODBC StaticC SQL

User Interaction

KQML

Flight Company A

Mobile1 ATP

ATP ATP

KQML

Agent Transport Protocol Actual Connection Potential Connection

Task Agent: JDBC+ODBC StaticA SQL

Mobile3

Flight Company U

ATP

Mobile4

Flight Company B

KQML

Task Agent: JDBC+ODBC StaticU

Mobile2

SQL

Task Agent: JDBC+ODBC StaticB SQL

Framework Manager Task Agent: JDBC+ODBC StaticM SQL

Figure 1. Electronic commerce framework for the flight ticket domain

14

Figure 2. KADS task decomposition model for the flight client

15

Figure 3: KADS model of co-operation on the flight client.

16

• •

Figure 4: Mobile agent architecture

17