Mobile Agents based Architecture for building ... - Semantic Scholar

Mobile Agents based Architecture for building Virtual Markets* Departamento de Electrónica y Sistemas, Universidad de A Coruña, Campus de Elviña s/n 15071 A Coruña Tlfno: +34 81 167150 Ext. 1213 Fax: +34 81 153639 Alberto Pan, Antonio López, Fidel Cacheda, Angel Viña { alberto,alf, fidel, avc}@gris.des.fi.udc.es

Abstract. This statement briefly describes the architecture of a virtual commerce meeting point based on mobile agents’ technology. These agents can negotiate and reach agreements on a secure environment provided by meeting points. The meeting point provides agents with services as agents and meeting point authentication, publishing and searching of agent’s interests, interagent communications, auctionsbased negotiation, electronic contracts and payment support.

1. Introduction Internet has the potential to become a global market area where physical barriers are removed. Nevertheless the problem of matching sellers and buyers in that global market remains unsolved. Internet existing search engines as Yahoo[13], Altavista[14] are clearly inadequate since one user could need to browse through thousand of sites before, for instance, finding the shop with the best price for a product. One step forward towards more reasonable shopping experiences on the Internet are agent-based systems which let users configure a search agent according to their preferences and let it surf the net instead of them finding the best deals. For instance, BargainFinder[15] offers this kind of service for finding the best prices for CDs and cassettes in several music stores. AdHound[16]browses several on-line magazines and newspapers in a similar way to find advertisements according to the interests of users. Though these systems are clearly much more suitable for electronic commerce than conventional search engines, they still have strong limitations. Searches are limited to a pre-defined list of sites that usually had to reach some kind of agreement with the service provider. This means that these systems are not open. Besides these systems are proposal-specific and don’t allow desirable features as direct negotiation between agents, automatic purchases, co-operation between agents, etc. Also, if the number of sites to be visited by the agent is very large, the process still could be very long for some purposes. A very interesting experiment towards more general virtual market architectures is Kasbah[1], where users can enter in a web site and configure seller or buyer agents. Users provide their agents with information about the good for buying or selling (there is a limited choice of possible goods) and a simple negotiation strategy based on a deadline date and maximum (minimal if it’s a seller) price willing to pay (receive) for the good. Nevertheless, Kasbah has a number of limitations for its use. The possible goods are a non object-oriented *

This work has been funded by the National R&D Program of Spain (CICYT Program) under contract TIC970438

pre-defined list, negotiation mechanisms are totally pre-defined and can’t be modified by users, agents are proprietary to the system and use proprietary communication mechanisms too, so it’s impossible to use heterogeneous agents in the market. Also, agents are not mobile so they can’t surf through other virtual markets or be locally built on user machines. In this paper we propose an architecture for building virtual commerce meeting points based on mobile agents technology. Sellers and buyers are represented on the system as mobile agents built and customized by users. These agents can negotiate and reach agreements on the trusted environment provided by the meeting-points, getting benefit of the facilities provided by the meeting points and avoiding unnecessary navigation of buyer agents through a large number of vendor sites. A meeting point provides agents with services as agents and meeting points authentication, publishing and searching of agent’s interests, inter-agent communication using non-proprietary mechanisms, built-in auctionbased negotiation, electronic agreements and payment support. Co-operation between agents from the same user is also possible by defining groups of authenticated agents that can communicate with each other in an efficient way. Also, we expose the guidelines with we’ve deployed the first prototype based on the architecture, the BISHOP system, using JAVA [11] and the Voyager plattform [12]. This paper is organized as follows. Section 2 outlines the objectives we think are necessary for our meeting-point architecture. Section 3 is an overview of the architecture. Section 4 addresses critical points of the architecture in more detail: sub-section 4.1 is about mobile-agents support, sub-section 4.2 addresses inter-agent communication, sub-section 4.3 outlines the built-in support for auctions as inter-agent negotiations, sub-section 4.4 addresses security, agreements and payment issues. Section 5 points possible industrial benefits derived from the architecture. Section 6 outlines the basic decisions taken on the implementation of the first prototype of the architecture, the BISHOP system. Finally, section 7 exposes our conclusions and future work.

