Mobile Agents for Telecommunication Applications: 4th International Workshop, MATA 2002 Barcelona, Spain, October 23-24, 2002, Proceedings

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis, and J. van Leeuwen 2521 3 Berlin Heidelberg New Y...

Author: Ahmed Karmouch | Thomas Magedanz | Jaime Delgado

59 downloads 948 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis, and J. van Leeuwen

2521

3

Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Tokyo

Ahmed Karmouch Thomas Magedanz Jaime Delgado (Eds.)

Mobile Agents for Telecommunication Applications 4th International Workshop, MATA 2002 Barcelona, Spain, October 23-24, 2002 Proceedings

13

Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editors Ahmed Karmouch School of Information Technology and Engineering, University of Ottawa 161, Louis Pasteur, Ottawa, Ontario, K1N 6N5 Canada E-mail: [email protected] Thomas Magedanz Fraunhofer Institut FOKUS Kaiserin-Augusta-Allee 31, 10589 Berlin, Germany E-mail: [email protected] Jaime Delgado Universitat Pompeu Fabra, Departament de Tecnologia Pg. Circumvallació 8, 08003 Barcelona, Spain E-mail: [email protected]

Cataloging-in-Publication Data applied for Bibliograhpic information published by Die Deutsche Bibliothek Die Deutsche Bibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data is available in the Internet at http://dnb.ddb.de

CR Subject Classification (1998): C.2, D.2.12, I.2.11, D.4.3-4, D.4.6, E.1, H.3 ISSN 0302-9743 ISBN 3-540-00021-6 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag. Violations are liable for prosecution under the German Copyright Law. Springer-Verlag Berlin Heidelberg New York a member of BertelsmannSpringer Science+Business Media GmbH http://www.springer.de © Springer-Verlag Berlin Heidelberg 2002 Printed in Germany Typesetting: Camera-ready by author, data conversion by Olgun Computergrafik Printed on acid-free paper SPIN: 10873081 06/3142 543210

General Chair Jaime Delgado, Universitat Pompeu Fabra (UPF), Spain

Program Co-Chairs Ahmed Karmouch, University of Ottawa, Canada Thomas Magedanz, IKV++ Tec-AG, TU Berlin, Germany

Tutorials Chair Isabel Gallego, UPC, Spain

Publicity Chair Rosa Gil, UPF, Spain

Local Arrangements Co-Chairs Jaime Delgado, UPF, Spain Josep Polo, UPF, Spain

Steering Committee Eric Horlait, LIP6, France Roger Impey, NRC, Canada Ahmed Karmouch, University of Ottawa, Canada Thomas Magedanz, IKV++, Tec-AG, TU Berlin, Germany

In Cooperation with IEEE Computer Society IFIP

Preface

Research in the telecommunications field suggests that future network infrastructures will be composed of sensors, wireless devices, personal digital assistants, networked appliances and numerous types of services. This brings up key issues such as unfamiliar users and service interfaces, discovering services that match user’s needs, finding and tracking people and resources, establishing useful contacts and appropriate associations between resources and users, and managing a large number of dynamic network entities all of which must be performed in an automated and proactive manner with a certain degree of autonomy and mobility. These are the main characteristics exhibited by mobile software agent behavior, making the technology more suitable for future telecommunication applications and services. It also reveals the tremendous potential for the mobile agent paradigm. The potential complexity of mobile agent operation requires that mechanisms exist on several levels to coordinate its activities. For this purpose research and development on various forms of mobile agents continues to grow in a staggering fashion. Agentbased applications and services such as network management, e-commerce, information gathering on the Internet, mobile communications, active networking, and most recently ad hoc communications are becoming increasingly popular and continue to contribute to the development and to the success of mobile agent technology. In addition it is well established that mobile agents is an ideal sister technology for mobile ad hoc networks where users, applications, services, devices and networks are mobile and dynamically configurable. The papers in this volume discuss issues from models, platforms, and architecture for mobile agents to security, communication, mobility, implementation, applications and management. They cover both practical experience and novel research ideas and concepts. We would like to express our appreciation and thanks to the authors for their contributions to preparing and revising the papers as well as the technical program committee and the reviewers who helped put together an excellent technical program for the workshop. Special thanks are due to Hamid Harroud who kindly contributed his time and effort to help with the organization of the review process and technical program. October 2002

Ahmed Karmouch Thomas Magedanz Jaime Delgado

Program Committee L. Ananda, NUS, Singapore P. Bellavista, DEIS-LIA-Universita’ degli Studi di Bologna, Italy ´ J.-C. Bernard, Ecole Poly. de Montréal, Canada A. Bieszczad, Lucent Technologies, USA R. Boutaba, University of Waterloo, Canada U. Cortés, UPC, Spain T. Chen, Southern Methodist University, USA J. Delgado, Universitat Pompeu Fabra, Spain J. Celestino, Federal University of Ceara, Brazil B. Falchuk, Telcordia Technologies, USA V. Gay, UTS, Australia M.-P. Gervais, LIP6, France R. Glitho, Ericsson Research, Canada T. Gray, Mitel Networks, Canada E. Horlait, LIP6, France R. Impey, NRC, Canada I. Jabbari, George Mason University, USA A. Karmouch, University of Ottawa, Canada G.S. Kuo, National Central University, Taiwan R. Liscano, Mitel Networks, Canada A. Liotta, University of Surrey, UK T. Magedanz, FhG FOKUS/TU Berlin, Germany S. Pierre, Ecole Poly. de Montreal, Canada S. Poslad, Queen Mary University, London, UK R. Sangüesa, UPC, Spain R. Stadler, ETH Zürich, Switzerland V. Roth, FhG, Germany J.-F. Wagen, UASW Switzerland, Fribourg

Table of Contents

Agent Architectures, Frameworks and Platforms Options for Reusing Agent Conversations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Santtu Toivonen (VTT Information Technology, Finland), Heikki Helin (Sonera Corporation, Finland)

1

Multi-management Schemes for MAF Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Rui Pedro Lopes (Polytechnic of Braganca, Portugal), José Luis Oliveira (University of Aveiro, Portugal) An Architecture for Negotiation with Mobile Agents . . . . . . . . . . . . . . . . . . . . . . . . 21 Jaime Delgado (Universitat Pompeu Fabra, Barcelona, Spain), Isabel Gallego (Universitat Politècnica de Catalunya, Spain), Roberto Garc´ıa, Rosa Gil (Universitat Pompeu Fabra, Barcelona, Spain)

Mobile Agent Frameworks for Telecommunication Services Internet Agents for Effective Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Vidya Renganarayanan, Abdelsalam Helal, Amar Nalla (University of Florida, USA) Programming and Executing Telecommunication Service Logic with Moorea Reactive Mobile Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Bruno Dillenseger, Anne-Marie Tagant, Laurent Hazard (France Télécom R&D, France) Generic Engineering Approach for Agent-Based System Development . . . . . . . . . 58 Seongkee Lee, Taiyun Kim (Korea University, Korea)

Mobile Agents in Active Networks An Ecosystem-Inspired Mobile Agent Middleware for Active Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Daniel Rossier, Rudolf Scheurer (Swisscom Co. Technology, Switzerland) An Enhanced Mobility Management Mechanism for Active Access Networks . . . . 83 Insu Kim, Keecheon Kim, Sunyoung Han (Konkuk University, Seoul, Korea), Hyukjoon Lee (Kwangwoon University, Korea) An Architecture for Active Network Performance Management Based on Intelligent Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Antonio Barba, Ernesto Sánchez (Universidad Politécnica de Cataluña, Barcelona, Spain)

X

Table of Contents

Context Aware and Ad Hoc Communications Agent-Based Context-Aware Ad Hoc Communication . . . . . . . . . . . . . . . . . . . . . . . 105 Mohamed Khedr, Ahmed Karmouch (University of Ottawa, Canada), Ramiro Liscano, Tom Gray (Mitel Corporation, Canada) Designing Multimedia Service Agents for Mobile Users . . . . . . . . . . . . . . . . . . . . . 119 Mohamed Ahmed (National Research Council, Canada), Hamid Harroud (University of Ottawa, Canada), Roger Impey (National Research Council, Canada), Ahmed Karmouch (University of Ottawa, Canada) A Mobile Agent-Based Framework for Configurable Sensor Networks . . . . . . . . . 128 Takeshi Umezawa (Keio University, Japan), Ichiro Satoh (National Institute of Informatics, Japan), Yuichiro Anzai (Keio University, Japan)

Distributed Monitoring and Network Management Evaluation of Migration Strategies for Mobile Agents in Network Routing . . . . . . 141 Sergio Gonzalez-Valenzuela, Son T. Vuong (The University of British Columbia, Vancouver, BC, Canada) A Hybrid Approach to Network Performance Monitoring Based on Mobile Agents and CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Christos Bohoris, George Pavlou, Antonio Liotta (University of Surrey, Guildford, UK) Mobile Agent Distribution in a Game-Theoretic Approach . . . . . . . . . . . . . . . . . . . 163 Robert Sugar, Sandor Imre (Budapest University of Technology and Economics, Hungary)

Security for Mobile Agents Anonymous Communications for Mobile Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Larry Korba, Ronggong Song, George Yee (National Research Council, Canada) Implementation of Secure Architectures for Mobile Agents in MARISM-A . . . . . . 182 Sergi Robles, Joan Mir, Joan Ametller, Joan Borrell (Universitat Autònoma de Barcelona, Spain)

Mobile Computing and QoS Management Quality of Service Management in IP Networks Using Mobile Agent Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Telma Mota (PT Inova¸ca˜ o, Aveiro, Portugal), Stylianos Gouveris, George Pavlou (University of Surrey, Guildford, UK), Angelos Michalas, John Psoroulas (NTUA, Greece)

Table of Contents

XI

Transparent QoS Support of Network Applications Using Netlets . . . . . . . . . . . . . 206 Kalaiarul Dharmalingam, Martin Collier (Research Institute in Networks and Communications, Ireland) FIPA-Based QoS Negotiator for Nomadic Agents . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Alberto Montilla Bravo (Motorola España SA, Madrid, Spain), Marisol Garc´ıa Valls (Universidad Carlos III de Madrid, Spain)

Migration and Network Management System and Network Management Itineraries for Mobile Agents . . . . . . . . . . . . . . 227 Emmanuel Reuter, Fran¸coise Baude (INRIA–CNRS, France) Four Multi-agent Architectures for Intelligent Network Load Management . . . . . . 239 Stefan Johansson, Paul Davidsson (Blekinge Institute of Technology), Martin Kristell (4UIQ Technology, Sweden) Automated Management of IP Networks through Policy and Mobile Agents . . . . . 249 Kun Yang, Alex Galis (University College London, UK), Telma Mota (Portugal Telecomm Inovacao, Aveiro, Portugal), Stylianos Gouveris (University of Surrey, Guildford, UK)

Mobile Services Facilitating Agent Messaging on PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Sasu Tarkoma (University of Helsinki, Finland), Mikko Laukkanen (Sonera Corporation, Finland) Mobile Agents for Discovering and Accessing Services in Nomadic Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Zhou Wang (University of Karlsruhe, Germany), Jochen Seitz (Ilmenau Technical University, Germany)

Collaborative Environments and Services An Extensible Mobile-Agent-Based Framework for Coordinating Distributed Information Retrieval Applications . . . . . . . . . . . . . . 281 Edgar A. Olougouna, Samuel Pierre (Ecole Polytechnique de Montreal, Canada), Roch H. Glitho (Ericsson Research, Canada) Seamless Incorporation of Agents in an E-Commerce Intermediation Platform . . . 292 Irene Sygkouna, Maria Strimpakou (National Technical University of Athens, Greece), Francisco Valera (Universidad Carlos III de Madrid, Spain), Anastasia Kaltabani (National Technical University of Athens, Greece), Luis Bellido, Enrique Vazquez (Universidad Politécnica de Madrid, Spain), Miltiades Anagnostou (National Technical University of Athens, Greece)

XII

Table of Contents

UNITE – An Agent-Oriented Teamwork Environment . . . . . . . . . . . . . . . . . . . . . . 302 Michael Zapf, Rolf Reinema, Ruben Wolf, Sven Türpe (Fraunhofer Institute for Secure Telecooperation, Germany)

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Options for Reusing Agent Conversations Santtu Toivonen1 and Heikki Helin2 1

VTT Information Technology P.O.Box 1023, FIN-02044 VTT, Finland [email protected] 2 Sonera Corporation P.O.Box 970, FIN-00051 Sonera, Finland [email protected]

Abstract. We present different options for storing elements of agent communication. We base our approach on the assumption that elements of a single agent conversation instance can serve multiple purposes. We consider mobile adaptive agents that visit several kinds of domains and perform tasks that require communication with local systems. Especially, we focus on the action-related elements included in conversations. We make a distinction between type- and instance-level elements of and give reusability examples of both categories. We consider options ranging from storing the entire conversations to storing only the communicative acts taking place during the conversation.

1

Introduction

Human beings perform different kinds of tasks in different places. What you do in your car differs from what you do in your office. Also the information required for performing these local operations varies. It can be questioned where the information needed for performing these local operations is located. Cognition is traditionally studied as a phenomenon that takes place inside the heads of (human) agents. Unlike the traditional approach, theory of distributed cognition emphasizes processes and elements of cognition that are external to the agents. There has to exist at least one agent of some kind for a cognitive process to take place. Rest of the systems that participate in a cognitive process might be more passive ones. For example, a mathematical problem might be distributed across a human being and a calculator. The human agent releases some of his cognitive capacities like working memory by utilizing the calculator [11]. Theory of distributed cognition has concentrated mainly on human beings and how they distribute their cognitive processes. Software agents and other computer systems have only participated in distributed cognition from the human agent’s point of view. Human agent distributes his cognition to computer systems and benefits from doing so in one way or another. And computer systems, especially user interfaces, should be designed so that the cognition distribution is considered [9]. In this paper we apply the approach to software agents. Software agents are considered as creatures that distribute their cognition into the environments they visit. The concept of agent can be analyzed and decomposed into properties that constitute it. There are number of definitions containing varying combinations of properties A. Karmouch et al. (Eds.): MATA 2002, LNCS 2521, pp. 1–10, 2002. c Springer-Verlag Berlin Heidelberg 2002

2

Santtu Toivonen and Heikki Helin

important for agency. Autonomy, reactivity, proactivity, social skills, mobility, adaptability and intelligence are among the most frequent properties in the literature (see e.g., [7]). Adaptability and mobility are the most important properties in this paper, although neither is conceptually necessary for agency. We consider agent mobility and show that adaptability could be a useful property for a mobile agent. Agents wandering around can adapt to domain-specific information distributed in the Internet. In this paper we concentrate on the domain-specific information related to agent conversations. We decompose agent conversations into elements and consider distributing these into servers for future reusability. Furthermore, we focus especially on the elements that describe and control the progress of the conversations. In this paper we are not interested in the conversating agents, nor the things agents are conversating about. The rest of this paper is organized as follows. In Section 2, we analyze the conversation concept and decompose it into elements. Then, in Section 3, we discuss adaptability and divide it into two subclasses. In Section 4 we consider mobility and show how mobile agents might benefit from adaptability. Section 5 gives examples of mobile agents adapting to local settings by utilizing stored conversation elements. Finally, Section 6 concludes the paper and briefly discusses some future work.

2

Elements of Agent Communication

In this section we present two complementary possibilities for categorizing elements of agent communication. The first one concerns dividing communication components into fact- and action-elements. The latter introduces the difference between type and instance-level elements. To exchange their knowledge agents typically communicate by sending messages directly to each other. In this communication paradigm, the life span of the messages is short; they normally serve no function once they have been processed. We consider different view of agent communication, where agents store the elements of their communication for future use. Agents need not keep the communication elements to themselves after they are stored in a server; duplicating the information is typically inappropriate. Instead, the agents can retrieve the communication elements from servers when needed. However, the agents have to be able to understand the retrieved data sufficiently enough to utilize it. In other words, agents functioning like this have to represent adaptability. The details of adaptability are further discussed in the next Section. Figure 1 depicts dividing communication components into fact- and action-elements. Relevant components of agent communication and their interrelationships are presented. Topics of conversations, that is, the things agents are communicating about, are perhaps the most important instances of fact-elements. Examples of typical topics are the products that e-commerce agents buy, but topics can also be actions, conversations, agents, or propositions about any of these. Storing the topics is perhaps the simplest and most widely used option and not closely connected to storing the communication elements for further use. Context data is also an example of a useful fact-element. With context data it is possible to express relevant knowledge with respect to the particular conversation instance, such as information about time and place. Storing action-elements is more unusual than is the case with fact-elements. Storing fact-elements is typical and useful even if the agents utilizing them are not adaptive.

Options for Reusing Agent Conversations 0..*

3

conversation has *

action-element

fact-element

A proposition can be about any combination of any of the classes in this diagram.

1..* has

conversation-action

task

proposition 0..1

Interaction Protocol

has

has Communicative Act 1..*

content has

1

Fig. 1. Division into fact- and action-elements Table 1. Division into type- and instance-level elements

Type-level Instance-level

Primitive Communicative Act Message

Composite Interaction Protocol Conversation

However, we believe that sometimes it is useful to store and reuse action-elements, either instead of or in addition to fact-elements. Communicative acts and interaction protocols are the most important conversation-actions. Communicative acts are structured actions that are fundamental building blocks of agent conversations. A message that an agent sends to other agent(s) consists of the contents of the message and a performative describing the type of the communicative act. Interaction Protocols describe an ordered set of communicative acts and some restrictions on them. Naturally, there is more to agent communication than Figure 1 implies. Contents of communicative acts, for example, might have referential expressions, action expressions, an so on, in addition to propositions [4]. We have selected only the elements we feel are useful when storing agent conversations. Table 1 depicts another means of categorizing conversation elements. Conversation elements are either primitive or composite in nature. Primitive conversation elements consist of but one interaction instance between communicating agents. Composite elements, on the other hand, can include several interactions between agents. This distinction is already present in Figure 1. What is missing from Figure 1, however, is the distinction between type- and instance-level elements of agent communication. The difference between type- and instance-levels resembles the difference between classes and objects in the object-oriented paradigm. Communicative acts and interaction protocols are abstract templates that become messages and conversations when they are given

4


values. Values in this case are for example conversating agents, topics of conversations and context data. We give examples of reusing these conversation elements in Section 5.

3 Adaptability Adaptability stretches from simple adjustments of behavior with predefined parameters all the way to complex and unpredictable learning. An entity that can adapt to its surroundings represents more agency than its counterpart without the adaptation capabilities. From the designers viewpoint one can ask, however, whether implementing adaptive agents is feasible or not. Why not just create simpler and “stupider” taskspecialists instead of more complex agents with adaptation capabilities? An obvious issue is how fast the agent can adapt its behavior to the new environment. In [12], the authors concluded, that if the environment change rate is low, agents that do more reasoning perform better than those that employ a more straightforward behavior. On the other hand, if the world change rate is high, a straightforward behavior outperforms those agents that “waste” too much time on thinking. There are number of different means for categorizing environments, for example the following [13]: The environment can be accessible or inaccessible depending on whether the agent’s sensory receptors can receive all the aspects that are relevant to the agent’s following action. Further, the environment can be deterministic or indeterministic, depending on whether the current state and the actions performed by the agents determines the next state of the environment. The environment is episodic or nonepisodic depending on whether the agent’s experience can be divided into “episodes” consisting of sensing and then acting. It is static or dynamic depending on whether it can change while the agent is acting. Finally, it is discrete if the number of possible kinds of sense data and actions at one point of time is limited and continuous if the number is unlimited. These categorizations characterize one environment. The requirements for adaptation multiply when the agent is visiting several different environments. The more environments differ from each other, the better adaptation capabilities are required from agents visiting more than one of them. Adaptability can be sensitive to facts or tasks. By fact-sensitive adaptability, we mean that the agent can learn new concepts. For example, an agent searching for publications in the web might have concepts ‘book’, ‘article’, and ‘magazine’ in its ontology. Later, it might acquire a new concept called ‘position paper’and include it in its ontology as a subconcept of ‘article’. By task-sensitive adaptability, we mean the ability to acquire new tasks. For example, the agent searching for publications might learn some new means of performing searches. Elements of agent communication can be accordingly divided into two categories, as depicted in Figure 1: fact-elements and action-elements. Adaptability that is sensitive to action-elements means, for example, that the agent searching for publications encounters a new electronic library, and learns how to communicate with the librarian-agent. It is possible that several agents are communicating about several topics in a single environment. To retrieve the stored elements of conversation instances efficiently the elements have to be appropriately indexed. This presupposes the usage of ontologies, that is, the concepts of stored elements and their interrelations have to be defined properly. The usage of standardized ontologies eases the adaptation of agents created by independent parties.

Options for Reusing Agent Conversations

4

5

Mobility

Mobility is not conceptually necessary to agency. An agent that does not move is still an agent. Besides conceptually, mobility is also often bypassed when implementing agent systems. Often using message passing can be more efficient than moving the agent (see e.g., [14]). Implementing mobility can however be justified if the agents are also adaptive. It might be appropriate to send an agent to a remote environment if it can adapt to local settings there. Mobility in general can be divided into two categories: autonomous and involuntary mobility. Involuntary mobility can exist with whatever thing capable of moving. Planets orbiting in space give a good example of involuntary mobility. Autonomous mobility, on the other hand, presupposes an agent; there has to be somebody or something that decides to make the movement. Mobility in software agent applications can be divided into two main categories as well: mobile code and terminal mobility. Mobile code means that the agent transfers itself from one host into another. Moving the code and state near the data source can reduce communication overhead significantly, assuming the agent can perform some data filtering at the remote location. Terminal mobility occurs when moving a mobile device such as a handheld device or a laptop computer from one environment into another. For example, nowadays several wireless access technologies— such as GSM, GPRS, and UMTS in the near future–can be used to connect the mobile device to the fixed network. Should the mobile device change the access technology, the agents situated in that device may have to change their behavior to fit the chosen technology. There is no difference between mobile code and terminal mobility as far as considering adaptability. In both cases, the agent enters a new environment and has to adapt. Mobile code is usually autonomous; the software agent moves itself according to its own decisions. The agent makes the final decision of its own movement even if the initial command comes from a human user or from another agent. Terminal mobility is typically involuntary with respect to the software agent. When moving the mobile device from one place into another in the physical world the software agent typically has no control over it. However, sometimes, it might be the agent that initiates the terminal mobility. For example, the agent might be responsible for choosing the most suitable access technology. Now, the agent notices that a better access technology is available and performs (autonomously) necessary roaming activities. In this case, the terminal mobility can be considered autonomous from the agent’s standpoint. Although the terminal is not necessarily moving in this, the agent’s environment might change dramatically. Although there are many technical limitations and drawbacks with mobile agents, they might prove useful sometimes. If the task is complicated, for example, mobile agents can prove to be an appropriate approach. An example of potentially complicated task is an auction that can include many messages sent between the auctioneer agent and the bidders. Transporting the bidder agent to the auction environment might often seem more appropriate than sending all the bids over the network. Auctioning is further discussed in the form of examples in Section 5.2.

6


2 BOOKSTORE1

HOME

1

IP-SERVER

4

BOOKSTORE4

5

BOOKSTORE2

3

BOOKSTORE3

Fig. 2. Visiting different environments

5

Examples of Agents Reusing Conversation Elements

Choosing the appropriate communication elements to store is usually case-specific. Sometimes it is appropriate to store entire conversations but sometimes only the topics of conversations. Yet at other times it is feasible to store nothing at all. It all depends on the things agents are communicating about or the tasks agents are carrying out. The choice of the combination of elements to store is unbound. For example, storing a communicative act does not require storing the contents it has, and storing the content does not presuppose storing the communicative act. The alternatives presented in Table 1 enable four different possibilities for storing and reusing agent conversations. In this section we consider each of these. First we consider the two options of type-level reusability. These options deal with machine learning of a kind. The basic idea is that the agent is introduced with some new conversation element that is structurally understandable for the agent. The latter two options are about instance-level reusability. In these cases the benefit of reusability comes from coupling fact-elements with action-elements into a whole that is searchable and retrievable with several parameters. 5.1 Type-Level Reusability Storing the interaction protocol descriptions is useful for example if minor adjustments to the protocols are made. Consider an agent with the intention of buying a book. The agent visits several electronic bookstores that have different policies of buying a book. This is depicted in Figure 2. When arriving to the BOOKSTORE1 , the agent first downloads instructions on how to use the service from the server (1). The agent examines the instructions and finds out that BOOKSTORE1 provides only two services: The agent can query the price of the book and the agent can buy the book. The first one is carried out, for example, using (say) the fipa-query interaction protocol [6] and just by giving the necessary information, for example credit card number, to the service, carries out the second one. Let us assume, that the agent knows the fipa-query interaction protocol. Therefore, it can query the price immediately (2). Based on the price, the agent decides not to buy the book yet but to find out the options provided by other bookstores first.


7

In BOOKSTORE2 , the agent again downloads the service usage instructions from the server (3). Now, the agent finds out that this service provides a more sophisticated way of interaction, and that an interaction protocol called x-bstore2 should be used when communicating with the service. The agent is unaware of this interaction protocol, but the service description contains a pointer to another server, namely IPSERVER, that contains the instructions for using this interaction protocol. The agent downloads the instructions from IPSERVER (4), and then can interact with BOOKSTORE2 (5). After visited all the electronic bookstores, the agent decides to buy the book from some bookstore. The agent goes back to that server and gives the necessary information to the server and later the book is delivered to the owner of the agent. The example above illustrated a possible usage of storing interaction protocol descriptions, and how this improves the interoperability between communicating agents. As communicative acts are similar kinds of building blocks of agent conversations, similar examples of storing communicative acts can be thought. Assuming a common description language for communicative acts, and that agent knows some primitive acts, it is possible to use this language for describing composite acts. These descriptions can then be stored to some common server, from where communicating agents can download them for use. We are considering the Semantic Web as one possible framework for adaptive agents as described in this paper. The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation [2]. Semantic Web technologies provide means for agents to publish their messages on web pages, and thereby it is one possible framework for this communication paradigm. Brokers could index the published messages and the indexed messages could later on be utilized either by the agent itself or by other agents [3]. For a common description language we are considering DAML+OIL [10]. More specifically, DAML-S process ontologies [1] might function well for storage format for action-elements of conversations. For the time being, however, it is not clear how to represent for example interaction protocols in DAML-S. That is why in [8] the authors consider plain XML for serializing interaction protocols.

5.2

Instance-Level Reusability

The occasions when reusing instance-level elements is useful differ from type-level occasions. Storing and reusing messages, for example, is useful when mere reusability of communicative acts or fact-elements included in messages is not enough. This section describes an example for storing and reusing instance- level conversation elements. Consider again the bookstore example presented above. Say BOOKSTORE2 is an auction house where agents bid for books. BOOKSTORE2 utilizes the FIPA English Auction Interaction Protocol [5] that has the following structure: First the auctioneer (initiator) sends an inform-start-of-auction message that indicates that the auction is announced open. Then it sends a cfp for some item. Then the bidders (participants) send either a not-understood or propose messages back to the auctioneer. After that the auctioneer either accepts or rejects the proposals. If the proposal the auctioneer received is appropriate and no higher bids emerge, the auctioneer informs the bidders

8


about the result and requests the winning bidder to complete the transaction. Otherwise it sends another cfp and the bidding continues. Like any electronic store, also BOOKSTORE2 wants some identification about its customers prior to completing transactions. Since BOOKSTORE2 is an auction house, the identification is perhaps even more important than if it were a regular bookstore. The auctioneer has to be able to trust the bidders. If some misunderstanding or intentional cheating emerges, the auctioneer has to be able to present proof about the bidders and the amounts they have committed to pay for items. That is why BOOKSTORE2 stores the conversation elements between the auctioneer and the bidders. The messages serve a different purpose when reused than when used for the first time. They are no longer used as messages but rather as evidence about commitments of bidder agents. Note that storing only the interaction protocols or communicative acts would not help in this situation; what is important is who has sent the messages. Naturally, BOOKSTORE2 has to exploit strict authentication mechanisms to prevent agents from bidding under false names. Discussing the authentication mechanisms is however outside the scope of this paper. BOOKSTORE2 has the opportunity to store either the whole conversations or the mere propose messages sent by the bidders. Storing only the propose messages would suffice if the following three pieces of information were present: identification of the bidder agent, identification of the item, and the amount of money offered by the bidder agent. BOOKSTORE2 has however decided to store the entire conversations instead of mere propose messages. That is because it wants to maintain statistics about the frequent customers, average selling prices of items, bidding strategies of agents, and so on. Maintaining statistics is again typical for electronic business—or any business for that matter. Stores want to know their customers and place them into certain segments by collecting data about their shopping habits. Figure 3 depicts the procedures for participating an auction in BOOKSTORE2 . Both agents, agent A and agent B, represent the same customer. When A registers for an auction (1), it is the first time for the customer, that is, there exists no prior information about the customer in the records of BOOKSTORE2 . Agent A passes for example the credit card number of the customer to the bookstore. The auction is then performed (2) and after that stored to the conversation database (3). Later, when agent B registers for another auction (4), the trustworthiness of the customer is first checked by examining earlier auction descriptions from the conversation database (5). If the customer proves to be trustworthy, B can participate in the auction (6) that is thereafter stored in the conversation database (7). But if agent A or some other agent representing the same customer has previously cheated or performed some other malicious actions, BOOKSTORE2 has the opportunity to reject agent B’s participation.

6

Conclusions and Future Work

We analyzed different options for storing the elements of agent communication. Elements of agent communication can be divided into those that concern the progress of the conversations and those that concern facts related to the conversation, such as the things agents are communicating about. Of these categories we concentrated mainly on the


9

BOOKSTORE1

HOME

ConvDB

A 2

BOOKSTORE4

1

4

B

3

5

7

BOOKSTORE2

6

BOOKSTORE3

Fig. 3. Checking the trustworthiness of agents

former. Additionally, we categorized the conversation elements into type- and instancelevel elements. We gave examples on different cases suitable for reusability. We discussed why the ability for adapting to these conversation elements might be a useful property for mobile agents acting in heterogeneous environments. Our further work includes implementing a framework—based on Semantic Web technologies—for agents that are adaptive as described in this paper. Further, we are considering ad-hoc networks. A new agent that enters a network (typically in a mobile device carried by a human user) could receive pointers to appropriate servers containing information about the nature and procedures of that particular network. For example, hosts of a conference could maintain such a network. Different kinds of information related to the event such as maps of the city, proceedings of the conference, and details of the banquet party could be provided to people when entering the venue. Some of the information might vary based on the status of the participant. When a regular participant enters the conference venue, the agent in his mobile device could pick up an interaction protocol description for registering for the conference. After adapting its behavior based on the description the agent can perform the registration and pay the participation fee. Invited speakers, on the other hand, typically need not pay the fee. The agent in an invited speaker’s device might instead receive a pointer to an interaction protocol description that helps his personal agent to specify practical details of the invited speaker’s dinner cruise, such as special diets, table preferences, and musical tastes.

References 1. A. Ankolenkar, M. Burstein, J. R. Hobbs, O. Lassila, D. L. Martin, D. McDermott, S. A. McIlraith, S. Narayanan, M. Paolucci, T. R. Payne, and K. Sycara. DAML-S: Semantic markup for web services. In International SemanticWeb Workshop—Infrastructure and Applications for the Semantic Web, pages 411–430, 2001. 2. T. Berners-Lee, J. Hendler, and O. Lassila. The semantic web. Scientific American, May 2001. 3. R. Cost, T. Finin, A. Joshi, Y. Peng, C. Nicholas, I. Soboroff, H. Chen, L. Kagal, F. Perich, Y. Zou, and S. Tolia. ITtalks: A case study in the semantic web and DAML+OIL. IEEE Intelligent Systems, 17(1):40–47, January/February 2002. 4. Foundation for Intelligent Physical Agents. FIPA Communicative Act Library Specification. Geneva, Switzerland, 2000. Specification number XC00037.

10


5. Foundation for Intelligent Physical Agents. FIPA English Auction Interaction Protocol Specification. Geneva, Switzerland, 2000. Specification number XC00031. 6. Foundation for Intelligent Physical Agents. FIPA Query Interaction Protocol Specification. Geneva, Switzerland, 2000. Specification number XC00027. 7. S. Franklin and A. Graesser. Is it an agent, or just a program?: A taxonomy for autonomous agents. In Proceedings of the ECAI’96 Workshop on Agent Theories, Architectures, and Languages: Intelligent Agents III, volume 1193 of LNAI, pages 21–36. Springer-Verlag: Heidelberg, Germany, August 1997. 8. J. Freire and L. Botelho. Executing explicitly represented protocols. In Proceedings of the 1st International Workshop on Challenges in Open Agent Systems, AAMAS’02, pages 37–40, Bologna, Italy, July 2002. 9. J. Hollan, E. Hutchins, and D. Kirsh. Distributed cognition: Toward a new foundation for human-computer interaction research. ACM Transactions on Computer-Human Interaction, 7(2):174–196, 2000. 10. I. Horrocks, F. van Harmelen, and P. Patel-Schneider, editors. DAML+OIL. 2001. http://www.daml.org/2001/03/daml+oil-index. 11. E. Hutchins. Cognition in the Wild. MIT Press, Cambridge, MA, 1996. 12. D. Kinny and M. P. Georgeff. Commitment and effectiveness of situated agents. In Proceedings of the Twelfth International Joint Conference on artificial Intelligence (IJCAI-91), pages 82–88, Sydney, Australia, August 1991. Morgan Kaufmann publishers Inc. 13. S. J. Russell and P. Norvig. Artificial Intelligence: A Modern Approach. Prentice-Hall, Englewood Cliffs, NJ, USA, 1995. 14. M. Straßer and M. Schwehm. A performance model for mobile agent systems. In Proceedings of the International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA’97), pages 1132–1140, Las Vegas, NV, USA, 1997.

Multi-management Schemes for MAF Platforms Rui Pedro Lopes1 and José Luis Oliveira2 1

Polytechnic Institute of Bragança, ESTiG, 5300 Bragança, Portugal VPSTIW$MTFTX 2 University of Aveiro, DET, 3810 Aveiro, Portugal NPS$HIXYETX

Abstract. Due to the crescent complexity of networks and systems, network management solutions are being pushed towards more distributed and cooperative models. Several specifications promoted by the IETF DISMAN charter already allow strong distribution of management tasks. Unfortunately, they are not adequate to achieve cooperative models. According to recent research, mobile agents provide a good platform to back cooperative models but several lacks are still identified – interoperability between different platforms and SNMP integration. Based on Mobile Agent Facility specification from the OMG, we propose a MIB to better integrate mobile agent models into SNMP frameworks and a GUI tool to monitor and control mobile agents platforms.

1

Introduction

There are several different ways to look at the term mobile agents. Usually it is used to name a mobile code paradigm where processes are allowed to migrate autonomously to another host and resume execution seamlessly. However, in the distributed artificial intelligence field, the term mobile agent refers to an intelligent agent with an additional property: mobility. As such, it encompasses a lot more than simply mobile code. In the context of this paper, and according to several positions about this field [1][2], we use the term mobile agents as the former although allowing a mobile agent to become, at some point, intelligent. We also consider that code mobility in the context of mobile agents also implies state mobility. If the platform does not allow strong mobility – transparent migration of state and code – the programmer can always explicitly preserve the agent state (weak mobility) [3]. Mobile agents require a runtime platform (agent system) that provides them with the resources they need to operate. The agents’ platform is typically constructed within a single organization in a closed way, and it usually supports agents that are strictly developed for that specific platform. The absence of standards for an agent system API limits or even eliminates the possibility for interoperability between different vendors’ products. This also means that the monitoring and management operations over any kind of agent element are performed with proprietary tools through proprietary methods.

A. Karmouch et al. (Eds.): MATA 2002, LNCS 2521, pp. 11–20, 2002. © Springer-Verlag Berlin Heidelberg 2002

12

Rui Pedro Lopes and José Luis Oliveira

The Mobile Agent Facility (MAF) specification is the first attempt to standardize agent system actions, thus aiming to achieve interoperability between different manufacturers’ agent systems [4]. MAF is a collection of definitions and interfaces designed as simple and generic as possible to allow future development in mobile agent systems. MAF uses OMG’s IDL to declare two interfaces, which are the base to all the operations on the agent system and on the region: the MAFAgentSystem and the MAFFinder. MAF interfaces specify a common access method to mobile agent platforms. So, any MAF platform can be managed by following the same procedures with the same tools. Concepts such as agent, place, agent system and region are the base of MAF nomenclature. A place is a logical entity where agents operate. Places can provide differentiated environments for agents depending, for instance, on agent goal, on organizational policies or on access control. The agent system (or agency for some) is the environment for several places, typically corresponding to a host. The region is more or less an organizational classifier that allows mimicking, in this environment, the domain concept of the IP-based LANs. On the other hand, the SNMP is, so far, the framework of choice from a large number of equipment (hardware, software and technical knowledge), so any near upcoming management architecture have to deal with SNMP standards. Thus, it is natural the coexistence of mobile agent and SNMP. Why should mobile agents be managed by SNMP? First of all, SNMP is specifically designed for management operations. Moreover, there are available several SNMP based powerful applications and quite a number of installed systems rely on them. This way it is possible to integrate both the mobile agent technology and the SNMP management architecture thus getting the advantages of both [1][5]. Management systems in general and SNMP in particular define a tool, usually called network management station, which provides the user with views of the network current and past state. With this tool, the user may be acquainted of the eventual problems and the current running condition. The continuous introduction of technological waves in modern networks forces these applications to cope with different models, access methods or security mechanisms. We recently proposed the use of URI (Uniform Resource Identifier) schemes [6] to identify the service tools to use in a common context interface, just like in Internet browsers. The resource is specified in the address field by the URI and, according to its grammar, it calls the appropriate tool for processing and presentation [7]. This approach allows using the same tool for managing different network elements as well as using different access mechanisms. The work presented in this paper follows some previous work related to the management of mobile agents and agent systems through MAF interfaces and SNMP. This work started by defining a specific MIB to convert between SNMP commands and MAF interfaces calls [8]. This paper is structured as follows: section II describes the MAF-MIB structure and its main functionality; section III describes some usage scenarios for the SNMPMAF association; section IV reveals the URI based mobile agent management station; the paper ends with some conclusions.

Multi-management Schemes for MAF Platforms

2

13

The Mobile Agent Facility MIB

The Mobile Agent Facility specification (MAF) is a first attempt to standardize agent system, i.e. the middleware that allows agents to stop, to move and to restart execution in another place. MAF uses OMG IDL to declare two interfaces, which are the base to all the operations on the agent system and on the region (some sort of domain in mobile agent technology): the MAFAgentSystem and the MAFFinder. The MAFFinder interface consists on an access point to a naming service for agents systems, places and agents. Catalogue and lookup are the main functionalities of this interface. The MAFAgentSystem interface defines methods and objects that support agent management tasks such as fetching an agent system name and receiving an agent. Following the MAF specification, the MAF-MIB is structured in two groups1: mafObjects and mafLookup. The mafObjects group is related to agent system information, retrieved through the MAFAgentSystem interface. The mafLookup group allows directory service queries through MAFFinder interface (Figure 1).

SNMP

Message processing

MIB

ORB

Other comm.

MAFAgentSystem MAFFinder

Fig. 1. Architecture of the MAF-MIB SNMP agent.

Related work around SNMP management of mobile agents’ platforms suggests using specific MIB to manage specific platforms [9]. The advantage of this approach is the possibility to explore all the characteristics of the platform but it disallows using it with other agent platforms. MAF allows achieving agent platform independence. 2.1

The mafObjects Group

This group is mainly based on the MAFAgentSystem interface. It starts with a mafSysId section, which has information about the agent system authority, identification, type, description and version (Figure 2). While the agents travel, several errors can occur. The table mafErrorTable, maintains a record of these errors. 1

This MIB is available on http://nms.estig.ipb.pt/

14


a)

b)

Fig. 2. MAF-MIB managed objects structure. a) global structure. b) detailed view of the mafObjects group.

The agent system supports agents written in several programming languages, such as Java, TCL and others. A manager that wants to know which language is supported may “look” at mafLanguageTable. The following two tables, mafPlaceTable and mafAgentTable, provide a list of currently existing places and agents in this particular agent system. Moreover, the agent table allows the user to suspend, resume or terminate an agent by setting the required agent status (mafAgentRequiredStatus). The index to mafAgentTable is composed of the agent authority, its identity and its agent system type. This triplet ensures that every agent has a globally unique name. The last section, mafCreateAgent, holds the necessary objects for creating an agent. The first two objects, Authority and Identity, will be ignored if the user does not have naming responsibility. In this situation, the authority and identity will be set by the agent system. The Name and CodeBase provides the agent system with the necessary information to download the code and construct the agent. It thus follows the pull model [10]. The agent will be created on the provided place name (mafCreateAgentPlaceName) or on a default place if no place has been provided. It is also possible to define arguments to be passed to the agent constructor (mafCreateAgentArguments). After setting the required values, the agent is created by setting the mafCreateAgentGo to 1 (create).


2.2

15

The mafLookup Group

To suspend or terminate the agent the user has to know its location. This information can be retrieved from the mafLookup group (Figure 3). It focuses on lookup operations, performed mainly with MAFFinder interface method calls and is not restricted to a specific agent system. It can be used to perform lookup operations anywhere up to the region limits. This service has some special characteristics and, as such, some factors conditioned the MIB structure: − Search flexibility – Internet search engines use special keys to specify the search terms. The same approach, already used by the agent platform Grasshopper [11], should be followed for increasing the search flexibility. − Concurrent access – several search operations may be started simultaneously by different management applications. The search system has to deal with this kind of access. − Simplicity of usage – the search system has to be simple to use.

Fig. 3. The mafLookup group.

These factors resulted in the definition of search filters associated with a search table. The table mafFilterTable allows keeping several search filters, indexed by man-

16


agement application (mafFilterOwner) and by a locally unique name (mafFilterName). The filter has a description to detail its function and the type of elements to search for. The search filter is a character string stored in the column mafFilter and its syntax depends on the kind of element to look for. For example, the search for places is only performed by name. There are no other relevant characteristics for this element. For agents and agent systems the filter may support other terms, for example, the supported language or the serialization method. For this reason, the filter syntax allows performing rather complex search operations. Following the Grasshopper’s syntax, the filter may be defined according to the following rules: filter = item = comparator key = value =

item (|,&) filter /* or, and */ key comparator value = (=,^,$,~) /*equal, start, end, contains*/ string /* Name, Codebase, Lang., Serialization…*/ string

The filter “Name=pingAgent&Codebase~myHost” is an example of a search operation for an agent with the name “pingAgent” with the code base “myHost”. By setting the column mafFilterSearchFor, the search filter may be applied to look for places, agent systems and/or agents. This column is of type BITS so it allows one or more types. The filter may be activated (searching), i.e., perform a new search, or deactivated (stopped) in the column mafFilterAdminStatus. Similarly, its current state may be retrieved from the column mafFilterOperStatus: searching, stopped, finished. The column mafFilterRowStatus creates or destroys filter entries. According to the search type defined in mafFilterSearchFor, the results are retrieved from mafLocPlaceTable, mafLocASTable and/or mafLocAgentTable for places, agent systems and/or agents. These are related to the filter by the index mafFilterOwner and mafFilterName and can contain several results for a given search operation (mafLocPlaceIndex, mafLocASIndex and/or mafLocAgentIndex). In case some error occurs due, for example, to a wrong syntax or to any other problem, this is shown in mafFilterErrorTable. If the user destroys the filter entry, all the dependent results are also eliminated from the respective table.

3

MAF-MIB Usage Scenarios

The natural evolution of systems such as network management is towards distribution as its size and complexity increases [12]. The increase in size and complexity of modern networks makes centralized management difficult, if not impossible. It is harder to scale, less flexible and less robust. In fact, with increasing network sizes, the computational load as well as the network load on the central manager can grow to a point where it might no longer be able to monitor all agents. Flexibility is related to the network capacity to respond to new conditions and to accept new technology. Because management functions are typically predefined and limited this is harder to


17

achieve with centralized models. A system may become more robust if some kind of redundancy is achieved, so that it can resist better to error or fault conditions. This is also contrary to the centralized concept. The Management by Delegation (MbD) model, proposed by Goldszmidt in the beginning of the 90’s and fully specified in 1995 uses code mobility to delegate management tasks dynamically over a distributed set of management agents [13]. This approach uses the remote evaluation (REV) approach, where code is sent near the resources and executed locally [3]. The Distributed Management (DISMAN) charter [14] of the IETF followed this approach in the Script MIB [15]. This module receives management applications as scripts and executes them locally. Script MIB implementations may support different languages simultaneously. The Script MIB provides a SNMP compatible framework thus easing the integration of mobile code approaches with existing management systems. The possibility of association of mobile code with other SNMP MIB modules is a powerful approach and can reduce or even eliminate some of the SNMP deficiencies [16]. Although capable of receiving and executing code, the Script MIB is not well suited to define script based cooperative management systems. It also does not allow process mobility [10]. Several studies, experiments and authors have been supporting the advantages of using mobile agents in different aspects of network management [17-21]. We believe that such tool may be useful and so it should be considered as mechanism to increase the distribution level up to the cooperative model. The MAF-MIB presents a smooth integration between mobile agents and SNMP by providing a mechanism to launch, monitor and control mobile agents through SNMP. At the current state, the biggest differences between both approaches are related to security. The Script MIB relies on SNMP security mechanisms so every security detail is fully controllable by SNMP. In MAF-MIB, the security is strongly associated with the runtime environment, i.e. the agent system. As a consequence, it is possible to control by SNMP the launching and controlling restrictions but it is not possible to set the runtime security parameters by SNMP. It will have to be done in a platform specific way. Several comparison aspects between the Script MIB and the MAF MIB are condensed in Table 1. Table 1. Script and MAF MIBs reflection table.

Integration with SNMP Association with other MIB modules Remote control of management tasks Remote monitoring of management tasks SNMP security mechanism integration Process mobility Cooperative model Multi-language support Access to intermediate results Access to final results

Script MIB yes yes yes yes fully no no yes (implementation) By SNMP By SNMP

MAF-MIB yes yes yes yes partially yes yes yes (MAF) Platform dependent Platform dependent

18


Another particularity is the access to intermediate and final results. The Script MIB allows accessing results at any time by SNMP. The MAF-MIB only provides tools for searching for mobile agents and controlling its life cycle. For example, adding a supplementary column (mafAgentResult) to the mafAgentTable may eliminate this problem.

4

The MAF Explorer

In this context, we developed also a prototype of a GUI tool for the management of mobile agents supporting two simultaneous access methods, SNMP and CORBA, in a single interface. This tool differentiates the access method based on the provided URI. At the moment it accepts two URI schemes, namely, one for SNMP [7] and one for MAF. We defined a MAF URL with the format: scheme host port path

= = = =

[scheme:][//host:port][/path] “maf” IP address or equivalent Internet name integer the path registered in the CORBA name server

An example for MAF URLs: maf://localhost:1050/CfMAF. An example for SNMP URLs: snmp://[email protected]/?v3. The common syntax, although semantically different, allows defining a list of URLs (bookmarks or favorites) regardless of the management model. According to the URI scheme, the tool loads the appropriate module and proceeds along with the user commands (Figure 4). The MAF Explorer follows the file manager paradigm with a tree view on the left and the content panel on the right. The previous figure shows a tree view of the mobile agents’ platform resources and was built after setting the URL in the address field (upper right corner). If the user sets an SNMP URL, the tree is modified according to the information from the SNMP agent. On the right side, it shows the details of the node “CopyAgent”. The grayed labels indicate that the parameter is read only. As an example, the user cannot modify the agent location, although the agent may move autonomously. A black label indicates that the user may also change its value. The agent status may be altered to suspend, resume or terminate its running status. This tool is used as a “proof of concept” to validate the MAF MIB and yet both MAF and SNMP access methods to agent systems. It has a close correspondence with MAF methods and MAF-MIB objects and it can manage any MAF compatible mobile agent platform either directly, through the CORBA interfaces, or by SNMP, through the MAF-MIB.

5

Conclusions

Mobile agents are supported by a platform, which provides the resources that they need to operate. It is typically constructed within a single organization in a closed


19

Fig. 4. URI based mobile agent management tool.

way and interoperability between different vendors’ platforms is not generally available. Sensible to this problem, OMG introduced the MAF specification based on CORBA interfaces, a first attempt to standardize agent system actions. MAF defines common access methods to mobile agent platforms, promoting the adoption of a uniform set of management tools and procedures. We have presented a MAF MIB that provides an SNMP access on MAF platforms. Besides, it establishes common search operations and elementary tools that allow monitoring and modifying mobile agents’ life cycle. This MIB may also complement the DISMAN Script MIB to supply a base for developing cooperative network management models and process mobility thus increasing the distribution level. Finally, in order to validate this concept and also to allow the monitoring and control of MAF platforms and MAF-MIB SNMP agents, a management system was created.

References 1. Goldszmidt G., Yemini Y., “Delegated Agents for Network Management”, IEEE Communications Magazine, Vol. 36, No. 3 (1998) pp. 66-71. 2. T. Magedanz, T. Eckardt, “Mobile Software Agents: a new Paradigm for Telecommunications Management”, Proc. of the 1996 IEEE Network Operations and Management Symposium – NOMS’96, Kyoto, Japan, April 1996.

20


3. A. Fuggetta, G. Picco, G. Vigna, “Understanding Code Mobility”, IEEE Transactions on Software Engineering, Vol. 24, No. 5 (1998) pp. 342-361. 4. Mobile Agent Facility Specification, Object Management Group, 00-01-02.pdf (ftp://ftp.omg.org/pub/docs/formal/00-01-02.pdf). 5. R. Lopes, J. Oliveira, “On the use of Mobility in Distributed Network Management”, Proc. of the Hawaii International Conference on System Sciences – HICSS, January 2000. 6. T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax”, Internet Request for Comments 2396, August 1998. 7. R. Lopes, J. Oliveira, “A Uniform Resource Identifier Scheme for SNMP”, submitted to IPOM’2002. 8. R. Lopes, J. Oliveira, “SNMP Management of MASIF Platforms”, Proc. of the IFIP/IEEE International Symposium on Integrated Management – IM’2001, Seattle, May 2001. 9. P. Simões, L. Silva, F. Boavida, “Mobile Agent Infrastructures: a Solution for Management or a problem to Manage?”, proc. of the Conference of Telecommunications - ConfTele 2001, Figueira da Foz, Portugal, May 2001. 10. J. Schönwälder, J. Quittek, C. Kappler, “Building Distributed Management Applications with the IETF Script MIB”, IEEE Journal on Selected Areas in Communications, Vol. 18, No. 5, May 2000. 11. Grasshopper, the agent platform (http://www.grasshopper.de/). 12. J. Martin-Flatin, S. Znaty, J. Hubaux, “A Survey of Distributed Network and Systems Management Paradigms”, Technical Report SSC/1998/024, Swiss Federal Institute of Technology Lausanne, August 1998. 13. G. Goldszmidt, Distributed Management by Delegation, PhD Thesis, Columbia University, New York, December 1995. 14. DISMAN, (http://www.ietf.org/html.charters/disman-charter.html). 15. D. Levi, J. Schoenwaelder, “Definitions of Managed Objects for the Delegation of Management Scripts”, Internet Request for Comments 3165, August 2001. 16. F. Strauss, “Distribution Models for Network Management”, Project Report (http://www.ibr.cs.tu-bs.de/projects/jasmin/dismod.ps), June 2000. 17. T. Magedanz, R. Glitho, “Mobile agent-based network and service management”, Journal of Network and Systems Management, vol. 7, September 1999. 18. G. Knight, R. Hazemi, “Mobile agent-based management in the INSERT project”, Journal of Network and Systems Management, vol. 7, September 1999. 19. M. Zapf, K. Herrmann, K. Geihs, “Decentralized SNMP management with mobile agents”, Proc. 6th IFIP/IEEE Int. Symp. Integrated Network Management, Boston, May 1999. 20. P. Simões, L. Silva, F. Boavida, “Integrating SNMP into a Mobile Agent Infrastructure”, Proc. of 10th IFIP/IEEE International Workshop on Distributed Systems: Operations and Management – DSOM99, Zurich 1999. 21. J. Oliveira, R. Lopes, “Distributed Management based on Mobile Agents”, Proc. of the 1st International Workshop on Mobile Agents for Telecommunications Applications – MATA’99, Ottawa, Canada, October 1999.

An Architecture for Negotiation with Mobile Agents Jaime Delgado1, Isabel Gallego2, Roberto García1, and Rosa Gil1 1

Universitat Pompeu Fabra (UPF), Departament de Tecnologia Pg. Circumval·lació 8, E-08003 Barcelona, Spain _NEMQIHIPKEHSVSFIVXSKEVGMEVSWEKMPa$XIGRYTJIW 2 Universitat Politècnica de Catalunya, Departament d'Arquitectura de Computadors Campus Nord, Mòdul D6, Jordi Girona 1-3, E-08034 Barcelona, Spain MWEFIP$EGYTGIW

Abstract. New applications make networks increase their traffic daily, so a reliable and robust design must be provided to conform an architecture that could satisfy new needs. Terms as knowledge management, agents, ontologies, are key issues to achieve that architecture. Agent technology allows us to carry out interoperability and autonomy among the modules that build the architecture. Different kinds of devices are appearing, such as wireless devices. Then, a new group of applications are coming into the market, and a relevant characteristic is common in many cases: mobility. The general architecture for mobile agents applications we are describing in the paper generalises a set of applications and tools we are developing. We start the work in the context of Digital Rights Management (DRM), and a specific negotiation scenario and its implementation with mobile agents is discussed, before giving technical details of the architecture. This generic architecture includes elements coming from different disciplines, that are assembled to form a structure that fits diverse environments.

1

Digital Rights Management

A very promising sector for the application of mobile agents is e-commerce, in particular the e-commerce of multimedia content. When trading with multimedia content, one of the key issues is what does it happen with the Intellectual Property Rights (IPR) that are normally associated to that content, being a picture, a song, a video clip or any other audiovisual content. When managing those IPR, what is normally called Digital Rights Management (DRM), we have to face with many issues, most of them not having currently a really optimal solution. We first developed a system for e-commerce of video content (MARS project [1]), in which we initially focused on data localisation aspects following different metadata techniques for its implementation. Then, we added copyright information to that metadata, and we included watermarks in the content itself. The results of this project were our main starting point for the work presented in this paper. Apart from metadata, in relation to representation of the information, there are other aspects to consider when dealing with DRM, such as the issues associated to the Rights Expression Languages (REL) and Rights Data Dictionaries (RDD). A Rights Expression Language is seen as a machine-readable language than can declare rights A. Karmouch et al. (Eds.): MATA 2002, LNCS 2521, pp. 21–31, 2002. © Springer-Verlag Berlin Heidelberg 2002

22

Jaime Delgado et al.

and permissions using the terms as defined in a Rights Data Dictionary that provides a set of clear, consistent, structured and integrated definitions of terms for use in the REL. For this, the current standardisation efforts in MPEG-21 [2], that try to integrate previously existing initiatives, are a clear example. A different approach to that problem consists on specifying an IPR ontology able to add semantic information for the management of digital rights, allowing in this way the interoperability of different applications. We have developed “IPROnto” [3], an IPR ontology that formalises the IPR domain with a Semantic Web approach, describing IPR contracts, actors, intellectual property creations, rights, etc., together with a complete metadata framework and a rights data dictionary, using RDFSchema, DAML+OIL, … 1.1

IPR Business Models

In order to work on DRM, we need to select a model in which to base IPR representation and negotiation. The IMPRIMATUR Business Model [4], the one we have selected, identifies a series of entities that may take different roles, such as Creator, Provider, Rights Holder, Distributor, IPR Data Base, or Watermarking & Fingerprint marking. A simplified and specific model, the one we are implementing, consists on the use of a Broker (with the role of Distributor) in charge of being an intermediary between providers of multimedia material (content providers) and customers interested in buying that material and the corresponding rights for use and/or commercial exploitation. From a functional point of view, these copyrighted multimedia material providers may also assume the roles of Creator and Rights Holder in the same entity. Furthermore, the broker stores and keeps up to date (with the help of content providers) the information about the multimedia material for sale in the system (from all content providers associated to the broker), and about the terms and conditions in which commercial electronic transactions are done, with the help of the IPR Database. Fig. 1 illustrates this Broker Based IPR General Model.

&RQWHQW 3URYLGHU

Creator Provider Rights Holder

Distributor

%URNHU

IPR DataBase

Fig. 1. Broker Based IPR General Model

1.2

Negotiation of IPR Conditions

Based on the IPR attributes set, when a buyer requests, to the broker, a purchase of audiovisual material subject to copyright, the broker extracts IPR information from its

An Architecture for Negotiation with Mobile Agents

23

database and presents an initial offer to the buyer. This information allows the buyer to take a decision on how to buy IPR, i.e., to know what are the copyright rules associated to the asset, to decide if to re-sell it, etc. To facilitate this process, a negotiation mechanism has developed, and it is described later. The negotiation protocol, that it is part of the “Service Request” phase in an ecommerce model [5], has three sub-phases: − Initial offer, − Co-operative contract production, and − Payment. In the Contract production sub-phase, the most complex and important one, there are several alternatives over which to work. First, the selling entity initiates the protocol with an initial proposal of digital rights conditions, normally taken from a predefined subset. After that, the buying entity has three alternatives: 1. Accepting the offer, 2. Making a counter-offer and 3. Rejecting the offer. After the initial proposal, the negotiating entities elaborate the contract, using the negotiation protocol, from the sequence of offers and counter-offers until a final agreement is reached, forming then the final electronic contract.

2

An Implementation with Mobile Agents

We are implementing our agents and ontology framework, described in this paper, in the context of the NewMARS project, an extension of the MARS project [1], mentioned before, and integrated as a subproject of the AREA2000 project1. Apart from the results of the MARS project, we are also using results from other previous work [6] in our research group. As an example, we describe how we implement a specific DRM negotiation scenario, taken from MPEG-21 work [7]. In the scenario, the user is a web designer that has decided to use a specific image in her current web work. She wants to locate a specific version of this image and acquire the necessary digital rights to use it. The phases of this scenario, according to the NewMARS implementation, are: user interaction, search, negotiation, outcome presentation and control. A sequence diagram of them, except for the background control phase, is shown in Fig. 2. To fulfil this scenario, the web designer of our example uses the NewMARS facilities, so she interacts locally with her NewMARS user agent residing in her mobile device. She uses agent’s GUI to determine all the criteria required to select the image she is interested in. Then, the agent enters the search phase and it migrates to another agent-platform container (section 3.2 explains this process and why it is so important). This new container is one of the server kind, where it has better Internet connectivity and processing power. Thanks to these greater resources, it can carry on less constrained searches and a more accurate negotiation process of the required image. 1

Project supported by the Spanish government (TIC2000-0317-P4-05).

24


The search is performed through the NewMARS meta-search engine [8] that looks for the required image in some Internet image directories. When the content is found, the meta-search agent returns a reference to the agent managing the image rights and the image identifier. When the user agent owns enough information, it can start the automatic negotiation process through a protocol defined by rules (see section 3). The retrieved licensing agent is contacted and a call for proposals is issued. An initial offer is received, if the licensing agent really has the requested image. From this point, some counteroffers may be interchanged till the negotiation ends due to a reject or an agreement. The negotiation results are then communicated to the user. To facilitate user interaction, the user agent returns to the agent-platform container at the users mobile device. In parallel, a post-agreement background phase is initiated in the NewMARS system. This control phase is conducted to guarantee a fair use of the negotiated product. A more detailed description of these phases is given in the following sub-sections.

Meta-search Agent

User image request

Images Images Directory Directory

Licensing Agent

Rights Holder

User Agentt search result

search result callforproposals offer counteroffer agreement agreement payment payment license

outcome User

Fig. 2. Sequence diagram of the negotiation NewMARS scenario

2.1

User Interaction

The user initiates her user agent for images search and negotiation. This can be done in her desktop or, in our scenario, in her mobile device running Personal Java. The GUI shows up and the user interacts with the forms shown to specify the image she is interested in and in what conditions.


25

The GUI allows defining image characteristics, like image format, title, subject, size, dimensions, etc. The user can also determine the negotiation conditions, like price, allowed uses, period of time, etc. During the interaction, the user agent checks the defined image properties and values against the used ontologies, one for images and another one for digital rights. Thus, only valid constraints can be defined and the agent can assist the user during their definition. The constraints are modelled using RDF Model and Syntax [9] and the ontologies against which they are checked are modelled using RDF Schema [10]. RDF defines the syntax and semantics of the exchanged messages. An example is given in Table 1. Finally, the user submits the checked search and negotiation conditions. The user agent internally stores them and enters the search phase, detailed in the next section. 2.2

Search

When the user agent enters into the search phase, it moves from the lightweight container in the user wireless device to a server container in a wired and more powerful machine. From this new location the user agent contacts a directory of services to locate the meta-search engine. This directory is initially implemented using the FIPA [11] Directory Facilitator (DF) provided with the FIPA-compliant agent platform that is used. The DF returns a pointer to the agent implementing the meta-search engine, which previously registered itself in the DF. Once the user agent has located the meta-search agent, it can use its predefined interaction protocol. A FIPA ACL message containing the image characteristics and negotiation constraints is sent. The meta-search agent processes it and, after performing the necessary searches, returns a set of locations of licensing agents. They have registered themselves as negotiators of the requested image. One of them is selected and the negotiation process starts. 2.3

Negotiation

Once the user agent has selected a reference to a provider of the image it is looking for, the negotiation to obtain it begins. The negotiation protocol is obtained from the agent platform, where it has been previously registered. First, the customer agent issues a call for proposals referred to the desired image. Then, the licensing agent responds with an initial offer if it has the requested content, a refusal otherwise. An example of offer is shown in Table 1. Given that we are considering a totally automatic scenario, the user agent analyses this offer and decides what to do afterwards. If it does not accept the offer conditions, it can formulate a counter-offer. The same applies for the licensing agent when it receives the counter-offer. This interchange of counter-offers continues till any of the parties abandons the negotiation or an agreement arises. Finally, when any of the parties agrees with the last offer, the other party can also agree and an agreement is reached. An electronic contract is produced, i.e. a RDF/XML document quite similar to that shown in Table 1. It contains the agreed conditions and two extra elements pointing to both license consenters. Both parties digitally sign it with XML Signature [12] and the result is a license that authorises the costumer to use the negotiated content under the stated conditions [13].

26

Jaime Delgado et al. Table 1. Example of offer serialised as RDF/XML

2.4

Outcome Presentation and Control

When the negotiation has finalised, the results are communicated to the user. To facilitate user interaction, the user agent returns to the agent-platform container at the users wireless device. If the user agent has succeeded, a RDF document representing the achieved agreement is presented to the user through the agent GUI. It is formatted in a user-friendly manner and it contains a URL pointing to a location from where the licensed image can be retrieved. All the involved parts have digitally signed the RDF agreement; really their representative agents have performed this action. Therefore, it can be used as a licensing contract that proves that the requested uses have been authorised. If not agreement has been achieved the user agent presents the last outcomes of the negotiation process, the offer, counteroffer or refusal where the negotiation broke. Finally, the control phase occurs in parallel and continues in the background. Its purpose is to monitor that the customer fulfils the conditions established in the agreement license. In [6] we outlined different approaches to this issue using mobile agents.


3

27

The Architecture

Fig. 3 outlines the architecture we are developing. This is more general than the DRM negotiation implementation we have described in the previous section, since some parts still need to be developed further. In the following, we detail some technical aspects of the agents’ architecture we have designed. SOAP Wrapper (ARB)

SOAP Agent SQL RQL

Jess RDFSuite

RDF Facts Ontologies RDFS DAML+OIL Rules RDFLogic DAML-L RuleML Services DAML-S ...

Postgres

RQL

SQL

- negotiation JADE-LEAP protocol Mobile Agent - negotiation strategy - DAML axioms

UDDI Wrapper (ARB) ontology ontology

facts -> RDF RDF -> facts

Cloud ontology

UDDI

Fig. 3. Model Architecture

The managed data, the facts, are stored in a database using ICS-FORTH RDFSuite [14] that provides persistence and a RDF query language, RQL. The RDF facts are structured using different ontologies, allowing to model processes and rules, like DAML-S [15], RDFLogic [16] or RuleML [17]. DAML+OIL [18] capabilities are planned using Prolog and DAML+OIL axioms [19]. Agents are modelled using JADE [20], based on FIPA Standard [11]. They are coordinated by an inference engine, in our case Jess [21], that also cares about the negotiation protocol. CLIPS files (the Jess expert system format) store rules that govern coordination and negotiation protocol besides rules that allow understanding DAML ontologies. The coordination role consists on controlling invocations of JADE agents and their association to negotiation protocols by loading the corresponding CLIPS file that contains them. This file manages negotiation protocols, so it takes cares of message interchanging and translating the RDF content to Jess facts. Translation is performed by a DAMLJessKB module [22]. This can be done because Jess has DAML axioms as Jess rules, which represent an ontology inside this data base. Jess knowledge base interprets these facts firing rules and generating a result that will be converted back to RDF or DAML. We will concentrate on the final part, where the connection between agents belonging to a JADE platform and final users, who are represented by mobile agents inside a wireless device.

28

3.1


Mobile Agents for Wireless Devices

In February 2002, a new agent platform implementation appeared, JADE-LEAP[20], designed to integrate wireless devices. On the other hand, Sun [23] has developed J2ME, intended to wireless devices too (see Fig. 4), where we can find MIDP profiles [24], which are a subset of PersonalJava [25], allowing to build more sophisticated applications because it has been thought for PDAs.

Fig. 4. JADE-LEAP agents architecture, from JADE-LEAP user’s guide

Also we find some restrictions, as GUI on PersonalJava. It must be developed with the standard Java AWT (Abstract Windowing Toolkit) and not Java Swing interface is possible. In every wireless device there is an AWT GUI (Graphical User Interface) associated to our agent that shows an agent list and its behaviour policies. Agents and policies are mobile and they are moved when the user decides it, so the agents send a call to Jess in the main-container. In the next section we will see how Jess engine manages mobility. 3.2

Mobility Policy

Mobility is managed from the Jess engine in the main container, a J2SE [26] one. It contains a set of rules, that depends on the specific application, that move agents when it is convenient and balance the load of the different containers. As we can see in Fig. 5, a mobile agent has capability for moving from a wireless device, as iPAQ or PersonalJava, to another resource in the same platform (intraplatform mobility) to carry out a mission. It would be valuable when, for instance, a negotiation must be done, because it means a lot of messages going up and down. The process takes place in a J2SE container, in a local server, so Jess rules govern the negotiation protocol and its policy.


29

Negotiation Server

Agent Migration

Client agent platform

User agent container

container

search content

Content Provider

negotiate content

Multimedia Search Agent

Negotiation Agent

Fig. 5. Negotiation mobile-agent scenario

The Jess inference engine governs agents’ behaviour, what includes their mobility patterns. User agents reside initially in the client hardware device, but these devices can have limited connectivity and processing power. When an agent wants to search and negotiate some content in the Internet, it is more efficient to do that from a wired and powerful device, what we have called a Negotiation Server. Under these circumstances, the mobility behaviour rules are put into action. Fig. 6 shows an example mobility rule that is fired because its conditions are met Its complexity depends, again, on the specific application. When an agent is operating from a mobile location and willing to start a connection intensive interaction, if there is an available server location, it is moved from the mobile location to the server.

4

Future Work and Conclusions

We have started from the issue of Digital Rights Management, looking to solve the problem of negotiation of rights, that we approach with the idea of using mobile agents. A solution along these lines has been implemented in the mentioned NewMARS project. From this, we have developed a general architecture for mobility using agent technology, that has been described. Our future work focuses on integrating all the presented architecture with the World Wide Web, more specifically with the Web Services environment. Web Services are self-contained programs and devices accessible from the web, for instance a web agent [27, 28]. They can be classified as information-gathering services, e.g. the map service at yahoo.com, or as world-altering services, e.g. the book buying service at amazon.com.

30


IF agent A wants to negotiate THEN the response is to activate the mobility.

Rule inside the knowledge base ; Rule header (defrule negotiate "jump" ;Patterns (negotiate (type yes)) ;THEN => ; Actions (assert (response (action move))))

agentA.move(locationQ)

Suppose the next situation LocationP

agentA

LocationQ

There are two templates associated (deftemplate negotiate (slot type)) & (deftemplate response (slot action))

Fig. 6. Example of rule governing mobility

Web Services are based on three pillars. First, a directory of services where they are registered, UDDI [29]. Second, a service description language that allows automatic matching and invocation of services. Here the main alternatives are WSDL [30] and DAML-S [15]. And finally, a message transport service for Web Services interaction, SOAP [31]. All these Web Services tools will be incorporated to our current FIPA compliant agent architecture. UDDI will be a complement of the used FIPA Directory Facilitator. It will provide DAML-S services descriptions that will enable automatic location and invocation of services in the heterogeneous web domain. Moreover, interactions between agents and services using SOAP messages will overcome agent platform restrictions. The building blocks needed to integrate Web Services in our architecture are shown in Fig. 3 with thin-dotted lines. They are the SOAP and UDDI wrappers that allow interaction with UDDI registries and SOAP agents. For instance, a DAML-S description of a licensing web service can be stored in the UDDI directory. Afterwards, it can be used to enrich query matching by the metasearch engine. Once located, the licensing service description is forwarded to the user agent, that uses the detailed description of the service to retrieve the negotiation protocol followed by the service. Thus, we are not constrained to previously established interaction protocols and the full dynamism of the agents and Web Services approaches can be exploited. As a conclusion, new technologies are growing, so it is necessary to provide a way to interconnect them; this is the first step we want to achieve with the architecture. Mobility in this case allows us to negotiate in good conditions, which it is a basic premise because of negotiation complexity when new challenges as semantics and intelligence are involved.


31

References 1. Garcia, R.; Delgado, J.: Brokerage of Intellectual Property Rights in the Semantic Web. 1st Semantic Web Working Symposium (SWWS-1), Stanford, CA (2001) 2. MPEG-21, http://mpeg.telecomitalialab.com/standards/mpeg-21/mpeg-21.htm 3. IPROnto, DMAG contribution to MPEG-21 Rights Data Dictionary and Rights Expression Language CfP. http://dmag.upf.es/ontologies/ipronto/mpeg21/m7675(DMAG).zip 4. IMPRIMATUR Project, http://www.imprimatur.net 5. Gallego, I; Delgado, J and Acebron, J.J.: Distributed models for brokerage on electronic commerce. In Trends in distributed systems for electronic commerce, Springer, Germany.1998. ISBN: 3-540-64564-0. 129-140. 6. Gallego, I., Delgado, J. and García, R.: Use of Mobile Agents for IPR Management and Negotiation. In Mobile Agents for Telecommunication Applications, MATA’00. LNCS 1931, ISBN: 3 540 41069 4. Springer, Germany, 2000, pp. 205-213. 7. MPEG-21 Use case scenarios v2.0, N4330, Section 15.3, http://ipsi.fhg.de/delite/Projects/MPEG7/Documents/W4330%20M21%20Use%20Cases.h tml#_Toc508698290 8. Tous, R. and Delgado J.: Advanced Meta-search in the Web. Elpub2002 (to be published) http://www.tu-chemnitz.de/elpub02 9. Lassila, O., Swick, R.R. (editors): Resource Description Framework (RDF), Model and Syntax Specification. W3C Recommendation 22 February 1999 http://www.w3.org/TR/REC-rdf-syntax 10. Brickley, D. and Guha, R.V. (editors): RDF Vocabulary Description Language 1.0: RDF Schema. W3C Working Draft 30 April 2002. http://www.w3.org/TR/rdf-schema 11. FIPA, http://www.fipa.org 12. Eastlake, D.; Reagle, J.; Solo, D. (editors): XML-Signature Syntax and Processing . W3C Recommendation 12 February 2002 . http://www.w3.org/TR/xmldsig-core 13. Delgado, J.; Gallego, I. and Perramon, X.: Broker-based secure negotiation of Intellectual Property Rights. Information Security, 4th International Conference, ISC2001. Springer-Verlag, 2001. Lecture Notes in Computer Science (LNCS), Vol. 2200. ISBN 3-540-42662-0. 14. ICS-FORTH RDFSuite, http://www.ics.forth.gr/proj/isst/RDF 15. DAML-S Coalition: DAML-S: Semantic markup for Web services. In Proc. Semantic Web Working Symposium (SWWS), 411–430, 2001. 16. RDFLogic, http://www.w3.org/2000/10/swap/log 17. RuleML, www.dfki.de/ruleml 18. Darpa Agent Markup Language + Ontology Interchange Language (DAML+OIL), http://www.daml.org 19. Zou, Y.: DAML XSB Rule version 0.3. http://www.cs.umbc.edu/~yzou1/daml/damlxsbrule.pdf 20. JADE-LEAP, http://leap.crm-paris.com/ 21. Jess, http://herzberg.ca.sandia.gov/jess 22. DAMLJessKB web page plan.mcs.drexel.edu/projects/legorobots/design/software/ DAMLJessKB 23. Sun, http://www.sun.com 24. Mobile Information Device Profile, http://java.sun.com/products/midp 25. Pjava, Personal Java. http://java.sun.com/products/personaljava/pj-emulation.html 26. Java 2 Platform Standard Edition, http://java.sun.com/j2se 27. W3C Web Services Activity. http://www.w3.org/2002/ws 28. McIlraith, S. and Son, T.C.: Semantic Web services. IEEE Intelligent Systems (Special Issue on the Semantic Web), 16(2):46-53 (March/April 2001) 29. Universal Description Discovery and Integration, http://www.uddi.org 30. Web Services Description Language, www.w3.org/TR/wsdl 31. Simple Object Access Protocol, www.w3.org/TR/SOAP

Internet Agents for Effective Collaboration Vidya Renganarayanan, Abdelsalam (Sumi) Helal, and Amar Nalla Computer and Information Science and Engineering Department University of Florida, Gainesville, FL 32611, USA LIPEP$GMWIYJPIHY LXXT[[[LEVVMWGMWIYJPIHYTVSNIGXWE^MQEWLXQ

Abstract. With the ever-growing Internet, distributed applications are gaining popularity. Going “online” to browse, to send/receive emails is an integral part of our daily lives. In fact, the majority of Internet users rely on email and web browsers as the de-facto tools for collaboration. Such popular tools, however, provide limited and inefficient mechanisms for collaboration, especially when several collaborators and resources are involved. Surprisingly, collaboration tools such as NetMeeting and Netscape Collabra are only used in limited applications despite their rich collaboration support. What is lacking is an invisible infrastructure that extends email and web browsing tools – to which most Internet users are accustomed and addicted – to intuitive interfaces of a full-fledged Web collaboration system. In this paper we present WAPM, a Web Agent Programming Model that uses mobile agents as the tool for coordination and describes a model that uses familiar tools such as the web and email for effective asynchronous collaboration. We introduce WAPM and give details of a simple scripting language used to direct agent actions, a pre-processor to check the validity of the script, an agent manager that creates and manages agents according to the script and a defined class hierarchy for developing application agents in WAPM. The mobile agents are based on the aZIMAs (almost Zero Infrastructure Mobile Agents) system that integrates mobile agents with web servers by providing mobility using HTTP.

1

Introduction

Many routine activities require coordination among several people and the input from multiple users; deciding venue, date and time for a group activity, taking a survey, distributed voting mechanisms and decision making that require the consensus of more than one person, to name just a few. These activities form a class of applications that are currently handled by sending emails and a personal assistant (human) collecting the responses and processing them or alternatively writing a CGI script to process input collected using a form. In today’s world of the Internet, where ubiquitous computing is actively being sought, the applet-servlet communication scheme is also being used. Internet has increased our web of contacts; more collaboration is possible and desired, yet we only have the same old tools. Software like Yahoo Messenger [14], MSN Messenger [10] and NetMeeting [8] that provide synchronous collaboration are prevalent.


34

Vidya Renganarayanan, Abdelsalam Helal, and Amar Nalla

A major drawback of all the schemes mentioned above is the necessity of a clientserver communication link or the burden on the personal assistant handling these tasks. An asynchronous mode of collaborating between multiple users and a purely automated processing of the user inputs would be a more attractive option. Such a technique would also be a more appropriate fit for the Internet computing model. This paper describes a programming model that primarily focuses on applications that require collaboration or coordination between multiple users. The Internet, which is our primary means of communication and collaboration today, has been used as the foundation for this model. The model aims at seamlessly exploiting agent technology to increase coordination and achieve more effective collaboration by using familiar and popular tools. Mobile Agents are software modules that can migrate from machine to machine carrying out user-defined actions. Web Agents represent their user on the Internet. Agents perform a wide range of actions, from information access, being personal assistants – assisting users in daily computer-based tasks to semi-intelligent agents that adapt to the user behavior and environment so as to mimic the user and carry out tasks on behalf of the user. The proposed model is based on the mobile agent paradigm. Mobile agents bring many advantages to this class of applications. They do not require an active connection to interact with the user, hence can work with low bandwidth, weakly-connected or disconnected environments. Mobile agents move to the user machine and once they are done, leave the machine hence freeing up memory for other applications. This provides users with low memory devices also, to access and interact with these applications. By their very nature they provide asynchronous communication. There are many Issues when handling mobile agents. Mobile agents are migratory; they hop to the user machine, interact with the user and then hop to the next host. However, typical agent architectures require a server to be running at every host that is to be agent enabled. The server implements the agent protocol that is used to send and receive agents. This requirement adds an overhead on the user machine. The agents need to interact with users who may be using different devices and different system configurations. The agents need to be written in an interpreted language so that it is more portable. Since the class of applications under consideration here are interactive, the interface rendering mechanism will have to be chosen carefully, to ensure optimum portability and compatibility. The Internet Agent Programming Model presented in this paper will address the above-mentioned issues. It is not a model that defines a new architecture, neither is it concerned about agent issues such as agent location, naming, inter-agent communication to name a few. Many architectures [[1], [5], [6], [9]] have been defined and many research papers have addressed these issues. The goal of this paper is to describe an effective programming model that provides an easy, quick and intuitive way of building applications that require user interaction. Some applications that we can build using this programming model are applications that schedule meetings, conduct surveys or implement a distributed voting mechanism. The rest of the paper is organized as follows: Section 2 briefly describes aZIMAs (almost Zero Infrastructure Mobile Agent system), the agent system used by the agent programming model. Section 3 will describe the proposed agent programming model.

Internet Agents for Effective Collaboration

35

Section 4 presents the agent primitives developed using the model, these act as building blocks for more involved interactive applications. Section 5 gives the conclusions.

2

aZIMAs: Almost Zero Infrastructure Mobile Agent System

The goal of the aZIMAs system is to make mobile agents pervasive on the Internet. This is achieved by developing a mobile agent platform that can be easily deployed on the existing infrastructure present in the World Wide Web. Web servers are important components in the architecture as they host the mobile agents and enable mobility of agents. The architecture targets simple information retrieval agents and interactive agents that enable collaboration of people over the Internet. These applications are enabled by a framework that enables mobile agents to jump from web server to web server for information retrieval and allow agents to transport themselves between the user’s browser and the web server. Agents are transferred between web servers as encapsulated multipart MIME message in a HTTP POST request. The server is an extended Apache web server that has an agent runtime layer to execute agents. The server side infrastructure consists of two components, an Apache module and an agent runtime layer written in Java. Figure 1 shows the overall architecture of the aZIMAs server. The module written for Apache reads the multipart HTTP request containing the agent and parses it into its constituent subparts. The subparts consist of the agent attributes, the agent code and the object having the agent state. The module reads the attributes of the agent to decide on the future course of action. The Apache server can be configured with a security policy to reject agents having certain names, or coming from certain hosts. If the agent does not meet the security requirements it is rejected, otherwise the agent information is passed to the runtime environment. The runtime environment is actually responsible for loading the agent class files and launching the agent on the server. The runtime environment can first decide to go through the agent attributes to retrieve encryption keys or any other required information before loading the classes. After the agent classes are loaded, an agent execution thread is instantiated using the agent state present in the agent object. Thus, functionality needed by a machine to host mobile agents is provided by extending the Apache web server by adding a server extension module and including a runtime layer to execute agents. The web server functions like any other web server for normal HTTP requests but when an agent arrives, the extension module that provides the infrastructure is activated and provides support for the agents. The web server allows for secure execution of the agents on the web server and also protects the host web server from rogue agents. Agents migrate between web servers carrying their entire code (Java class files) and their state with them. aZIMAs [11] a mobile agent system that uses the established HTTP infrastructure to mobilize agents, has been integrated into the Apache Web Server hence enhancing it to accept and send mobile agents. It provides APIs for building interactive and noninteractive agents. WAPM is an application built to exploit the potential of such a system.

36


Agent Manager

HTTP POST containing Agent

Minimal Infrastructure Components

Apache Modules

Agent Runtime Layer

MA Capable Web Server

JVM

Host

Web Browser

Fig. 1. Architecture of aZIMAs platform. The figure depicts the client and server components of the system.

3

Web Agent Programming Model (WAPM)

The proposed Web Agent Programming Model (WAPM) is based on a simple mobile agent system called almost Zero Infrastructure Mobile Agents (aZIMAs) [11], developed at the University of Florida. The aZIMAs system, which was summarized in Section 2, is an agent system that provides mobility to agents by using the Hyper Text Transfer Protocol (HTTP). It enhances the Apache Web Server to provide the means to send agents from client to the web server, run the agents at the web server and move the agents between web servers. WAPM enables development and deployment of Web Agents over aZIMAs. Web Agents are agents that use the Internet as their roaming ground and jump from browser to browser carrying out activities for the user. Primary focus is on agents that interact with users to obtain information and process that information to retrieve meaningful results for the owner. WAPM does not address inter-agent communication or general agent applications. It is a model specifically focused on asynchronous collaborative applications involving multiple users and information on the Internet. WAPM provides a web agent development environment. It provides guidelines for agent developers on how to put the agent system to work. It also enhances the architecture by providing agent developers with a means to express in a more intuitive way, what they want to do with their agents. Many agents have been developed and if we could harness the functionality of these, to do what we desire rather than re-invent the agent every time; that will provide for very effective code reuse. The WAPM addresses two issues associated with any agent architecture. One, it provides a development environment specifically geared towards building agents that need to interact with multiple users. Two, given any architecture, a means to treat


37

agents at an abstract level and coordinate the actions of the agents as per the logic of the specific algorithm for that application. The agents built using WAPM can actually reside in the user’s web browser interacting with the user, providing the information, getting feedback and then move on, to the next user performing the collaborative application’s logic. WAPM provides: Agent Specification Language – To coordinate and relate multiple agents. The agent specification language is a high level language that treats agent invocations like function calls. It is a scripting language that provides a restricted but powerful set of language features to direct agent activities and relate multiple agents. Pre-processor – For syntax and type checking of the script. The script written according to the Agent Specification Language is pre-processed to check for syntax and type safety before attempting to execute it. Agent Manager – To manage agents according to the instructions in the script. The Agent Manager is the implementation of the script; it creates agents and functions as the script interpreter. Agent Development Infrastructure – To develop collaborative application agents. WAPM provides a set of classes to build mobile agents of an interactive or noninteractive nature. Collaboration Mechanism – Agents interact with users by residing in the user’s web browser. There is no infrastructure requirement at the collaborating user’s machine. This is achieved through a combination of email and Java Applet technology.

Script

Pre-processor

AgentManager

WebServer

Fig. 2. Client-Side environment of the model. The script written in the restricted language of the model is run through a pre-processor and the syntax-error free script is parsed by the AgentManager. The AgentManager then moves to the first web server (as read from configuration)

3.1

Client Side Scenario

In this context client is used to indicate the agent initiator, the user on whose behalf the agent moves about carrying out the actions requested of it via the instructions in the script written using the agent specification language. The script is input to a pre-processor. The pre-processor ensures correct syntax and performs type checking. The pre-processor is run at the client-end so that the agents may be lightweight. Various agents written for the WAPM are pre-registered with the Agent Manager. The pre-processor gets the information and performs type checking for the agents invoked from the script. The pre-processed script is then given to the Agent Manager. Agent Manager is the module that holds the logic of the script. It is the engine of the system and is a generic module that chooses its path of execution based on the conditions in the script. It executes the body of the script, which might require jump-

38


ing to a web server or to a user. The agent manager maintains state between agent calls so that it can resume execution once the agent completes its job. 3.1.1

Agent Specification Language

The agent specification language gives users the ability to abstract agents and describe their requirements, which translate into actions of the agents, in a logical or algorithmic manner. The agent specification language describes the language features that can be understood by the agent manager. It supports a limited set of data-types and language constructs to effectively relate activities of multiple agents. The script can have two sections DECLARE and BODY sections. The DECLARE section specifies the name value mappings to be used in the script. The data types supported are String, array of Strings and integer. Language constructs supported are if-then-else and assign statements. The if-thenelse construct can have an agent invocation as part of its condition and the result of the agent action can be compared to a value to produce a boolean valued expression that evaluates to true or false. The then-stmt and else-stmt parts can have agent actions or assign statements. The assign statements can assign the return value of an agent action or the results of an agent action to a name (results of agent actions are registered with the Agent Manager, see 2.2.1) and use the name elsewhere. The specification language described here is intended to be a guide to realize the potential of such a system and can be expanded to include the rich set of features that are typical of any specification language. A parser that already supports an extensive grammar set may be used to input tokens to the Agent Manager, which interprets it to construct the agents. Every agent to be used in this script must register with the agent manager (see 2.1.2.1 Agent Manager APIs). At the time of registration, it will specify the RESULTS that it produces. The pre-processor will type-check agent invocation using this information. 3.1.2

Agent Manager

Agent Manager extends the AzimasAgent class provided by the architecture. Hence agent manager is also an agent conforming to the aZIMAs architecture. It implements the abstract run method of the AzimasAgent class provided by aZIMAs. This is to allow it to be launched as a thread. The agent manager is not just an interpreter for the script written in the agent specification language. It saves state when an agent is to be invoked and stays dormant until the agent has completed its job. Every agent is aware of its agent manager and once the agent has done its action, it will re-start the agent manager. The agent manager will then restore state and resume execution of the script. Upon startup the agent manager will automatically discover the agents in the current directory that are written for this architecture. It will then invoke static method initialize, to be provided in every conforming agent, to get agent information such as agent name and agent results.


39

3.1.2.1 APIs Provided by Agent Manager • registerApplicationAgent – The agent developer in his initialize method, to register the agent with the agent manager, should call this method. It takes as arguments the application name, namely the function that this agent can provide users. • registerResults – The agent developer in his initialize method, to register the results of agent action with the agent manager, should call this method. It takes as arguments the name of the result and the result type, namely String String array or integer. • setResult - The agent developer in his doAction method must use the setResult method, upon completion of agent action, to give the result values to the agent manager. • setReturnValue – The agent developer in his doAction method must use the setReturnValue, upon completion of agent action, to give the return value to the agent manager. The return value must be an integer and the its meaning must be clearly documented by the agent developer.

Mobile Agent (MIME message in HTTP POST)

Web Server (Apache) Agent attribute: application/agent

aZIMAs module agent state

Agent Launcher Thread.run()

AgentManager / Application Agent

Executes Script Fig. 3. WAPM – Server Side. The Mobile Agent sent as a multi-part MIME message in an HTTP POST message is received by the Apache Web Server. The web server invokes the aZIMAs module for applications of type application/agent, indicated in the HTTP header. The module parses the MIME message and passes control to the Agent Launcher. The agent enabled by the Agent Launcher could be an Agent Manager or an Application Agent.

3.2

Web Server Scenario

The Agent Manager reads from configuration at the client side and uses aZIMAs’s go API to move itself to the first web server. The go API [11], composes a multi-part MIME message consisting of the agent-attributes, agent state and the various class files required by the agent. This MIME message is then sent as a HTTP POST request. At the web server, the application type is read from the HTTP header; an appli-

40


cation/agent type of agent is handed over to the aZIMAs module of the Apache web server. This module stores the class files and transfers the agent state to the Java Runtime support environment, which is a Java program for launching agents, running on the web server. The launcher creates a separate thread of execution for each agent [Fig. 2]. Agents migrate from one machine to another by using the aZIMAs infrastructure’s go method or using applet communication provided by a combination of sendEmail and the WAPM. Depending on the application the agent may also migrate from one web server to another using aZIMAs go API. 3.3

Interaction with User

Applets [7] have been chosen as the means of communicating with users on their browsers. Applets activate the Internet. Most popular browsers are already JavaEnabled. Users are familiar with the process of downloading applets off the web and running them. Web Servers already have a way of handling applets and security related issues could be met. Hence applets provide an established mechanism to interact with users. WAPM provides applet-agent technology for agent developers to develop agents that need to interact with users. Agents send the link to the applet using the sendEmail API in aZIMAs[11]. The agent state is dumped into a file. The applet will contain a parameter that indicates the name of the file containing the agent state. aZIMAs receives the agent and starts it off on a separate thread. The currently executing agent still has control and can now decide if it needs to contact other users or if has obtained the results. Contacting other users follow the same process as outlined above[Fig.3]. Once the agent has collected all the results, it returns control to the agent manager by activating the agent manager’s thread of execution. 3.3.1

Dialog Applet

(MEPSK%TTPIX is a generic applet provided by the infrastructure to wrap the user interface provided by the application agent. DialogApplet reads the parameter from the HTML file, gets the agent state from the web server and calls doInit on the agent. The agent’s doInit method has the look-and-feel of the applet as coded by the agent developer. The applet has now been rendered on the web browser. The user actions are processed and once the agent has completed its work, it goes back to the web-server by using the aZIMAs API, go method [Fig. 3]. 3.4

Developing a Mobile Agent

aZIMAs defines AzimasAgent which is an agent that can use the aZIMAS infrastructure for its mobility. Hence, an agent in WAPM needs to be an AzimasAgent. A WAPM agent attains its mobility from the aZIMAs architecture and is an agent that can be used in the agent specification language to be linked in a pipeline of agent activies.


Web Server Host

41

User

Interactive Agent clicks on applet link

Load Applet Perform Action Agent Manager email

read „Agent“ parameter

Load Agent

Save state

doInit()

Send Applet

Render Applet on Browser

agent_obj

Applet-User interaction done

„go“ API

Send Agent back to Web Server

Fig. 4. WAPM – Interactive Agent. At the Web Server the interactive web agent, to contact the user it wishes to interact with, dumps its state to a file and sends applet as email to user. The user on clicking the applet link activates the process of bringing the agent to his/her web browser. Once interaction is over, the agent returns to the web server. This process may be repeated as many times as required by the agent.

AzimasAgent

AgentManager

ApplicationAgent

SystemAgent

InteractiveAgent

Fig. 5. Class Hierarchy of the Programming Model – Two kinds of application agents are possible, Interactive and non-interactive or SystemAgents.

WAPM has a class hierarchy defined that best suits the goals it is trying to demonstrate. WAPM has an Agent Manager that need the mobility of an agent but is functionally different from an agent that will be built for a specific task as described by the agent specification language. So, there are defined two classes that derive from

42


Azimas Agent: Agent Manager and Application Agent. Application agent is further sub-classed as InteractiveAgent and SystemAgent to differentiate between agents that use applets to interact with users and agents that do not need to interact with a user but need access to the user’s machine to perform it’s operations such as a search or information mining. Though only the Interactive Agent is described here WAPM may also be used to develop System Agents. Thee WAPM infrastructure provide the set of classes described above as well as the DialogApplet. The following is a detailed description of steps that a mobile agent developer would need to do in order to develop an agent using WAPM. Step 1: Extend the ApplicationAgent class. The ApplicationAgent class extends from the AzimasAgent class provided by the architecture. This class also holds a reference to the AgentManager. Every agent has an agent manager associated with it; the reference is set when the agent is instantiated. Step 2: Implement the abstract methods in the ApplicationAgent class, namely • initialize() This method is a static abstract method specified in the ApplicationAgent class. It is used by the AgentManager to discover and get information about the Application Agent developed. This method must invoke two methods on the associated agent manager: • registerApplicationAgent() This method registers the name of the application agent. Once registration is done, the user can use this application agent in the agent specification language. • registerResults() This method informs the agent manager of the results produced by this application agent. Each result is given a name, the value for which will be set once the agent executes. The result name, as specified, can also be used in the agent specification language. • doAction() This method is an abstract method in the ApplicationAgent class. It is invoked when the agent manager comes across the agent name in the agent script. This implements the application logic of the agent. A single application agent may perform more than one action. The doAction method takes String name as a parameter. Depending on the name passed the appropriate logic may be executed. To provide for this functionality, registerApplicationAgent, which associates a name with the agent, may be called more than once in the initialize method. Step 3: The infrastructure provides additional facilities for agents that intend to interact with users. Applets are the means of interacting with users. If the agent being developed is to interact with the user, then it should over-ride the doInit method of the ApplicationAgent class. The infrastructure applet, DialogApplet, invokes the agent’s doInit method to render the applet on the web browser. The template for an application agent to be developed using this model is given below:


43

GPEWW%R%TTPMGEXMSR%KIRXI\XIRHW%TTPMGEXMSR%KIRX _ TYFPMGZSMHMRMXMEPMÎ _ 8LIJSPPS[MRKX[SGEPPWEVIVITIEXIHEWQER]XMQIW EWXLIRYQFIVSJJYRGXMSRWXLMWEKIRXTVSZMHIW KIX%KIRX1EREKIV VIKMWXIV%TTPMGEXMSR%KIRX l*YRGXMSRz KIX%KIRX1EREKIV VIKMWXIV6IWYPXW_ l6IWYPXz6IWYPXz|z6IWYPXRza a TYFPMGZSMHHS%GXMSR7XVMRKREQI3FNIGX?ATEVEQW _ ETTPMGEXMSRPSKMGJSVXLIJYRGXMSRTEWWIHMR TEVEQIXIVDREQI

a 3TXMSREPQIXLSHHS-RMX 8SFITVSZMHIHMJXLIEKIRXRIIHWXSMRXIVEGX[MXL YWIVSRXLI;IFFVS[WIV TYFPMGZSMHHS-RMX _ %TTPMGEXMSRPSKMGXSVIRHIVETTPIXSR[IFFVS[WIV ERHTVSGIWWYWIVMRTYX a a WAPM provides some agent primitives that may be useful for users in writing more effective scripts using the agent specification language. Operations that are very commonly used, such as: sending information via email to a list of people, confirming agent actions that obtained user input, canceling agent actions that required interaction with the user. These primitives may be accessed in the agent specification language by the names: SEND, CONFIRM and CANCEL. These are SystemAgents and extend from the 7]WXIQ%KIRX class. They do not require the applet model, since they do not interact with users. System agents are typically used to send information or perform action at the web server.

4

Application Agents Developed Using WAPM

Application Agents were built using the Web Agent Programming Model to demonstrate the features and to be able to present, visually, this new scheme of mobile agents and their interaction with users.

44


4.1

Multi-user Collaboration Application Agent

Frequently we come across scenarios where it is required to collect input from numerous users; namely surveys, feedback forms, scheduling meetings to name a few. To send out emails to multiple users and then track their replies, co-relate them and process the information to release meaningful data is a very involved process. To expedite this process, the Query agent can be programmed with the necessary logic to process user information. The agent can jump from web browser to web browser, getting user input for users in a domain. It will jump from web server to web server to reach users in different domains. Identification of users is done using email addresses. The agent code is written using the model described in Chapter 4. The steps to develop a mobile agent using WAPM were followed and the application agent written conforms to the template. The query application needs to interact with the user, hence the applet interaction model was used and a doInit method was implemented in the query application agent. The WAPM provides the facility to freeze the agent’s state by serializing it and then re-starting it at some pre-defined point. This fits in with the requirement of the query application agent to be able to stay quiet until the user picks it up and interacts with it and then, return to the web server to find out the next user and continue collecting input. The query application agent needs inputs of the form: from address, to addresses, subject and body (actual query). It can be invoked in the script using the application agent name registered with the agent manager; ASK. This information is specified to the agent manager in the initialize method as per the model specification. The syntax and data types are enforced when the AgentScriptPreProcessor runs through it. An example of the query application agent, if used in a script as per the agent specification language: ()'0%6) *631!ZMH]EVI$YJPIHY 0-78!_\$YJPIHY]$YJPIHY^$YJPIHYa 79&!7YVZI]JSVXLI0EF 59)6=!l;SYPH]SYPMOIGEVHEGGIWWXSXLIPEF#l )2(()'0%6) &3(= MJ%7/*6310-7879&59)6= " XLIR '32*-61*6310-7879&59)6= IRHCXLIR )2(&3(= This agent can be used to conduct surveys, implement a distributed voting system and many other application. This simple API which provides a mechanism to receive yes or no responses from multiple users, can be used as a building block to develop more involved applications.


4.2

45

True Crawler/Filter Application Agent

The Internet is a treasure house of resources, resources in the form of information and in the form of the multitude of users who log-on everyday to browse or check email. We could tap these resources to obtain useful information; use a specialist in a field to filter out a huge list of information to something more appropriate for your needs. An application agent that could take a set of input and interact with the user to filter it and reduce it to a more meaningful set was developed. This agent is a true crawler since it carries only the essential and most pertinent information. It extends from the -RXIVEGXMZI%KIRX class to provide an applet interface to the user. The agent is registered with the name FILTER; it takes a list of information, sends it to users and returns the filtered results. This agent uses the (MEPSK%TTPIX to render the applet on the web browser. The %KIRX1EREKIV, activates the agent by invoking the doAction method. This method does some processing to initialize the state of the agent, and then invokes the sendApplet method, provided in the -RXIV EGXMZI%KIRX, to send email containing the applet link to the user indicated in the script. The sendApplet method as described earlier, will dump the agent state into a file, indicate the name of the file as a PARAM in the applet’s html file and send the email. The agent is now in an inactive state, waiting to be loaded by the applet, once the user clicks on the link. The agent once loaded by the applet, sits on the web browser of the user, renders the interface via its doInit method and interacts with the user. The Filter application agent is to be used as a building block. It makes possible applications such as scheduling meetings; where a user may be given a number of choices and he chooses the ones convenient for him, applications to specialize search results by sending it to a live person and many others that involve a selection process.

5

Related Work

Applying the mobile agent paradigm to the Internet model is an area of active research. Many techniques have been proposed to enable collaboration applications. TANGO [2] provides web-based collaboration using the JAVA applets feature. However it does not use the mobile agent model. The clients wishing to use an application in TANGO need to install the client-side environment. TANGO addresses collaborative applications where multiple users interact with each other simultaneously such as chat, whiteboard conferencing or a common drawing board. WASP [4] uses the mobile agent paradigm and integrates it with the web server. It provides for users to interact with agents installed at the web server. The model however, does not address the issue of dynamic agents, created by users and which are not already installed on the web server. Migratory Applications [3] describe a programming model for agent applications that hop from site to site, carrying information in briefcases and they receive a briefing at each site. The briefing contains advice for the agents such as site is busy or try an alternate site and site-dependent data. This model requires that an agent server be present at every site that is to be agent enabled.

46


Collaborative Interface Agents [7] address routine tasks that users perform on a day-to-day basis, but this talks about collaboration between the agents to assist the user better in performing these tasks. Collagen [12] is an agent model that interacts with people, however the aim is to interact with only one user and present information from various sources to this user in a user-friendly manner.

6

Conclusions

In this paper we described a Web Agent Programming Model (WAPM) that applies the mobile agent paradigm to building collaborative web-based applications. The model was developed over the aZIMAs architecture, which offers mobility to agents by transporting them between web servers using HTTP. The communication mechanism to other hosts on the Internet is through the popularly used electronic mail (email). The WAPM provides the environment to build collaborative applications that are deployed over the Internet. It also clearly defines the interface an agent must conform to, hence allowing easy integration of existing applications with WAPM. This model is a proof of concept to taking familiar, widely accepted tools such as email, web browsers and JAVA applets and combining them to provide a powerful environment for web-based collaborative applications. Issues such as error recovery have not been handled in the work done, but the model may be extended for robustness, reliability and more sophisticated applications. We have demonstrated the use of WAPM by implementing two application agents, the Multi-User Collaboration Agent and the True Crawler/Filter Application Agent.

References 1. Ajanta – Mobile Agents Research Project, http://www.cs.umn.edu/Ajanta, University of Minnesota (Apr 1998). 2. Beca, L., Cheng, G., Fox, G.C., Jurga, T., Olszewski, K., Podgorny, M., Sokolowski, P., Stachowiak, T., and Walczak, K., TANGO – a Collaborative Environment for the World Wide Web, Northeast Parallel Architectures Center, Syracuse University, 111 College Place, Syracuse, New York (1997) 3. Bharat, K.A., and Cardelli, L., Migratory Applications, ACM Symposium on User Interface Software and Technology ’95, Pittsburgh, PA, November 1995. pp. 133-142 (1995) 4. Funfrocken, S., How to Integrate Mobile Agents into Web Servers, Proceedings of the WETICE’97 Workshop on Collaborative Agents in Distributed Web Applications, June 18-20, Boston, MA (1997) 5. Gray, Robert S., Agent Tcl: A flexible and secure mobile-agent system, In Proceedings of the 4th Annual Tcl/Tk Workshop (TCL’96) (July 1996). 6. Karjoth, G., Lange, D., and Oshima, M., A Security Model for Aglets, IEEE Internet Computing, Jul-Aug 1997, pp. 68-77 (1997). 7. Lashkari, Y., Metral, M., and Maes, P., Collaborative Interface Agents, Huhns, Michael N., and Singh, Muninder P., editors, Readings in Agents. (1997). 8. Microsoft NetMeeting, http://www.microsoft.com/windows/netmeeting


47

9. Mitsubishi Electric., Concordia: An Infrastructure for Collaborating Mobile Agents, Proceedings of the 1st International Workshop on Mobile Agents (MA’97) (April 1997). 10. MSN Messenger, http://messenger.msn.com 11. Nalla, A., Helal, A., and Renganarayanan, V., aZIMAs – almost Zero Infrastructure Mobile Agents, IEEE Wireless Communications and Networking Conference, March 2002. Available at http://www.harris.cise.ufl.edu/projects/publications/azima.pdf 12. Rich, C., and Sidner, Candance L., COLLAGEN: When Agents Collaborate with People, Huhns, Michael N., and Singh, Muninder P., editors, Readings in Agents. 13. Sun Microsystems, Java, http://www.java.sun.com. 14. Yahoo! Messenger, http://messenger.yahoo.com/

Programming and Executing Telecommunication Service Logic with Moorea Reactive Mobile Agents Bruno Dillenseger1, Anne-Marie Tagant1, and Laurent Hazard2 France Télécom R&D, DTL/ASR chemin du Vieux Chêne, BP 98, 38243 Meylan cedex 238/40 rue Général Leclerc, 92794 Issy Moulineaux cedex 9 {bruno.dillenseger,annemarie.tagant, laurent.hazard}@rd.francetelecom.com 1 28

Abstract. In the context of advanced telecommunication service execution environments, this paper presents a reactive mobile agent platform, based on a synchronous programming model, a flexible object request broker, and OMG's MAF specifications on mobile agent systems interoperability. The paper details the specific design of the platform, and shows how it addresses key issues such as scalability, reliability, transparent mobility and interoperability. Finally, the paper shows the use of Moorea agents for executing telecommunication service logic in the ITEA Athos European project's Enhanced Call Server architecture, featuring transparent and dynamic distributed system reconfiguration.

1

Introduction

As of today’s research topics, involving (mobile and/or intelligent) agent technology in telecommunication infrastructures is a well-known trend (e.g. see a digest of several European projects in [12]). It has been used already in several experiments ranging from information infrastructure to network management and active networks. Interest in mobile agent technology mainly arises from its ability to handle in a unified way a variety of issues [10], such as code deployment, autonomous adaptive routing, network bandwidth saving, disconnected operations... The topic of this paper is the use of mobile agent technology in the context of a distributed execution environment for telecommunication applications. While many practical applications of mobile agent technology exploit only a subset of the paradigm (e.g. single-hop, weak mobility), our approach makes a complete utilization of the advanced properties of the Moorea platform. The development of Moorea springs from the consideration that mobile agent technology often comes with several drawbacks, such as bad scalability, cost and complexity of agent activity transportation, unreliable agent communication and lack of interoperability. Moorea is a Java mobile agent platform implementing the Mobile Agent Facilities specification [13]. It comes with a peculiar reactive model for agent communication and activity, enhanced with distribution support and transparent mobility features. This paper first describes the Moorea platform, details its specific properties and compares them to existing platforms. Then, the paper describes the use of Moorea in the field of telecommunication service execution environments, through the example of an Enhanced Call Server developed in the context of the Athos European project. A. Karmouch et al. (Eds.): MATA 2002, LNCS 2521, pp. 48–57, 2002. © Springer-Verlag Berlin Heidelberg 2002

Programming and Executing Telecommunication Service Logic

2

Moorea Overview

2.1

Moorea Architecture

49

Moorea ("MObile Objects, REactive Agents") is a 100% Java reactive mobile agent platform. As shown by 0, its architecture combines: − a reactive object model and execution kernel (Rhum and Junior [11]), − with a Java mobile object framework (SMI [7]) implementing OMG’s Mobile Agent Facilities specification [13] (MAF, also known as MASIF), − on top of a flexible Object Request Broker (Jonathan [21]) offering both a JavaRMI and a CORBA personality (API), − extended with transparency to mobility support.

MOOREA MAF-based mobility framework

CORBA API flexible, open ORB hardware and base software heterogeneity transparency

SMI

Rhum / Junior

synchronous reactive objects

David

Jeremie

RMI API

Jonathan Java virtual machine

mobility transparency enhancements

Fig. 1. Moorea’s software architecture is based on the integration of a MAF-based mobile agent framework (SMI) with a reactive distributed object environment (Rhum).

2.2

Key Concepts

2.2.1 Reactive Agents and Events Moorea’s agent model is based on Rhum’s distributed reactive object model (0). The basic processing procedures and internal data of an agent is embedded in a reactive object which controls its behavior. A behavior describes the agent’s activity in a synchronous language - Rhum - featuring high-level constructs to define parallel branches, conditions, synchronization, loops... Agents are reactive in that the execution of the behavior may both depend on (or react to) and generate events. Agents are created, hosted and executed by agencies (agent systems in MAF terminology). Events are generated by agents or by their host agency. Events may hold values, and may be either locally visible by all the agents in a given agency, or specifically sent to a given agent, whatever local or remote. The exact semantics of events is given in section 2.2.2. Agents are designated through their reference, which may be used for managing them or for sending them events.

50

Bruno Dillenseger, Anne-Marie Tagant, and Laurent Hazard

synchronous reactive compiler specification (Rhum)

events reactive class (Java)

passive class (Java)

reactive behaviour

reactive interface

basic processing procedures, agent’s data

Fig. 2. The behavior is compiled from a Rhum program to a Java reactive class, embedding the associated passive object. Events are mapped to methods of the object’s reactive interface.

2.2.2 Focus on Synchronous Programming Model Derived from Esterel [3], synchronous language Rhum slightly modifies its semantics to avoid causality problems and to allow dynamic program composition. However, the synchronous execution principle remains: in such an execution model, time is sliced into logical instants, which define the lifetime of an event and the reaction semantics (0): (1) an event is present during an instant if and only if it is generated during this instant; (2) reactions to an event are run in the same instant; (3) an event may trigger reactions only once per instant, whatever the number of times the event has been generated during this instant. An instant ends once all reactions are terminated or stopped. A reaction stops by waiting an event which is not present in the instant, or by explicitly waiting next instant. Start new instant

executing

idle logical time

Agents react to events in the instant they are generated.

An instant ends when all reactions are complete or stopped.

Fig. 3. A synchronous execution is split in instants where agents react to and generate events.

Each agency contains an engine to locally manage instants, events and reactions. Agencies are independent reactive domains (for efficiency reasons, sequences of instants of distinct agencies are fully independent). 2.2.3 Scalability Aspects The execution model is based on reacting in sequence (i.e. with no actual parallelism) to events. This model both saves processing time (no preemptive scheduling and no context switching) and avoids complex code related to concurrency and consistency management. This model thus enforces good scalability, in terms of number of agents per agency. A scalability comparison of Rhum with thread-based agents is given in [8]. The results show that the number of reactive agents does not impact the system


51

normal functioning, while allowing a greater number of agents. At the present time, we can run a million reactive agents on a single PC. 2.3

Strong Mobility Support

In the mobile computation community, Fugetta et al [9] define the concept of weak and strong mobility, to express the fact that a computation may be more or less disturbed by mobility. As a matter of fact, a running process uses local computing resources, which, after a move, either would have to be accessed remotely, or would have to be replaced by local similar resources in the "same" state. Obviously, today’s operating systems do not support such features. As a consequence, support for transparency to mobility must be provided by upper software layers. Moorea claims a strong mobility support for two reasons: (1) execution is not disturbed and (2) communications are not disturbed. 2.3.1 Transparency to Mobility for Execution Moorea agents’ behavior is represented by a reactive program, whose execution is split into instants. The beginning of an instant is triggered by the reactive domain, and the end of an instant is reached when no agent reacts any more. At the end of an instant, the state of agents is stable, well defined and easy (not costly) to transport. Moorea takes advantage of this property, by actually performing moves once the end of instant is reached. A moving agent is frozen and transported with its behavior and full state, and then resumed in the new reactive domain (agency), in a new instant. Note that the combination of mobility and reactive model considerably limits mobility overhead. This approach must be compared to thread-based mobile agents, whose mobility is either disturbing (the execution state is reset to some default state after move), or complex and costly (mobility includes execution stacks). On the contrary, Moorea’s agent model allows a low-cost serialization and transport of agents’ execution state (an agent behavior is equivalent to a state machine). Moreover, the synchronous reactive model offers clear mobility semantics, which is not always the case of thread-based mobile agents introducing (sometimes unclear) side effects to the programming semantics. Besides, the programmer is freed from concurrency management burden, as well as inconsistency and deadlock threats (see 2.2.3). 2.3.2 Transparency to Mobility for Communication Since Moorea reactive model tightly couples activity with communication, transparent mobility must also consider events. While environment events remain purely local, targeted events should always follow the target agent, without being lost, even during the agent transportation timeframe. This transparency is achieved by a combination of two well-known techniques, namely forwarding and naming service: − forwarding consists in replacing the moved agent by a forwarder object that forwards invocations to the new location. Basic forwarding can lead to a long reference chain (multiple hops), relying on every visited agency to keep running, which is not always assumable for mobile agent applications; − a naming service – or relocator – associates a name to a location-dependent distributed object reference. By updating this information after each move, mobile agents can still be located. The major drawback of this technique is that it introduces a central authority and bottleneck.

52


Moorea combines both techniques while seriously limiting these drawbacks. First of all, the reference chain maximum length is limited to one indirection, by having forwarders directly get the new agent location from the relocator. Moreover, the forwarder updates the reference in the clients, which reduces the relocator "bottleneck effect" by preventing clients from invoking the relocator. Lastly, there may be several relocator servers, defining their own name spaces, and avoiding to enforce globally unique agent names. Let’s assume that an agent is moving from agency A to agency B, and that other agents send it targeted events: − during the move, and as long as the agent has not been reinstalled in agency B, events are buffered in agency A; − agency A gets the new agent reference from the relocator, forwards events to agency B, and gives the new agent reference to the senders of the events; − if agency A is unreachable (e.g. it has been shut down), the client directly gets the new reference from the relocator. These transparency features are implemented by the stubs in the underlying middleware (i.e. Jonathan and its RMI personality Jeremie, and Rhum) [14]. They are not fully specific to Moorea, and have been reused in another work in progress, to support object mobility in Jonathan’s CORBA personality (David).

3

Related Work

3.1

Middleware Approach, Interoperability

Moorea follows a middleware approach, which was not the case for historical mobile agent platforms. Not only Moorea is built on open ORB Jonathan, but its mobility feature is fully CORBA-based and MAF compliant thanks to the underlying SMI framework [7]. Moorea agents and agencies communicate through the ORB, using common services such as naming service. Previous similar approaches, and their benefits in terms of code reuse and agent interoperability, have already been described in [6]. Below SMI, other known mobile agent systems implementing MAF are Grasshopper [20], SOMA [23]; version 1.1 of Aglets [17] plan to be MAF compliant. Besides MAF specification, the activities of the Foundation for Intelligent Physical Agents consortium (FIPA [19]) and OMG’s Agent Special Interest Group [22] (including a mobility working group) show that interoperability is considered as one of the key issues for the success of agent technology. 3.2

Transparency to Mobility

Most of mobile agent platforms take care of transporting the agent’s code and "static" state when moving an agent, but very few of them are able to transport the execution state, i.e. to resume the agent execution at the very point of its execution. Dartmouth College’s AgentTcl/D’agent [10] and General Magic’s Telescript [16] support such strong mobility. The problem with strong mobility is that it is typically complex and costly, especially when agent activity is based on threads (e.g. see work on Java thread migration in [15]).


53

An efficient alternative of the "move anytime" approach is the "move sometimes" approach, which means that the agent activity can be interrupted, frozen, transported and resumed only at certain well identified points. In the case of Moorea, these points identified by the ends of instant (i.e. when the agent is waiting for an absent event or for next instant, see 2.2.2). After a move, an agent transparently resumes its activity in a new instant, at a new location. This semantics is clear - and "natural" in some way -, whatever the behavior complexity and the number of active loops or parallel branches. As a consequence of this approach, the transparent mobility support is provided at low cost, by avoiding to freeze and transport "expensive" items like running threads. 3.3

Formal "Behavior"

Thanks to the separate programming of the agent global behavior and basic computing procedures, Moorea exhibits the agent activity logic, with its parallel branches, synchronization points, event waiting. This high level activity representation is not only the key to low-cost, portable mobility, but also a key to easy and reliable agent programming, since it prevents the computing procedures from handling monitors, semaphores, locks, etc., for managing synchronization and concurrency issues. Moreover, it opens the way to simulating and testing, and even probably to proving execution properties, as it is already the case with Esterel programs [4]. The Bond agent system [5] follows a very similar approach: agent activity is controlled by a multi-plane state machine, generated from a description in a dedicated language called "BluePrint". The basic processing procedures are implemented by a set of so-called "strategies" objects, equivalent for Moorea’s passive object. Unlike Moorea, it is not based on a synchronous programming model. Being also based on synchronous reactive objects and a dialect close to Rhum, Rejo is the most similar approach [1]. This on-going work goes further in the integration between Java and the reactive language, since both the reactive behavior and the Java code are mixed in the same file. Usage will tell what is the most convenient between separating basic processing and activity skeleton with Moorea, or having a unique, unified agent definition with Rejo. As a major difference, events in Rejo are basically local, while Moorea object references support distribution.

4 4.1

Application to a Telecommunication Service Execution Environment Requirements of Telecommunication Services

In the ATHOS project [18], Moorea is integrated to a telecommunication service creation and execution environment. This European project is aiming at defining a relevant architecture for such an environment, in order to develop and run services on a bunch of computers linked to telecommunication networks through legacy protocol stacks, typically in an intelligent network architecture. The service creation and execution environment is expected to support several advanced features. First of all, distribution would be valuable, for the execution environment should be highly scalable to support a great variety of services (from tens to hundreds) and to handle thousands (or more) of simultaneously active instances of these services.

54


Moreover, the execution environment should be able to be continuously running for a long period of time (at least for months). This requirement implies that it should be possible to dynamically reconfigure the execution environment for maintenance issues (e.g. add, reboot or shutdown a node) and to dynamically update software. Service Logic execution Moorea agents Service Logic execution nodes local network

intelligent network

agent-based, messageoriented middleware + Moorea gateway INAP...

Internet

Internet protocols

SS7 central office Enhanced Call Server Fig. 4. The ATHOS Enhanced Call Server architecture makes it possible to build advanced services, accessing both the Internet and the Intelligent Network worlds, using modern and open information technologies.

4.2

Moorea in the ATHOS Architecture

The ATHOS architecture is based on the concept of Enhanced Call Server (or ECS, 0). The ECS embeds the protocols-specific knowledge and software of both the Internet and Intelligent Network worlds. Its static infrastructure is composed of a Unix server running the AAA message-oriented middleware [2] (see also JORAM in [21]) and protocol stacks connected through IP to a gateway giving access to the Intelligent Network. The service logic is executed by Moorea agents on a local network of computers, providing the dynamic infrastructure of the ECS. 4.3

Example: A Simple Email Waiting Indicator Service

4.3.1 Scenario A demonstration of Email Waiting Indicator (or EWI) service is developed on the ECS architecture. This service consists in providing a phone subscriber with information about his pending electronic messages. Once the service is subscribed and the information about the email account is provided (typically the IP address of the POP3 server, identifier and password), the user may enable and disable the service by dialing special codes on its phone. When the service is enabled and the user unhooks his/her phone, s/he gets the information about pending messages (e.g. special tone or voice message). These IN events (dial codes, off-hook) are handled by the ECS, which performs the appropriate action.


55

4.3.2 Implementation To enable the service, the ECS asks a Factory agent to make a new EWI service logic agent ready. The Factory agent either recycles a passivated EWI service logic agent, or creates a new instance if necessary. Note that the service logic agent may be created and reside in any agency, on any execution node. Then, the Factory agent sends an "activation" event to the service logic agent and provides it with the user’s profile holding the necessary data (identification, e-mail account...). Once activated, the service logic agent sends its reference to the ECS which stores it in the user profile. Finally, the service logic agent starts polling the e-mail server in a generic way, by using an e-mail server encapsulation provided by the ECS, in order to keep the service logic independent from the protocols. The polling period is based on a "tick_1s" event generated every second by a timer agent in each agency. When the user unhooks the phone, the ECS finds the EWI service logic agent’s reference in the user’s profile and sends a "signaling" event to the agent. The service logic agent gives the information about pending messages to the ECS which transmits the information through the Intelligent Network to the user in an appropriate manner. When the user disables the service, the ECS sends a "passivation" event to the EWI service logic agent, which in turn informs the Factory agent and goes idle. The user profile is updated to clear the service logic agent reference. The passivated agent will be recycled by the factory for any later EWI service activation for any subscriber. Fig. 5 shows the reactive behavior of the corresponding EWI service logic agent. behavior service_behavior() { loop HQGOHVVORRSLHXQWLODJHQWLVWHUPLQDWHG await activation ; ZDLWIRURFFXUUHQFHRIDFWLYDWLRQHYHQW { activation(activation::arg_0) } ; LQYRNHSDVVLYHREMHFW stop ; ZDLWIRUQH[WLQVWDQW do loop SROOHPDLODFFRXQW repeat { delay } times ZDLWDQXPEHURIWLFNV await tick_1s ; stop IURPDWLPHUDJHQW end ; { polling() } ; DVNPDLOVHUYHUIRULQIRUPDWLRQ await reply ; ZDLWLQIRUPDWLRQIURPPDLOVHUYHU { getReply(reply::arg_0) } end || SDUDOOHOFRPSRVLWLRQ loop JLYHHPDLOLQIRUPDWLRQWRVXEVFULEHUZKHQQHFHVVDU\ await signaling ; { signaling() } ; stop end until passivation ; H[LWRQRFFXUUHQFHRISDVVLYDWLRQHYHQW { passivated() } LQIRUPWKH)DFWRU\DJHQW end } Fig. 5. The Simple Email Waiting Indicator service logic is executed by a Moorea agent, whose behavior is coded in synchronous reactive language Rhum.

56


4.3.3 Advanced Features Enabled by Moorea Thanks to the strong mobility support, the service logic agents may be transparently moved from one agency to another, from one execution node to another. This makes it possible to add and remove execution nodes dynamically. We introduced in each agency a Manager agent, whose role is to dispatch every local service logic agent to other agencies before shutting down the agency. This move is transparent to the ECS and the Factory agent, which can still use the same references to deal with, and manage, the service logic agents. In the other way round, new agencies are taken into account on the fly by the Factory and Manager agents to host new or redeployed service logic agents. This is also an opportunity to implement preemptive dynamic load balancing, which is the next step of our work. Besides these features, we found useful (after an adaptation stage) to use a synchronous language to code the service logic, and not to have to care about concurrency issues when programming the associated passive classes. The reactive behavior is also a good basis for simulation and checking.

5

Conclusion

Moorea is a 100% Java mobile agent platform, based on a standard software infrastructure (Java, RMI, CORBA, MAF), and a distributed reactive object model. These peculiarities improve portability, interoperability and standardized management on the one hand, as well as scalability, transparency to mobility, and reliability on the other hand. We have shown an application of Moorea to a telecommunication service execution environment. Based on synchronous reactive language Rhum, Moorea offers the opportunity to conveniently implement telecommunication services by separating the service logic from the basic computations. Moreover, the transparent, low-cost mobility of Moorea agents provides an opportunity for dynamic redistribution and load-balancing of executing services. Immediate directions for future work on Moorea deal with scalability characterization and preemptive dynamic load balancing. Further directions include modelchecking and dynamic versioning.

Acknowledgement Moorea is developed in the context of the ATHOS project of the ITEA European research program. Thanks go to Italtel team, for their design of the ECS and their interest in agent technology, and to Serge Lacourte and Laurent Chauvirey for their help on the AAA-Moorea Gateway.

References 1. Acosta Bermejo, R., "Programming in REJO", Calculateurs parallèles, special issue "Evolutions dans le domaine des intergiciels", Hermes ed., 2001. 2. Bellissard L., de Palma N., Freyssinet A., Herrmann M., Lacourte S., "An Agent Platform for Reliable Asynchronous Distributed Programming". Symposium on Reliable Distributed Systems (SRDS’99), Lausanne (Switzerland), 20-22 October 1999. 3. Berry G., Gonthier G., "The Esterel Synchronous Language: Design, Semantics, Implementation", Science of Computer Programming, 19(2), 1992.


57

4. Bertin V., Poize M., Pulou J., Sifakis J., "Towards Validated Real-Rime Software", proc. 12th Euromicro Conference on Real-Time Systems, Stockholm, june 2000. 5. Bölöni L., Jun K., Palacz K., Sion R., Marinescu D., "The Bond Agent System and Applications", proc. ASA/MA 2000, Lecture Notes in Computer Science 1882, Springer, pp. 99112. 6. Dillenseger B., "From Interoperability to Cooperation: Building Intelligent Agents on Middleware", proc. 2nd International Workshop on Intelligent Agents for Telecommunication Applications, Paris, july 1998. Lecture Notes in Artificial Intelligence 1437, Springer, ISBN 3-540-64720-1, pp. 220-232. 7. Dillenseger B., "MobiliTools: An OMG standards-based toolbox for agent mobility and interoperability", proc. 6th IFIP Conference on Intelligence in Networks (SmartNet 2000), Vienna, september 2000, Kluwer Academic Publishers, pp. 353-366. 8. Dillenseger B., Tagant A.-M., Hazard L., Tran Viet H., "Les agents mobiles réactifs Mooréa - une approche réactive pour la transparence à la mobilité et le passage à l'échelle" RSTI-TSI 21/2002 "Agents et codes mobiles" special issue, Lavoisier-Hermès ed. p. 1-26. 9. Fugetta A., Picco G.-P., Vigna G., "Understanding Code Mobility", IEEE Transactions on Software Engineering, vol. 24, No 5, 1998, pp.342-361. 10. Gray D., Kotz D., Nog S., Rus D., Cybenko G., "Mobile Agents: the next generation in distributed computing", proc. 2nd Aizu Int. Symposium on Parallel Algorithms and Architectures Synthesis, Fukushima (Japan), IEEE Computer Society Press, 1997, p. 8-24. 11. Hazard L., Susini J.-F., Boussinot F., "The Junior reactive kernel", Rapport de recherche Inria 3732, 1999. 12. InfoWin project, "Agents Technology in Europe, ACTS Activities", 1999, ISBN 3-00005267-4. 13. Object Management Group, "Mobile Agent System Interoperability Facilities", TC document orbos/97-10-05, 1997. Revised in "Mobile Agent Facilies", formal/2000-01-02. 14. Tran Viet H., "Gestion de la mobilité dans l'ORB flexible Jonathan", Ph.D. dissertation, Université Joseph Fourier, Grenoble (France), 25th April 2002. 15. Truyen E., Robben B., Vanhaute B., Coninx T., Joosen W., Verbaeten P., "Portable support for transparent thread migration in Java", Proc. ASA/MA 2000, Lecture Notes in Computer Science 1882, Springer, pp. 29-43. 16. White J., "Telescript technology: the foundation for the electronic market place", General Magic White Paper, General Magic, 1994.

Web References 17. 18. 19. 20. 21. 22. 23.

Aglets - http://www.trl.ibm.com/aglets/index_e.htm ATHOS project (ITEA European program) - http://www.itea-athos.com/ Foundation for Intelligent Physical Agents - http://www.fipa.org/ Grasshopper - http://www.grasshopper.de/ ObjectWeb Initiative - http://www.objectweb.org/ OMG Agent Platform Special Interest Group - http://www.objs.com/agent/ SOMA - http://lia.deis.unibo.it/Research/SOMA/

Generic Engineering Approach for Agent-Based System Development Seongkee Lee and Taiyun Kim Department of Computer Science, Korea University Anam-Dong, Sungbuk-Ku, Seoul, 136-701, Korea [email protected]

Abstract. It is necessary to support user-centric service provision paradigm in distributed, dynamic and complex computing environment. Software agent technology is considered as one of the technologies suitable to adopt such computing environment. Many researchers have emphasized on the necessity of agent technology, but the research on agent-based system development methodology is not sufficient. We propose the engineering approach for agent-based system development from problem domain modeling to design phase. We survey existing methodologies and extract considerations to improve them. Based on the considerations, we establish six steps in which modeling method and activities are systematically defined. Also we apply the proposed methodology to virtual example in order to show applicability of the methodology. The proposed methodology is more systematic and useful than existing methodologies. This methodology helps system engineer develop agent-based system and provides ideas to establish more complete methodology.

1

Introduction

As use of internet is increasing, computing environment is changing. Users request one-stop service in wireless mobile situation. Computing resources such as processing capacity or data repositories are distributed in the world and many businesses are processed in remote. Also the operation infrastructure becomes large and complex. To support these situations, many related computing technologies are newly developed or improved. However, many issues to be solved are still remained. One of the important issues is to devise the engineering approach to construct the system that runs on dynamic, distributed and complex environment. In recent, software agent technology is considered as the technology suitable to adopt today’s computing environment. The reason is that software agent has the capability of acting in autonomous and dynamically interacts with each other to achieve system goal in distributed complex environment. Now one of the most important issues is how to engineer agent-based system in which each component of system is viewed as agent. In this paper, we propose the engineering approach for agent-based system development. We establish new methodology which engineers agent-based system from problem domain modeling to design phase. New methodology has six phases in which modeling methods and activities are systematically defined. The proposed methodology is more systematic and useful than existing methodologies.


Generic Engineering Approach for Agent-Based System Development

59

In detail, we survey and analyze the existing methodologies and extract considerations to be improved in section 2. Based on the results of previous sections, we devise new engineering approach for agent-based system development in section 3. Section 4 shows the usefulness of new methodology by virtual example. The characteristics of new methodology and future works are described in section 5 and 6. Table 1. Characteristics of Existing Agent-based Development Methodologies Method. Domain GAIA Software Requirement Specification

MaSE

Software Requirement Specification

SODA

Heterogeneo. dynamic, open, distributed, unpredicted.

MAS Software Common Requirement KADS Specification

BDI

2

Analysis - Role Model .responsibility .permission .activities .protocols - Interaction Model - Capturing Goal .goal hierarchy diagram - Applying Use Case .use case, sequence diagram - Refining Roles .role model .concurrent task diagram

Design - Agent Model . agent type, role - Service Model . services of agent type - Acquaintance Model . communica. between agents - Creating Agent Class . agent class diagram - Constructing Conversation .communication class diagram - Assembling Agent Class . agent architecture diagram - System Design . deployment diagram - Agent Model . extract behaviors - Society Model . coordination media, architecture(agent group, coordination) - Environment Model . define infrastructure class - Agent Network Design . MAS infrastructure - Agent Design . agent architecture . platform - Platform Design . decide development environment

- Role Model . individual task: role . social tasks: group - Resource Model . access, permission - Interaction Model . interrelation with role, resource, interaction rule - Conceptualization .use case, .sequence diagram - Agent Model . analyze actors . template of agent model. - Task Model . tasks of agent - Expertise Model . information to achieve goal - Organization Model . architecture of agents - Coordination Model . interaction, protocols among agents - Communication Model .human-software interaction - External view: agent model, interaction model - Internal view: Belief model, Goal model, Plan model

Note Full Cycle, Not Social, Not open, Static, NoCoordinat Detail, Internet, OO based

Society, Internet

Use KE tool Not detail, No Exam.

Special OO model

Related Works

Although many researchers have emphasized on the necessity of systematic development methodology, the research on agent-based system development methodology was not sufficient relatively. We analyze GAIA[9,16], MaSE[12], BDI[3,14], MAScommonKADS[4] and SODA[10] among methodologies. Specially, GAIA and BDI have been referenced in many literatures. Although the primary existing methodologies in table 1 provide useful concepts and methods for agent-based system engineering, there are some weaknesses or points to be improved as followings.

60

Seongkee Lee and Taiyun Kim

– Researchers say that methodology must consider heterogeneous, dynamic, open, distributed and unpredictable computing environment, but such environment isn’t sufficiently considered in their methodologies. – Methodologies don’t consider nonfunctional factors such as system reliability, extendibility, flexibility, adaptability, etc. – Although most methodologies consider views(internal, external) or phases(analysis, design), they don’t clearly consider both views and phases. The partition of views and phases are not clear. – Some diagrams of object-oriented methodology are used to represent models in phases, but seamless interconnectivity among them is not enough. Also sequence diagram may not be appropriate to represent autonomous behavior of agent. – Organization methods aren’t described clearly. This may be because agents act in autonomous. However, if we establish relationship among agents or analyze interaction patterns, then we can reason about organization. Also, coordination mechanisms aren’t sufficiently considered.

3

New Development Methodology

3.1

Approach

To improve the weakness of existing methodologies, we extract the improvement points and devise new engineering methodology. Figure 1 shows our engineering approach for agent-based system development. 3.2

Domain Model

This model extracts the characteristics or constraints of system’s computing environment by examining given domain description. The examples of characteristics are as followings: homogeneous or heterogeneous, static or dynamic, closed or opened, centralized or distributed, predictable(system behavior) or unpredictable, etc. Also constraints such as QoS are determined. This model is described in informal manner. Because the results of this model effect on each phase of engineering, this model as the start point for engineering is very important phase. 3.3

Analysis

Considering the results of domain model, this phase analyzes domain description in agent-oriented view. In order to support analysis activities, goal-role-agent model and relationship model are used. 3.3.1 Goal-Role-Agent Model By analyzing domain description, this model defines the structure of domain, extracts roles included in domain and finally identifies agents that execute the extracted roles. At first, this model extracts goal, sub-goal and tasks from domain description in top-


61

down manner and represents them in hierarchical structure. Goal hierarchy diagram clearly shows the relation of goal, sub-goal and tasks. After grouping similar tasks and taking each group as a preliminary role, we can identify roles. In order to examine whether roles are appropriately identified or not, use case diagram in UML can be used. After modeling domain description into use case diagram, we examine that each use case matches with task and each actor matches with the group of tasks. If each actor corresponds to the group of tasks and use case corresponds to task within group, then we can easily extract agents and roles of each agent. In order to show role and agent identification step, we extend goal hierarchy diagram.

Domain Model - Domain Description, SRS

Goal, Tasks/ Actor

Goal-Role-Agent Model

Relationship, Messages

Agent, Use Case

- Goal Hierarchy Diagram - Use Case

Role,Agent, Tasks

Agent Model - BDI(Goal,Plan,Behavior,Infor.) - StateChart Diagram

Relationship Model - Graph

Messages

Relationship

Agents Agents for interaction

Internal

Interaction Model - Coordinator, Interoperation - Organization

Organization, Coordination

External

Prediction of Performance - G/Q/M Model - Metrics

Fig. 1. Engineering approach for agent-based system development

3.3.2 Relationship Model It is necessary to examine how agents to interact with each other to achieve goal of domain. This model is to establish the relationship among agents identified by goalrole-agent model. We represent the relationship by graph form. Although sequence

62


diagram in UML is often used to show interaction between agents, it may not be suitable to represent the interaction between autonomous agents because sequence diagram represents the procedural flow based on work order. Graph naturally shows the relationship among agents rather than sequence diagram. In graph, agent is modeled by node and the interaction between agents can be modeled by link. Link means that there exist messages between agents. Messages between agents can be extracted from domain description. Figure 2 shows example.

Message3

Agent1

Message9

Agent2

Message4 Message1

Message10

Agent5

Message7

Message2

Message8 Message11

Message5

Agent3

Agent4 Message6

Fig. 2. Relation Graph

Interpreting the direction of message in graph, we can obtain some useful information. At first, since messages are used to interact, set of messages should be included in vocabulary of agent communication language. For example, message1-11 in figure 2 should be supported by vocabulary of agent communication language. Each message must be transmitted in standard format. FIPA ACL can be used to establish ontology and define format for message. Other interpretation is that the agent receiving certain message must have the capacity to react(process) to the message(request). That is, agent receiving certain message has responsibility to complete the message that is entered into itself. Table 2 shows the responsibility of each agent in Figure 2. Table 2. Responsibility of agent Agent Name Agent1 Agent2 Agent3 Agent4 Agent5

3.4

Responsibility(Function) Processing message1, message4 Processing message3, message8, message10 Processing message2, message5 Processing message6, message7, message11 Processing message9

Design

Based on the agents and relationship among them, this phase designs internal and external view of agent. 3.4.1 Agent Model This model defines the internal elements of agent. Referencing BDI model, this model defines elements necessary for agent: goal to achieve, attributes about itself, plans


63

toward goal, behavior to execute, information necessary to behavior, language to interact with other agent and operation environment to communicate. Also stimuli types that enter into agent are message, event, sensor, etc. Goal defines what agent must achieve. In actual, goal means the role assigned to agent. Roles of each agent are already informed in analysis phase. Attribute defines static or dynamic attributes of agent. Static attributes are intrinsic or unchanged data such as agent name, address, group, etc. Dynamic attributes are changing attribute in time or other reasons. The state of agent in system can be one of dynamic attributes. States may be classified into idle, work, pause and fault. Plan controls agent’s behavior. Plan selects behavior suitable to response receiving request. When stimulus is entered into agent, plan searches behavior to react to the input. The selected behavior executes its function and returns results. Behavior defines action that agent can execute. Table 2 shown in relationship model is used to define the behaviors. For example, agent1 has behaviors processing message1 and message4. Information defines information(fact or knowledge) for agent to execute each behavior. Language is for agent to communicate with other agent. Agent communication language such as FIPA ACL can be used. If agent is legacy system and doesn’t use agent communication language, then interoperation mechanism between agent and legacy system is needed. Also, it is necessary to define operation environment of each agent. If operation environment between agents is heterogeneous, interoperation mechanism should be included in agent or provided by other assistant. 3.4.2 Interaction Model Each agent in agent-based system interacts with other agents to achieve system goal. In order for agent to efficiently interact with other agents, interaction model defines several mechanisms such as coordination, interoperation, external operation environment, management, etc. – Coordination. During interaction, conflicts or competition among agents may occur. Coordination mechanism is needed to control these situations. The mechanisms such as contract-net, matchmaker or broker can be used. – Interoperation. In order for heterogeneous agents to interact with each other, methods to support interoperation are necessary. There are many heterogeneous cases in agent society: different communication protocol and operation environment, different agent communication language such as ACL and KQML, different database query language. In order to support heterogeneous situations, system should support many interoperation assistant methods like wrapping, translation, etc. Each agent may contain necessary methods, or assistant can be employed to support interoperation. – Operational Environment. It is necessary to define external operation environment that every agent in system works on. Although each agent runs on internal operation environment, it interacts with other agents through external operation environment. That is, external operation environment is common working space for every agent. For example, internet environment is a typical external operation environment. If system supports mobile computing, then wireless internet can be used as external operation environment. – Management(manager). This supports operation of agent-base system. Primary management functions are as followings: create, register, delete and add agent, inform meta-information about agent, etc. These functions are similar to yellow-page services. In order to manage agents efficiently, useful management policies are needed.

64


For example, if certain agent can’t execute the assigned behavior for long time, then manager replaces the agent of new agent. When certain agent is overloaded, manager adds new agent or distributes the agent’s load into other peer agents. Further more, if interactions among agents are added, deleted or changed depending on the result of load balancing, then system performance may be changed. In this situation, manager should reorganize system architecture so that system performance can become optimal. 3.4.3 Looping There may exist some incomplete, inconsistent, or even erroneous aspects during above engineering steps. In order to correct or compensate them, it is necessary to review the results of each phase in reverse. For example, we may find incompletion of analysis phase during design phase or know inconsistency between domain model and results of analysis phase in design phase. We call reverse review activities as looping. This paper represents looping step by reverse(dot line) directed arrow in figure 1. The interaction model motivates looping. The first looping is to reflect the results of interaction model into the results of agent model. The coordination mechanism defined in interaction model can be included in agent model. For example, if engineer specifies contract-net method as coordination method, then each agent defined in agent model should have capacity to execute contract-net method. Since coordination mechanism is specified in interaction modeling step, coordination method isn’t specified in agent before interaction modeling step. Another factor to be reviewed in this looping step is whether new agent should be added or not. During interaction modeling step, new agents to execute new capacity may be extracted. For example, management agent or coordination agent can be newly identified for system management, coordination or interoperation among agents. In this way, looping is executed among whole engineering steps. These activities in looping phase compensate engineering activities and refine products of each phase. Therefore, it is effective to include looping phase in agentbased engineering. 3.4.4 Organization System components and relation among components(agents and relationship among agents) are established after looping phase. Before implementation phase, it is necessary to consider how to organize system. Because of autonomy of agent, we can’t know organization of system in design phase. In run time, system dynamically calls necessary agents and retracts unnecessary agent. In design phase, we can predict the organization that agent-based system shapes. Primary shapes are as followings. – Peer-to-Peer structure. If system uses contract-net coordination method, then system doesn’t have additional coordinator because each agent directly interacts with each other. Naturally, system organization will be peer-to-peer structure. – Hierarchical structure. If system uses mediator such as broker or matchmaker, then each agent interacts with other agent via mediator or by mediator help. Therefore system organization will be hierarchical shape. There are two types: group with local coordinator, tree with global coordinator. The structure grouping with local coordinator has local coordinators under which control agents. Local coordinators are interconnected in horizontal manner. Tree structure with global coordinator has global


65

coordinator that supports local coordinators. In tree structure, local coordinators are interconnected via global coordinator. Figure 3 shows the typical organizations of agent-based system. Although actual system organization is known in run time, these organizations can be predicted in design phase. Autonomous Agents identified in Design Phase Agent1

Agent2

Agent6

Agent7

Launching

Agent3 Agent8

Agent4 Agent9

Ma-Agent

Launching

Co-Agent

Launching

agent

agent

Agent5

local coordinator

local coordinator

global coordinator

agent Architecture1 in Run Time

Architecture2

in

Run

Architecture3 in Run Time

Fig. 3. System organization

In figure 3, agent1-9 are application agents related to domain. Ma-agent and Coagent are system agents related to system management and coordination. All agents are defined by agent model template. 3.5

Evaluation of Architecture

Performance of system is important factor in system engineering. In general, existing methodology approach focuses on specification, not performance. In fact, because many informal factors are related to performance, it is not easy to deal with system performance in design phase. This paper recognizes that system performance can be measurable using system organization. For systematic evaluation, G/Q/M model used in software quality field can be applied. G/Q/M is to define evaluation goal, query to extract metric, metric to evaluate performance. The example of query and metric is as followings: – Query: How many links are there in system organization?, How many links are increased when one agent is added?, How reliable is system when error in agent occurs?, How many accesses are needed until system starts to execute behavior?. – Metric: Number of links among agents, Number of links that need to add agent or coordinator, Number of interaction until one-time-search-success after receiving request, Number of interaction until more-time-search-success after receiving request, etc.

66


4

Application of New Engineering Methodology

4.1

Domain Modeling

We want to develop agent-based system that supports virtual e-shopping work. One user(buyer) wants to buy health goods via internet. Using his PDA, the user enters goods description: price, number, etc. Buy support department accesses mart sites distributed in the world and collects information related to the health goods. Then the department analyzes the collected information and provides the analyzed results for buyer. Buyer decides item and orders it with necessary information such as item number, credit card number, delivery location and delivery date. After receiving order, the mart confirms stock of item and requests that delivery firm should deliver the item at specified location and date. Delivery firm delivers the item and receives receipt from buyer. Finally, mart checks if buyer receives the ordered item within delivery deadline. In order to support e-shopping, system that provides quality service for user in open distributed environment is required. That is, the goal of this system is to provide one-stop buy service for user. Although user doesn’t go mart, he can buy and receive goods in home. 4.2

Analysis

4.2.1 Goal-Role-Agent Model At first, this step analyzes domain description and identifies goal and tasks. Then this step represents the structure of goal and tasks in goal hierarchy diagram. After grouping related tasks and matching use case diagram with the groups, we identify roles and agents. We can extend goal hierarchy diagram(EGHD) by linking roles and agents. In e-shopping work, goal is one-stop service for buy. Tasks are buy, order, sale, delivery and inventory. Each task also has several subtasks. Primary roles are buy, buy-support, sale, delivery and inventory. From these results, agents for eshopping are buyer interface, buy-supporter, mart, manufactory firm, delivery firm. 4.2.2 Relationship Model This step analyzes interrelationship among agents. Relationship can be modeled with agents and messages among agents. Graph naturally represents the relationship. In eshopping, relationship is modeled like figure 4. This graph contains messages that each agent sends to and receives from other agents. For example, – Buyer interface agent: Request information(goods specification), Order(item, payment card, delivery date), Confirm delivery(delivery specification) Also each message implies behavior that each agent must execute when it receives message. – Buyer interface agent: Confirm delivery(ordered item), Retrieve information(information from mart)


67

Fig. 4. Relationship graph of e-shopping

4.3

Design

4.3.1 Agent Model Agent model defines internal agent capability. Items of agent definition template are name, goal(role), attribute, plan, behavior, information, language and internal operation environment. Results of previous steps are used to define the template. For example, agent and role from goal-role-agent model, vocabulary and behaviors from relationship model, operation environment from domain model. Each agent is defined as to template. For example, buyer interface agent is defined like below. Name Goal Attribute Plan Behavior

Information Language Op. Environ.

Buyer interface agent Buy goods Address: Resource Need: State: idle, work, pause or fault Select the behavior matching with entered request(message) Send: Request information(goods specification), Order(item, payment card, delivery date), Confirm delivery(delivery specification) Behavior: Confirm delivery(ordered item), Retrieve information(information from mart) Goods specification to buy, Order description Request information, Order, Confirm delivery, Retrieve information Internet

4.3.2 Interaction Model This model defines coordination, external operation environment, interoperation, management, etc. These activities are to support interaction among agents. – Coordination: In e-shopping, if there is only one mart, then coordination between mart agent and buy-support agent is not required. If there are several marts, then buysupport agent must decide one mart among marts. In this case, mediator searches appropriate mart among registered marts and helps buy-support agent and the selected mart agent interacts with each other in manner of broker or matchmaker. If engineer

68


wants that buy-support agent and mart agent interact with each other without mediator, then contract-net method can be used. Mediator can be defined as coordinator agent that plays a role of coordination. This agent has behaviors such as broker, matchmaker or contract-net. – External operation environment: This defines external operation environment that agent communicates with other agents. That is, external operation environment is defined in order for all agents to communicate with each other. In e-shopping, external operation environment must be internet as described in domain description. Therefore, all agents must have internal operation environment to communicate through internet. Otherwise, interoperation assistant is needed. – Interoperation: When heterogeneous agents want to interact with each other, interoperation must be supported. In e-shopping, every agent are not homogeneous. Buyer-interface agent, buy-support agent and mart agent run on internet, but delivery firm agent and manufactory firm agent run on ethernet. In order for mart agent to interact with delivery firm agent, language translator and gateway are needed. – Management: Manager agent establishes and executes management policies to efficiently manage agents(society) related to e-shopping. Management activity is common to all agent-based system. 4.3.3 Looping There may be some inconsistency and omission during engineering. In e-shopping, reviewing interaction model, we can recognize that coordinator agent and manager agent be newly needed. They are to coordinate agents’ interaction, support interoperation among agents and manage agents’ society. They can be defined as to template of agent model. For example, coordinator agent can be defined as below. Name Goal Attribute Plan Behavior Information Language Op. Environ.

Coordinator agent Conflict protection Address: Resource Need: State: idle, work, pause or fault Select the behavior matching with entered request(message) Coordination: Matchmaker, Broker Interoperation: DB wrapper, Translator, Interface mapping Requester list, Server list Ask-all, Reply Internet

4.3.4 Organization After looping step, agents and relationship among agents are established. Before implementation phase, it is necessary to consider system organization. System organization for e-shopping is like figure 5. Agents for e-shopping are buyer interface agent, buy-support agent, manufactory firm agent, delivery firm agent, mart agent, manager agent and coordinator agent. Buyer interface agent interacts with buy-support agent without coordination. Coordinator agent contains coordination behaviors. Buysupport agent interacts with mart agent using matchmaker behavior. Interoperation behaviors are needed between mart agent and delivery firm agent as well as mart agent and manufactory firm agent. We assume that interoperation behaviors are included in coordinator agent. Coordinator agent plays a role of broker between mart agent and delivery firm agent. Manager agent maintains meta-information about reg-


69

istered agents and provides meta-information. Before system starts, agents are individually placed in repository. As system proceeds, necessary agents are launched into working space of system. Launched agents interact with other agents to execute their role. Autonomous Agents Repository Buyer i/f

Buy-support

Manufactory

Manager

Coordinator

Inter-operation

Delivery

Mart

Launching Mart

Manager

Buyer i/f

Buy-support

Coordinator

Delivery Firm

Inter-operation

Manufactory Firm

Agents Interaction in Runtime

Fig. 5. System organization of e-shopping

4.4

Performance Prediction

Based on system organization, we can predict system performance. It is necessary to define G/Q/M model. We can measure organization characteristics using metrics and evaluate(predict) system performance. If there are some alternative organizations, we can analyze alternatives and select optimal organization.

5

Characteristics of New Methodology

This methodology improves and extends existing methodologies as followings. – New methodology steps into two dimensions-phase and view dimension. Phase is analysis and design. View is partitioned with internal view and external view. By considering two dimensions together, new methodology can execute engineering activities systematically and clearly. Most existing methodologies don’t clearly consider together both phase and view.

70


– Models and activities are interconnected in seamless. In order to provide seamless engineering, this paper introduces necessary models. For example, relationship model connects goal-role-agent model with agent model and also becomes reference model for interaction model. – Autonomy of agent is considered on our methodology. After internal view of agent is defined by agent template, agent autonomously acts. Because of autonomy of agent, we don’t know how agents interact with each other and which system organization will be shaped until run time. New methodology considers dynamic organization by autonomy of agent. – New methodology adds activities to complement engineering: relationship, looping, performance evaluation. Existing methodology don’t emphasize on them. They must be important activities to enhance quality of engineering results. In special, since system organization is not shaped until run time, it is efficient to predict performance based on the organization that can reason in design phase. Engineers can predict and improve system organization and performance before implementation. In this paper, nonfunctional aspect is considered during engineering. – New methodology contains coordination methods. Most existing methodologies focus on development process or representation method, but don’t consider coordination methods in their methodologies. By including coordination mechanisms, our methodology efficiently supports interaction and enhances society of agents. – The interoperation methods described in this paper show how heterogeneous agents interact with each other in generic architecture. Interoperation provides idea to develop into generic methodology.

6

Conclusion and Future Work

It is necessary to establish systematic engineering methodology so that system developer can use to develop agent-based system. We find some weaknesses of existing methodologies and extract considerations to improve them. Based on the considerations, we establish engineering methodology for agent-based system. In detail, this paper defines engineering phases and views, models in each phase, activities in each model and diagrams to support activity. Also through virtual example, we show new engineering methodology can be used to analyze and design agent-based system. The characteristics of this methodology are as followings: clear engineering steps, add models and activities to support seamless engineering, include coordination and interoperation methods, predict system performance using system organization, adapt generic agent-based system architecture, etc. This methodology helps system engineer develop agent-based system. In future, engineering methodology must support more detail method for system performance prediction, dynamic system organization method, management policy of agents, etc.

References 1. Bauer, B., et al: gent UML: A Formalism for Specifying Multiagent Software Systems, Agent-Oriented Software Engineering, LNCS 1957, Springer (2000) 91-103. 2. Esmahi, L., et al: Toward a Mobile Work Environment, Mobile Agents for Telecommunication Applications, LNCS 1931, Springer (2000) 29-47.


71

3. Huhns, M. et al: Interaction-oriented Software Development, Inter. Journal of Software Engineering and Knowledge Engineering, Vol. 11, No.3, World Scientific Pub. (2001) 259-279. 4. Iglesias, C.A. et al: Analysis and Design of Multiagent Systems using MAS CommonKADS,Intelligent Agent IV, LNAI 1365, Springer (1998) 313-327. 5. Jennings, N.R.: An Agent-Based Approach for Building Complex Software Systems, CACM,April, Vol.44, No.4 (2001) 35-41. 6. Lander, S. E.: Issues in Multiagent Design Systems, IEEE Expert, Mar.-Apr. (1997) 18-26. 7. Lejter, M., et al: A Framework for the Development of Multiagent Architectures, IEEE Expert, Dec. (1996) 47-59. 8. McBreen, H.M., et al: Evaluating Humanoid Synthetic Agents in E-Retail Applications, IEEE Trans. on Systems, Man, and Cybernetics-Part A: Systems and Humans, Vol.31, No.5, Sep. (2001) 394-405. 9. Wooldridge, M., et al: A Methodology for Agent-Oriented Analysis and Design. 10. Omicini, A.: SODA: Societies and Infrastructures in the Analysis and Design of Agentbased Systems, Agent-Oriented Software Engineering, LNCS 1957, Springer (2000)185193. 11. Shehory, O.: Software Architecture Attributes of Multi-agent Systems, Agent-Oriented Software Engineering, LNAI 1957, Springer, (2000) 77-90. 12. Scott, A., et al: Multiagent Systems Engineering, Inter. Journal of Software Engineering and Knowledge Engineering, Vol.11, No.3, World Scientific Pub.(2001) 231-258. 13. Schetter, T., et al: Multiple Agent-based Autonomy for Satellite Constellations, ASA/MA 2000, LNCS 1882, Springer, (2000) 151-165. 14. Vidal, J. M., et al: Inside an Agent, IEEE Internet Computing, Jan-Feb. (2001) 82-86. 15. Woods, S. G., et al: Architectural Evaluation of Collaborative Agent-based Systems, Technical Report CMU/SEI-99-TR-025, Oct., CMU (1999). 16. Zambonelli, F., et al: Organizational Rules as an Abstraction for the Analysis and Design of Multi-agent Systems, Inter. Journal of Software Engineering and Knowledge Engineering, Vol. 11, No.3, World Scientific Pub. (2001) 303-328. 17. FIPA: FIPA Agent Management Specification, http://www.fipa.org/specs (2001) 18. FIPA: FIPA Agent Software Integration Specification, http://www.fipa.org/specs (2001)

An Ecosystem-Inspired Mobile Agent Middleware for Active Network Management Daniel Rossier1,2 and Rudolf Scheurer2 1 Swisscom

Innovations, Switzerland (ERMIP6SWWMIV$W[MWWGSQGSQ 2 University of Fribourg, Switzerland 6YHSPJ7GLIYVIV$YRMJVGL Abstract. We present Ecomobile, a mobile agent infrastructure based on ecosystem principles, serving as a middleware for distributed network-centric applications such as network management algorithms. First we identify the main characteristics of conventional multi-agent systems based upon different coordination and navigation models. Thereafter we describe Ecomobile as a reactive system consisting of a self-regulating population of mobile agents. We also present simulation results examining the ecosystem behaviour and propose a viable deployment within a FIPA-compliant environment using the Jade agent platform. Finally, we report about applications for the creation and management of novel value-added services in optical networks (presented in previous publications).

1

Introduction

In the past few years, there was much of a hype related to software agent technology. A lot of research projects have been dealing with agents that are autonomous, intelligent, deliberative, and so on. But when it comes to mobility, people (at least those related to industry) still tend to query the need for software agents to be mobile. It is argued that all what is achieved using mobile agents can also be done by means of “traditional”, stationary agents. This is certainly true when we note that most mobile agents based applications are in fact based on a very limited use of mobility, i.e. mostly being restricted to the download and remote execution of code. This may be true even for mobile agents exploiting the full flavour of mobility. But that is not the point. We think that mobile software agents have application areas where they are particularly suitable, additionally offering a new approach (or even paradigm) for service creation and application development. This is especially true for domains where conventional approaches fail due to problems related to complexity, scalability, lack of flexibility or the like. Network Management is one of the most promising application domains for mobile agent technology. Active Networks, for example, have been subject to many research activities. In this paper, we present Ecomobile, an ecosystem-inspired mobile agents middleware providing the means to disseminate and execute tasks for distributed network applications mainly related (but not restricted) to network management. It is predicated as ecosystem-inspired since it makes use of a self-regulating population of moA. Karmouch et al. (Eds.): MATA 2002, LNCS 2521, pp. 73–82, 2002. © Springer-Verlag Berlin Heidelberg 2002

74

Daniel Rossier and Rudolf Scheurer

bile agents that serve as an independent middleware to distribute the tasks. The probably most distinguishing aspect of Ecomobile, i.e. the separation of the computation model from the navigation and coordination model, is explained in this paper. In the area of mobile agent technology, deployment issues tend to be disregarded. But, especially for network management applications in the telecommunications area, this is a crucial point. A successful deployment of mobile agents based solutions in telecommunication networks requires a robust, self-adaptive and scalable mobile agents framework. With our work, we tried to address these issues with a deployment approach based on the Jade agent platform and a reactive programming framework. This document is structured as follows: subsequently, in Chapter 2 we present some of the most relevant approaches using mobile agents for network management and comment on them from the point of view of our work. In Chapter 3 we describe the design of Ecomobile and present some simulation results, whereas in Chapter 4 we discuss issues related to the deployment. Finally, Chapter 5 will outline our intentions regarding applications and future work and Chapter 6 presents our conclusions.

2

Mobile Agents in Network Management

Considering mobile agents in telecommunication networks entails several advantages, among which the reduction of message processing between distributed entities limiting the bandwidth required for management purposes, the local processing enabling fast reaction to external changes, the design of distributed applications in which the management logic supposes the visit of several nodes, a significant improvement in terms of scalability and robustness, etc. Within the scope of this paper it is impossible to give an exhaustive account of this research field. Nevertheless we will try to cover the most important approaches for mobile agent based network management relevant to the context of Ecomobile. A very comprehensive study of mobile processing for network management was done within the Perpetuum Mobile Procura (PMP) project [1]. In the context of this project, a taxonomy of mobile code leads to the definition of various kinds of mobile agents [2] which are supposed to evolve in the same infrastructure in order to fulfil different functional areas of network management. These agents evolve in a particular mobile code environment (MCE) which is part of a network element and provides for example migration, communication and security facilities, and an interface to managed resources within the network element. Active Networks (AN) are based on a similar approach, namely on Actives Nodes containing Execution Environments for capsules transporting the Active Applications. The AN infrastructure therefore appears to be an ideal candidate for the implementation of mobile agent based applications. It supports the transfer of code via capsules and also ensures reliable communication channels as well as a secure access to the local resources. Furthermore, it supports several execution environments, so that active applications can be divided into different categories according to their application domain. Still, the deployment of mobile agent systems into ANs is at an early stage and reveals several issues such as security, performance, safety, garbage collection, and platform independence [3]. All the above approaches are based on mobile agents that act more or less isolated, i.e. there is no notion of a society of mobile agents and little or no coordination or

An Ecosystem-Inspired Mobile Agent Middleware for Active Network Management

75

cooperation ability. A sample approach based on a population of cooperating mobile agents is the one proposed by the MIT [4]. The experiments were performed with a discrete simulation of a mobile ad-hoc network involving several types of mobile agents working cooperatively to build a network map which can be used for routing decisions. Here, cooperation is based on direct communication when agents meet and exchange their knowledge. On the contrary, there are also approaches based on indirect communication. In systems endowed with the property of Swarm Intelligence [5], unintelligent agents with limited individual capabilities collectively exhibit intelligent behaviour. This bio-inspired approach draws its model from evolutionary biology and from the study of ecosystems such as bacteria, ants or bees societies: it turns out that these societies exhibit social coherence although the individual’s behaviour is mainly stochastic. This kind of behaviour is known as emergent behaviour. A very similar approach is AntNet [6], a mobile multi-agent system aimed at the adaptive learning of routing tables in communications networks. The system refers to the stigmergy concept, which may be defined as the indirect communication mediated by modifications of environmental states that are locally accessible by the communicating agents. In the following chapter we propose a particular mobile multi-agent system architecture dealing with the issues of mobility, coordination, communication, and agent population in a transparent way.

3

On the Design of Ecomobile

Ecomobile is an artificial ecosystem that provides an efficient middleware for the development, simulation and efficient control of distributed, open and self-organized applications and considering the mobility as a key concept for the support of decentralised network management; still, Ecomobile exploits mobility functions, such as cloning or meeting-based coordination [7]. A community of interacting mobile agents continuously evolves within the network infrastructure. Mobile agents implement particular bio-inspired behaviours accommodating the dissemination and activation of intelligent tasks within the network; the agents’ lifecycle leads to emergent selfregulatory properties. We now introduce the Ecomobile model and its components; the ecosystem principles and the associated reactive behaviours will then be described. The Ecomobile model relies on two concerns: the Mobile Behaviour Scheme (MBS) and the Task Objective (TO). The MBS, on the one hand, implements both a navigation and a coordination model; it describes the agent behaviour from the point of view of migration and agent-to-agent interaction by means of reactive behaviours ( -behaviours). The -behaviours characterize the activities of the ecosystem individuals, such as movement, waiting, self-reproduction, action, etc., or activities implying interactions with other individuals, such as communication or competition. The -behaviours are reactively triggered by the environment in which the agents are evolving. The task objective, on the other hand, consists in the operational behaviour of the agent, i.e. the description of a specific network management task such as routing, monitoring, resource allocation, fault detection, etc. The TOs are deposited in the agents’ environment and dynamically loaded into the ecosystem’s mobile agents. They

76


rely on a particular computational model based on a single dependency relationship from the MBS to the TO; the task has no direct effect on the agent behaviour. As a consequence, a task objective navigates within the network according to passive migration. In case of inappropriate destination, the TO may be detached from the agent transporting the TO and put back into the environment. The mobile agents’ statistical visits which emerge from the self-regulatory population property of the ecosystem, will allow the task to be reloaded and propagated to the expected destination. The TO's lifecycle therefore turns out to be different from the agent’s one. In this paper, we mainly focus on aspects related to the MBS; a discussion on task objectives dedicated to routing applications can be found in [8]. Other applications are pointed out in the last chapter of this paper. The clear separation of MBS and TO leads Ecomobile to exhibit a radically different programming model from other mobile agent systems; the agent navigation, for example, does not rely on a particular task, so that the regulation of agent population is much more efficient. 3.1

Agency and M-agent

The main components of Ecomobile are the agency, the blackboard, the place and the M-agent referring to the mobile agent (see Fig. 1). Place and agency are organized in an identical way proposed by the OMG MASIF specification [9]. All these components are supposed to be installed into an appropriate execution environment of each network device. In this context, Active Networks (AN) are particularly interesting for implementing Ecomobile since they provide an interesting way to host Java applications by means of a specific operating system such as Janos or Ants [10]. The Agency is a FIPA1 agent which implements the Ecomobile components; it may co-exist with other stationary agents such as SNMP/CMIP agents and is responsible for managing the blackboards and the places. The agency also provides Ecomobile with an adequate mobile agent environment different from the active node's execution environment; it governs the M-agent activities and manages the agent-to-agent and agent-to-environment interactions, so that security policies and access control can be implemented into the agency. The agency also provides the mobility services which are necessary for the M-agent migration. The migration itself between Ecomobile agencies is achieved via a specific FIPA-compliant Agent Communication Language (ACL) message and a particular protocol including class transfer when necessary. The place, in Ecomobile, has two main functions: at first, the place is used as a basic location concept; M-agents migrate from place to place. Furthermore, places are interconnected to form the intra-agency and the inter-agency connectivity. The intraagency connectivity allows the M-agents to migrate virtually, whereas the interagency connectivity allows them to migrate physically from one node to another. A connectivity matrix reflects the place topology maintained up-to-date by the agency. Each place is associated to a passive blackboard which is part of the ecosystem environment and allows M-agents to deposit information intended for other agents. Each M-agent only has visibility on the blackboard associated to the place in which it resides. In Ecomobile, the blackboard is also used as a repository for the task objectives. 1

Foundation for Intelligent Physical Agents (FIPA) appears to be the dominant standards organization in the area of agent technology.


77

Interaction

Blackboard

t2 tBlackboard n tBlackboard t1 n t3

Mobile Behavior Scheme (MBS) f(f1, f2, …fn)

• Mobility Service • Place Management

Ecomobile Agency

Agent Context

Place

ti tj tk Active Node

get/set/action

FIPA Agent Platform

SNMP/CMIP Agent

Java OS

Agency Agent

Execution Environment (EE)

MIB

M-agent

Fig. 1. Active Node Environment with Ecomobile

3.2

An Ecosystem-Inspired Approach for Mobile Processing

The ecology enlightens the impact of the individuals’ behaviour on the ecosystem population: the competition between individuals in a natural ecosystem, in particular, plays a fundamental role in the self-regulation of the population. Competition can appear between individuals belonging to the same species, in which case it is known as intraspecific competition, or belonging to different species, in which case is called interspecific competition. We aim at exploiting a particular kind of competition called territoriality [11], in order to address the problems of the density control, the agents’ population size as well as their propagation in the network. Territoriality is defined as an interference2-based intraspecific competition occurring between members of the same species for the control of territories. The significance of territoriality lies in the fact that individuals of a territorial species that fail to obtain a territory often make no contribution whatsoever to future generations. Consequently, the territoriality exhibits a particularly powerful regulatory influence on the populations concerned3. This highly interesting density-dependent and self-regulatory property suggests proposing a mobile behaviour scheme approximating the territoriality paradigm issued from the ecosystem theory. Such a design requires a judicious combination of behaviours. In our context, the territory refers to the network node. A number of definitions are now introduced in order to formalize the description of -behaviours. Reactive Behaviours. -behaviours are defined as a form of simple ecological behaviours that M-agents can perform within the ecosystem. According to the different mobile agent based approaches that we have examined, eight -behaviours 2 3

Interference is a kind of competition between individuals interacting directly. In ecology, territoriality is one particularly important and widespread asymmetric intraspecific competition.

78


have been identified: -{birth, migration, action, interference, absorption, clone, wait, death}. The combination of -behaviours enables the definition of a particular MBS. We now describe two different MBS, called MBS-low and MBS-high (depicted in fig. 2) approximating the territoriality paradigm and therefore leading to a densitydependent self-regulatory population of M-agents.

M-Agent

M-Agent

z

M-Agent

y

birth

M-Agent

x

M-Agent

z

M-Agent

y

birth

birth

x

birth

migration

migration

…

… death

action

death

action

…

… interference

absorption

wait

clone

interference

yes

no

death

yes

no

Knowledge Transfer

wait

absorption

wait

death

clone

death

Knowledge Transfer

wait

death

Fig. 2. Two different mobile behaviour schemes approximating a territorial behaviour: MBSlow (left) and MBS-high (right)

In MBS-low, the agent starts a migration directly after its birth ( birth). When the agent has reached a new place, it activates the action behaviour, which consists in loading the possible task objectives present in the associated blackboard into its context. The agent, which "defends" its territory (its place), enquires if another M-agent is residing in the same place: it contacts a visible M-agent ( interference), provided the contacted agent is performing a wait behaviour. The M-agent can then perform two different actions depending on whether the contact has been established or not. In case of successful contact, the contacting agent performs a absorption which implies a transfer of all task objectives from the contacted agent into its agent context, irrespective of the task nature. In the proposed MBS, the contacted agent dies ( die) whereas the agent enriched with the new knowledge leaves the current place towards another place ( migration) in order to "conquer" other nodes4. If the M-agent fails to contact another agent, it performs a clone behaviour according to its own cloning strategy and eventually continues its migration over the network. Since the diffusion of the M-agents within the network is "slow", this kind of mobile behaviour scheme is known as low diffusion - or MBS-low. The second MBS is rather similar to the first one, with the exception of two modifications: in order to ensure that no other agent is sharing its location place during a certain time (defined by wait), the M-agent iterates the interference-absorption scheme. In order to compensate for the high mortality rate of this iterative process, the M-agent activates a cloning process before leaving the node so that all the available output links are investigated by the M-agents at the migration time. This behaviour, 4

In this context, "conquering" the network simply means exploring the nodes; no specific mark is deposited by the M-agent into its environment.


79

which is similar to a breadth-first parallel search, allows exhaustive exploration of the network leading to a faster diffusion of M-agents. This is why this mobile behaviour scheme is referred to as high diffusion - or MBS-high.

4

Implementation, Simulation, and Deployment with Jade

Implementation with Reactive Programming. We consider Ecomobile as a reactive system [12] that has been implemented with a reactive programming framework called Junior [13]. Two fundamental notions are defined in the scope of the reactive approach: an instant is defined as a logical instant of execution during which all the parallel components of a program perform one execution step, i.e. a reaction corresponding to that instant. Junior provides an efficient Java API based on formal semantics for reactive programming; it has been developed in the scope of the MIMOSA project5 at INRIA, France. Its small code size allows Junior to be considered as a micro-kernel. Junior implements a reactive machine which manages the execution of event-based reactive programs composed of Reactive Instructions (RIs). In Ecomobile, each -behaviour corresponds to a RI. RIs can be added in the program statically or dynamically by means of the parallel constructor: Par(Program first, Program second). Simulation of Ecomobile. Using the time reference model defined by the Junior instants, we have performed several experiments on various network topologies; we present simulation results obtained with the Swiss network (33 nodes, 50 links) depicted on Fig. 3, which represents an optical network within Switzerland. The node frequency visit (V) corresponds to the number of TO activations. The number of coresiding agents (AG) represents the final value (last instant of the simulation). The migration time has been empirically chosen as a random value between 0 and 10 instants. The simulation has shown that the MBS promotes frequent M-agents visits when the nodal degree6 is high; the number of TO activations is therefore higher in nodes which are considered as critical because of their high connectivity. Another interesting property is that, because of the density-dependence of the MBS, the same magnitude of node visit frequency may be observed for nodes with identical nodal degrees. The evolution of the population average is shown on Fig.4 with different values of waiting time (wait) and migration time (move). According to the MBS, the number of agents grows when the migration time increases; however, the population is lower for low values of waiting time. We have observed that the number of agents is the closest to the number of network nodes with MBS-low when move=10 and wait=15. This is also the case for other network topologies presenting different characteristics regarding symmetry, nodal degree and connectivity. 5

More information about MIMOSA (Migration & Mobility: Semantics & Applications) available at http://www-sop.inria.fr/mimosa/rp 6 The nodal degree of a node is defined as the number of input and output links connected to this node.

80


Fig. 3. The Swiss network and node frequency visit (V) (MBS-low, move=10, wait=5)

Population average 100

N(t)

80

MBS low , move=10, w ait=5 MBS high, move=10, w ait=5

60

MBS low , move=20, w ait=5 40

MBS high, move=20, w ait=5 MBS low , move=10, w ait=15

20

MBS high, move=10, w ait=15 0 0

5000

10000

15000

20000

Time (#Jr Instant)

Fig. 4. Evolution of the M-agents’ population over the time

In all cases, simulation results have shown that the M-agent population remains stable over the time. Further experiments with large-scale networks are currently under investigation. Deployment in a FIPA environment with Jade. Jade [14] is a popular and freely downloadable FIPA-compliant agent platform which defines a one thread-per-agent model and implements the intra-agent activity with a synchronous (non pre-emptive) concurrency model. In this context, different behaviour patterns (cyclic, sequential, parallel, FSM, etc.) are supported by the platform; we have implemented the Ecomobile agency with a cyclic behaviour which allows the reactive machine to be activated synchronously. Additionally, Jade enables any kind of Java object to be serialised via the setContentObject() method and consequently provides a way to transport the agent code (class and object), since FIPA does not support mobility yet.

An Ecosystem-Inspired Mobile Agent Middleware for Active Network Management Jade Agent Agency

81

2: Asynchronous ACL messages exchange

setContentObject(M-Agent)

Agency 3: PutInPlace(dest)

CyclicBehaviour

CyclicBehaviour Synchronous Activation

• putInPlace() • putInPlace() • moveTo() Reactive Machine • leave() •…

1: moveTo()

• moveTo() Reactive Machine • leave() •… first, Program second) Par(Program 5: add( -behaviour) 4: onWarmUp()

Place

Place

Fig. 5. Deployment of Ecomobile in a FIPA environment with Jade

Fig. 5 shows a scenario involving the migration of M-agents between two agencies. It is assumed that an agency is embedded into each network node involving the presence of a FIPA agent platform. Other FIPA agents can share the same platform seamlessly. We can for example assume that an M-agent requests the agency to move it: the migration behaviour invokes the moveTo(destination) method (1) provided by the agency. The agent is then directly embedded in an ACL message and sent immediately to the corresponding agency (2). The sender agency continues its activities while the remote agency stores the message in an internal buffer until it is processed by the cyclic behaviour. The agency then places the M-agent at the right place (3) and resumes the execution of the M-agent by calling the method onWarmUp() (4). This method inserts into the reactive machine the -behaviour (5) which will be executed at the next instant.

5

Summary and Future Work

Ecomobile is an artificial ecosystem composed of reactive mobile agents. Its model relies on the separation between the combined navigation and coordination model, implemented by the mobile behaviour scheme (MBS), and the computational model represented by the task objectives (TO). Ecosystem principles such as the territoriality paradigm ensure a self-regulatory property of the M-agent population. As a reactive system, Ecomobile has been implemented with reactive programming; thanks to the notion of instant, it is possible to evaluate how the population of M-agents is evolving. Simulation of Ecomobile with two MBS (low, high) on a Swiss network has shown that the M-agents investigate the network adequately with respect to densitydependence issued from the territoriality. Based on Ecomobile we have investigated on several applications for the creation and management of novel value-added services in optical networks. In recent publications we gave an account of applications like routing in optical VPNs and a novel

82


protection service that relies on the allocation and monitoring of protection paths based on a QoP (quality of protection) metric [8, 15]. Besides, we intend to investigate on other aspects such as automated SLA (service level agreement) management and generic service composition.

References 1. Andrzej Bieszczad, "Advanced Network Management in the Network Management Perpetuum Mobile Procura Project", SCE Technical Report SCE-97-07, March 1997 2. Andrzej Bieszcad, Bernard Pagurek, "Application-Oriented Taxonomy of Mobile Code", IFIP/IEEE Network Operations and Management Symposium (NOMS’98), February 1998 3. Stamatis Karnouskos, "Agent-populated Active Networks", Proceedings of the 2nd International Conference on Advanced Communication Technology (ICACT’00), 2000 4. Nelson Minar, Kwindla Hultman Kramer, Pattie Maes, "Cooperating Mobile Agents for Dynamic Network Routing", Chapter in Book "Software Agents for Future Communication Systems", A.L.G. Hayzelden, J. Bigham (Eds), Springer, 1999 (ISBN 3-540-65578-6) 5. Eric Bonabeau, Marco Dorigo, Guy Theraulaz, "Swarm Intelligence - From Natural to Artificial Systems", Oxford University Press, October 1999 (ISBN 0-19-513158-4) 6. Gianni Di Caro, Marco Dorigo, "AntNet: Distributed Stigmergetic Control for Communications Networks", Journal of Artificial Intelligence Research 9 (1998) 317-365 7. Giacomo Cabri, Letizia Leonardi, Franco Zambonelli, "Mobile-Agent Coordination Models for Internet Applications", IEEE Computer Magazine, February 2000 8. Daniel Rossier-Ramuz, Rudolf Scheurer, "Ecomobile: A Mobile Agent Ecosystem for Distributed Network Management", in Proc. of ECUNM'02, 2nd European Conference on Universal Multiservice Networks, Colmar (France), April 2002 9. OMG, "Mobile Agent System Interoperability Facilities Specification", Joint Submission, http://www.omg.org/cgi-bin/doc?orbos/98-03-09, March 1998 10. Patrick Tullmann, Mike Hibler, Jay Lepreau, "Janos: A Java-oriented OS for Active Network Nodes", in IEEE Journal on Selected Areas in Communication, March 2001 11. Begon, Harper, Townsend, "Ecology - Individuals, Populations and Communities", Blackwell Scientific Publications, Second Edition, 1990 (ISBN 0-86542-111-0) 12. D. Harel, A. Pnueli, “On the development of Reactive Systems”, In logic and Models of Concurrent Systems, NATO Advanced Study Institute on Logics and Model of Verification and Specification of Concurrent Systems ASI Series F, Vol. 13, Springer-Verlag, 1985 13. Laurent Hazard, Jean-Ferdy Susini, Frédéric Boussinot, "The Junior Reactive Kernel", Inria Research Report 3732, July 1999 14. Fabio Bellifemine, Agostino Poggi, Giovanni Rimassa, "Jade - a FIPA-compliant agent framework", in Proc. of the 4th Int. Conference on the Practical Application of Artificial Intelligence and Multi-agent Technology (PAAMS’99), pp. 97-108, London (UK), 1999 15. Daniel Rossier-Ramuz, Daniel Rodellar, Rudolf Scheurer, "Dynamic Protection Set-up in Optical VPN using Mobile Agent Ecosystem", Proceedings of DRCN'01, 3rd International Workshop on Design of Reliable Communication Networks, Budapest, October 2001

An Enhanced Mobility Management Mechanism for Active Access Networks Insu Kim1, Keecheon Kim1, Sunyoung Han1, and Hyukjoon Lee2 1

School of Computer Science & Engineering. Konkuk University Seoul, Korea, +82-2-450-3518 _HEVOKY]OGOMQW]LERa$OSROYOEGOV LXXTRKMGOSROYOEGOV 2 School of Electrical and Computer Engineering. Kwangwoon University Seoul, Korea LPII$HEMW]O[ERK[SSREGOV

Abstract. By having a local mobility management scheme such as regional registration of IETF, we can achieve local handoffs instead of global handoffs. Local handoffs by micro-mobility techniques shorten the delay in managing mobility in the visited domain since it eliminates the registration process to the home network of mobile nodes, hence it also decreases the load of HA(Home Agent). Using the characteristics of the active network, by employing active nodes in the wireless local mobility management environment, we can optimize the mechanism of registration and path setup for the mobile data traffic. We propose an enhanced mobility management mechanism which combines the micro-mobility techniques and active nodes of active access networks.

1

Introduction

In order to support IP mobility in the carrier’s network, end to end IP mobility needs to be provided. Mobile host moves with a permanent IP address, and the base stations are to be assigned with IP addresses, too. So, normal IP routing structure does not support the mobile host mobility. In order to solve this problem, MIP WG(Mobile IP working Group) in IETF(Internet Engineering Task Force) suggest a Mobile IP structure. To support IP packet mobility in the carrier’s domain, they use mobile IP in such organization as 3GPP2(3rd Generation Partnership Project 2). However, there are many problems in applying functional entities and physical entities at a same time, and tests are too difficult because the test cost is very expensive. Mobile IP structure of IETF is made for IP network mobility, not necessarily for a cellular network. So, MIP WG updates mobile IP structure to apply to a wireless network. Active network has programmable network nodes which execute or forward user program codes. In contrary to the existing network that stores and forwards packet, active network executes the installed program and forwards user packets. These


84

Insu Kim et al.

characteristics of active network support flexibleness and have many merits over the traditional networks. Active network[2] structure is developed to reflect user’s requirements. Active network nodes are programmable and execute user’s functions. If we use active network’s these characteristics, we can optimize the mechanism of registration and path setups. In this paper, we propose an enhanced mobility management mechanism using micro-mobility techniques and active nodes.

2

Related Works

2.1

Active Network

As the number of the internet users increases, user requirements are getting more complex and larger. In order to meet these requirements, many techniques are developed, however it needs long time to standardize and to be realized in the real network. And the rapid changes of user requirement compared to the slow changes in the network system make us to meet the user requirements difficult. In order to overcome these limitations, active network that has programmable network node which executes or forwards user program code is developed. In contrary to the existing network that stores and forwards packet, active network executes the installed program and forwards user packets. These characteristics of active network support flexibleness and have many merits over the traditional networks[6]. There are two different ways of implementing active network from the view point of sending program codes, one is a discrete form and the other is an integrated form. Discrete form which is also called as a programmable switch, executes some functions by sending program identifier and parameters to programs that are installed on network nodes. In this case, all the packets are separated as program codes and user data. Integrated form delivers and executes a capsule that consists of program codes and user data to internal nodes. In this case, all of packets are programs of network nodes and these programs are able to be transmitted by any of network users. 2.2

Mobile IP

Mobile IP[1] is developed by IETF to support user mobility between IP based networks in a global internet. When a mobile host moves, MN(mobile node) must register it’s COA(care of address) to HA(home agent). If MN moves far from the home network, the delay for the registration will be long enough for the proper mobility service to be inadequate. And the number of MN increase, the more loads for HA by MN-HA registration mechanism. It can also generate a serious security problem in registering the mobile node to the HA. In order to overcome these problems, micromobility techniques are developed. Local handoffs by micro-mobility techniques decrease the delay in managing the mobility in the visited domain, and it can also decrease the load for HA.

An Enhanced Mobility Management Mechanism for Active Access Networks

85

1. Agent Advertisement 2. MN Registration request

3. FA relays status to MH

FA

2. FA relays request to HA Tu nne ling

3. Registration response and binding

HA

6. FA de-tunnel and deliver data to the MN

5. HA tunnels data to the COA

4. CN Send Data to MN via standard IP routing

Fig. 1. Mobile IP

2.3

Micro Mobility

Micro mobility techniques manage local movement instead of managing global HAFA-MN movement. By having small regions such as cell sites or paging regions for fast handoffs and lower transmission delays, it can provide a better performance for the moving handset users. Many schemes have been developed to provide this local mobility such as Regional Registration, Cellular IP, and HAWAII. Those schemes have a local mobility management center in the visited area to shorten the unnecessary global registration. These protocols give faster handoffs and support more efficient mobile management and result in better transmit rate.

Coarse grain mobility

Global Internet with Mobile IP

Gateway

Wireless access network Local handoff fine grain mobility

Global mobility

Fig. 2. Micro Mobility

86

Insu Kim et al.

3

An Enhanced Mobility Management Mechanism for Active Access Network

In this paper, we propose a more efficient mobility management mechanism for MN in a visited network that consists of active nodes. There is GAR(Gateway Active Router) in the visited network. Mobile IP manages two level mobility HA-GAR and GAR-MN. The movement of MN which requires mobile IP services is mostly local within the visited domain. 9LVLWHG'RPDLQ $FWLYH1HWZRUN $5

$5 $5

01

+RPH 1HWZRUN

*$5

3XEOLF 1HWZRUN

+$

$5

5HJLRQDO7XQQHOLQJ0DQDJHPHQWGRPDLQ Fig. 3. Mobile IP in Active Network

3.1

A Path Setup Scheme in Active Network Environment

Active nodes are able to process program code in active capsule. In this paper, we propose a new path setup scheme without tunneling using the characteristics of active node. Registration request capsule which is delivered from MN to HA is consisted of normal mobile IP registration request message integrated with active code to be executed by active routers. ‘Packet parser’ in active nodes divides the capsule into a message and program codes. Program code is sent to ‘Code Loader’ in EE(Execution Environment)[3]. EE executes program code and stores MN’s home address taken from a registration request message into AR’s storage. ‘Forwarder’ in AR forwards capsules. When AR receives registration reply message, MN’s home address and port entry pair is stored in a routing table. ARs forward packets to MN by longest prefix matching rule of standard IP routing. If the registration timer expires, MN’s entry id in a routing table is deleted. If AR receives another registration request capsule, AR forwards the capsule instead of parsing the capsule. If AR receives registration request capsule of MN that has an entry in a routing table, AR updates it’s routing table and sends the registration reply packet to MN instead of forwarding the packet. Figure 4 shows the architecture of active router[5]. It has a code loader, code parser, forwarder, and storages as explained here.


87

Assistant

Forwarder Routing table

AA 1

AA 2

Execution Environment

Packet Storage Timers Parsing

Code Loader VM Node OS Fig. 4. Active Router

3.2

Registration Request Capsule

Registration request capsule consists of normal mobile IP registration request message and active codes. The following shows pseudo active code. In figure 5, we explain the structure of the registration request capsule which has a message part and program code[4]. boolean active_route() { if(packet.type==RREQ) if(node.visited) { make_register_reply(&msg); send(msg, mn_address); table_update(mn_address); } else { node.visited = TRUE; forward_packet(GAR); temporary_teble_insert(mn_address); } else if(packet.type==RREP) { routing_table_update(&temp_table, mn_address); forward_packet(mn_address); } }

88

Insu Kim et al.

Fig. 5. Registration Request Capsule

3.3

Home Registration

MN must create a new tunnel MN-HA with registration request when it moves and contacts new access point. Registration request message is delivered to GAR by AR(active router)s and each AR marks MN’s home address. ARs records MN’s home address and an incoming port number into their routing table as a pair. ARs, including GAR can send packet to MN by the information in their routing tables. GAR changes COA field in the registration request message with it’s address and relays the message to HA to register it’s address as MN’s COA. GAR records MN’s home address into it’s routing table, too. HA binds MN’s home address and GAR’s address, then a new tunnel is made between HA-GAR. And a path is set up between GAR-MN. CNs(correspondent nodes) in outer domains can send message to MN via HA-GAR tunnel and GAR-MN routing table. CNs in a visited domain, can send message to MN directly. Messages from visited domain to MN, are not necessarily reach HA because the routing table in ARs can guide packets. ARs, in a visited domain forward packets to MN by longest prefix matching rule of standard IP routing. 3.4

Local Mobility Management of MN

Mostly, MN moves around within a local network, and the existing paths to MN are located nearby the MN’s new position. New path to MN’s new position is set up by the updates between MN’s new position and the branch point. In figure 7, a tunnel between HA(GAR) and MN must be changed by the MN’s movement. A new tunnel set-up shown the right-hand side is necessary, a path between HA(GAR) and R2 is remained same as beofre. Reconfiguration of path between HA(GAR) and R2 is not necessary. In figure 7, making a new path to MN requires a new configuration of R2 and R4 only. R2 works like a MA(Mobility Agent) implicitly and sets up a new path to MN. Routing table entries in R3’s routing table are no more used and are removed by the record timer. MN’s information in the routing table is treated specially.


01

$5

* $5

+$

Fig. 6. Home registration

HA

HA

R1

R1

R2

R3

R2

R4

R3

MN

R4

MN Fig. 7. Changing path by Active Router

89

90

Insu Kim et al.

In order to support this mechanism, MN sends a registration request message to HA and the intermediate ARs record MN’s home address and port in their routing table. If an AR which records MN’s home address in it’s routing table receives a registration request message, it sends a routing reply to MN instead of forwarding a registration request and it updates it’s routing table entry for a new path for the MN. AR is a Mobility Agent works like an HA temporarily. This mechanism offers a very fast registration reply message to MN. Moving of active packets is shown in figure 8.

01

$5

$5

Fig. 8. Local movement manage

4

Performance Evaluation

We started our performance evaluation of the proposed method, when a MN is ready to get service after the successful registration on FA1. We assume that MN move to FA2 after FA1 registration is complete. Our simulation ends when MN finishes it registration to the new location FA2. We assume that the probability for FA1 and FA2 to be in a same domain is 50 percent. We describe the message transmission time between MN and GAR as tMG, and th transmission time between GAR and HA as tGH. Time dH and dG are used to represent the processing time for registering HA and FGA respectively, and dR means a searching delay on AR to process the routing table entries. We randomly select the values for the parameters t and d, and each test is run ten times to properly evaluate the new scheme.


91

Fig. 9. Average registration delay

Except for the worst case when MN requires home registration continuously, which is rare in a real environment, even though it is not consistent, the proposed mechanism shows less average latency time than the basic mobile IP mechanism. We test the registration delay by changing tMG to simulate the different network delays.

Fig. 10. Average registration delay relying on tMG

Since our regional registration scheme with active network nodes doesn’t necessarily send packets to GAR, the more network delay the better the performance. Testing the average registration delay time relies on AR’s processing speed shown in figure 11. Our mechanism shows the better performance with the faster processing speed of AR’s. As the processing speed of node increases, the performance of this mechanism is going to be more superior.

92

Insu Kim et al.

Fig. 11. Average registration delay relying on dR

5

Summary

In this paper, we propose an enhanced mobility management mechanism for mobile host in active network environment. By having active nodes in the intermediate nodes needed for location registration, we showed that the handoff performance has been greatly improved. Local handoff mechanism, based on micro mobility techniques can decrease the delay of mobility management and HA’s load. Path management using AR requires minimum message exchange. We expect very high performance when CN and MN are located in the same domain as well. In the future, we are going to add AAA(Authentication, Authorization, and Accounting) framework to solve the security problems occurred in the enhanced mobility management mechanism.

Abbreviation HA COA MN GAR EE AR FA AAA

Home Agent Care Of Address Mobile Node Gateway Active Router Execution Environment Active Router Foreign Agent Authentication, Authorization, and Accounting


93

References 1. Charles E. Perkins, “Mobile IP”, Addison Wesley, 1998. 2. D.L.Tennenhouse, J.M.Smith “A survey of active network research”, IEEE Communications Magazine, vol. 35, no 1, pp. 80-86, 1997 3. Scott Alexander et al., “The Switchware active network architecture”, IEEE Network Special Issue on Active and Controllable Networks, vol. 12, no 3, pp. 29-36, 1998 4. Mike Hicks, Pankaj Kakkar, Jonathan Moore, Scott Nettles and Carl Gunter, “PLAN:A packet language for active networks” in Proc. Of the Third ACM SIGPLAN International Conference on Functional Programming, pp. 86-93, 1998 5. D.L.Tennenhous and D.J.Wetherall, “Toward an active network architecture”, Comput. Commun. Rev., col.28, no. 2, pp. 5-18, 1996 6. E. Amir, S.McCanne, and R. Katz, “An active service framework and its application to real-time multimedia transcoding”, in Proc. ACM SIGCOMM, Vancouver, BC, Canada, pp. 178-189, 1998

An Architecture for Active Network Performance Management Based on Intelligent Agents Antonio Barba, Ernesto Sánchez Universidad Politécnica de Cataluña, Campus Nord, Módulo C-3 08034 Barcelona, Spain {telabm, ernesto}@mat.upc.es

Abstract. New active networks are integrated in global computing systems. These systems are based on programmable nodes in order to provide advanced management. In this article, a proposal for an architecture based on intelligent agents for active networks performance management is proposed. The architecture uses intelligent brokering with mobile agents to provide distributed processing with optimised variable charge in a global computing network. Different aspects, such as traffic, delays, performance, congestion, etc, are studied for providing the best quality of service with the proposed traffic management mechanisms.

1 Introduction The active network concept has arisen from dissertations in the DARPA development community between 1994 and 1995 about the future in network systems. Usually, an active network is considered as composed by Active Nodes, which allows their functions to be extended beyond from traditional routing actions, allowing the network to evolve from a simple user’s bits transport media to programmable environment, enabling it to adapt itself to current traffic conditions. Also, the development of this kind of networks necessarily involves new and very important approaches about highly significant aspects, such as security, interoperability, scalability and migration strategies. The point of view of the proposal introduced in this paper considers the active networks as based on new features derived from a new internal programmability structure. These new features allow network intelligence and new services to the user with best performance to be provided. Furthermore, the use of distributed processing for the nodes also allows advanced network management techniques based on Common Object Request Broker Architecture (CORBA), JavaBeans, artificial intelligence and so forth to be used. This article proposes a stimulating new network management framework based on intelligent brokering services provided by a set of powerful advanced nodes and databases. Mobile agents provide the required processing mobility to support the variable charge of the subscribers’ requests. The proposal described in this paper enhances an earlier architecture described in [1], representing a step towards a more complete design.

A. Karmouch et al. (Eds.): MATA 2002, LNCS 2521, pp. 94–103, 2002. c Springer-Verlag Berlin Heidelberg 2002

An Architecture for Active Network Performance Management

95

2 An Architecture for Active Network Management This article proposes an architecture based on intelligent agents for performance management in active networks, particularly in the traffic and congestion control areas. The main objective of this proposal is to allow user’s connections to be established based on QoS criteria, and then, to exert control mechanisms that allow the negotiated QoS levels to be maintained, avoiding congestion and, if it occurs, eliminate it with a minimum of user’s connections detriment. This architecture is composed of a Main Network Management Station, M-NMS, responsible for a complex network domain (Fig. 1). M-NMS

User

Domain

Fig. 1. Scheme of the proposed management architecture.

This domain is divided in groups, or Management Sub-Domains, all of them with similar characteristics, which in turn can be composed of smaller and simpler management sub-domains. Each one of these management sub-domains is managed by one of its active nodes, namely the Sub-Domain Main, or Manager Node, in a relative independent way, constituting thus a hierarchically distributed management architecture. In the following sections the main components of this architecture are described with more detail. 2.1 A Main Network Management Station, M-NMS The M-NMS’s task is coordinate the elements composing the architecture, as well as. provide a generalised view of the whole domain. However, the main, middle and low level, management tasks will be performed by the distributed entities of this architecture, i.e. agents and agencies, coordinated by the manager node. M-NMS relational databases will store useful information to traffic and congestion control in the sub-domain elements, such as the SLAs (used to perform a user admission control), information about the state of the network resources, and traffic

96

Antonio Barba and Ernesto S´ anchez

parameters monitored by the main nodes. The monitored information will be used to coordinate the traffic and congestion management among all the main nodes, as well as to route users’ applications considering the QoS. The state of the resources in each sub-domain will be maintained and upgraded by all the manager nodes via communications provided by means of mobile agents running over Java RMI and/or IIOP CORBA protocols. The management parameters stored in this database are classified by ports, which are characterised by the link and buffer maximal capacity and the queue policy. This management information are related to the state of resources on each port and the parameters of the aggregated traffic of each class of service defined. 2.2 The Sub-domain Nodes As shown in Fig. 2 there are basically three different types of nodes in a sub-domain, namely the edge nodes, the core nodes and the manager node. [1] offers a better description of these nodes and how they can be modelled and implemented.

Fig. 2. A Basic Management Sub-Domain and its three Types of Nodes

The active node architecture is based on functional components like the Active Node Operating System (ANOS) and a set of specific processes supported by a main card (SUN platform). Furthermore, there exists an interconnected group of cards with network interfaces (ATM, IP, RMI...). The structure of this kind of node is described in [2, 3].

3 The Intelligent Agents and the Management Functions Management functions are exerted by agents, supported by agencies, which offers a set of basic services to agents, such as, security, creation, deletion, etc. In the following sections these management functions are described with some detail. 3.1 Adaptive Traffic Monitoring Traditional monitoring is based on interfaces defined by communication protocols, on the basis that every connection has the same class of service. This scheme of monitoring has an important deficiency since all classes of traffic are treated as


97

equals, without any distinction of the QoS levels. On the contrary, This architecture performs a monitoring that dynamically adapts itself to the different classes of service and the number of user connections of the same class circulating through a node, i.e. the amount of the aggregated traffic of the same class. Thus, monitoring frequency is estimated by a cost function, depending basically on the class of service and the number of connections the aggregated traffic flow is being monitored. As a consequence, the management traffic produced by the monitoring is maintained as low as possible, offering more attention where is needed. Also, traffic parameters that must be monitored will depend on the class of service. Thus, only those parameters really important for each class is gathered, without wasting processing time at nodes and network resources. A Monitoring Static Agent (MA_s), resident in each sub-domain node will periodically consult the node MIB to obtain the information needed, such as per traffic class lost rate, delay, jitter, throughput, error rates, etc. Each one of those parameters will be monitored with a frequency dynamically adapted, as mentioned before. Furthermore, this selective monitoring needs MIBs designed in a manner to support it, and the MA_s will update these databases. The management information is structured in managed objects according to CIM and a specification of XML document. The XML document may be encapsulated in an IDL format for a CORBA intelligent brokering [4]. In this case, the managed objects can be deployed as applets and represented as an XML document. Monitoring Mobile Agents (MA_m) will migrate among the nodes gathering this information and taking it to the main node. The path used for these agents, as well as its frequency is coordinated along with the MA_s. The migration strategy affects the efficiency of these agents, and must be considered carefully. Latter on this paper, some conclusions arisen from simulation results will justify which migration strategy has been chosen for these agents. 3.2 Services to the User In the present stage of this design, two different types of agents directly related to the user are foreseen. User Static Agent (UA_s), hosted in every outer edge node, represents the first contact the user makes with the network. It supports the connection establishment, negotiating the traffic parameters according to the SLAs. Moreover, User Mobile Agents (UA_m) will negotiate with the network the best route for each application, requesting to the manager node the best route for the user in each sub-domain. In this case, routing information is limited to each sub-domain, and is estimated according to a more complex cost function than those used in traditional routing algorithms, such as RIP or OSPF. 3.3 Traffic Management The proposed management mechanisms are based in the use of predictive agents distributed among the nodes. These nodes support agent algorithms with diverse threshold conditions according to the traffic levels of the network. There are static autonomous agents allocated in the nodes and other elements of the network, which are able to communicate with each other to adapt the traffic of the network. Other

98


agents are mobile agents and they are sent by the management system (i.e. the MNMS and active nodes) through the connection paths and nodes collecting information and cooperating with the static agents in order to obtain the global control in the network [5, 6]. The static agents work in the active nodes to assuring an appropriate QoS, testing differently each type of traffic. Four classes of traffic have been defined, according to priority levels. The agents will adopt different management policies according to QoS requirements defined for each traffic class and priority level. Furthermore, the results of the operations that perform the mobile agent in the managed node are transferred to the agent of the manager node by means of mobile agents and with a periodicity depending on the priority specified by the management centre. Nodes’ resource optimisation policies and the global network status, stored in the M-NMS databases, are taking into account to provide the best routing possible. In this sense, the manager agents relate the active nodes with the requirements of QoS specified by the subscriber in the SLA. Traffic management included in this architecture is composed of a small set of functions. The following are the main traffic management functions for this architecture. Link and Traffic Control. Many flow control research, specially in ATM networks, have established two main flow control mechanisms: Rate-Based Flow Control, such as the ERFC, and the Credit- or Window-Based Flow Control, such as Quantum Flow Control, QFC. Both mechanisms have their own advantages and drawbacks [7, 8]. The proposed architecture takes advantage of both approaches combining them, implementing a rate control of each source by means of UA_s at the outer edge nodes the users are attached to, and exerting an aggregated traffic control link by link through the core nodes of the whole domain. The following Fig. illustrates this concept.

Fig. 3. Traffic and link control exerted by intelligent agents.

Moreover, Traffic Control Mobile Agents (TC_m) will migrate between each pair of adjacent active nodes coordinating management policies exerted on both traffic and node resources. These agents will apply these management policies, described latter in this paper, according to traffic levels, threshold conditions, classes of services and priority levels


99

Resources Control. Two resource management functions are proposed intended for congestion avoidance in case it is detected, buffers configuration and processor control. These mechanisms, exerted by TC_m agents, will be coordinated along with actions performed by other agents in the system, such as predictor agents. All active nodes in the sub-domain will consider the queues of their links as a whole RAM memory block, susceptible of being dynamically configured. Thus, the TC_m, will assign more or less RAM to queue buffers of different service class according to the traffic needs, taking into account traffic parameters, such as the delay added by enlarging the buffer of a given class of traffic. This agent can decide how much the buffer size of a given class of traffic can be increased without increasing prohibitively the mean delay negotiated for it. Thus, losses rates can be limited under minimal threshold for sensitive traffic. The next figure illustrate this concept.

Fig. 4. Buffer control and configuration according to current occupancy.

In Fig. 4 can be seen an example of buffer configuration for class of traffic 4 (the higher class of service), where RS is the reserved memory space for other classes, ASC4 is the available memory space for class 4, TL is the threshold level and MBL is the mean buffer length, which refers to the buffer occupancy level of class 4. If traffic of class 4 ever reaches TL, more buffer room from ASC4 is assigned to this class in order to avoid the packet loss rate to increase. Moreover, if it is not possible to increase the buffer size for a class of service, TC_m agents will assign temporally more processor time to some packets belonging to this class, i.e. they will increase the priority levels of these packets in order to avoid packet losses or detriment in the traffic QoS. Other management functions has been defined in [1], such as link and traffic classification, which are essential for routing, resource planning and load balancing issues. 3.4 Congestion Management Lets suppose that a congestion situation has occurred in a sub-domain, or that it is imminent in spite of all the efforts made to avoid it. Rather than proceed to drop packets, the sub-domain main node will must try to deviate some traffic from affected nodes to alleviate the congestion. Traffic deviation can be performed at two levels. First, the traffic is deviated inside the same sub-domain, and thus the main node has only to create a new different route

100


for certain traffic in its own sub-domain and, therefore configure its nodes to perform this deviation. Second, it is possible that the traffic must to be deviated out of its subdomain to other sub-domains. In that case, the main node will send a Traffic Deviation Mobile Agent, DA_m, equivalent to the UA_m agent mentioned before, to the main node of one of its preceding sub-domains in order to request a new route for part of its traffic. Once the new route is configured, the traffic is deviated avoiding the affected sub-domain. 3.5 Prediction of Traffic Behaviour Another important objective of traffic monitoring in the network nodes will be the prediction of traffic conditions performed in all nodes in each sub-domain by a Predictor Static Agent, PA_s, which, using monitored traffic information, will generate these estimations. Considering the fact that network traffic exhibits a selfsimilar behaviour [9], these nodes will must estimate these characteristics and will predict the traffic levels. This information will be useful to estimate link classifications, as well as detect a possible congestion and apply active measures to avoid it. Predictor agents will inform the main node about their predictions. With this information, the Manager Node Predictor Static Agent, MPA_s, will produce an estimation about the traffic conditions in the entire sub-domain. The main nodes in all the sub-domains will share their respective predictions, gathered by mobile agents, in order to produce a prediction on the whole network, which will be sent to the MNMS. Thus, the network resources can be better planned and unwanted situations, such as the congestion, can be avoided by means of executing the appropriate controls on resources or by traffic deviation.

4 Common Considerations on Intelligent Agents This section describe some common issues related to defined agents. Agencies, which are the running environment of agents, offering them a set of services, are defined according to the specific management functions. An Agent interacts with its environment by means of events, which trigger the agent to perform specific tasks. If necessary, the agent responds to the eventgenerating entity sending a message, which is in fact another event, with the corresponding information (an acknowledge, a set of requested information, etc.) 4.1 States Defined for Agents The following states have been defined for all agents in the systems. All these states are common for all types of agents, although it is possible for some agents types to have more states defined specially due to its specific behaviour. The Fig. 5 shows these states and the transitions mentioned.


101

Fig 5. Common diagram state for intelligent agents. Event

Description This is the first state an agent is in, once it is created. In this state the agent exist INACTIVE but it cannot process any event, except special events, such as create or activate events. The agent goes to the IDLE state when it receives an ACTIVATE event. An agent is IDLE when it has been activated and it is waiting for an incoming IDLE event to process. When the agent receives an event, either external or internal, it goes to the BUSY state and process it. An agent is in this state while it is processing an event or performing some action. BUSY Any incoming event is queued and has to wait the agent to go to the IDLE state to be processed. However, it can be interrupted . If an agent, while in the BUSY state, needs some external event to complete the WAIT task it is performing, it goes to this state to wait for this event to happen. Again, some special events can force the agent to go to another state. If an exception occurs while an agent is performing a task, or the waiting time for some external events to complete its tasks is exceeded, the agent goes from the FAILURE BUSY or the WAIT state to the FAILURE state. Then, it creates an ALARM with a description of the exception and send it to the agent management system. When an agent exceeds its Time to Live field, it goes to the EXPIRED state and EXPIRED waits for either a DELETE or a RENEW event to come Table 1. Possible states for agents in the proposed architecture.

4.2 Results on Migration Strategies Simulations In order to determine which migration strategy fits best in this architecture, an experimental sub-domain was defined, shown in the next Fig., to perform some mobility simulations.

102


Fig. 6. Experimental sub-domain for mobility simulation.

A number of mobile agents will depart from the manager node (node 1) to gather monitored information from all the rest of nodes, and will come back to the manager node carrying this information. The idea is to determine which migration strategy perform this task in less time and with a less number of visits for each node. Four different migration strategies were considered: Random (R), Restricted Random (RR), Older Node (ON) and Defined Path (DP). The Fig. 7 represents the time spent in visit all the nodes in the sub-domain as a function of the number of agents employed for all migration strategies considered.

Fig. 7. Time vs. number of agents for each migration strategy.

As can be seen, the DP strategy is the most efficient considering the time needed to visit all the sub-domain nodes, which, in the best of cases, takes half the time the second best strategy (ON). Fortunately, it is possible to implement this strategy due to the limited size of the sub-domains.


103

5 Conclusions The proposed network management approach based on independent, distributed subdomains will allow this architecture to be highly scalable. Furthermore, since this architecture makes use of intelligent agents deployed in Java, and a middleware based on CORBA, it ensures a great interoperability and adaptability to new, emergent network technologies, while keeping independence on transmission technologies, protocols and either hardware and software environments. The modular nature of the applications based on intelligent agents and CORBA will allow new management functionalities to be easily incorporated to the proposed architecture. The management functions proposed are web-oriented since they foresee the use of technologies such as XML and DTD along with the CIM meta-model, all of them DMTF standards, to define the management information bases, MIBs. These features allow the application to be very portable and human managers can use simple tools to monitor and manage the network, such as Internet browsers. Furthermore, these mechanisms use information about network resources utilisation in order to establish a classification of the links that compose the network sub-domain and its traffic. Thus, this information is used to route users’ connection in an efficient manner, taking into account the state of the network and the QoS requested by users. In addition, these tasks also allow this information to be used in other management functions and, therefore, saving time and network management resources. Finally, predictions made upon traffic behaviour offer a mean to anticipate the congestion in order to avoid its appearance by means of actions whit a minimum of damage on user traffic, if possible. On the contrary, traditional mechanisms perform reactive actions against congestion (i.e. once it occurs) or, at least, alleviate the situation by dropping user packets.

References 1. Barba, A., Sánchez E. An Intelligent Agent-Based Architecture for Active Network Management. PRIMA2002. Tokyo, Japan (2002). 2. Barba, A. Gestión de Recursos en Conmutadores Mediante Agentes Inteligentes Móviles. II Jornadas de Ingeniería Telemática JITEL. Leganés (Madrid), Spain (1999) (in spanish) 305310 3. Barba, A. Gestión de la Calidad de Servicio en Conmutadores Mediante Agentes Inteligentes Móviles. Telecom I+D. ISBN: 84-7653-730-1 (in spanish) (1999). 4. Corba and XML resource page. http://www.omg.org/library/corbaxml.html 5. IKV++ Grasshopper, a Platform for Mobile Software Agents. http://www.ikv.de/yroducts/grasshopper/ 6. IKV++ Grasshopper User’s Guide, http://www.grasshoPDer.de/download/uguide.pdf 7. Duncan, C. Simulation and Analysis of Credit- and Rate-based Switch Interoperability in an ATM Network. Master of Science Thesis of the Department of Computer Science, Brigham Young University (1997) 8. Mollenauer, J. New Prospects for ATM Flow Control. Bussines Communication Review. http://www.bcr.com/bcrmag/03/mar9706.htm (1997) 9. Paxson, V., Floyd, S.: Wide-Area Traffic: The Failure of Poisson Modelling. IEEE/ACM Transactions on Networking, Vol. 3, Nº 3. (1995) 226–244

Agent-Based Context-Aware Ad Hoc Communication Mohamed Khedr1, Ahmed Karmouch1, Ramiro Liscano2, and Tom Gray2 1 Multimedia and Mobile Agent Research Lab School of Information Technology and Engineering, University of Ottawa 161 Louis Pasteur St. Ottawa, ON, K1N 6N5 Canada _QOLIHVOEVQSYGLa$WMXIYSXXE[EGE 2 Mitel Networks, Kanata, Ontario

Abstract. This paper presents a technique for combining context information and agent technology to support spontaneous applications in an ad hoc network environment. The multi-agent system uses the Ad hoc Context Aware Network (ACAN) infrastructure for context gathering, network setup and application management. Agents manage the process of creating, adapting, policing and terminating applications that rise spontaneously according to the situational context information of users, services, and resources. Typical spontaneous applications include locating services and users, invoking services in a nonpredefined scenario (such as remote conferencing between distant places), facilitating a common communication mechanism between users, and adapting to changes in the environment and the users’ mobility. The paper examines the requirements of a spontaneous ad hoc communication, the ACAN infrastructure, and the context-based service discovery protocol (CBSDP). The Ontology Aware Service System (OASS) is described as a semantically rich way for a common communication language between the agents and for the process of building up services discovered by the CBSDP protocol. Simulation scenarios are provided and the implementation currently being tested is described.

1

Introduction

Research in the telecommunication field suggests that future networks will be composed of sensors, wireless devices, personal digital assistants, networked appliances, and many different devices. This brings up issues such as unfamiliar users and service interfaces, the discovery of services to match the user’s needs and the management of a large number of network entities. This must all be accomplished in an automated way. A variety of protocols and services like SLP (Service Location Protocol), Jini, UPnP (Universal Plug and Play), and Salutation have developed to help resolve some of these research issues. In a service discovery environment, services advertise themselves, providing details about their characteristics and capabilities. Users can then find the information necessary to search and browse for services, choose the service with the desired characteristics, and use it. These current protocols have some common disadvantages. They do not access services spontaneously, they cannot provide initial configuration, they lack the ability


106

Mohamed Khedr et al.

to discover services semantically, they cannot rapidly adapt to service changes, and they cannot compose services. Our work considers these drawbacks and tries to overcome them by using agent technology and context information to build smart networks capable of spontaneous ad hoc applications. Agents have the advantage of being able to assist users, to represent services, and to manage sessions in complex environments, including service selection, QoS specifications, and negotiation. Agents are also mobile and are able to deploy functions on the fly. This helps with fast and autonomous adaptation to service changes. Context is raw information that, when correctly interpreted, can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application [7].Context awareness is the ability to use context information. A system is context-aware if it can extract, interpret and use context information and adapt its functionality to the context currently in use. Our system is context-aware and provides the capability required to make services detectable and accessible in an ad hoc environment. As part of our research, we needed to clarify the types of context required in spontaneous ad hoc communication. This led us to model the context information as shown below.

The model shows that context is a function of time, distance and the environment. The environment is in turn a function of the users, services, resources and the other entities residing in it during the system’s lifetime. This kind of context is acquired either through some kind of signaling technique, or through the use of special messaging between the agents in the system. This paper is organized as follows. A brief overview of related work is presented in section 2. In section 3, we describe the main components of the ACAN Architecture. In section 4, we highlight our agent-based design, and describe the role of each agent. Section 5 introduces the Ontology Aware Service System (OASS) used in the agent communication model and in the creation of the directory of discovered services. In section 6, we discuss our simulation model and our results. In section 7, we present some considerations arising from the implementation of our work. We draw our conclusions in section 8.

Agent-Based Context-Aware Ad Hoc Communication

2

107

Related Work

Service description protocols exist today either as standards or as research work. Several research projects in the area of location-based context awareness are also ongoing. This section reviews some of the related work in these two main areas. The Service Location Protocol (SLP) [2] is a service discovery protocol for IP networks providing predefined service attributes for software services and hardware devices. The architecture consists of three agents: the user agent representing the user who requests a service, the service agent representing the service, and a directory agent for maintaining the available services. SLP uses multicasting for announcement, registration and service requests. JINI [3] is a java-based service discovery where an object representing the requested service is downloaded from a lookup service to the user node. Salutation [4] is a platform-independent service discovery and session management protocol. Its main component is the salutation manager that acts as a service broker for the services in the network. Current commercial discovery protocols use a centralized information server that listens for broadcast or multicast packets on a well-known address. The server accepts registration requests for available services and answers queries about services. But an ad hoc group cannot use the centralized infrastructure to provide these functionalities. Nor are current protocols sufficient to enable network services in a spontaneous networking environment. Mechanisms are required to decide which nodes should host services, to determine the configuration of services and databases, and to ensure the availability of service and the consistency of databases in the event of partitions and failure. GIAOS infrastructure [5] is an operating system that manages the resources in an active space. But it does not deal with context as a parameter for managing resources, nor does it provide policies to monitor the behavior of the entities in the space. SCAP [6] is a project that proposes an approach to reveal the user’s context in a self-organized sensor network without a central point of control. It is based on passive packets, formatted as a document containing an execution plan that determines the type of sensor, a context hypothesis that accumulates the values retrieved from several sensors, and a packet trace. The packet trace uses two stacks. One stack contains the history of visited nodes and the other contains the route of the incoming nodes. SCAP is similar to OPENSIG architecture in that it deals with active networks within the network layer. Our work seeks to use agents to bring those functionalities to the application layer. It also seems that SCAP will face scalability issues in a highly dense sensor network [6]. Finally, the context toolkit [7] proposes architecture that hides the details of the context sensors, and adds context to applications without it. It has the advantage of reusability. But the context toolkit lacks the infrastructure that supports the transparent acquisition of context; it must already know the network configuration. It also lacks a method of dealing with component failure, a method which our architecture provides.

108

3


ACAN Architecture

The main characteristics of the ACAN architecture are flexibility, scalability and adaptability. Flexibility is provided by the layered architecture of the ACAN, allowing tasks and functionalities to be distributed on the different layers of the model. Each layer has certain functions to fulfill, and keeps the processing details in its own layer. Other layers receive only the results they need. Adaptability is achieved by the context awareness mechanism embedded in the system. The tasks performed by the ACAN are constant and specific. But the operations and functionalities that provide these tasks are dynamic and active, changing according to the context fed to the system by the sensors [1]. Protocols designed for the ACAN architecture are extensible, distributed and lightweight, the main requirements of scalability. ACAN can add or remove services dynamically. It can accepts new users, suspend or remove existing users, and provide network parameters in an efficient, dynamic way. The ACAN architecture consists of three layers: the mobility layer, the active ad hoc network layer and the ad hoc applications layer. The mobility layer is network independent. Physical sensors in this layer gather information about the current environment and users in the system. The active ad hoc network layer handles the connectivity and reachability of the nodes in the environment. According to the context provided from the sensors in the mobility layer, it is responsible for the autoconfiguration and management of the network, using tools such as an addressing scheme, a routing technique, QoS mechanisms, and mobility management. The ad hoc applications layer uses the context gathered from the mobility layer, and the connectivity established by the active ad hoc network layer, to deploy applications spontaneously [10], discover services and users in the environment, and adapt its requirements according to the current situation. See figure 1.

$GKRFDSSOLFDWLRQVOD\HU

Context interpreter

$FWLYH$G+RF1HWZRUNVOD\HU

0RELOLW\ /D\HU

Fig. 1. ACAN Layer Architecture

Context information as display, location, processing power, services preferences

Context interpreter

as Location, Mobility, network parameters.

Required Bw,delay jitter,etc

Context information

Resource reservation admission control prioritization routing scheduling, shaping

QoS manager


4

109

The Multi-agent System

The multi-agent system is composed of five main components: sensor agents, context agents, service agents, directory agents and user agents. The ACAN has sensors responsible for acquiring information about surrounding devices and services. This information is provided to a context agent that interprets it in order to extract specifications such as location, time, users, and values. Directory agents use the interpreted context to build a directory of available services and their attributes together with the service agent that represents each service. Service agents work as managers for the services they are in charge of: they communicate with the other entities to perform duties like monitoring the use and availability of service. 4.1

Sensor Agent (SA)

The environment where the spontaneous application occurs contains different forms of sensors (hardware and software). Each sensor delegates responsibilities to a sensor agent that performs the tasks of data checking, data aggregation, communication with other sensor agents, and communication with the associated context agent. The context agent interprets the raw sensor data into meaningful information. The directory agent builds the directories of available services using the interpreted information, allowing users to query, search and use these services. Each sensor has a unique identifier (SNSR-ID) that is used by the sensor agent and other agents to identify the sensor in the communication and data transportation protocol. Sensors are clustered into groups, each covering a certain area in the environment. Each group also has a unique identification (GSNSR-ID) used when addressing all sensors in the group. The sensors can be arranged in three communication modes: • Peer-Peer mode: where every sensor can communicate with any other sensor using the SNSR-ID. • Clustered mode: where groups communicate with each other using the GSNSRID. • Hybrid mode: a mix of the previous two modes. While the procedure is beyond the scope of this paper, the SNSR-ID and the GSNSRID are acquired during the network setup from the ACAN network layer so that unique value identifiers are guaranteed. Each cluster has a sensor representative agent (SRA) that communicates with the sensors in the cluster to ensure the correctness and consistency of the data acquired The sensor representative agent has the GSNSR-ID as its ID to ensure that it can be reached by every sensor agent. The sensor representative agent receives the acquired data from the cluster’s sensors, and processes it using the Ontology Aware Service System (OASS). The SRA ensures that the data received from different types of sensors are correctly interpreted, and reports any significant updates. Maintenance is resolved using a hybrid soft state. This means that the SRA uses the soft state for registering a sensor as long as the sensor sends information to it. Otherwise, it uses information from nearby sensors.

110


4.2

Context Agent (CA)

Each cluster is associated with a context agent. The CA is responsible for processing the contextual information of the cluster and for providing this information to the cluster’s directory agent. To do so, the context agent performs three functions. The first function is the gathering of the context provided by the SRAs. The context falls into two main categories: context related to the application, and context related to the network. Application context awareness has subcategories such as service awareness, which includes discovery of services, looking up and joining services, and maintaining services once they are discovered. There is also policy awareness, a protocol that uses context to become aware of the types of organizations, the life time of the sessions, and the duties distributed among the users. Network context awareness is the ability to use context to provide information like mobility, the capabilities of the different resources in the environment, the auto-configuration of the ad hoc network and the provision of QoS. See figure 2. Types of Awareness

Application Context Awareness

Network Context Awareness

M obility Aware

Network Aware

QoS Aware

Relative location Hand over, notification Addressing Configuration Topology Administration

Application Aware

Service Aware

Admission Control Prioritization Scheduling

Policy Aware

Typ eCoherency Resources

Discovery Joi nLook up maintenance Organization Duties Distribution Life time Qo S

Fig. 2. Types of Context

The second function of the context agent is the interpretation of the context using the OASS. The third function is the provision of accumulated information to the directory agent so that services and users may later be retrieved. SAs and SRAs find their associated context agent by using the GSNSR-ID if the CA resides in the same host as the sensor representative agent, or by using CA-ID address provided by the network aware protocol. 4.3

Directory Agent (DA)

In each cluster, the directory agent receives the contextual information from the cluster’s context agent and is responsible for:


1. 2. 3. 4. 5. 6.

111

Defining the services available. Defining the users in the system. Building the directory lookup table. Associating services to users. Maintaining the directory lookup table. Communicating with other DAs to exchange information and services.

The first two of these requirements are accomplished by using the information provided to the DA by the CA through the OASS. The DA therefore contains a lookup table that stores information about services and users. This table is updated from the information sent by the context agent. The default association to discovered services is based on the user profile sent to the directory agent by the user agent and the services discovered. SAs, CAs and SRAs can find their associated directory agent in three ways. The directory agent can reside in: 1- The same host as the SRA agent, thus having the same address the GSNSR-ID. 2- The same host as the CA, thus having the same address the CA-ID. 3- A different host that will obtain its address (DA-ID) from the ACAN system. 4.4

Service Agent

A service agent is associated to each service in the system that handles request messages from UAs or DAs. It also accesses the service for the requesting entity and monitors usage. In addition, the service agent acts as a mediator between the service and the users requesting it. The service agent becomes involved when the service is detected by the sensor agents in the environment. The SA is then registered with the directory agent enabling it to dynamically provide the directory agent with service updates. The complete model is illustrated in figure 3.

5

Ontology Aware Service

As described in [8], the service ontology was designed using Protégé [9], developed at Stanford University. It is a hierarchy of classes that represents general services to be found in the environment, and subclasses representing the services. Each class contains slots that represent the attributes of the services. The ontology is extensible, allowing services or attributes to be easily added, thereby increasing the knowledge of the agents in the system. The ontology consists of eight main classes representing services such as audio, video, context, printing, quality of service and networking. Each of these classes is further subdivided to specific services such as speakers, projectors, physical and software sensors. For each service, a list of most common attributes is defined in an attribute value tuple. These classes are transferred to an RDF file and are used by the directory agents to build a common lookup table. They are also used as the root ontology in the OASS. This form of ontology cannot support the exchange of semantically rich data between agents and services because it is built on

112


Fig. 3. Agent Model

abstraction and generalization. It also faces problems such as dynamic changes in the service ontology, while the root ontology remains the same. To tackle these problems we modified the system to the OASS. The OASS provides a semantic meaning to the classes represented in the ontology proposed. It fits the classes in the root ontology to currently available services and adapts the attributes locally without affecting the general ontology. The OASS consists of an abstract ontology system, a categorizer, a meter, an adapter and a policy and conditioner coordinator. 5.1

The Categorizer

The categorizer is responsible for producing a more specific ontology than the abstract root ontology. The specific ontology will be more related to the current situation and to the policies imposed by the different entities in the system. Policies are sets of rules reflecting the overall strategy or objective; they therefore affect the behavior of the system. A policy rule is a group of actions to be performed on the root ontology by the categorizer, meter or the adapter providing some conditions are defined. Detailed policy rules and actions are described in [11].


113

The categorizer selects the classes, subclasses and the associated attributes from the abstract root ontology to match specific rules from the policy-aware protocol [1], the environment, the types of service agents available, the number of sensor agents, and the availability of directory agents. 5.2

The Meter

The meter processes the available service profiles representing the classes selected by the categorizer. It applies some system conditions to produce a temporal, servicespecific ontology that can be accessed by the service, modified and used without modifying the root ontology. The root ontology, however, can be used as a default for services with no profile. The service profile file is a cc/pp file that holds the capabilities and preferences of the service when it is discovered and added to the system. The cc/pp file is integrated with the root ontology based on restrictions provided by the policies. This produces a specific service ontology that is richer in attributes and describes the service in more detail than the root ontology. The service ontology is dynamic, and describes the services currently available in the environment. Once the session is terminated, the service ontology is deleted and the root ontology once more becomes the default. 5.3

The Adapter

The adapter completes the process of providing a more semantically rich ontology by adding user profiles and producing the final modified ontology adapted to both user profiles, and to the services in the system. The user profile is also a cc/pp file that is under development by the W3. By describing the user, the profile makes the system more aware of the user’s behavior and needs [12]. Figure 4 shows the OASS to be system-dependant, supporting the representation of services, the interaction between the agents, and a common access to services that can adapt according to user profiles and service context. The OASS operation can be illustrated by the example of a conferencing room. The room’s normal use includes services like video, audio, printer and a power point. These options are provided in the categorizer block. In a given session, the policy states that only a laser printer may be used, video capabilities are only of MPEG1, and no cellular phones are allowed. Applying these rules, the categorizer presents a specific ontology that uses only parts of the root ontology as specified by the policy. The specific ontology contains classes allowing audio, video, printer and power point, but no cellular capabilities. During the meeting a user requires a printer. The system provides him with the laser printer. But the printer has extra attributes that are specific to its operation. At this point, the meter receives the service profile of the printer and also some conditions that the room imposes on printer use, such as printing priority and cost. The meter modifies the specific ontology accordingly. The user who requested the printer requires different printing quality for certain pages, and wants the printing job alerts to be send to his PDA. This information is

114


Fig. 4. The Ontology Aware Service System

kept in the user profile in the adapter along with any other conditions such as the failure of a job. The final modified ontology for use by these particular entities is then produced.

6

Simulation

Our simulated environment consists of three regions. Each region has one sensor agent, one context agent and several user and service agents. There are 5 types of services (printer, projector, email, phone and internet) distributed over the three regions with random arrival time. We conducted three types of simulation. The first type had a high rate of service requests with a request interval time close to the sensor acquisition time. We measured the average detection time and average waiting time. The second type had a medium rate of service requests with a request interval time above the sensor acquisition time. In the third type, we gradually increased the service use time. We then checked the performance of the system by recording the average utilization, average availability of the services and the percentage of successful service access. In the three types of simulation we used two scenarios: the first had location as the only context information and no region interaction; the second had region interaction and additional context information like the shortest busy service and the longest idle service.

Results and Analysis The results in figure 5 show the performance of the system with high and medium rates of service requests. The top graphs show the average detection time, and give an

Agent-Based Context-Aware Ad Hoc Communication high request rate ( Revenue(ak , hβk ), therefore changing ak ’s strategy to hk yields to a larger revenue than choosing hβk as in the alternative case3 .

4

Local Strategies

The theoretic results in Section 3 show the achievable optimum in global strategies, but the assumptions we made do not always hold in real-life situations. In fact information is neither perfect nor up-to-date, and more importantly it is not free. In this chapter we examine the game where the agents only have limited information, and gaining more knowledge is always associated with an additional cost in delays. In our second model every agent can have a search radius si . In every decision the agent is only aware of entities within that si distance4 . The agent can choose its search radius in every step but it will pay a price for that information proportional to that value. The current factor is two, which reflects that queries make a round-trip to that distance. The utility function in the modified game will look like: ϕij =

rj − (dij + 2si ) , dij < si where no agent is present on hj − (dij + 2si ) , dij < si otherwise

(3)

Since the agents’ vision is now limited the strategy set has two axes. One is selecting the search radius and one is selecting the next hop within that radius. Collisions become much harder to forecast since the possibly colliding agents may be out of each other’s sight. To analyze the effect of search radius let us define the strategy set as a continuous function of s, where every agent will select the host with the most possible revenue within that s radius. Thus the utility function for agent i is:

maxhj , dij LSY;ERK$XQYOEHI 2 Institute of Communications Technology and Measurement Ilmenau Technical University, D-98693 Ilmenau, Germany .SGLIR7IMX^$XYMPQIREYHI Abstract. Discovering and accessing distributed services in the Internet from portable devices in nomadic environments is of increasing interest for mobile users. But it is challenged by the deficiencies of wireless communication, heterogeneous environments, and user mobility. To surmount these obstacles, we propose a mobile agent based service architecture CHAPLET which provides an integrated, uniform, and general-purpose middleware platform to enable mobile users to discover and to utilize services efficiently and conveniently. The distinct features of CHAPLET include asynchronous service look-up, flexible service selection, dynamic configuration and adaptation, and interoperability with heterogeneous service environments. In this paper, the concept and architecture of the CHAPLET platform is presented, followed by the system design and implementation, as well as experimental results.

1

Introduction

The development of distributed information systems is pushed by the increasing number of mobile users who desire to discover and utilize information and services in the Internet at anytime from anywhere. The wide employment of wireless or mobile communication networks, such as WaveLAN, GSM, and UMTS in future, provides underlying infrastructures, which effectively relieves the connection into the Internet. However, only such “IP-tones” are not enough, some kind of middleware platform geared to mobile wireless environments has to be integrated in distributed systems. The constraints and characteristics in wireless and mobile environments complicate the design of distributed service platforms and require the revision of traditional client/server based approaches. From our point of view, the deficiencies of wireless communication, heterogeneous service environments and user mobility are the most critical factors affecting nomadic service discovery and utilization. Firstly, the portable devices used by mobile users are usually limited in computing power and resources, and connect with wired networks mostly through wireless links which are characterized by low but variable bandwidth, high latency time, and unpredictable intermittent disconnections. Therefore, the activities which involve large resource usage, long time connection, or intensive data transfer, should be avoided if possible, shifted to the service side, or delegated to a third entity in the infrastructure. Secondly, the heterogeneity of services environments is another problem the mobile users have A. Karmouch et al. (Eds.): MATA 2002, LNCS 2521, pp. 269–279, 2002. © Springer-Verlag Berlin Heidelberg 2002

270

Zhou Wang and Jochen Seitz

to be confronted with. Currently, services available in the network may be configured and managed using different service networking technologies, such as UPnP[10], Jini[15], Bluetooth [1], SLP[6], Salutation [14], etc. Despite that most of them have similar functionality, each of them is suitable for different application environments. However, these service frameworks are incompatible with each other both in service description and in interaction model. Mobile users have to know how to configure multiple “standard” protocols, and how to formulate service queries using specialized description methods, since they might connect to different networks over time, and thus face different service networking approaches. Obviously, this is ineffective and uncomfortable for end users. A general service middleware platform gracefully dealing with heterogonous service networking approaches is therefore strongly desired. Last but not least, user mobility requires additional management policies. Mobile users may change their geographic locations with time. Consequently, the set of services available in the network will change drastically. Mobile users wish to locate and use desired services with no or only limited manual configuration, especially if they come into an unknown environment. In order to fulfill these technical requirements, we developed an agent-based service platform called CHAPLET that focuses on providing an integrated, uniform, and generalized approach, with which mobile users are able to locate distributed services in the Internet in a unified, simple and efficient manner, utilize services without complex configuration and pre-knowledge of service interfaces, and make services dynamically adapt to the communication quality and device characteristics. Moreover, by tracing the movement of mobile users, CHAPLET will support mobility related services, such as personalized services or context-dependent services. This paper is organized as follows. In section 2 the design principles and the concept of CHAPLET are described. Section 3 presents system architecture and main components in detail, followed by experimental results we have obtained. After a comparison to related work, we summarize the paper.

2

System Concept

In last years the mobile agent technology has gained a lot of research interest. Mobile computing is one of the promising areas of applying mobile agents. From our point of view, the mobile agent paradigm has several useful but essential features for mobile computing, including reducing the vulnerability to disconnection and increased flexibility for adaptation, which are demonstrated through the development of the CHAPLET platform. 2.1

Design Principles

Considering the characteristics in wireless and mobile environments, we are aiming to achieve following goals with CHAPLET: Efficiency. Most existing distributed service platforms were conceived for stationary environment, using a synchronous client/server model. However, the unexpected but frequent disconnections and possible long delay of wireless links greatly influence the

Mobile Agents for Discovering and Accessing Services in Nomadic Environments

271

usefulness and efficiency of synchronous calls. We believe that such tight coupling patterns should be used in mobile environments only when users are effectively interacting with a server, e.g. during receiving service data. In other cases, such as service discovery, asynchronous operation seems more attractive. In CHAPLET, we explored the potential of mobile agents to realize an asynchronous service discovery mechanism to improve efficiency and reduce the dependence on the wireless link. Effectiveness. When users want to find some kind of services, what they are concerned about is service functionality and service characteristics. But today’s mobile users have to be involved in technical details posed by different service networking approaches. As pointed out before, this heterogeneity critically influences the effectiveness of service location and utilization. Therefore, CHAPLET aims at providing a general integrated platform to enable interoperability in heterogeneous service environments. Mobile users just need to interact with CHAPLET to initiate the service lookup procedure, without worrying about underlying infrastructure and technology. Simplicity. The CHAPLET platform provides a uniformed and simple means to describe search queries, so that the users are not confused by different description methods supplied by underlying service discovery protocols. Moreover, instead of the rigid search form used in most protocols, the queries in CHAPLET are represented in a more expressive and flexible manner which supports inexact and dynamic search. Flexibility. Apart from flexible service selection, the CHAPLET platform should support dynamic installation of service interfaces and adaptation to environmental conditions including communication and device characteristics, to ensure service usefulness and quality. Furthermore, we try to integrate mechanisms to enable mobilityspecific services such as personalized push services or context-aware services. Generality. In order to achieve wide acceptability, the CHAPLET system should be general enough to not impose any assumptions on services types and applying environments. That is to say, mobile users can discover and invoke any kinds of services, in wireless environments as well as in wired networks. 2.2

System Overview

The conceptual scheme of the CHAPLET system is presented in fig. 1. In CHAPLET, both mobile clients and service providers are built on mobile agent technology. The main components are two types of mobile agents that we called chaperon and valet, which act as active and moveable proxies to support service discovery and access in nomadic environments. Besides them, there are several other stationary agents resident in the infrastructure to provide essential basic support functions. In CHAPLET, we referred to autonomous domain as the collection of services that under the authority of a particular administration. Within an autonomous domain, more than one service networking approaches can exist simultaneously. Each of them has its own control scope. The set of services that is governed by a particular service networking protocol is known as a service domain. For example, in Fig. 1, two different service networking protocols are available in an autonomous domain. The Service Domain A uses UPnP, while the Service Domain B supports SLP.

272


2.3

Service Discovery and Selection

Once a mobile user requests services in wired networks, he presents query requirements with the help of XML-based service query schemes. After connecting into the network via a particular access point, he firstly locates the node where the agent Domain Access Entry (DAE) is running, then sends the agent chaperon together with the search queries into the wired network ( in fig. 1). The agent DAE, similar to an access point in the data link layer, is the entry to the autonomous domain to which the client is connecting. If the user is successfully authenticated by the DAE, an access ticket including the list of searchable service domains is sent to the chaperon. Having the configuration information of the current autonomous domain in mind, the chaperon conceives an itinerary to travel through available service domains, and then starts the search procedure.

Fig. 1. The Conceptual Architecture of CHAPLET

The chaperon begins with the first service domain listed in its itinerary. There is at least one Service Discovery Adapter (SDA) in each service domain, which bridges the chaperon and the service domain it is visiting. The chaperon migrates to one of the nodes equipped with an SDA in that service domain ( in fig. 1), and passes the search predicates to the SDA through predefined APIs. After getting search results from the SDA, the chaperon might migrate to the service node that is of interest, if the chaperon thinks that the service description returned by SDA is inadequate to make a decision ( in fig. 1), and negotiates there with the server about further service details. In this way, the chaperon is able to get to know more about services, especially some performance parameters or attributes that are changed rapidly. After the chaperon completes the search process in a service domain, it migrates into the next one specified in the itinerary if it wants to continue ( in fig. 1). When the chaperon has visited all service domains, it collates the retrieved services and sends the most appropriate services to the client on the mobile node.


273

Compared to those service discovery approaches currently in use, the CHAPLET provides more flexibility. In addition to specify service type and service attributes that must be satisfied (search constraints), the clients can describe their own preferences for service selection (search preferences). The search preferences can be given by clients explicitly, or be derived from the services the user utilized before. The search constraints state the essential requirements that the services must satisfy, while the search preferences give the chaperon the hints to select the most suitable services among qualified candidates. By this means, a user can submit such a query as “searching for a color printer if available, otherwise a black-and-white printer”. 2.4

Service Invocation and Adaptation

As the desirable services are found by the chaperon, it notifies the service manager on the mobile host, which then sets up a connection with the service provider. At this time, another agent called valet is being prepared by the service provider according to the user’s needs, and is then sent back to the mobile client ( in fig. 1). Running on the mobile node, a valet can be regarded as the proxy for accessing the remote service. The valet either implements the whole functionality of the requested service, which again supports disconnected users. Or – similar to the Jini architecture [15] - the valet only contains service interfaces which the client can invoke. Therefore, mobile users avoid to install or configure any service-specific software in advance. Not only the technical details of invoked services are kept transparent to users, but also the usage of the scarce resources on the mobile node is improved. Meanwhile, the valet plays a key role in providing proactive and reactive service adaptation. On the one hand, the valet can select the best format and form of services based on device properties and available resource on the mobile host. On the other hand, the valet will react to changed environments, after it receives notification from the resource monitor in CHAPLET. In some cases, the valet creates other agents which migrate to other appropriate places in the network to transform service data dynamically, e.g. at the end point of wired link, on the client or both on client and server [17]. Since the valet comes directly from service providers, services can be optimized by utilizing a service specific protocol or other implementation details. Thus valets are more advantageous than general filters. 2.5

Accompanying User Migration

From the perspective of mobile users, it is preferable that they can be automatically notified by the appearance of desirable services as they enter a new environment or the services newly become available, instead of searching for services manually. Hence, mechanisms for supporting push-based personalized services are integrated in the CHAPLET system, too. As mobile clients roam within a mobile network or between different networks, horizontal or vertical network hand-offs arise in the data link or network layer. Through the network monitor in the CHAPLET system, the chaperon can be notified about the change of access points. Then, the chaperon tries to locate the DAE in the new area, and migrates there to search for services continually. The same procedure happens too, when the user establishes a new wireless link after disconnection.

274


By keeping track of the movement of the user, the chaperon can discover services which are in the proximity of the mobile user. Moreover, the search procedure can be initiated by the chaperon based on user’s preferences, predefined search requests, or time/location relevant trigger conditions. If the chaperon finds appropriate services, it will push related information to the mobile user actively. The chaperon can be treated as an intelligent accompanying assistant, which helps mobile users to discover and utilize services in a more comfortable and efficient way. We believe such personalized context-aware push services have fundamental effects on convenient operation and usefulness of mobile devices.

3

System Architecture

In this section we describe main components in CHAPLET. As depicted in Fig.2, the CHAPLET platform is built on an existing agent runtime system, presently on IBM Aglet system [18]. The CHAPLET runtime system provides fundamental support functions, such as events subscribe/dispatch, security control, and monitoring network status and resource usage. Upon the CHAPLET runtime system, system agents, e.g. DAE, and user agents such as chaperon and valet, are running. Although in the Fig.2. nodes running DAE and running SDAs are separated, they can be the same node, too.

UIA

Chaperon

Valet

Chaperon DAE Executor

Event Manager

Query Security Manager Manager

Event Manager

Security Manager

Resource Monitor

Comm. Manager

Comm. Manager

Config Manager

Config Manager

Chaplet Runtime System

Agent Runtime System Mobile IP/IPv6

Wireless Acess Point

Host System

Mobile Host

The Wireless Link

≥ SDA

Valet Executor

Query Transformers

Chaplet Runtime System

API for UPnP API for SLP API for Jini Chaplet Runtime System

Agent Runtime system

Agent Runtime System

Host System

The Wired Link

DAE

Host System

SDAs/Servers

Fig. 2. The System Architecture of CHAPLET

3.1

Query Representation

In CHAPLET, we use XML to describe client queries. The flexible hierarchical structures and semantic-rich content of its self-describing syntax makes XML a good choice for describing and disseminating queries. For each service type there is a predefined query schema based on W3C’s XML Schema Definition [16]. The query schema defines a set of rules to dictate which service attributes and values can be applied in the query. With the guide of predefined


275

schemes, clients can easily input their service queries. In Fig. 3, a simple example is shown. This example indicates such a query that the user wants to search for a printing service that accepts PS- or PDF-format document, and uses laser printer as output device. These two conditions are regarded as mandatory by setting the tag attribute “Priority” to “0”. In contrast, other service attributes such as “Color”, “Location” and “Price” are specified as preferred. The given priorities are used to select the most appropriate service. #\QPZIVWMSR!IRGSHMRK!98*#" 5YIV]\QPRW!LXXTXQYOEHIGLETPIX\QP4VMRXIV \WMWGLIQE0SGEXMSR!LXXTXQYOEHIGLETPIX\QP4VMRXIVTVR\WH" 7IVZMGI8]TI"4VMRXIV 7IVZMGI8]TI" 4VMRXIV8]TI4VMSVMX]!"0EWIV 4VMRXIV8]TI" (SGYQIRX8]TI4VMSVMX]!"4(*47 (SGYQIRX8]TI" 'SPSV4VMSVMX]!"XVYI 'SPSV" 0SGEXMSR4VMSVMX]!") 0SGEXMSR" 4VMGI4VMSVMX]!" PMF1MRMQYQ" PMF1MRMQYQ" PMF1E\MQYQ" PMF1E\MQYQ" 4VMGI" 5YIV]"

Fig. 3. A Query Example in CHAPLET

3.2

The Agent Chaperon, Executor and UIA

The agent chaperon is critical for asynchronous service discovery. It is usually prepared by the client on portable devices, and sent into the wired network. After receiving a query request from user, the chaperon learns current domain configurations from the DAE, and then creates its search itinerary independently. Then, it creates a child agent called Executor which is responsible for resolving this request using the current itinerary, so that the chaperon can work on multiple requests concurrently. The inherent mobility of agents enhances the service search functionality, since it can travel different service domains. Instead of sending his own chaperon to the wired network, the mobile user can sometimes directly utilize shareable chaperons installed in the autonomous domain. The advantage of using these public chaperons is bypassing the transfer of the chaperon from the mobile node to the network if the user only occasionally retrieves services. Of course, by this he loses the flexibility to customize the search procedure using his own chaperons. The agent User Interaction Agent (UIA) provides the user interface to accept search queries. It runs on the mobile host, and implements the basic interaction protocol between mobile node and the agent chaperon. Users can also integrate the UIA into existing software to take advantage of CHAPLET. 3.3

The Agent DAE

The agent Domain Access Entry (DAE) is the rendezvous point for mobile clients to interact with the autonomous domain. The DAE is adopted for two purposes: admis-

276


sion control and configuration management. As the chaperon enters the autonomous domain, the DAE firstly authenticates the chaperon by digital certificates. After successful authentication, an access ticket with configuration information is returned to the chaperon. Before the ticket expires, the chaperon should ask the DAE to renew it. Such an admission control is useful to prevent the autonomous domain from being flooded of query messages from malicious clients. The DAE in an autonomous domain is managed by the domain administrator. When the mobile node connects to a network, it can discover the address of the DAE through cell broadcast channels, using DNS lookup, or using multicast query. 3.4

The Agent SDA

The agent Service Discovery Adapter (SDA) is the bridge between the agent chaperon and the specialized service domain. In order to speak with different protocols, the chaperon might have to take with itself various modules for possibly encountered protocols. However, such a heavyweight agent is not suited for migration due to vast network bandwidth usage. Therefore, we introduced the Service Discovery Adapter (SDA) in the infrastructure to relief the overload of the chaperon. The role of the SDA is twofold. On the one side, the SDA maps the general query representation into the form that is dedicated for local service discovery protocol. On the other side, the SDA contains specialized codes for interacting with the local discovery protocol, and is thus able to participate in the service discovery process in the local service domain.

4

Experimental Results

In this section we present the experiments conducted to verify the correctness of the CHAPLET system and also to quantify the performance under different access networks. In experiments, we configured the autonomous domain with two service domains in two different subnets. In each service domain, there is an SDA supporting the SLP protocol and 10-15 services running on two or three nodes. Firstly, we measured the response time of six typical queries under different network situations. For comparison, we made the same tests using the traditional synchronous message model. The results are shown in fig. 4. We found that in the cases that users connect into the network with enough bandwidth, such as through Ethernet or 11MB WaveLAN, there is no great difference in response time between CHAPLET-based approach and synchronous model. But in the cases that the access network has only limited bandwidth, such as 2MB WaveLAN, 56K Modem, or 14.4K Modem, the CHAPLET-based approach resolved the queries much faster than the synchronous model. In other words, the mobile agents based approach is much less sensitive to the bandwidth of the access link. The reason is that the asynchronous search needs fewer message exchanges between client and servers than in synchronous model.


277

Fig. 4. Response Time of Queries Using Different Access Links Table 1. Average Time in Setup Phase and Query Phase

Agent Mode

Setup Phase(s) Avg. Response Time(s)

0.744 3.702

11MB WaveLAN 0.815 3.761

Sync. Mode

Avg. Response Time (s)

2.504

2.587

Ethernet

2MB WaveLAN 1.246 7.671

56K Modem 2.817 6.169

14.4K Modem 3.612 10.916

32.889

34.552

97.146

Table 2. Average Communication Volume over the Access Link

Agent Mode

Setup Phase (KB) Avg. Query Data (KB)

57.814 9.941

11MB WaveLAN 56.539 9.580

Sync. Mode

Avg. Query Data (KB)

130.839

125.952

Ethernet

2MB WaveLAN 65.391 12.161

56K Modem 66.680 9.603

14.4K Modem 56.387 9.603

144.555

125.856

128.070

In terms of overhead of transferring the chaperon into the network, we measured the dispatch time and communication volume under different conditions, which is shown in the “setup phase” in table 1 and 2. We measured data volume over the access link by capturing all packets in the LLC-layer, i.e. though eth or ppp interfaces, using the ethereal [4] as traffic monitor. Since the testbed is built on shareable networks, the communication volume may be affected by current network load, and waved as we tested the same mode under different access links. From our point of view, both the dispatch time and the communication volume caused by sending the chaperon is acceptable, especially considering narrowband access links. Table 2 also shows that the mobile agent based approach greatly reduces the data volume transferred over the access link, because only the final results, neither intermediate nor irrelevant results, are transmitted. Besides, it clarifies that if the user only wants to

278


search for a few number of services, it is more economical to use a public chaperon, since the migration of a chaperon causes ca. 60KB additional network traffic.

5

Related Work

Mobile service access is a hot research area in recent years. Several service networking frameworks are proposed either in academic research projects or by industry consortiums. Examples are UPnP[10], Jini[15], Bluetooth[1], SLP[6], Salutation[14], Havi[8], SDS[3] etc. They approach the problem from different philosophical and technical viewpoints, each of them has both strength and weakness. However, the undesirable diversity prevents mobile users from discovering and accessing services freely. Although some approaches have been proposed to bridge different technologies [7, 11], they are limited to pair-wise bridges. To the best of our knowledge, integrated multi-way interoperability solutions are not available yet. With CHAPLET, we provide a uniform and extensible middleware platform to accommodate the heterogeneity in service environments. Moreover, distinct from these existing approaches, we introduced asynchronous service discovery mechanisms to compensate the deficiencies of wireless link. On the other side, a number of research projects explored mobile agents or mobile code to resolve problems of mobile computing in different aspects, such as [3,5,9,12,13]. All of them have special features in supporting nomadic use of distributed systems. However, none of them fulfilled the requirements of discovering and utilizing networked services in nomadic environments. Therefore, we borrowed experiences from these projects, and developed the CHAPLET platform.

6


In this paper, we presented a mobile agent based middleware platform for discovering and accessing distributed services in nomadic environments. We showed that the mobile agent technology is a feasible approach for nomadic service access. The proposed CHAPLET platform contains a number of features, such as asynchronous service lookup and selection, interoperability with different service networking technologies, dynamic configuration and adaptation, and personalized push services, so that it not only overcomes the constraints in wireless and mobile environments, but also enables mobile users to discover and to access networked services efficiently and conveniently. In future, we will develop further SDAs for other popular service networking technologies and integrate support for locating services across autonomous domains. Besides, we will extend CHAPLET to support service access in ad-hoc environments.

References 1. Bluetooth SIG, Specification of the Bluetooth System – Core, Version 1.1, February 2001 2. S. Czerwinski, B. Zhao, T. Hodes, A. Joseph, R. H. Katz, An Architecture for a Secure Service Discovery Service, Proceedings of The Fifth ACM/IEEE International Conference on Mobile Computing, Seattle, WA, August 1999, pp. 24-35


279

3. Duda and S. Perret: Mobile Agent Architecture for Nomadic Computing, Proceedings of International Conference on Computer Communications, Cannes, October 1997. 4. ethereal: www.ethereal.com 5. R. Gray, D. Kotz, S. Nog, D. Rus and G. Cybenko, Mobile Agents for Mobile Computing, Technical Report TR96-285, Dept. of Computer Science, Dartmouth College, May 1996. 6. E. Guttman, C. Perkins, J. Veizades, and M. Day. Service Location Protocol, Version 2, IETF, RFC 2608, http://www.ietf.org/rfc/rfc2608.txt, June 1999. 7. E. Guttman and J. Kempf, Automatic Discovery of Thin Servers: SLP, Jini and the SLPJini Bridge, Proceedings of 25th Annual Conference of IEEE Industrial Electronics Society (IECON’99), Piscataway, USA, 1999. 8. HAVi Consortium, HAVi Specification V1.0, www.havi.org, 2000. 9. A.D. Joseph, M. F. Kaashoek, Building Reliable Mobile-Aware Applications using the Rover Toolkit, 2nd ACM International Conference on Mobile Computing and Networking, New York, November 1996, pp 117-129 10. Microsoft. Universal Plug and Play Device Architecture, version 1.0, June 2000. 11. Miller and R. Pascoe, Mapping Salutation Architecture APIs to Bluetooth Service Discovery Layer, http://www.bluetooth.com, July 1999. 12. S. Omar, X. Zhou, and T. Kunz, Mobile Code, Adaptive Mobile Applications, and Network Architectures, Second International Workshop, MATA 2000, Sep. 2000. 13. Sahai and C. Morin, Mobile Agents for Enabling Mobile User Aware Applications, The 2nd International Conference on Autonomous Agents, USA, May 1998. 14. The Salutation Consortium. Salutation Architecture Specification, Version 2.1, 1999. 15. Sun. Jini Technology Core Platform Specification. Sun Microsystems, Inc, October 2000. 16. W3C, XML Schema Specification 1.1, W3C Recommendation, May 2001. 17. Z. Wang and J. Seitz, An Agent-based Distributed Service Model for Nomadic Users, The Eighth International Conference on Parallel and Distributed Systems, June 2001, Korea. 18. www.aglets.org , The Aglets Open Source Project

An Extensible Mobile-Agent-Based Framework for Coordinating Distributed Information Retrieval Applications Edgar A. Olougouna1, Samuel Pierre1, and Roch H. Glitho2 1 Mobile Computing and Networking Research Laboratory (LARIM) Department of Computer Engineering, École Polytechnique de Montreal P.O. Box 6079, Station Centre-Ville, Montreal (Quebec), Canada, H3C 3A7 _IHKEVSPSYKSYREWEQYIPTMIVVIa$TSP]QXPGE 2 Ericsson Research Canada 8400 Decarie Blvd., Town of Mount Royal (Quebec), Canada, H4P 2N2 VSGLKPMXLS$IVMGWWSRGE

Abstract. The mobile agent technology is likely to epitomize an enabler for sustaining handy information retrieval services. This will be the case in the future when wireless and small footprint devices become ubiquitous, requiring performance, customization and device independence. Mobile agents are a worth candidate to overcome the limitations of such environments. This paper proposes an extensible mobile-agent-based framework for coordinating distributed information retrieval applications. It leverages the emerging XML and agent-technology standards to encode content exchanges. We motivate the use of multiple cooperating agents to engineer handy information retrieval applications (e.g., mobile web crawler, mobile bargain hunter, mobile event scheduler) in order to improve performance. The required coordination scheme may be centralized, hierarchical peer-to-peer, or hybrid. The measurements made on the single-mobile scheduler prototype indicate that the mobile-agent approach can outperform an even optimally designed client-server counterpart.

1

Introduction

Ubiquitous computing calls for new models for sustaining handy information retrieval applications. Online information has become pervasive due to the widespread deployment of the client-server paradigm and the rapid development of the Web. But the vertiginous growth of information sources over the Internet has raised new engineering challenges to integrate mobile environments. Wireless mobile environments are typically geared with limited resources such as processing power, storage capacity, and available bandwidth. It is intolerable that information retrieval over wireless links involves a prohibitive cost. The extended client-server model has been one the most commonly resorted solutions to engineer information retrieval applications for mobile environments [1]. A component is installed on each server/proxy-server and the processing is performed at A. Karmouch et al. (Eds.): MATA 2002, LNCS 2521, pp. 281–291, 2002. © Springer-Verlag Berlin Heidelberg 2002

282

Edgar A. Olougouna, Samuel Pierre, and Roch H. Glitho

the server. Extended client-server coordination is used to support multi-server interactions. An interesting work is presented in [2], where service requests from multiple servers are managed directly, or indirectly through a mediating system-level server. However, each specific extended client-server coordination model relies on a dedicated API, which constitutes the client access API. Such extended client-server architectures are bloated in complexity, and provide stiff customization. Mobile agents are a promising avenue to enable easy customization and performance as well as to support user mobility. The mobile agent technology emerged in the mid-1990s and is rooted in process migration [3]. Mobile agents are programs that can start execution in a node, suspend execution, and then move to another node to resume execution. They have been experimented in applications ranging from electronic commerce to information retrieval. The critical design issues for distributed mobile-agent-based information retrieval applications include: • • •

accessing the information distributed on servers; optimizing the number of agents and their dissemination; coordinating the execution of distributed entities (e.g., agents, cooperators).

This paper proposes extensible mobile-agent-based coordination schemes for distributed information retrieval applications. The schemes leverage the emerging XML standard [W3C] for information representation in a device-neutral format, and agenttechnology de facto standards to encode content exchanges. We motivate the use of multiple cooperating agents to engineer handy information retrieval applications. These applications range from web mining to electronic shopping and office task automation. In all cases, the agents and their cooperators need to be disseminated and coordinated in order to achieve their joint goal. The next section gives a brief overview on mobile agents and their coordination models for information retrieval. After that, we motivate the use of mobile agents for sustaining handy information retrieval services and derive requirements. We then introduce our coordination schemes, and a layered architecture for realization. The section after describes a single-mobile-scheduler prototype and presents some measurements. We conclude with a summary, lessons learned and items for future work.

2 2.1

Mobile Agents and Their Coordination Models for Information Retrieval Mobile Agents

A mobile agent is an autonomous and goal-oriented software entity that has the ability to self-transport across physical network nodes [3]. It transfers its computational logic, i.e., code, data and running state, to remote hosts, taking advantage of local resources/services along with its proactive-ness and reactive-ness. This mobility borrows a lot from mobile abstractions related to code, objects and process migration. The mobile agent execution requires a specific environment commonly called platform.

An Extensible Mobile-Agent-Based Framework

283

Mobile agent platforms offer basic facilities including services for mobility, communication, naming and location, and security. They are implemented nowadays as Java applications running on top of operating systems [4]. Mobile agents are claimed to bring a host of benefits to distributed computing. For instance, they can allow: • • • •

asynchrony and autonomy, by roaming and supporting disconnected operations on behalf of users; heterogeneous networking, by enabling communication layer independence and adapting to various types of devices; performance improvement, by moving the computation co-located with the data source, reducing the length and the number of messages exchanged in a traditional approach; flexibility and extensibility, by facilitating smooth integration of changing needs both from user perspective and engineering perspective.

Mobile agents have been experimented in applications ranging from telecommunications to electronic commerce and information retrieval. 2.2

Mobile Agent-Based Coordination Models for Information Retrieval

Coordination models generally provide an elegant solution for distributed cooperating applications (e.g., information retrieval). They realize logical roles between the communicating entities, and define the way to handle distributed interactions. Mobileagent-based coordination models for information retrieval have been surveyed recently [5]. The taxonomy can be categorized in two chief models. Direct coordination: This model often relies either on the client-server style or on the rendezvous style. In the first case, inter-agent communication uses remote procedure calls (RPC). In the latter case, the coordination is centralized at a meeting node. In both cases, resources and services are accessed using RPC. Indirect coordination: This model uses a dataspace (e.g., blackboard) residing on each site as coordination means. Agents are independent to post, broadcast, and retrieve messages using the content-addressable space. A variant is the mobile agent reactive tuple space (MARS) co-ordination model [6], which further allows issuing programmable reactions for policing the interactions between agents and their hosting execution environment. Conversely to direct models, indirect models cater for a transparent network-aware communication. However, a coordination language is generally required. Linda is one the most elaborated work. It defines a set of coordination primitives to handle indirect interactions through tuple spaces. Derived implementations are Laura (service-typed) and Jada (object-oriented) proposed in the PageSpace architecture [7] for coordinating distributed interactive applications. Shared data/object spaces are limited in deploying many distributed applications (information retrieval, e-commerce). Let illustrate this fact by a simple bargain hunter application. Cooperating mobile agents could not expect that competitive service

284


providers implement shared spaces. Instead, they will provide service access and business rules interfaces. Furthermore, extensible coordination models may be the most appropriate models for several information retrieval applications, as showed in a latter stage in this paper. They can leverage emerging standards for data description as well as inter-agent communication (ACL and rule-based XML messages) [8]. Cooperation facilitators can even be realized as customizable / mobile agents, allowing flexible coordination operations.

3

Mobile Agents for Sustaining Handy Information Retrieval Services

We successively elaborate examples of information retrieval applications suitable for mobile wireless environments and derive a set of comprehensive requirements. 3.1

Dynamic Search Engines – A Mobile Web Crawler

Most web search engines suffer from performance. Key weaknesses are communications delays, and poor quality of retrieved results. These engines are overwhelmed by the lack of structure of an exponential growth of information on the web [9]. Duplicated, outdated and hidden links are among the key issues. Mobile agents can be used to improve performance of web searching. Especially in small-footprint-devices environments, shifting the retrieval in the network might reduce communication costs. The agents move to proxy servers, process and filter results locally. Intelligence and cooperation will help to improve the quality of results. When children agents are dispatched to proxy servers, they could identify scores of hidden pages, then refine the results according to the user profile/interests. 3.2

Electronic Shopping – A Mobile Bargain Hunter

Finding a bargain price on the web often requires extensive searches on appropriate electronic stores. Search engines are provided on each store to let the user identifying products of interest. They typically lie on scripting services, applets/servlets, active server pages, and web-oriented databases technologies. These solutions are less tailored for mobile wireless environments, where deal negotiations entail disconnected operations. Intuitively, it seems natural to automate online shopping with agents. Stationary shopping robots (i.e. shopbots) have already been proposed for modeling online shopping services [9]. Mobile agents are a worth alternative or complement to deal with information overload and user mobility willing. Customized shopping agents can roam the network (e.g., closely to provider servers) and perform retrieval and identification operations locally on behalf of their us-


285

ers. They will clone themselves as appropriate to cooperatively hunt/negotiate the best bargains using service access interfaces (e.g., XML-like standards). Mobile bargain-hunter applications scenarios range from products purchasing to business travel reservations. A complex scenario is one in which mobile agents arrange a business meeting if they find a bargain ticket price and a travel reservation that satisfy the user previous arrangements. 3.3

Office Task Automation – A Mobile Event Scheduler

Scheduling a suitable date/time for a multiparty videoconference or a business workshop can easily become time-consuming and tedious. The scheduling process remains manual in most cases, although electronic agendas are commonly used. In intranet environments, multiparty events are mostly scheduled with client-server tools (e.g., MS Outlook, Lotus Notes). These solutions rely on the retrieval of electronic agendas shared on servers. They entail limited automation and stiff customization, and raise an issue of performance. Mobile agents can be used to address the issues mentioned above [11]. They can serve to realize customizable schedulers. The scheduler agents can roam the agenda servers, retrieve the information on availability, and identify the dates. They can intermediate with personal agents that act on behalf of the participants to handle the negotiations inherent in rescheduling previous arrangements. 3.4

Requirements

The main requirements we have identified for handy information retrieval services are: 1. Minimal delay: The service response time should be minimal. 2. Customization: Profile, preferences and negotiating rules (if any) should be customizable by end users. 3. Accessibility: Service accessibility should be easy and independent of end-user devices. 4. Automation: The service process should be fully automated. 5. Cost: The communication cost should be as low as possible.

4 4.1

Extensible Mobile-Agent-Based Coordination Schemes and Architecture Driving Forces and Prospects

XML as an Enabling Technology. The Extensible Markup Language (XML) is an emerging standard for deploying structured documents on the web [10]. It is a univer-

286


sal format for describing data. It enables an application-independent encoding of a document, regardless of the running platform. XML targets a device-neutral format. For instance, directing data to different devices can be achieved with the eXtensible Style Language (XSL) and XSL Transformations (XSLT). Another interesting strength of XML is its meta-language function. Any specific language vocabulary is constructed by defining a Document Type Definition (DTD). It suffices an XML parser to interpret a document content using the DTD. Prospects with the Use of Mobile Agents. The integration of XML technology with the mobile agent technology features numerous benefits for sustaining handy information retrieval services. As an illustrative scenario, let us assume that the information sources that may contain the information of direct interest to the user are scattered over the network. Let assume that the data size to be processed is large as it is usually the case on the web. Let us further assume that each source provides XML documents that describe the way to access and retrieve information. The engineering benefits are numerous. The first is to launch a mobile agent that is clone-capable from almost any type of device. The second is that the agents can leverage XML technology to retrieve information from the sources using the provided service interfaces. The third is that multiple agents can cooperate by exchanging XML messages in order to improve performance, thus encoding content exchanges in XML-based ACL messages. Another benefit relates to flexible cooperation operations that may be easily realized by generating extensible rules manageable by cooperation facilitators. 4.2

Coordination Schemes

We propose below a centralized scheme, and two decentralized schemes for coordinating distributed information retrieval. The schemes are illustrated in Fig. 1. 4.2.1 The Centralized Scheme In the centralized scheme (Fig. 1.a), a dedicated entity/coordinator monitors and synchronizes the whole retrieval and identification phases. It is the coordinator that gathers the relevant information from individual agent results. It performs the function of filtering with respect to the involved constraints (e.g. user preferences) and the function of ending the cooperation between agents. 4.2.2 The Decentralized Schemes In the decentralized schemes, the coordination and the synchronization of both retrieval and identification phases are carried out in parallel. Groups of peers are formed with a delegated agent per group that acts as representative. The two schemes we propose are based on this basic peer model. The first variant of decentralized scheme is a hierarchical peer-to-peer coordination (Fig. 1.b). Peers identify intermediate results at their level. These results are then


287

evaluated between delegated peers agents of the second level, and so forth. It is the outer level of peers that produces the final results. The second variant of decentralized scheme combines the hierarchical peer-to-peer scheme and the centralized scheme (Fig. 1.c). In this case, the peer-to-peer exchange occurs at the inner level for identifying intermediate results. The centralized coordination scheme serves among delegated agents at the outer level to derive final results.

A13 A1

A12

D41

C31 D31

D21

D21

a) centralized

A23

A23

C

A22

A22

c) hybrid

b) hierarchical peer-to-peer Mobile Agent

A12

D11

outer level

Ak

A

Peers of inner level

D11

A2

C

A13

Peers of inner level

Coordinator

D

Delegate

Fig. 1. Centralized and decentralized coordination schemes

In the decentralized schemes, the complexity of the number of messages is less than square of the number of agents, compared to a pure peer-to-peer model. Although the centralized schemes present a single point of failure, the hierarchical peerto-peer model will be more robust to find sequences of information. In fact, instead of being from down to top, information flow is from the uniform outer level (peer-topeer) to the inner level. This also applies to the hybrid coordination scheme. 4.3

Distributed Architecture

Our architectural framework design relies on a set of assumptions: • Each server is equipped with a mobile agent platform. • Each server provides an API for retrieving information. • Each server provides XML interfaces that describe the way to access and retrieve information. • Java is used as programming language, the most widely used language for programming mobile agents. A layered view of the architecture is depicted in Fig. 2. The main components are the interaction layer, the cooperation layer and the service layer.

288

• •

The interaction layer – It handles the interactions between end users and mobile information agents. This layer also contains support applications. The cooperation layer – It provides cooperation operations for managing distributed interactions between agents. It maintains cooperation facilitators that are asynchronously networked. The service layer – It encompasses service access interfaces as well as service descriptors. It is also in charge of the management of inter-agent communications. Remote communications encode and exchange XML messages between distant agents or other entities.

Interaction

Cooperation

Service

Agents + applications

Cooperation

Interactions

facilitators

operations

platform

Services logic

Communication bus

•


Services descriptors

Information servers

Fig. 2. Distributed software architecture

The coordination schemes are enabled at the cooperation layer by the twofold function of the cooperation facilitator agents (CFAs). CFAs primarily handle distributed interactions between information agents. In the decentralized schemes for instance, CFAs help to subscribe / request for information as well as to tell / notify other agents. CFAs further deal with remote requests directed from the mobile information agents to distant support agents/services. This allows for instance to perform further search/negotiation even when the mobile information agent already toured a service place.

5 A Case Study on Information Retrieval for Distributed Scheduling of Multiparty Events Our case study is on information retrieval for distributed scheduling of multiparty events. A single-mobile agent sequentially roams the agenda servers, retrieves the information on availability, and schedules multiparty events. A terse summary of a single-agent prototype is introduced. The provided assessment demonstrates the per-


289

formance worthiness of the multi-agent schemes we elaborated earlier. More details can be found in [11] and [12]. 5.1

Prototype

The single-scheduler prototype is built in MS Outlook calendar environment and relies on the mail server of Ericsson Research Canada (Montreal). Grasshopper is used as mobile agent platform. The bulk of the prototype is implemented in Java. The software architecture is made of the mobile event scheduler agent (MESA), the master event planner (MEP) and the bridge. The MESA includes proxies of the retriever, identifier, and “notifier” since the calendar API is in Visual Basic (VB) [13], and the information is not easily processed from the Java code. The MEP resides on the scheduler service place and implements the real entities in VB executables. The bridge allows a JAVA-COM mapping between the proxies and the real entities. 5.2

Test Bed

During the tests, the scheduler service place runs on a dedicated machine for security reasons. It is a 400 Mhz Intel Pentium II desktop running Windows 4.0, equipped with Grasshopper 2.1 mobile agent platform. The MEP loads test calendars from the mail server using the Outlook 2000 API and store them as personal folder files on the dedicated machine. In order to launch the application from small footprint devices (e.g. Windows CE 2.1.1-enabled), we ported the MESA on Personal Java 1.0. The other laptops and workstations used in the experiment were running Windows NT 4.0 and Grasshopper 2.1, and connected to a 100 Mb/s Ethernet local area network. 5.3

Measurements

We have contrasted the mobile agent prototype to two client-server counterparts. The plain client-server counterpart retrieves information remotely by using plain Outlook API, whereas the optimized client-server counterpart uses an extended server API mapped onto the Outlook API. Fig. 3 shows the network load induced by the scheduling process as a function of the number of targeted participants, as well as the response time, both for a monthly timeframe in the worst case the date is detected on the 30th day. The event duration varies between 1 and 8 hours. Both communication cost and response time are significant in the plain clientserver case. In this case, the client application always downloads all the agendas. The mobile agent case and the optimized client-server counterpart are neck to neck, because the optimized counterpart retrieves information with a refined level of granularity. It should however be noticed that easy customization remains out of reach of the optimized client/server approach.

290

Edgar A. Olougouna, Samuel Pierre, and Roch H. Glitho Response time: event scheduled on day 30

600 500

Response time in seconds

Amount of data in kilobytes

Communication cost : event scheduled on day 30 700 plain client-server mobile agent optimized client-server

400 300 200 100 0 5

10

15 20 25 Number of participants

30

90 80 70 60 50 40 30 20 10 0

plain client-server mobile agent optimized client-server

5

10

15

20

25

30

Number of participants

Fig. 3. Network load and response time measurements in the worst-case scenario

6

Conclusion

The framework proposed in this paper is general enough to be applied to other mobile-agent information retrieval applications. It elaborates different coordination schemes: a centralized scheme, a hierarchical peer-to-peer scheme, and a hybrid scheme. We propose the integration of XML and mobile agents and the use of agenttechnology de facto standads such as ACL to engineer handy information retrieval applications. These technologies will enable to meet the requirements of automation, accessibility, and easy customization in mobile wireless environments. A case study is provided on information retrieval for distributed scheduling of multiparty events. A single-agent prototype of the mobile-event scheduler is introduced with performance measurements. From both delay and communication cost standpoints, the single-mobile-scheduler prototype outperforms an even optimally designed client-server counterpart. However, the optimization has required extension to the APIs offered by the server. As key lessons, it should be highlighted that the performance benefit, which could somehow be realized with extended client-server applications, can easily be sustained with mobile agents. Moreover, elegant customization remains difficult to achieve with cleverly designed client-server applications, but is easily realized with mobile agents. Ongoing work is prototyping several information retrieval applications that will serve as case studies to evaluate our coordinating schemes. We explore negotiation aspects in several application settings (e.g., mobile bargain hunter, mobile event scheduler). We will further investigate web information services. These latter are based on XML and allow program-to-program interactions on the web (e.g., WSFL [14], WSDL [15]).


291

References 1. J. Jing, A. Helal and A. Elmagarmid, “Client-Server Computing in Mobile Environments,” ACM Computing Surveys, Vol. 31, No. 2, June 1999, pp. 117-157. 2. R. M. Adler, “Distributed Coordination Models for Client/Server Computing,” IEEE Compute Magazine, Vol. 28, No. 4, April 1995, pp. 14-22. 3. V. A. Pham A. and Karmouch, “Mobile Software Agents: An Overview,” IEEE Communications Magazine, vol. 36, No. 7, July 1998, pp. 26-37. 4. M.K. Perdikeas et al., “Mobile Agents Standards and Available Platforms,” Computer Networks, Vol. 31, No. 19, August 1999, pp. 1999–2016. 5. G. Cabri, L. Leonardi, and F. Zambonelli, “Mobile-Agent Coordination Models for Internet Applications,” IEEE Computer Mag., Vol. 33, No. 2, February 2000, pp. 82-89. 6. G. Cabri, L. Leonardi, and F. Zambonelli, "XML Dataspaces for Mobile Agent Coordination," ACM SAC 2000: Special Track on Coordination Models, Languages and Applications, Como, Italy, 19-21 April, 2000, pp. 181-188. 7. P. Ciancarini, et al., “Coordinating Multi-Agents Applications on the WWW: A Reference Architecture,” IEEE Transactions on Software Engineering, Vol. 24, No. 8, May 1998, pp. 362-375. 8. B. Grosof and Y. Labrou, “An Approach to Using XML and a Rule-Based Content Language with an Agent Communication Languages,” IBM Research Report RC 21491 (96965), May 1999. 9. M. Kobayashi and K. Takeda, “Information Retrieval on the Web,” ACM Computing Surveys, Vol. 32, No 2, June 2000, pp. 144-173. 10. The World Wide Web Consortium, eXtensible Markup Language, http://www.w3.org/XML 11. E. A. Olougouna, R. H. Glitho and S. Pierre, “A Novel Mobile-Agent-Based Framework for Coordinating Distributed Scheduling of Multiparty Events,” Proc. of 21st Biennial Symposium on Communications, Queen’s University, June 2-5, 2002. 12. R. Glitho, E. Olougouna and S. Pierre, “Mobile Agents and their Use for Information Retrieval: A Brief Overview and an Elaborate Case Study,” IEEE Network Magazine, Jan./Feb. 2002, pp. 34-41. 13. D. Gifford, Outlook 2000 VBA, Programmer’s Reference, Wrox, 1999. 14. Web Services Flow Language (WSFL 1.0). Edited by Prof. Dr. Frank Leymann, (Member IBM Academy of Technology, IBM Software Group), May 2001, http://www4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf. 15. Erik Christensen, Francisco Curbera, Greg Meredith and Sanjiva Weerawarana, “Web Services Description Language (WSDL) 1.1”, W3C Note 15 March 2001, http://www.w3.org/TR/wsdl.

Seamless Incorporation of Agents in an E-Commerce Intermediation Platform Irene Sygkouna1, Maria Strimpakou1, Francisco Valera2, Anastasia Kaltabani1, Luis Bellido3, Enrique Vazquez3, and Miltiades Anagnostou1 1 National

Technical University of Athens, 9, Heroon Polytechneiou Str., 15773, Zografou, Athens, Greece _MW]KOQWXVMQEOEPXQMPXSWa$XIPIGSQRXYEKV 2 Universidad Carlos III de Madrid (UC3M) Avda. de la Universidad 30, 28911 Leganés Madrid, Spain JZEPIVE$MXYGQIW 3 Universidad Politécnica de Madrid (UPM). Spain _PFXIZEÛYIâ$HMXYTQIW

Abstract. This paper describes the realization of a business-to-business intermediation e-commerce platform. The main concern derives from the combined usage of two emerging technologies, namely the Java 2 Enterprise Edition (J2EE) and the Mobile Agent Technology (MAT). The key issues that are addressed in this paper are the following. First, the scenario of the proposed system. Second, the definition of the required functionality and its design by means of appropriate service components based on J2EE principles. Third, the exploitation of agents in terms of their detailed design and implementation activities. Finally, the evaluation of the two interoperable technologies.

1

Introduction

Over the past few years, electronic commerce has become an increasingly central part of the economy. In e-commerce literature, the overall electronic intermediation theme, as well as its relevance and relationship with particular business to business issues, have attracted considerable attention and generated quite comprehensive analyses [1,2]. Equally important experimentation and commercial exploitation of respective software systems [3] have been, in parallel, achieved. One of the most important things in actual electronic commerce is to achieve an accurate information interchange between participating entities (typically customer and provider), using any available communication infrastructure. The current networking environments with all the Internet and intranets communication services make possible the access to a great amount of information. Nowadays, it is essential to find a mechanism that allows customers and providers to find each others and perform e-commerce transactions in a fluent and precise manner, minimizing the time normally spent in finding useful information, which tends to be quite high. This kind of mechanism is provided by the so called mediation platform [3] that typically includes the set of duties which are supposed to rule every transaction associated with


Seamless Incorporation of Agents in an E-Commerce Intermediation Platform

293

e-commerce and are oriented to decrease the distance between customers and providers, from a commercial point of view. In this paper, we present a particular brokerage platform, compliant to business to business models and respective systems implementation requirements, that is considered to be applicable across a number of diverse business domains. It introduces some experiences from the architecture, that are mostly related to the J2EE and MAT. The whole procedure has been performed in the context of the IST Smart-EC project. The J2EETM [4], is a middleware platform that appeared at the same time as the beginning of Smart-EC project and so it has been possible to follow its evolution very closely. It facilitates the development, deployment and execution of distributed multitier Internet applications, like the brokerage one we are presenting. On the other hand, MAT is an advanced software technology, well suited for e-commerce since it supports the possibility of the direct and efficient interaction with procurement software through the agents’ ability to move among network nodes. Both technologies have been successfully integrated and tested, as it is described in the article. This article is structured as follows: Section 2 describes the scenario of the proposed platform as well as its architecture in terms of the J2EE terminology. Section 3 focuses on the usage of the agent technology according to a detailed design and implementation issues, and the incorporation of the two technologies. Finally, Section 4 introduces some comparisons and remarkable conclusions in terms of the two aforementioned software technologies evaluation.

2

Modeling an Intermediation E-Commerce Platform

2.1 Smart-EC Scenario In the proposed complex services transactions model we consider three basic domains that are the User Domain, the Service Provider Domain and the Broker Domain, which actually represents the specific brokerage platform domain. The main phases of the complex e-commerce service transactions lifecycle of the proposed system are the following: first, the request formulation and solutions pre-processing, second, the solutions identification and bilateral negotiation, third, the solutions evaluation and finally, the transaction execution. The proposed system [5] is able to handle complex services composed by a set of simple services. A simple service is defined to be provided as a whole by a provider. In the sequel, the functionality of the complex services transaction e-commerce system is described. After a customer has successfully accessed the system, he may construct requests by browsing a hierarchical menu of provided services. The knowledge required by the user to dynamically formulate a complex service request is provided by means of the Ontology technology [6] capabilities supported by the platform. Upon the user request validation and confirmation, the system invokes its internal brokering functionality in order to find an acceptable solution. A solution is defined as a set of offers (made by service providers) that is able to satisfy the user request. Specifically, for each simple service composing the request, the system identifies corresponding offers (i.e., zero, one, or more) meeting the requirements that account to the attribute values selected in the request form. When the solution identification phase is completed, the system presents a solution to the customer. The solution may be presented in several ways depending on the

294

Irene Sygkouna et al.

customer preferences. The platform is designed so as to support the co-operation with and servicing to a class of providers by allowing an extensive and online access to the brokered resources (affiliate service providers). The customer of the described brokerage platform, hereafter denoted as user, may redefine the attribute values of simple services for which no satisfactory offers have been found. In this case, the system will validate the updated request and perform a new solution identification process, until a satisfactory solution is found. Once the proposed solution has been accepted the system proceeds with the subsequent phase that is the transaction execution phase. In this last phase, the platform performs the corresponding service reservation and the necessary interactions with the service provider domains in order to actually proceed with e-commerce services provision and delivery. 2.2 Smart-EC Architecture Based on J2EE Principles In the middle of the J2EE architecture are Enterprise JavaBeansTM (EJBTM) [4], which are responsible for solving the business logic and data access of the enterprise application. They are reusable components where developers can code almost any necessary object functionality (through session or entity beans) and that can be accessed by client programs and run on a J2EE server. Following this movement, in Smart-EC a three-level-tier architecture (client, server and information services) based on J2EE is used (see Fig.1). In this way, clients just have to handle the user interface and they do not have to query databases, execute complex business rules, or connect to legacy applications, because the middle-tier server is transparently doing these jobs for them.

Fig. 1. Smart-EC core system architecture based on J2EE

Smart-EC supports a diversity of heterogeneous clients, such as Web browsers and hand held devices. These clients are built with plain HTML and WML pages (no Java applets or scripting languages are used) and server access is done through HTML and WML forms that are processed by a servlet in the middle tier.


295

This servlet acts as an information entry point to the middle tier from the client and several EJBs [5] are responsible for providing the business logic of the project (see Fig. 1). One of them, the System Controller Bean, is responsible for analysing the XML stream received from the servlet and dispatching the corresponding action to other related beans (UserHandler, ProviderHandler, LoginBean). These XML information exchanges, together with XSL (eXtensible Stylesheet Language) documents make the system independent from the accessing device. Whenever it is necessary to retrieve external data, two special beans are used to contact the third tier of the architecture: the Ontology Handler is able to interact with the stored ontological knowledge and the Data Controller is centralising specific database accesses (user and provider profiles and catalogue queries or updates), so that the rest of the modules do not have to cope with database issues. Finally, there are three more beans that complete the system: the Complex Service Handler that is able to build atomic requests breaking the global request from the user into simpler requests so that they can be solved by different providers although they are finally offered as a whole to the user, the Solution Builder (SB) bean classifies the retrieved catalogue so as to select the offers that best fit with the user requests and the Transaction Handler (TH) bean in order to complete the trading cycle. The remaining bean, the Remote Provider Handler (RPH), is responsible for the connection of the system with the external affiliate provider system. In specific, RPH is commissioned with the responsibility to create and delegate the Mobile Provider Agent (MPA) in order to carry out the interaction between the Smart-EC side and each affiliate provider. In each Affiliate Provider Domain, the two agents that are identified are respectively called Static Affiliate Provider Agent (SAPA) and Mobile Affiliate Provider Agent (MAPA).

3

Use of Agents in Smart-EC

3.1 Agent-Based Functionality In the context of the system communication with the external providers, a two-way interaction is ensured, namely each external provider has the possibility to contact the broker domain while on the other way around the Smart-EC system takes the initiative to contact the remote providers. The functionality that is mainly provided by the agents in the Smart-EC platform is spanned over the processes that are analytically described in the sequel. The proposed system architecture enables each affiliate provider to contact the Smart-EC platform in order to keep up-to-date the system database. In this respect, it has the possibility to add, update or delete one or more of its offers to/from the system database. In the first case, namely the addition or update of offers, SAPA creates MAPA and supplies it with a collection of offers retrieved from provider’s database apart from the credentials that are necessary for gaining access to the Smart-EC database. Then, MAPA migrates to the broker domain and proceeds with the permissible insertion of the offers in the database. In the case of the deletion, MAPA is provided with the code names of the offers that have to be deleted as well as with the corresponding credentials. The following figure (Fig.2) shows the sequence of the events. In Smart-EC domain, the administrator, in terms of his global monitoring responsibility, is able to request specific offers or the whole catalogue of offers that are a pro-

296

Irene Sygkouna et al. 6 W D W L F $ I IL O L D W H 3 U R YLG H U $ J H Q W

0 R E L O H $ IIL O L D W H 3 U R YLG H U $ J H Q W

6 P D UW( & ' D WD E D V H

F UH D WH D X WK H Q W L F D W H D G G 8 S G D W H 2 IIH U V G H O H W H 2 II H UV

Fig. 2. Affiliate provider initiative for the information update in Smart-EC

vider’s own. More specifically, he is privileged to request the update of offers whenever he detects that some offers stored in the Smart-EC database are stale. In this sense, the AdminManager invokes the RPH that in turn creates and initiates the MPA. The RPH supplies the MPA with the appropriate credentials so as to be authenticated in the affiliate provider side and the requested offers code names. In the sequel, the MPA migrates to the affiliate provider domain where it interacts with the SAPA in order to be authenticated and to obtain the relevant information from the local database. Then, it migrates back to the system where the captured information is stored in the Smart-EC database. The aforementioned process is analyzed in terms of time ordered messages, in the following sequence diagram (Fig.3): 6 P DUW( & 'DWDEDVH

$ GP LQ0 DQDJHU

5HP RWH3 URYLGHU + DQ GOHU

0 RELOH 3 URYLGHU$ JHQW

6 WDWLF$ IILOLDWH 3 URYLGHU$ JHQW

$ IILOLDWH ' DWD E DVH

UHTXHVW2IIHUV FUHDWH JHW2IIHUV5HP RWH JHW8VHU JHW2IIHUVE\ &RGHV JHW2IIHUV XSGDWH2IIHUV

Fig. 3. Information renewal in Smart-EC motivated by the Administrator

During the process of finding suitable offers that meet the user request, the SB sometimes tracks that some offers stored in the database are incomplete, i.e., some attributes have no value. In this case, it requests these offers to be completed by contacting the owner of the offers and afterwards proceeds with the evaluation of their potential correspondence to the user request.


297

The relevant process falls into the following operations: The SB invokes the RPH that then creates the MPA. Following, the MPA migrates to the affiliate provider domain carrying the code names of incomplete offers. With the fulfillment of the compulsory authentication procedure it retrieves the completed offers through the SAPA agent. Finally, it returns back and delivers the acquired information to the SB. In the context of the solution building, if the customer has selected the online checking of the offers’ availability, a remote communication takes place between the system and the appropriate affiliate provider. In this sense, the system avoids proposing to the user a pointless solution due to potential unavailability. In terms of system modules, as it is shown in the next diagram (Fig.4), the SB triggers the RPH that then communicates remotely with the SAPA residing at the provider side. At the end, SAPA returns the proper answer after inquiring the local database. The following sequence diagram enlightens the aforementioned processes: 6 R OX W LR Q % X LOG H U

6 P D UW ( & ' D WDED V H

5 HP R WH 3 U R YL G HU + D Q G OH U

0 RE L OH 3 UR YLG H U$ J H Q W

6 W D W LF $ IILOLD W H 3 UR YLG H U$ J H Q W

$ IILOLD W H ' DWDE DV H

J H W 2 IIH UV F R P S OH W H 2 II H UV F UH D W H JH W 2 IIH UV 5 H P R W H JH W8 V H U J H W 2 IIH UV E \ & R G H V J H W 2 IIH UV

X SG D W H 2 II H UV F K H F N $ YD LOD E LOLW \ F K H F N $ YDL O5 H P R WH J H W $ YD LO

Fig. 4. Solution building procedure with the affiliate provider participation

Once the customer determines the most preferable solution according to his request among a list of proposed solutions, the system engages to start the transaction procedure. For the offers that correspond to affiliate providers, an online connection to these providers is required. More specifically, the transaction phase consists of the following tasks: 1. Reserve all the atomic offers that compose the solution and correspond to different affiliate providers. 2. Confirm every atomic offer if each one has been successfully reserved. 3. Cancel the overall reservation in the case that at least one of the atomic offers either is not reserved or is not confirmed by the corresponding affiliate provider.

298


As the following diagram depicts (Fig.5), the TH that is triggered with the customer initiative to proceed with the transaction details, invokes the RPH that in turn communicates remotely with the SAPA in order to perform the specified task. & X V WR P HU+ D QG OHU

7UDQ V DF WLR Q + DQ GOH U

5 H P R WH3 UR YLGH U + D QG OHU

6 WDWLF $ IILOLDWH 3 UR YLGH U$ JH QW

$ IILOLDWH ' DW DED V H

V WD UW* O RE D O 7UDQ V DF WLR Q UH V H UYH6 H UYLF H UH V H UYH 6 HUY5 H P R WH J HW5 H V F RQ ILUP 6 HUYLF H F RQ ILUP 6 HUY5 H P R WH JH W& RQ I F D QF HO6 H UYLF H F D QF HO6 H UY5 HP R WH J HW& D QF H O

Fig. 5. Involvement of affiliate provider in transaction procedure

3.2 Implementation of the Agent-Based Components In order to create and execute software agents, the developer can use a ready-made development environment. In the context of Smart-EC, the selection of the mobile agent platform, should enhance the system performance with the higher acceptability regarding the implementation of the core Smart-EC system, while at the same time, overcome any interoperability problems with the J2EE technology. Following the framework of the seamless integration of MAT to the existent architecture of SmartEC, the use of Grasshopper [7] was decided, keeping in mind that one of these platform considerable advantages is that it effectively supports J2EE compliance. Mobile agents require a specific and secure runtime environment that provides the mechanisms and the functionality necessary on all potential destination hosts, in distributed environments. Among others, this environment has to fulfill the tasks of supporting the agents’ creation, execution, localization, migration, communication and security control. In specific, Grasshopper is a middleware mobile agent platform that is built on top of a distributed processing environment, manifesting the evolution of distributed software objects towards mobile agents. In principal, it provides all the aforementioned services while at the same time it ensures the interoperability between agent platforms of different manufactures, compliant with the Mobile Agent System Interoperability Facilities (MASIF) standard [9]. As it is known, mobile agents are able to move from one physical network location to another. In this respect, MAT is regarded as a replacement of the client/server paradigm. However, the combination of both approaches, i.e., not only migration and local interactions but also remote procedure calls enables the development of applica-


299

tions that exploit the advantages of both mechanisms in an optimal way, something that Grasshopper supports. Although Grasshopper platform offers many advantages in the context of SmartEC system and therefore, the incorporation of mobile agent technology in an ecommerce application is realized without confuting problems, the interoperability between Grasshopper and J2EE technology has a black point. Specifically, Grasshopper employs the Communication Service, one of the system core services, for all the remote actions that take place between its distributed components, such as location-transparent inter-agent communication, agent transport and agents’ localization. In addition, this service enables external application objects, such as EJBs to interact with Grasshopper components. An application object may act as a client, something that is realized in Smart-EC without any complication, for example EJBs simply invite the agents’ methods. On the other hand, if an application acts as a server, namely receive requests, it must follow some specific rules dictated from the Communication Service. The application component should implement a server interface and start a communication receiver that listens to communication clients on a specific address and port. The dispute arises when a Grasshopper component, in this case one of the designed agents, propagates a request to an EJB. In this sense, neither a Grasshopper agent is able to create a new instance of an EJB nor an EJB is able to register itself as a server object to the communication receiver. Thus, given this restriction, one of the issues that should be solved is the access to the Smart-EC database by an agent. Undoubtedly, a Grasshopper agent can contain SQL code and elaborate a usual API, like JDBC, for accessing a database. The main drawback in this approach comes from the fact that in systems like SmartEC it is much more efficient to retain a centralized control of the database to a unique component and not let other components interfere with it. Moreover, the code for disseminating data in the database is already in the Data Controller component and it would be inefficient to repeat existing functionality. In this respect, an alternative is found and the desired communication is achieved with the usage of J2EE Application Clients. A J2EE Application Client [4] is a Java application that differs from a stand-alone Java application Client simply because it is a J2EE component. Firstly, it is portable, running on any J2EE-compliant server and secondly, it may access J2EE services. In a few words, it is a stand-alone program launched from the command line or desktop, and typically accesses EJB executed on the J2EE application server. A brief insight in the way the J2EE application client acts as a middleware between Grasshopper agents and EJBs is illustrated in the Fig. 6. As it is depicted, the Application Client comprises two modules. Firstly, a server object module that actually implements the server interface and provides the access to the EJBs methods. Secondly, a main module that starts the communication receiver and registers the aforementioned server object to it. Thus, if an agent is commissioned to access an EJB method it merely uses the standard communication mechanism that Grasshopper prescribes for accessing any external application.

4

Conclusions

In this paper, an intermediation platform for e-commerce is described emphasizing on the several experiences derived from the usage of the new middleware J2EE platform


$JHQW 0RGXOHV *UDVVKRSSHU &RUH 6\VWHP

*UDVVKRSSHU&RPPXQLFDWLRQ5HFHLYHU

300

0DLQ 0DLQ 0RGXOH 0RGXOH 6HUYHU 2EMHFW 0RGXOH $SSOLFDWLRQ &OLHQW

+RPH ,QWHUIDFH 5HPRWH ,QWHUIDFH

(QWHUSULVH %HDQ

'DWDEDVH

&RQWDLQHU

-((6HUYHU

Fig. 6. The J2EE Application Client as a middleware in Smart-EC

and the mobile agent possibilities within the same environment that are considered as a value added in its architecture. Useful and interesting remarks from the combined exploitation of both technologies are deduced and analysed in the sequel. After the implementation of the final prototype of Smart-EC (May 2002), the main advantages we have obtained from J2EE in order to design, build and run our ecommerce mediation platform are the following: • Easy design and integration process: The structured modular approach imposed by the EJB architecture serves the good functionality division and reusability of code. Moreover, due to this modularity, the integration phase is not so hard as in conventional software developments. • Distribution facilities: Communications between different EJBs are mainly based on RMI. This means that application distribution has been managed in a completely transparent manner in our system. Interesting advantages have also arisen with the appearance of J2EE v1.3 asynchronous communications that have been presented in different middleware platforms for a long time ago [8]. • Supporting services: Some e-commerce necessary tasks such as transaction and security are easily managed by the system. • Database interoperability: It is almost immediate to install different databases and make them run within the system. In Smart-EC prototype, both Cloudscape and Oracle databases have been used and both are accessed locally or remotely. Despite of these advantages, J2EE has also shown notorious inconvenience during several phases of the project: • The development and execution platform is quite a resource intensive one. It is mandatory to have never less than a Pentium III with 128 MB RAM. • During the designing phase, remote communications, scalability and database design and fine-tuning, must be seriously considered. Otherwise, the running application will be suffering from serious performance lacks. • Integration and deployment processes have turned out to be very specialised tasks that have nothing to do with other kind of software development cycles. Apart from the J2EE, an evaluation process of the mobile agent technology is also regarded. Taking into consideration that Smart-EC system is not a pure mobile agent


301

application but one that elaborates agents as an add-hoc technology for serving the real-time access to remote resources, the main observations are the following: • For complex or data-intensive interactions, where the amount of the transferring data is considered respectable, e.g. in the request offers procedure, or the given task involves multiple interactions in order to be accomplished, the shifting of the computation to the data rather than the opposite, with the elaboration of agents, is a very appealing proposition to reduce the network load. • On the other hand, the design procedure has shown that in some use cases, the sum of the exchanged communication messages restricts to limited, short server requests and responses, e.g., in the transaction procedure. In this context, the use of a mobile agent would consume extravagant bandwidth, in expense to performance, comparing to the utilization of remote location-transparent procedure calls. In this sense, the proposed application takes advantage of both communication mechanisms that the mobile agent platform supports. • Concluding, it is worth mentioning that the interoperability between J2EE and Grasshopper agent platform is quite feasible despite the fact that some additional system configurations are needed in order to achieve their successful merging. In this respect, a more global exploitation of the J2EE facilities is accomplished due to the fact that the use of J2EE Application Clients is motivated.

References 1. J.P. Bailey, J.Y. Bakos, “An exploratory study of the emerging role of the electronic intermediaries”, International Journal of Electronic Commerce, Spring 1997 2. Chircu, R. Kauffman, “Reintermediation strategies in business-to-business electronic commerce”, International Journal of Electronic Commerce, Fall 2000 3. Martin Bichler, Arie Segev, “A Brokerage Framework for Internet Commerce”, Distributed and Parallel Databases, Vol.7, Number 2, pp.133-148, April 1999 4. Sun Microsystems, Inc. JavaTM 2 Platform, Enterprise Edition Specification v 1.3. February 2001. [Last visited: August 2001] http://java.sun.com/j2ee/ 5. Smart-EC: Support for Mediation And bRokering for Electronic Commerce, IST-199910130, RTD Project, Deliverable 4.2, “Smart-EC Architecture V2”, November 2001 6. M. Fernandez Lopez, “Overview of methodologies for building ontologies”, Proceedings of the IJCAI-99 workshop on Ontologies and Problem-Solving Methods (KRR5) 7. IKV++ Technologies AG (2002), Grasshopper MAP v.2.2.3 http://www.grasshopper.de 8. F. Valera, J. E. López de Vergara, J. I. Moreno, V. A. Villagrá and J. J. Berrocal, “Communication Management Experiences in E-Commerce”, Communications of the ACM (ISSN: 0001-0782). 44 (4): 63-71. April 2001 9. OMG MASIF Standard http://www.fokus.gmd.de/research/cc/ecco/masif/

UNITE – An Agent-Oriented Teamwork Environment Michael Zapf, Rolf Reinema, Ruben Wolf, and Sven Türpe Fraunhofer Institute for Secure Telecooperation (SIT), Darmstadt, Germany {zapf,reinema,rwolf,tuerpe}@sit.fhg.de

Abstract. Providing seamless, fluid interaction between team members, contractors, consultants from any world-wide location stimulates virtual organisations. The agent-based team work environment UNITE offers team members intuitive and ubiquitous access to each other, and to information and resources of their project, secure and transparent to their physical workplaces and their own tools. Thus, team focus will remain wholly on the project. In this article we will provide informations about the underlying architectural model, the application of agents in particular, and show how we integrated external tools.

1

Introduction

The UNITE (Ubiquitous and Integrated Teamwork Environment) project [1] acknowledges the growing need for computerised collaboration environments supporting teams working on specific projects, in particular when team members are located at different and, over time, changing places. It is essential that such environments allow team members to switch between different projects, make it easy for them to preserve and restore the work context of any given project, allows them to reserve and tailor physical workplaces as team members move and change places, and last but not least be sufficiently secured. UNITE aims to do research and development on cooperative workplaces and their creation from a unified cooperation platform. This platform is the key system component which provides the facilities for devices, components, and networks to fully interact, despite the possible original inherent heterogenity, and which takes care that a uniform and ubiquitous view is presented to all team members regardless of their physical location. The overall objectives of the UNITE project are as follows: 1. Identify, document, and verify the overall requirements of future project-oriented team work and develop for it a cooperative workplace. 2. Define a suitable architecture of the cooperation platform, based on the above paradigm. 3. Validate the paradigm of a cooperative workplace and the architecture of the cooperation platform. To this end, a prototype is developed and evaluated by means of realistic trials involving real users and teams. This article is structured as follows. In section 2, we give some information about the underlying paradigms which led to the architecture of the UNITE platform, described in section 3. This section will also present some basics of the agent system AMETAS A. Karmouch et al. (Eds.): MATA 2002, LNCS 2521, pp. 302–315, 2002. c Springer-Verlag Berlin Heidelberg 2002

UNITE – An Agent-Oriented Teamwork Environment

303

which serves as the base for implementing the core platform. Section 4 provides some more in-depth information of the implementation issues, and finally section 5 offers our conclusions.

2

Requirements and Paradigm

The UNITE Platform is an innovative approach to merge the world of virtual teamwork with real-life teamwork [2]. With projects spanning multiple institutions, we identified a clear need of defining the idea of teamwork in a distributed environment. 2.1

Distributed Teamwork

In many locations, workplaces are no longer allocated to a specific person but are flexibly assigned as required. There is an increased focus on teamwork world-wide, and societies without a previously well-developed teamwork ethic are joining this trend. For this reason, in addition to the emergence of mobile and tele-working forms of occupation, offices will continue to gain in importance as meeting points. The overall concept and architecture of the office is still pretty traditional and does not consider how to accommodate the needs of modern organizational structures of work (such as networked structures, projects, and virtual organizations), to address increased employees’ responsibility and diversity of tasks, and to fully exploit the benefits of new technologies. The only changes in the working environment that have occurred have resulted from the need of telecommuters for home offices. However, to appropriately implement new methods of work, a holistic environment is needed which can fully support these methods effectively while giving people at work the resources that they need to perform their duties, and convenient means for interacting with each other. Traditional, work-sharing organisations are not suitable for reacting dynamically, flexibly, quickly and economically enough for dealing adequately with permanently changing customer demands. New paradigms of work organization ask for room structures and furnishings which meet the requirements of teams and which contain dynamically re-configurable teamwork environments, individual workplaces, conference rooms, and communication islands [3]. There are many other important factors which have to be considered in developing future workspaces like – driving the transition to virtual team-based structures, – managing virtual project-teams, or – dynamic sharing of resources, such as e.g. office spaces. With respect to the physical workspaces, intelligent buildings with flexible building structures must be considered [4]. Last but not least, social impacts have to be carefully investigated, for example the increasing demands on private time and space, the blurring of boundaries between private and professional zones, and integration and coordination of distributed work across boundaries. One of the objectives of the UNITE project is to define a new paradigm, namely the cooperative workplace, aiming at supporting communication and collaboration in distributed project teams and to put it into practice by developing a cooperation platform.

304

Michael Zapf et al.

2.2 Work Contexts UNITE focuses on the idea of supporting teamwork in distributed teams. People working in teams may participate in different projects. They usually organize their way of working by filtering E-Mail messages, putting them in different mail folders, using various document repositories and so on. Behind this organization strategy lies the idea of sets of resources that are associated to a project. The virtual workspace is where cooperation among project team members occur as a whole. The physical workspace is where individual or group work physically takes place. Hence, there is exactly one virtual workspace per project while physical workspaces may be assigned to different projects at different times. Conceptually, each project has a virtual workspace of its own, and anyone who is a member of several projects would go from one virtual workspace to another as he or she goes to work from one project to another. The cooperative workplace integrates physical and virtual workspaces under a unified user interface. Physical and virtual workspaces are combined under a common metaphor, so that one can act equally in either one and make a seamless transition from one to the other. Entering a context means that a user wants to have access to the respective resources, filtering out those that are connected to other projects. This means that instead of remembering the mailbox to use, the calender to access, the number to dial, the document repository to utilize, the user should be presented the correct set just by selecting the project. While in a team context, users move among the team resources in a virtual way and are accessible by other team members. If a user wants to communicate with another user, they may create an ad-hoc meeting. This meeting is defined by the participating people and by the resources that are required. One example could be a phone conference, a simple text chat session, or advanced groupware tools like application sharing. 2.3 Agent-Orientation Since the mid-nineties of the last century, the new paradigm of agent-oriented software development received an ever-growing interest for application on various scenarios. The definition of an agent is not as concise as other definitions because agenthood does not only relate to implementing special components called agents but also to design the architecture in a certain way. Different research groups, especially from the area of artificial intelligence on one side and distributed systems on the other side, assessed specific properties of agents to be most important, thereby coming to diverging specifications. In UNITE, we apply autonomous agents for several purposes: 1. Entity modelling: Users, teams, and resources are represented by agents. 2. Distribution handling: The distributed nature of the platform requires mechanisms for information transport from one network location to another. 3. Remote execution: In order to negotiate communication parameters, not only parameters need to be transported, but also code to be executed remotely. 4. Autonomy: The agents shall decide how to contact their respective real-world counterpart; for example, the agents representing users may decide to send an SMS notification whenever special events happened during the user’s absence.


305

3 The UNITE Architecture At first we give a short view on the agent system AMETAS which is the base of our platform implementation. After that, some details on the platform architecture are presented. 3.1 The Agent System AMETAS AMETAS (Asynchronous Message Transfer Agent System) [5] is a platform for the development of autonomous and mobile agents. AMETAS was designed and implemented at the University of Frankfurt/Main, Germany. In the agent system, three kinds of components are defined: Agents, user adapters, and services. All three kinds of components share the same message exchange mechanism and are called Place Users. In order to send a message to another Place User, the message must be created by the sender and submitted to the infrastructure (the place) which then deposits the message in the recipient’s mailbox. The recipient has to retrieve the message by itself; it may be notified that a new message has arrived. Note that it is up to the recipient whether and when to retrieve a message. Places are the execution environments for Place Users. Each network node which is part of the agent environment should run an own place. Mobile agents may then decide to migrate to these places in order to access the specific services or to meet other agents. AMETAS abstracts from the details of external facilities by introducing the services which provide access to the outside world. On the other hand, agents are not allowed to access these resources by themselves. Thus, the only way to communicate with an agent or to have the agent change its environment is by means of asynchronous messages. Services may translate these messages to database accesses, file system accesses, socket communication and so on. Individual users may be coupled to the agent system using the so-called user adapters. A user adapter may consist of a graphical user interface which translates user actions to messages. In the other direction, messages from other Place Users are translated to graphical output. From an agent’s point of view, a user adapter looks like any other agent, so the user interaction is modelled similar to any other inter-agent interaction. Place Users are strictly separated from each other by the infrastructure. Each Place User is driven by one or more separate threads in the associated threadgroup. Furthermore, separate class loaders are utilized. It is not possible to pass references between Place Users so that the decoupling is ensured. Despite the autonomy, agents of one application are usually designed to cooperate, similarly to a team of individual humans working together. 3.2 The UNITE Platform as an Agent-Based System UNITE employs an inherent feature of the AMETAS platform to support virtual teams. A virtual team is formed temporarily out of members of several separate organisations. Each participating organisation remains independent, and may participate in multiple virtual teams. Besides participating in virtual teams each organisation still has its private projects and infrastructure. This separation may most easily be provided by introducing several kinds of AMETAS places.

306

Michael Zapf et al.

Migration User Interface

Service Agent

User adapter External object

Messages Place Fig. 1. AMETAS structure

Places. AMETAS provides places as the execution environment for agents and agent migration as a communication mechanism between them. Places are independent of each other and all settings and security policies are defined locally. Thus, inherently, AMETAS supports cooperative operations of the infrastructure with a clear separation of ownership and responsibility. Within UNITE, three types of places are distinguished: homebases, team places, and room places. On homebases, users and their personal tools, services, and data are represented. A team place represents one particular team; distinct teams use distinct team places. Thus, the independence of places is maintained within the UNITE platform. Homebases are independent of team places, and team places are independent of each other. There are no relationships between homebases, or between team places. Relationships between homebases and team places are established dynamically as users start or cease to work in teams. Generally, a homebases represents a set of users and can thus be used to represent an organization. A team place, being an independent entity, can be run by an organization participating in the respective project or by an independent third party. Place Users. The AMETAS places provide the architectural base for the UNITE platform. Each of these places has specific Place Users running on them. Homebase. At the homebase, Personal Agents are maintained of all users who take this homebase as their UNITE login access point. The Personal Agents are launched automatically when starting the place, and they continue running after the user logged out again. Furthermore, to allow access, a specific service (described below) is provided to allow users to log in with their web browser. This so-called UI service gets the user actions, translates them to messages, and directs them to the respective Personal Agent. Vice versa, messages coming back from the Personal Agent as a result of the action are translated into a suitable output frame to be displayed by the user’s browser. Auxiliary services may be found at the homebase which provide access to features like the user’s private calendar, or the own document repository. As described above,


307

these services are required to bridge the abstract world of AMETAS services with the concrete service implementations. Team Place. Similar to homebases hosting the Personal Agents, the team place hosts Team Agent as well as the so-called Personal Representatives which are sent by the respective Personal Agents when the user enters a project context. This team agent is responsible for granting access of Personal Representatives which have migrated to this team place as a consequence of users entering this team context. On the team place, similar auxiliary services may be found which allow to access the team address book, the team calender and so on. Again, there is a UI service which allows users to directly contact the team place. During our design it showed that having a separate web access point into the team is preferred to handling everything by one single access point. Room Place. The third kind of place hosts the so-called room agents and device agents. These kinds of agents provide interact with a room and facilities management infrastructure which allows to allocate rooms and facilities for real meetings which happen in the course of virtual meetings. The current version of the UNITE platform, however, does not yet support rooms and devices management, but this feature has been selected to be important for future extensions. 3.3

Capabilities and Preferences

One of the key features of the UNITE platform is to allow users to log in from various locations, not only from the standard office workplace. Furthermore, different devices may be used for accessing. Many of the tools used for synchronous communication depend on all participants using the same or at least a compatible client program. However, some of these tools are probably not available at the client’s side, or they are not executable because of the different capabilities of the execution environment. Therefore, UNITE defines the notion of capabilities and preferences. Capabilities are related to the set of possible tools which are available at the client’s side, while preferences are related to the user’s desires which tool should be used while communicating with him. While the user may have constant preferences (e.g. preferring to use text chat instead of phone communication), the capabilities change over time and for each login incident. 3.4

Role of the Mobile Agents

The set of capabilities is managed by the Personal Agent. When the user joins a team, these data must be propagated to the team place. This is done by sending the mobile agent called Personal Representative to the team. When a communication session shall be established between two team members, the corresponding PRs compare the capabilities and preferences of each participant and try to find out which collaboration scenario is most appropriate. Furthermore, changes

308

Michael Zapf et al.

in the personal profile that are related to a special team may be synchronized with the information held by the team agent. In order to access resources at remote places, the team agent sends simple agents (called messengers) to the remote places. These mobile agents may either just deliver a message (thus implementing a remote message routing) or execute a multi-step task remotely, for instance, to allocate rooms and ensure the availability of devices.

Client location

Web server

PA

Homebase location

d)

c)

PR

a) e)

UI service

Client browser

Web server b)

g)

Team place location

TA

f)

Active members

UI service

Fig. 2. User sending the PR into a team

Figure 2 illustrates what happens when the user enters a team context. At first the user’s browser contacts the home web server – and also the team server. But the team server will not respond until the following action is complete. The UI service at the homebase looks up the associated Personal Agent (PA), creates a message, and submits it. The PA instructs the Personal Representative (PR) to wander to the Team place and provides it with the user’s current preferences and capabilities. After the PR has arrived at the Team place (where PRs from other persons may be present), it informs the Team Agent which sends an update to the local UI service. Now the UI service enables the team web server to complete the request by sending a reply to the user’s browser. 3.5

Communication and Collaboration Tools

UNITE specifically addresses the easy-to-use provision of communication channels (synchronous as well as asynchronous) between the people involved in the collaborative work processes, at any time and at any place. UNITE provides a unified communication and collaboration middleware, independent of specific protocols, networks, media types or languages so that the virtual office will be flexible and work over various disciplines, will use any available communication channel and enable media-rich real-time interaction. Users may use different networks and protocols but still join in the same communicative session. Such hybrid communication services will support the ability to


309

establish connections between end-points that use different communication protocols as well as blend different media streams. Since collaborative processes often span multiple sites, the support of multi-party distributed communication is mandatory. By providing a unified way of communication for all types of real-time interaction, it is possible to develop applications for the virtual office with the ability to focus on the application domain rather than on the communication protocols and infrastructure. The UNITE-supported user will be able to locate another UNITE-supported user and contact him without considering which method of communication to use. The communication/collaboration middleware services is responsible for the following main tasks: – Connect between one or more UNITE users – Conference between several UNITE parties – Establish communication with people that are not UNITE users Communication and collaboration between team members relies on a communication and collaboration layer, which itself accesses several communication and collaboration servers and services and has the capability of integrating existing software packages. The software chosen for the platform is given below; but in general, the platform permits other packages to be used as well.

4

Implementation Details and Applications

In this section, we give some further information about implementation issues. These refer to the implementation of the Basic Platform, the first prototype of the UNITE platform. These issues also apply to the Enhanced Platform which is currently near completion. 4.1

User Interface

The UNITE user interfaces are fully based on Web technology. Although Web browsers as a UI platform have quite some limitations compared to a fully featured GUI platform, its great advantage is the support of ubiquitous access. The user interface consists of a navigation bar at the left side which allows access to the respective features, and a detail view in the rest of the screen. Figure 3 shows a sample screenshot of the current UNITE Basic Platform. Target users of the UNITE platform are expected to be highly mobile, accessing their work-related resources from a variety of places. Web-based access to E-Mail messages gained quite some popularity for just this reason. Each AMETAS place in the UNITE platform provides its own user interface if desired. Thus, from the user’s perspective, UNITE appears as a network of web sites. The homebase serves as the entry point; single sign-on is supported throughout the sites a user has access to. Although there is a strict separation of user interfaces belonging to different work contexts in a technical sense, integration is possible in the user’s perception. In particular, elements of the homebases user interface, that is, personal

310

Michael Zapf et al.

Fig. 3. UNITE project portal

tools and services, can be embedded in any team user interface, provided the Personal Representative carries URLs of them to the team place. In contrast, Room Places do not offer similar user interfaces; they are only accessible via the agents that migrate to them. From the agent system perspective, the user interface is regarded as an external entity interacting with Place Users inside. This enables the UNITE platform to support other user interface technologies besides plain Web interfaces, e.g. Java applets continuously interacting with platform components or dedicated client software components. The user interfaces are implemented in three layers. The gateway between the inner platform and the outer world is the UIService. It provides a call-level API to an AMETAS place of the UNITE platform. Its methods can be called remotely through an RMI-like scheme. Method calls from outside generally lead to one or more messages being sent to place users inside. Return values are retrieved from response messages sent back to the UIService. Besides this translation between the communication paradigms of remote method invocation (outside) and asynchronous messaging (inside the platform), the UIService also performs the task of a firewall, and user session management. What messages can be sent into the platform is controlled there and message contents can be controlled as well. An authenticated session ID is required for all API operations except those supporting login. This session ID serves as a reference to the user ID. On top of UIService’s API there is the server-side presentation layer. It consists of servlets and eXtensible Server Pages (XSP) [6] which are accessed through HTTP and in turn access the platform API. XSP produce an abstract XML representation of the user


311

interface, which is then translated into client-specific formats like HTML for standard Web browsers or WML for handheld WAP devices. Such client-side components form the third layer of the user interface, accessing the server side through HTTP. This protocol is also the preferred method of attaching client-side applets or applications to the platform since it is available virtually everywhere, even behind many firewalls. 4.2

Service Adapters

Since a key feature of the UNITE platform is integration of existing tools and services, agents have to interact with such external entities. This is achieved through service adapters. AMETAS offers the concept of services for interfacing with the outer world. A service is a Place User that can, if possessing appropriate permissions, perform arbitrary actions outside AMETAS, e.g. open network connections or access files. It is therefore natural to represent external tools and services by AMETAS services inside a place. Besides mere representation,AMETAS services perform role-based access control for the service they represent, single sign-on, and abstraction. Though there are several different implementations of each kind of tool, e.g. a synchronous collaboration service or a calendar tool, there is only one abstract AMETAS service interface for each type. A lower level of abstraction is buried inside the AMETAS services. There, similar services are encapsulated under unified interfaces at the Java class level as far as possible. The difference between these two levels of abstraction is that Place Users, and thus AMETAS services in particular, can be exchanged without any code modifications and even at runtime, while class-level abstraction is helpful mainly in the implementation phase. 4.3

Support Applications

The integrative architecture of UNITE allows for embedding external tools in a simple way: Using the service adapters, the agents need not distinguish between different flavors of a service of the same kind. The user is presented the well-known interface of the service, while the agents communicate on an abstract level. Moreover, different kinds of services are accessed via the adapters in a uniform way, thanks to the messaging system in the AMETAS infrastructure. The UNITE platform distinguishes between a private portal which the user enters on initial login and a project portal which the user accesses after being authenticated to one of the accessible teams. Many of the applications available in the private portal (representing the user’s private context) are also available in the team contexts. The tools currently made accessible to the UNITE user comprise the following applications: – Message center: Unified view to different kinds of messages (including a voice portal). The message center accesses one or more E-Mail accounts of the respective user. – Document repository: Providing access to the repository of documents. Currently, the BSCW document management system [7] is used. – Bookmarks: Web bookmarks which may be of special interest for this team. The bookmarks may be stored in a database and so provide a common view to all team members.

312

Michael Zapf et al.

– Calendar: Common team calendar. Team members may schedule meetings or other events and enter them in the team calendar. Users may confirm dates which are then copied to their private calendar. Calendar servers range from simple databases to full-featured commercial calendar servers, accessible via special adapters provided by the UNITE platform. – Addressbook: Similar to the common bookmarks view, there is a common storage of addresses which are relevant to the team. Here as well, various different kinds of databases may be used, and import/export operations (e.g. via LDIF [8]) are available. Asynchronous messaging between users is possible by E-Mail and voice mail. The message center interfaces to the Java Mail API [9] and the Java Telephony API (JTAPI, [10]). On the hardware side, an IBM DirectTalk machine is used. The UNITE mail support offers a unified view by providing a special user interface. The unification is two-fold: not only may multiple mail accounts be displayed in one view, but also different kinds of messages (like standard mail or voice mail). The user may still use the well-known mail clients because the messages are kept on the server. Currently, the protocols SMTP, POP3, and IMAP are supported. 4.4 Team Collaboration Applications In addition to the previously listed applications, the teamwork support includes an integrated access to collaboration tools. Again, AMETAS services are used to launch the respective service clients on request of the team agent. The communication and collaboration services use telephony (PSTN) and IP-based networks. The following types of interactions are currently supported on these lines (some also in combinations): – – – – –

PSTN and mobile phone connections (based on IBM DirectTalk using JTAPI). Voice over IP connections (based on Lotus Sametime [11] using Sametime API). Chat connections (based on Lotus Sametime using Sametime API). Application sharing meetings (based on Lotus Sametime using Sametime API). Whiteboard meetings (based on Lotus Sametime using Sametime API).

The communication and collaboration middleware is composed of several communication and collaboration servers and services. The API exposes the functionality without getting into the details of implementation, standards, protocols etc. The implementation itself is aiming to use as many as possible standards. In order to have more than one option for implementation we chose to use standards that are implemented under the communication/collaboration API like JTAPI, JavaMail, and JMS (Java Message System, [12]). The Java Telephony API is also used for collaboration services. The Java Telephony Service Provider Interface (JTSPI), part of the JTAPI implementation, is specific to Sametime. It interacts with the Sametime server in order to send messages to the Sametime client on the user’s PC. The communication and collaboration layer is designed as a stateless mechanism. It assumes that the underlying architecture – the agent infrastructure – manages the state of


313

the team and of individual users in an appropriate, consistent way. Thus, the agents need not only keep the state and record changes, but they also need to synchronize changes between different parts of the distributed system. While the user is absent from a team, his/her Personal Agent is the central point of information for this user, collecting the changes coming from the other teams. This allows the Personal Agent to draw the user’s attention to some team where crucial changes have occured. 4.5

Security Issues

A variety of features and properties supports platform security. The AMETAS agent system cares for the infrastructural security of the platform by ensuring the integrity of mobile code and communication [13]. The user interface gateway (UIService) controls user access. It is responsible for identification and authentication of users looging in to the platform. Only authenticated users are granted access to the platform functionality. An inherent security feature is the inability to login without the Personal Agent or representative being present. In order to log in to a homebase under some user ID, a Personal Agent for that user ID has to be present there. Otherwise there is no way to get an authenticated session. In order to enter a team place, a Personal Representative of the user has to be present there, and the team agent has to acknowledge this particular instance of a Personal Representative. The connection of the user to the Personal Agent is secured using the https protocol between the browser and the UIService which employs the SSL protocol [14]. Access control is performed as a local function of each place. This is an implication of the distributed nature of the platform, and of distributed responsibility and ownership. On the place, access control is enforced by each service individually. UNITE employs a simple role-based access control scheme [15]. The access control administration follows a decentralized approach by defining one security administrator role per place. This decentralized approach is preferred to a centralized security infrastructure which would weaken the distributed nature of the platform architecture. The UNITE platform does not address the danger of hostile hosts and hostile agents. One one hand, the AMETAS infrastructure ensures that only agents which were signed by a trustful signer in the agent system may enter any place in the system. On the other hand, we believe that there is some degree of responsibility of the maintainers of such an agent environment to check whether the participants are trustful or not.

5


Cooperative Workplaces are environments that facilitate and support collaborative work. They provide for easy communication between co-workers and for easy coordination (e.g. by means of supporting peripheral awareness) of their individual activities. In addition, they provide for collaborative work among co-workers. The ultimate goal of UNITE is to strive for a comprehensive cooperation platform, which is based on basic building blocks and services provided by heterogeneous tools. Such a cooperative workplace develops and dissolves with the progress of a project, is ubiquitous, i.e. accessible from virtually anywhere, and is integrated with respect to different contexts of

314

Michael Zapf et al.

work, virtual and physical workspaces, and established and emerging tools. Furthermore, it allows for awareness with respect to the progress of project related work, the current activities of other project members, and the availability of other project members and allows for adaptation and personalization not only through a personalized portal but also through the arrangement of tools and resources, and opportunities to adapt the look and feel of the workspace. The current state of the project is that the Basic Platform (the user interface of which has been shown in this article) is completed and that it passed the user trials. We are currently implementing the Enhanced Platform which realizes nearly all architectural issues introduced in this article. However, as stated, some features will probably stay for future extension, like a full-featured interaction with rooms and facilities management.

Acknowledgement This project is funded by the EU under the Information Society Technologies (IST) Programme (Project No. IST-2000-25436). The UNITE consortium is led by IBM France (F), for project management, and the Fraunhofer Institute SIT (D), for technical direction. The Fraunhofer IAO Institute (D) and Coventry University (UK) are cooperating on user requirements elicitation and user evaluation, with the primary user input throughout coming from consultancy company Pentascope (NL). Together, Fraunhofer-SIT, IBM Haifa Research Laboratory (IL), ADETTI (P), and Steria (F) are developing the platform architecture and prototype. For further details on UNITE see also [1]. This paper was supported by the IST UNITE project; however, it represents the view of the authors only.

References 1. UNITE consortium: The UNITE homepage. http://www.unite-project.org/ 2. K. Bahr, H.-J. Burkhardt, R. Reinema et al.: Integrating Virtual and Real Work Environments. Proceedings of the IEEE SoftCOM’99 conference, Split, Croatia, October 1999. 3. R. Reinema, K. Bahr, H.-J. Burkhardt et al.: Cooperative Rooms – Symbiosis of Real and Virtual Worlds. Proceedings of the 8th International Conference on Telecommunication Systems, Modelling, and Analysis; Nashville, Texas, March 2000 4. R. Reinema, K. Bahr, M. Baukloh et al.: Cooperative Buildings – Workspaces of the Future. Proceedings of the World Multiconference on Systemics Cybernetics and Informatics (SCI’98); Orlando, USA 1998. 5. M. Zapf, K. Herrmann: AMETAS web site. http://www.ametas.de/ 6. The Apache Software Foundation: Cocoon 2 User Documentation – XSP. http://xml.apache.org/cocoon/userdocs/xsp/index.html 7. OrbiTeam: The BSCW homepage. http://www.orbiteam.de/. 8. G. Good: The LDAP Interchange Format - Technical Specification. IETF RFC 2849, http://www.ietf.org/rfc/rfc2849.txt. 9. Java Mail API. http://java.sun.com/products/javamail/ 10. Java Telephony API. http://java.sun.com/products/jtapi/ 11. IBM Corporation: Lotus Sametime. http://www.lotus.com/products/lotussametime.nsf /wdocs/homepage. 12. Sun Microsystems: Java Message Service API. http://java.sun.com/products/jms/


315

13. M. Zapf, H. Müller, K. Geihs: Security Requirements for Mobile Agents in Electronic Markets. Trends in Distributed Systems for Electronic Commerce – International IFIP/GI Working Conference, TREC’98, Hamburg 14. A. O. Freier, P. Karlton, P. C. Kocher: The SSL Protocol Version 3.0 Internet Draft, Netscape Communications Corp. http://home.netscape.com/eng/ssl3/ssl-toc.html, March 1996 15. R. Sandhu, D. Ferraiolo, R. Kuhn: The NIST model for role-based access control: Towards a unified standard. Proceedings of the fifth ACM workshop on Role-based access control, Berlin, Germany 2000.

Author Index

Ahmed, Mohamed, 119 Ametller, Joan, 182 Anagnostou, Miltiades, 292 Anzai, Yuichiro, 128

Lee, Seongkee, 58 Liotta, Antonio, 151 Liscano, Ramiro, 105 Lopes, Rui Pedro, 11

Barba, Antonio, 94 Baude, Fran¸coise, 227 Bellido, Luis, 292 Bohoris, Christos, 151 Borrell, Joan, 182

Michalas, Angelos, 193 Mir, Joan, 182 Montilla Bravo, Alberto, 216 Mota, Telma, 193, 249

Collier, Martin,

Oliveira, José Luis, 11 Olougouna, Edgar A., 281

Nalla, Amar,

206

Davidsson, Paul, 239 Delgado, Jaime, 21 Dharmalingam, Kalaiarul, Dillenseger, Bruno, 48

206

Galis, Alex, 249 Gallego, Isabel, 21 Garc´ıa, Roberto, 21 Garc´ıa Valls, Marisol, 216 Gil, Rosa, 21 Glitho, Roch H., 281 Gonzalez-Valenzuela, Sergio, 141 Gouveris, Stylianos, 193, 249 Gray, Tom, 105 Han, Sunyoung, 83 Harroud, Hamid, 119 Hazard, Laurent, 48 Helal, Abdelsalam, 33 Helin, Heikki, 1 Impey, Roger, Imre, Sandor,

119 163

Johansson, Stefan,

239

Kaltabani, Anastasia, 292 Karmouch, Ahmed, 105, 119 Khedr, Mohamed, 105 Kim, Insu, 83 Kim, Keecheon, 83 Kim, Taiyun, 58 Korba, Larry, 171 Kristell, Martin, 239 Laukkanen, Mikko, 259 Lee, Hyukjoon, 83

33

Pavlou, George, 151, 193 Pierre, Samuel, 281 Psoroulas, John, 193 Reinema, Rolf, 302 Renganarayanan, Vidya, 33 Reuter, Emmanuel, 227 Robles, Sergi, 182 Rossier, Daniel, 73 Sánchez, Ernesto, 94 Satoh, Ichiro, 128 Scheurer, Rudolf, 73 Seitz, Jochen, 269 Song, Ronggong, 171 Strimpakou, Maria, 292 Sugar, Robert, 163 Sygkouna, Irene, 292 Tagant, Anne-Marie, 48 Tarkoma, Sasu, 259 Toivonen, Santtu, 1 Türpe, Sven, 302 Umezawa, Takeshi,

128

Valera, Francisco, 292 Vazquez, Enrique, 292 Vuong, Son T., 141 Wang, Zhou, Wolf, Ruben,

269 302

Yang, Kun, 249 Yee, George, 171 Zapf, Michael,

302

Mobile Agents for Telecommunication Applications: 4th International Workshop, MATA 2002 Barcelona, Spain, October 23-24, 2002, Proceedings

Mobile Agents for Telecommunication Applications: Second International

Mobile Agents for Telecommunication Applications

Mobile Agents for Telecommunication Applications, 2 conf., MATA 2000

Graph Transformation: First International Conference, ICGT 2002, Barcelona, Spain, October 7-12, 2002, Proceedings

Mobile Agents for Telecommunication Applications: 5th International Workshop, MATA 2003, Marakech, Morocco, October 8-10, 2003, Proceedings

Cooperative Information Agents VI: 6th International Workshop, CIA 2002, Madrid, Spain, September 18 - 20, 2002. Proceedings

Mobile Agents for Telecommunication Applications: Third International Workshop, MATA 2001, Montreal, Canada, August 14-16, 2001. Proceedings

Distributed Computing: Mobile and Wireless Computing, 4th International Workshop, IWDC 2002, Calcutta, India, December 28-31, 2002, Proceedings

Scientific American (October 2002)

Learning Classifier Systems: 5th International Workshop, IWLCS 2002, Granada, Spain, September 7-8, 2002, Revised Papers

Information Hiding: 5th International Workshop, IH 2002, Noordwijkerhout, The Netherlands, October 7-9, 2002, Revised Papers

Object-Oriented Technology. ECOOP 2002 Workshop Reader: ECOOP 2002 Workshops and Posters, Málaga, Spain, June 10-14, 2002, Proceedings

Artificial Neural Networks - ICANN 2002: International Conference, Madrid, Spain, August 28-30, 2002. Proceedings

Artificial Neural Networks - ICANN 2002: International Conference, Madrid, Spain, August 28-30, 2002. Proceedings

Distributed Computing: 16th International Conference, DISC 2002. Toulouse, France, October 28-30, 2002, Proceedings

Flexible Query Answering Systems: 5th International Conference, FQAS 2002. Copenhagen, Denmark, October 27-29, 2002, Proceedings

Embedded Software: Second International Conference, EMSOFT 2002, Grenoble, France, October 7-9, 2002. Proceedings

Infrastructure Security: International Conference, InfraSec 2002 Bristol, UK, October 1-3, 2002 Proceedings

Advances in Information Systems: Second International Conference, ADVIS 2002, Izmir, Turkey, October 23-25, 2002. Proceedings

Articulated Motion and Deformable Objects: Second International Workshop, AMDO 2002, Palma de Mallorca, Spain, November 21-23, 2002, Proceedings

Innovative Internet Computing Systems: Second International Workshop, IICS 2002, Kuhlungsborn, Germany, June 20-22, 2002: Proceedings

Frontiers of Combining Systems: 4th International Workshop, FroCoS 2002, Santa Margherita Ligure, Italy, April 8-10, 2002. Proceedings

Multimedia, Telecommunications, and Applications: Third International COST 237 Workshop, Barcelona, Spain, November 25 - 27, 1996, Proceedings

Advanced Internet Services and Applications: First International Workshop, AISA 2002, Seoul, Korea, August 1-2, 2002. Proceedings

2002)

2002)

2002)

2002)

2002)

2002)

Mobile Agents for Telecommunication Applications: 4th International Workshop, MATA 2002 Barcelona, Spain, October 23-24, 2002, Proceedings

Mobile Agents for Telecommunication Applications: Second International