Title: PERSONAL TRAVEL MARKET: A REAL-LIFE APPLICATION OF THE FIPA STANDARDS

Transcription

1 Title: PERSONAL TRAVEL MARKET: A REAL-LIFE APPLICATION OF THE FIPA STANDARDS Authors: Jorge Núñez Suárez British Telecommunications jorge.nunez-suarez@bt.com Donie O'Sullivan Broadcom Eireann dos@broadcom.ie Henri Brouchoud France Télécom henri.brouchoud@cnet.francetelecom.fr Patrice Cros ONERA/CERT cros@cert.fr Clair Moore KPN Research c.r.moore@research.kpn.com Address for correspondence: Jorge Núñez Suárez British Telecommunications BT Advanced Communications Technology Centre, PP 146/B54 Adastral Park Martlesham Heath Ipswich IP5 3RE UK Tel: +44 (0) Fax: +44 (0) jorge.nunez-suarez@bt.com Key Theme: T3 1

2 1 Abstract The purpose of this paper is to report the experiences gained during the first year of the Personal Travel Market application developed under the umbrella of the FACTS project. This is a two years long, EU-sponsored 1, collaborative project whose objective is to evaluate and drive the set of FIPA agent communication standards in real-life applications. In the electronic marketplace chosen for this test, three types of agents (Personal Travel Agent, Travel Broker Agent and Travel Service Agent) collaborate to resolve travel requirements for a human user. In order to test the interoperability provided by the standards we have used two different FIPA-compliant platforms, developed three types of agents and connected them to external Web servers. The initial results are very encouraging, as the standards have proved very useful in the integration of six completely independent, FIPA-compliant software components. The companies involved in this application are British Telecommunications, Broadcom Eireann, France Télécom, KPN Research and ONERA. 1 FIPA Agent Communication Technologies and Services. ACTS Project AC317 2

3 2 Introduction The goal of FACTS [FACTS] is to validate and drive the FIPA agent communication specifications. To this effect, an EUsponsored project has been set up in collaboration with a number of European companies. Three main domain applications have been chosen to test the standard in real-life scenarios: service reservation, electronic trading and audio-visual entertainment and broadcasting. This paper describes the experiences and findings of the electronic trading application (Personal Travel Market). The FIPA [FIPA] standards provide a set of normative and informative specifications that allow developers to build independently multi-agent systems with very little integration. Although the number of standardisation areas continues to grow, the main ones are Agent Communication Language, Agent Management and Agent/software integration. In the electronic marketplace modelled in this application the following types of agents co-exist: 1. PTA. The Personal Travel Assistant acts as the interface between the user and the application thus representing their interests. It co-operates with TBAs in order to find travel plans that satisfy both the user s explicit travel request as well as the user s personal preferences. 2. TBA. The role of a Travel Broker Agent is to act as an intermediary between the Personal Travel Agent and Travel Service Agents, offering service bundling. Typically, it will collect a trip request from a PTA, analyse it, identify the different segments, query the TSAs and try to compose a trip plan that satisfies the user s requirements. This agent may have a company profile expressing the preferences of the user s company in business travel. 3. TSA. The Travel Service Agent is responsible for providing data and services to the TBA such as airline tickets sales, railway timetables, hotel room availability and prices, weather reports and so on. Since the TSA is the boundary between the FIPA world and the non-fipa world, it presents two interfaces, one to the FIPA side and one to the services it wraps (i.e. html servers, databases, etc). The system aims to allow a human user to book a trip simply by specifying the details to her PTA, which will take the requirements and send them to a TBA. This agent will in turn decompose the trip into a series of segments and query the TSAs which represent the service providers. With the replies of the TSAs it will re-compose the trip trying to match the user's preferences. It will then send a bundled trip back to the PTA for evaluation. This agent will look at the preferences and check the validity of the proposal. If the offer is likely to be accepted, then it is passed onto the user, otherwise it is rejected and a negotiation process commences. If the user accepts the offer then the TBA 3

4 proceeds to book the individual segments and collects payment from the PTA. Figure 1 presents the agents present in the scenario and the communication between them. The PTA resides in the Agent Services Layer (ASL), a FIPA compliant platform. The agent uses the services of the platform to locate and communicate with the other agents in the application. The TBA and the TSAs are connected to JADE, another FIPA compliant platform [JADE]. ASL environment Jade environment Non-FIPA world User Personal Travel Agent (Broadcom) Air France Travel Service Agent (France Telecom) Java RMI+Java Events IBIS Travel Service Agent (France Telecom) Air France Web site (ONERA) IBIS Web site (ONERA) Platform 1 ASL (Broadcom) Platform 2 Jade (Telecom Italia) Travel Broker Agent (BT) IIOP communication Figure 1 The PTM Application 3 Using the PTM The user's interaction with the system is exclusively with the PTA through a series of windows that are used to specify the details of trips and view offers. Therefore the user remains completely unaware of the complexity and the number of actors involved in the process. After the user inputs the basic information needed by the PTA to create a valid trip request, the trip request is analysed by a case-based reasoning module and if a similar case is found, then the preferences of the current request are completed before the approval of the user to be sent to the TBA. The PTA keeps a user profile of the user's travel preferences as a collection of cases. Case Base Reasoning (CBR) was chosen as the learning method because it is an incremental learning system, cases can be acquired easily and the decisions of the agent can be easily explained to the user. The PTA acquires profile information by observing the users actions when planning a trip. This information is converted into cases, which are stored. A minimal amount of direct user feedback will also be used. The travel preferences supplied by the user are used to query the case base, and one or more 4