2. Objectives Our proposal aims to suppose a new step towards building flexible and efficient electronic commerce environments. We believe that any architecture for such an environment should address the following issues: • Commodity for users: Users must be able to configure their agents on their machines, and forget about them until they come back with deal information. This implies that agents must be able to operate in an off-line way with respect to the user’s machine. • Efficiency: Buyer agents should avoid the need of visiting thousands of Internet sites before finding the best deal for their users. Agents should only need to visit one or a few meeting points to find suitable deals. This can imply some sort of collaboration and information exchange between meeting-points. • Openness: It seems no realistic to expect that all the agents roaming the Internet will follow the same structure. Meeting points must offer an open environment where heterogeneous agents can interact through well-defined communication interfaces. This also solves the problem of buyer agents visiting heterogeneous virtual stores. • Direct negotiation between agents: Users should be able to provide their agents with negotiation parameters and strategies that let them reach agreements on their behalf. Agents should even be able of making electronic payments if their users want them to have that prerogative. Users should have complete control over their agent actions to feel responsible about their decisions. • Collaboration between agents: Users may want their agents to collaborate. In some cases

the actions wished for an agent could depend on deals or information found by other agents from the same user. • Flexibility on the agent’s interests specification: Agents interests shouldn’t be restricted to a pre-defined list of goods. Object-oriented ontologies of goods should be available in order to be capable of specify agent’s interests in an understandable way for other agents and to permit users to extend this ontologies for specific purposes. • Security: Agents should be authenticated before their entry on the meeting-point. In a similar way, agents should be able to authenticate a meeting point before moving to it. Also, agents must be confident that their code and data won’t be eavesdropped by the sites it moves to. We think it’s easier with a schema based on meeting-points (which can be ruled by trusted entities) than with a buyer agent visiting thousand of probably nontrusted shops. Other schemes based on that we could call “tamper-resistant software”[2] are attractive but we believe more research work is needed before their use. • Electronic agreements: In an environment where real deals with real money are achieved between agents, conflicts may arise. The meeting-point should be able of acting as a “judge” capable of demonstrate the conditions of an agreement.

3. Architecture Overview A typical sequence of steps for an agent in the system will be the following: • One agent “Bob” is created on the local machine of the user and is configured with an interest (objectives of the agent) and some negotiation parameters and strategies. Note that the choice and use of the tools for building the agents are entirely under the user’s control so he/she can program them in any way wished. • Once the agent is created, he must travel to a meeting point. Before of moving, user’s system can establish a secure connection with the meeting-point (using e.g. SSL) to make sure that Bob won’t be observed or modified during the travel. Then Bob is digitally signed by the user and sent through the secure channel to the meeting-point. • When Bob arrives, the meeting point checks its signature and registers him on its DB associated with the identity of the user. Then executes him and adds him to the group of agents from Bob’s user. This has the effect that Bob will be able to communicate with other agents from Bob in a more efficient way and could send them multicast messages. • Now Bob is running and can begin to benefit from the meeting point services. First he uses a “register-interests” service to include his interests on the “public blackboard” (locally stored on a DB) of the meeting point. This way, other agents with concordant interests could locate it. Then the agent can use the “search-interests” service for retrieving from the blackboard, references to agents with interests according to a query. • Using the references obtained, Bob can communicate directly with the other agents. Say that the agent with more concordant interests is “Alice”. Using a standard language and protocol such as KQML, Bob and Alice can agree in the general terms of the communication such as the ontologies that will be used for goods and agreement conditions. In order to be ready to make an offer, Bob uses the “request-key” meeting point service to obtain a unique secret key that let it make signatures on the objects exchanged. The meeting point will store which secret key was given to which agent in order to verify signatures. Now, Bob can generate an offer according to its negotiation criteria (perhaps also considering previous communications with the other agents from the same user), signs it and sends it to Alice. Alice can verify the signature by using the “check-signature” service of the meeting point, which receives the message and a reference to the signing agent. If systems like proposed in [2] evolve, perhaps agents

•

•

•

•

could carry their own private keys securely without depending on the meeting point. An offer includes objects representing the objects to be bought or sold along with payment and delivery conditions. When Alice receives an offer, evaluates it according to her negotiation criteria. If she accepts, then she just signs the offer and sends the offer signed by both Bob and her to the “register-agreement” meeting point service. The “register-agreement” service verifies both signatures, stores the agreement and returns an agreement identificative. Then Alice sends Bob the offer signed by her along with the agreement id. Bob can verify that the agreement was registered asking the “register-agreement” service. If Bob and Alice had agreed on it, they also could not register their agreement but in that case, the meeting point wouldn’t be able to guarantee the non-repudiation of the agreement. It can also occur that Bob, Alice or both weren’t authorized by their users to definitely close agreements. In that case the offers or responses of the non-authorized agent must be NOT signed. In that case, no agreement is reached until the non-authorized agent gets confirmation for his/her user and makes a signed offer. Of course, during that time, perhaps the deal was already lost. Now, let us suppose that Bob is a buyer agent and Alice is a seller agent. Typically now Alice’s user has to delivery goods for Bob’s user and Bob’s user has to make a payment for the goods acquired to Alice’s user. Delivery of goods will be off the system in many cases. Nevertheless seller agents could carry with them small sized non-physical goods or passwords for accessing non physical goods located on the remote store they’re representing. In that cases, Alice’s agent could use the “deliver-good” service on the meeting point, passing it the goods to be delivered along with the agreement id. The service would send the goods to Bob, store a copy of them to solve possible conflicts and records that goods has been delivered for the specified agreement. If Alice and Bob agree on it, delivery can be made without involving the meeting point. In that case, the meeting point couldn’t assure that delivery of goods for the agreement has been made With respect to the electronic payment, on today environments, where security of confidential information carried by agents can’t be totally assured, many users can prefer to conduct the payments off the system. Nevertheless we think that at least two payment mechanisms could be used with very reasonable security (see 4.4 for details). In any case, Bob can send Alice a signed payment order that includes information as payment instrument and the agreement id. Now Alice can present it along with financial information of her user (e.g. an account number) to the “receive-payment” service on the meeting point. This service acts as a trusted intermediary with the selected payment system: checks that Bob’s user payment is valid, deposits the payment on the Alice’s user account on the payment system and returns to Alice the information relevant about the deposit (if it was successful, etc.) that Alice can finally send to Bob. The service also stores the payment order and records that the payment has been made for the specified agreement. If Alice and Bob agree on it, payment could be made without involving the meeting point. For instance, Alice could receive the payment order, travel to her bank’s site and deposit the payment. In that case, the meeting point couldn’t assure that the payment for the agreement has been made. One variation of this scenario could occur if Alice has a number of possible buyers (or Bob has a number of possible sellers). In that case Alice (respectively Bob) can use the “auction” service of the meeting point. This service gives Alice (respectively Bob) a reference to an agent that will conduct the auction. Alice (respectively Bob) must pass to the auction agent an offer object, a vector of references to interested buyer (respectively seller) agents and perhaps the kind of auction desired (between those supported). The auction agent coordinates the auction until an agreement is reached (see 4.3 for details).

4. Architecture Critical Issues 4.1 Mobile Agents Support The proposed architecture is based in the mobile agents’ technology in order to achieve a greater efficiency and flexibility in resources usage. Although this technology appeared few years ago, new mobile agents platforms based on the Java programming language are arising new improvements to this technology. Until now, most mobile agents’ platforms were based in proprietary programming languages like Telescript[17]. With the apparition of Java based platforms like Voyager[12], Aglets or Odissey it is easier to implement agents for these platforms because agents’ programmers haven’t to learn a new programming language. This aspect is very important to our architecture because it makes easier to develop customized agents that are compatible with our system. Mobile agents’ utilization provides our system of some useful characteristics: • Efficient resource usage: agents can move his execution to the place where the resources are located, avoiding unnecessary bandwidth usage and reducing access time. • Off-line system operation: after the user defines the agent’s interests, this agents moves to a meeting point and therefore doesn’t needs an on-line user. This user can turn off his computer and the agent will continue with his work. One of the big problems in the mobile agents’ platforms arises because agents only can move from and to computers with these platforms installed on them. With the use of Java based platforms we can use the dynamic network class loading mechanism to distribute the code needed by the mobile agents’ platform to operate. A computer with a Java virtual machine is the unique requirement to use our platform. This requirement is achieved by most of the computers in these days. Voyager platform was used to implement the first prototype of our architecture. Royaltyfree license for commercial uses and CORBA platform support were decisive factors to choose this mobile agent’s platform. 4.2 Inter-agent Communication In order to let agents to be locally built on the user’s machines, a common protocol and language must exist in order to let them exchange information and services even when they are built in very different ways. Though it’s easier to build an ‘ad-hoc’ solution for agent communication it would make the system proprietary: only agents built on a pre-defined way could enter the meeting point and benefit from its services. KQML[3] is today the most remarkable effort towards a standard language and protocol for communications between heterogeneous automated agents. It’s based upon an extensible set of performatives which support computer programs in identifying, connecting with, negotiating the terms of the communication (basically which ontologies will be used) and exchanging information with other programs. KQML is progressively gaining support between agent platforms and is an adequate communication framework for our architecture. Assuming such common language exists, it’s still necessary for communicating agents to share ontologies. An ontology can be seen as a structured reference vocabulary used by agents to interpret the semantic of the messages they exchange. Ontologies should be object-oriented in order to be easily extensible. Such shared ontologies are currently under development in many application domains. Ontologies will be usually domain-oriented and