5 cases similar to the new case are retrieved. Travel references defined in these cases are extracted. Preferences from several different cases may be combined. The travel preferences specified by the user and those extracted from the case base are merged. The PTA then constructs a trip request message from this information, gets user approval and sends it to the TBA. The PTA also evaluates offers sent by the TBA whose features do not exactly match the preferences specified by the user. Some basic details in the offer and the request sent by the PTA, e.g. destinations, are compared to make sure that they match. If there is a mismatch between these details, then the offer is rejected immediately. Otherwise, the rest of the user's preferences are compared with the offer details and the differences between them are identified. This information is passed to a retrieval module that retrieves cases in which there were similar discrepancies. If the offer is categorised as being of interest (depending on whether the offer was accepted in the retrieved cases), then it is passed to the user for evaluation. Otherwise it is rejected. Figure 2 Main PTA and Request Windows Figure 3 Case-based reasoning in the PTA The TBA's role in the PTM is mainly to unbundle and bundle services. It receives requests from the PTA in the form of 5

6 calls for proposals and then identifies the segments that compose the trip (outbound and return trip, different hotel stays, etc.). The agent then generates a number of tentative routes to the destination and identifies the segments that compose them. In Figure 4 for example the agent has proposed the routes Torino<->Dublin, Torino<->Amsterdam<->Dublin and Torino<->London<->Dublin, which in total represent ten individual travel segments. The agent also identifies the need for additional services if required such as hotel stays. These segments will be used to query a number of dedicated TSAs to obtain scheduling, pricing and availability information. Once the TSAs' information is received, the agent tries to assemble a proposal that both satisfies the PTA's requests and the TBA's business targets (revenue, percentage of accepted proposals, etc.). The agent then sends this proposal for evaluation to the PTA. If the trip proposal is accepted then a booking is made with the relevant TSAs, if it is rejected, then it tries to patch the proposal with the information available form the TSAs and re-send it to the PTA. The Travel Service Agent provides airline tickets sales, railway timetables, hotel room availability and prices to the TBA. Because current technology does not provide Web servers with APIs, special pieces of software called wrappers, need to be implemented. The goal of these wrappers is to provide an abstract representation of real, existing Web servers where relevant information can be found. In the PTM application, the TSAs play this role of wrappers and provide the following functionalities to the other agent: - Proposition of a segment of a trip depending on data given in a request: this proposition is sent in the first step of a negotiation protocol. Some TSAs specialise on airline services, others on hotel rooms, etc. - Booking of accepted segments. - Cancellation of a booking. - Notification of temporary special offers. This functionality is available to other FIPA compliant agents through the use of the FIPA Agent Communication Language and protocols. The agents that want to interact with one or several TSAs should use the PTM protocols and the PTM Ontology as defined in the PTM application specifications. Moreover, the TSAs are registered with the Directory Facilitator (yellow pages agent) of their host FIPA platform with service description that allow other agents to establish contact with them. It has to be noted that one TSA represent a commercial entity in the PTM market, and as such has the possibility to define a specific policy to maximise its revenue. That means that when a TSA can propose several solutions in reply to a request, it will choose the one that fulfils best the 6

7 requirements and also that is in conformance with its commercial policy (high margin or resource usage). Figure 4 TBA route map 4 Conclusions The importance of the work implemented as part of this project is to show true interoperability at application level using the FIPA standards. In fact, this is the first instance of a system composed of a number of independently designed agents communicating using two independent FIPA-compliant agent platforms and solving a complex problem. Probably the main advantage of using the FIPA standards is a tremendous reduction in the amount of work that designers have to devote to ensure intra-application interoperability. In our case only the following items were considered: Definition of the responsibilities of each agent in the scenario. Common ontology. Application specific protocol. This means that any designer that wishes to successfully develop an agent for the Personal Travel Market only needs to ensure that the agent complies with the FIPA standards, that it is able to understand and compose messages using the PTM ontology and that it follows the sequence of messages outlined in the PTM-Protocol. In our case, the three agents have been designed independently with their own hidden internal architecture. The integration phase has been very short and simple with success and the only minor running problem was at protocol and ontology level, not at low implementation level. This demonstrates clearly the advantage of using a standard such as FIPA: agent implementers have only to concentrate on their own knowledge domain, the ontology, and use the tools and design process they are used to. This should make the development process faster than with other technologies where 7

8 the low-level technical aspects interfere with the domain level. Since FIPA ACL communication is based on the use of a wellknown and well-supported standard (IIOP) and the exchange of text messages, we consider that it is a flexible communication standard. We can also see that there are no technical requirements other than to comply with the standards and the interfaces in the application. In the example above, JADE has been developed using 100% pure Java while ASL is based on CORBA and provides hook-ups for a number of languages, such as Java, C++, etc. If we compare these requirements with traditional development methods, we see that FIPA frees the agent developer to use any available technology. This is largely thanks to the standardisation of inter-platform communication and the centralisation of the transmission capabilities in the platform. Although the FIPA specifications are in the main realisable there are a number of areas in which difficulties arise especially in the context of the PTM application, such as the bootstrapping problem or multicast communication. In this work we have also shown the different roles that agents can play in a networked economy. The PTA is the point of entry for the user to the marketplace. It collects the user's requirements and complements them with knowledge gained observing his behaviour. The TBA acts as a mediator between consumers and producers. It analyses the requests, decomposes them into small segments, queries the providers for suitable products, re-composes the segments into a full proposal and sends it to the PTA for evaluation. This agent can filter out those proposals that do not satisfy the basic user's requirements and present the rest for evaluation. This application architecture is very flexible and allows for a variety of business models. We can see in fact that the user only sees a very simple interface to a whole complex system (the PTA) that contains a number of actors and companies. 5 References [FACTS] [FIPA] [JADE] 8