may co-exist with other ontologies for the same domain. Thus, it’s needed that the common language lets agents specify which will be used. Such ontologies will be available for reference on the meeting point of our architecture. Also, meeting point can provide services for making the translation between the several possible ontologies. Both ideas are supported by KQML communication architecture. 4.3 Negotiation and Collaboration between agents Much work is being made on the research of suitable negotiation and collaboration strategies between agents[4][5]. Our objective on the architecture is giving the users the complete control over their agents’ strategies. We don’t propose any specific collaboration or negotiation strategy. We only aim to give basic support for any of them. As a basic structure for negotiation, the architecture provides built-in support for auctions. For its fairness and well-defined mechanism, auctions are considered as suitable mechanisms for negotiations between artificial agents. The way of providing the service is simple. When an agent wants to start an auction requests it to the meeting point. The meeting point returns a reference to an “auction-agent” that will conduct the auction. In the simpler operation mode, this trusted agent simply collects one bid for each participant and generates an agreement between the agent with the best bid and the agent that started the auction (only if the offer reaches the minimum established by the agent that started the auction). This mechanism is very simple and very efficient. A more sophisticated auction schema has been proposed in [7], the Vickrey mechanism (also very efficient) is proposed as a better way of conducting auctions. [6] proposes an interesting but more complex mechanism based on Spanish fish market. Meeting points can choose to provide several kinds of auctions. With respect to collaboration between agents, we think that the basic need is providing the collaborating agents with an efficient communication mechanism, which include support for multicast messages. Each agent must be able of sending messages to all the other agents in the group in an efficient way. A suitable basis for grouping agents is having all the agents of a user in the same space and the agents from the same user in each meeting point in a subspace of the previous space. Maintaining the spaces is responsibility of the agent platforms that must inter-operate in order to assure this. 4.4 Security, authentication and electronic payments Meeting point can get security against malicious agents by avoiding forbidden accesses of the agent outside of its execution environment, much in the way Java applets are executed. The meeting point also should authenticate the identity of the agent’s user using a standard public-key infrastructure based upon any of the certification infrastructures existing. The problem of agents’ protection against malicious meeting points is more difficult due to the fact that the execution environment is totally controlled by the meeting point. Nevertheless, we expect meeting points to be generally ruled by well-known and trusted entities, so users can consider that authenticating the meeting point identity and establishing a secure channel with it before sending their agents is enough. For “jumps” from a meeting point to another, the meeting point of the origin can authenticate the destiny. On the other hand, many research efforts[2][10] are now trying to solve the problem of getting secure executions on insecure environments. When these efforts evolve, they could be seamlessly integrated in our architecture. The issue of electronic payments is closely related to this problem. For making electronic payments the agent often had to carry confidential information about their users such as credit card numbers or private keys. Many people could think that it would be trust too

much the meeting point. There are several possibilities to decrease those concerns. The meeting point could offer a privately run account service to the users, where they could charge money by a standard credit-card transaction. Later the user’s agents could make payments against the funds of that account. An agent could also make payments in other meeting points using its user’s account on another meeting point if both meeting points trust themselves: the meeting point where the payment is produced simply checks the balance of the user’s agent asking the meeting point which runs the account. Later, the meeting points can adjust their balances. Note that the receiving agent hasn’t necessarily an account on the meeting point: the payment could be made using other payment system (e.g. SET). Of course, the meeting point still could cheat the users but in that case, it quickly will loose its users, besides, it will probably be protected by credit-card companies’ policies (the initial charge on the account was through a credit card transaction). Similar account-servers based schemes have been often proposed to electronic payments in Internet[9]. Besides, in some cases trusting the meeting point can be fully justified. For instance, if a user uses a meeting point ruled by his/her bank, it makes no sense to hide his/her credit card number to it. Extending this idea, to make a credit card payment an agent could move to a specialized payment site ruled by the its user’s bank. The bank would check the signature on the agent and let it make credit card payments on behalf of the signing user.

5. Industrial Benefits The new agent-based architectures for virtual markets are creating a new way of business . Specific benefits for the consumers are: time saving (since agents do most of the work for them), better deals (since agents can process and consider thousands of offers) and support for off-line operation (since user’s machine doesn’t need to be permanently connected) . Specific benefits for business include: • For SME’s and even personal traders, this architecture is a good way to create a virtual selling presence in Internet at low cost. This kind of business may not be able to create a big selling presence, so it can be very difficult for them to get widely known. This architecture helps to solve the problem, allowing the sellers to reach to a significant number of users, with a minimum cost in comparison with the high costs of establishing and promoting traditional virtual shops. • For big traders, this is another way of arriving to clients in an inexpensive way. Barriers are related to the lack of standardization of the technologies involved. Troubles derived from the early state of development of this technology will have to be addressed. It’ll be also needed to study consumer’s reactions to this way of conducting commerce.

6. Prototype description The first prototype of our architecture provides the basic functionality required for operating in an experimental environment. Our main goal with this prototype is experiment with final users’ view of the system, detecting their reactions and points of view before of making a fully functional implementation. Results from our experiments will be reported. To achieve mobile-agents support we have used the Voyager platform from ObjectSpace. This platform based in the Java language provides us with support for mobility and efficient group communication. For KQML support we use an existing JAVA API. This prototype also implements the “register-interests” and the “search-interests” services storing the required information in an Oracle relational database. These services

are implemented using the JDBC API to connect against the mentioned database. So, currently it’s possible to create agents, send them to a meeting point and them wait for deals to be made. The ontologies currently used are very limited and only valid for verification purposes. Besides, buyer agents only obtain references to the sold products and no electronic payment support has yet been implemented.

7. Conclusions This paper has described an architecture for building open virtual commerce meeting points where agents can interact, negotiate and conduct electronic transactions. We believe that the architecture provides a suitable way for matching buyers and sellers on the Internet, helping to make the process simpler, faster, and more comfortable for the final users. The architecture gives support for authentication, open communications, publishing and searching interests, negotiation, electronic agreements and payments. In comparison with other agent-based schemas for electronic commerce, our architecture is open, which improves fastness, security and solves the problem of accessing very heterogeneous virtual shops and gives support for agreements and payments directly between agents. The first prototype based on this architecture, the BISHOP system is built in JAVA to achieve platform-independence, and using the Voyager platform for mobile agents support. Publishing and searching services are implemented using JDBC connections against an Oracle DB. We’re currently working on building on the prototype the remaining features of the architecture. Then we intend to conduct trials with real users to study their reactions and thoughts to the system. References [1] A. Chavez, P. Maes, Kasbah. An agent marketplace for buying and selling goods. I International Conference on the Practical Applications of Intelligent Agents and MultiAgent Technology. London, 1996 [2] T. Sander, C. Tschudin. Protecting Mobile Agents against malicious hosts. LNCS on Mobile Agent Security, 1997. [3] T. Finin and R. Fritzson. KQML as an agent communication language. Proceedings of the Third International Conference on Information and Knowledge Management, 1994. [4] K. Binmore, N. Vulkan. Applying Game Theory to Automated Negotiation. DIMACS Workshop on Economics, Game Theory and the Internet, April 1997. [5] J. Rosenschein, G. Zlotkin. Rules of Encounter, The MIT press, Cambridge 1994. [6] C. Di Napoli, M. Giordano, M. Mango. A PVM implementation of the Fishmarket Multiagent System. [7] M. Tsvetovatyy, M. Gini. Toward a Virtual Marketplace: Architectures and Strategies. Proceedings of PAAM’96, pp. 597-613. London, 1996. [8] B. Cox, J.D.Tygar, M. Sirbu. NetBill Security and Transaction Protocol. Proceedings of the First USENIX Workshop on Electronic Commerce. 1995 [9] G. Medvinsky, B. Clifford Neuman. A design for practical electronic currency on the Internet. Proceedings of 1st ACM Conference on Computer and Communication Security. 1993 [10]C. Meadows. Detecting attacks on mobile agents. Proceedings of DARPA workshop on foundations for secure mobile code, USA, 1997. [11]D. Kramer. The JavaTM Platform. White Paper, 1996. [12]Voyager Core Package Technical Overview. Object Space Inc. 1997 [13]Altavista Internet search engine. http://www.altavista.digital.com [14]Yahoo !! Internet Search engine. http://www.yahoo.com [15]Bargain Finder. http://bf.cstar.ac.com [16]AdHound. http://www.classifiedwarehouse.com [17]TeleScript Technology: The Foundation for the Electronic MarketPlace. General Magic Technical report. http://www.genmagic.com