Embed Size (px)
Citation preview
Royal Institute of Technology
A Mobile Agent Based-Service Architecture for Internet Telephony
Roch H. Glitho
A thesis submitted toThe Royal Institute of Technology In partial fulfilment of the requirements forThe Doctor of Technology degree
April 2002
TRITA-IT-R:02:01ISSN 1403-5286ISRN KTH/IT/AVH-02/01--SE
Department of Microelectronics and Information Technology
AbstractInternet Telephony defined as real time voice or multimedia communications over packet switchednetworks dates back to the early days of the Internet. ARPA’s Network Secure Communications projecthad implemented, as early as December 1973, an infrastructure for local and transnet real time voicecommunication. Two main sets of standards have emerged: H. 323 from the ITU-T and the sessioninitiation protocol (SIP) from the Internet Engineering Task Force (IETF). Both include specifications forvalue added services. Value added services, or more simply services, are critical to service providers’survival and success. Unfortunately, the service architectures that come with the ITU-T and the IETF setsof standards are rather weak. Although they are constantly evolving, alternatives and complements need tobe researched. This thesis which is made up of a formal dissertation and 6 appendices, proposes a novelmobile agent based service architecture for Internet Telephony. The architecture addresses the issues noneof the existing architectures solves in a satisfactory manner. Furthermore it adds mobile agents to thepanoply of service creation tools. The appendices are reprints of articles published in refereedmagazines/journals or under consideration for publication. The formal dissertation is a summary of thepublications. A consistent and comprehensive set of requirements are derived. They are TINA-C flavored,but adapted to Internet Telephony. They are used to critically review related work and also used tomotivate the use of mobile agents as the pillars of a novel architecture. The components of this novelarchitecture are identified. The key component is the mobile service agent. It acts as a folder and carriesservice(s) to which the end-user has subscribed. Mobile service agents need to be upgraded when newversions of service logic are available and when end-users make changes to service data. This thesisproposes a novel upgrading framework. The current Internet infrastructure comprises a wide range ofhosts. Mobile agent platforms are now available for most of these hosts/clients including memory /processing power constrained PDAs. Our mobile service agents need to adapt to host variability whenroaming. A novel adaptivity framework is also proposed. These two frameworks are general and can beapplied to any other mobile agent which meets a basic set of assumptions. A key advantage of a mobileagent based service architecture is that it enables the developement of mobile agent based services. Thethesis proposes a novel mobile agent based multi-party session scheduler. The feasibility and theadvantages of the architecture proposed by this thesis have been demonstrated by a prototype on whichmeasurements have been made. Future work includes the addition of a security framework to thearchitecture, and refinenements to the upgrading and adaptivity frameworks. More mobile agent basedservices, especially mobile multi agent based services will also be developed.
Acknowledgements
I am indebted to Professor Gerald Q. Maguire Jr. from the Royal Institute of Technology, Stockholm,Sweden, for having accepted me as industrial doctoral student. I would like to thank him for his patienceand his guidance. I am also indebted to Professor Ahmed Karmouch from the University of Ottawa,Canada, for his comments on the draft manuscript. Professor Yechiam Yemini (YY) from ColumbiaUniversity, New York is not to be forgotten. I would like to thank him for his support at the very earlystages of this thesis. I still remember him telling me at a breakfast in New Orleans, Louisiana, "Do not getoverwhelmed, you will make it!"
This thesis is based on articles that have either been published in internationally refereed journals or arebeing considered for publication. I would like to thank all the anonymous reviewers for their comments.They have helped in improving the quality of the articles, thus the quality of the thesis. The administrativeassistance of Ann Myrand (Ericsson Research Canada) in formatting the manuscript was invaluable. Mygratitude goes to her, especially as she has kept her smile, despite the very tight deadlines.
"The formulation of a problem is more essential than asolution, which may be merely a matter of mathematical orexperimental skill. To raise new questions, new possibilities, toregard old questions from a new angle, requires creativeimagination and marks real advances".
Albert Einstein
The Evolution of Physics, 1938
TABLE OF CONTENTS
1. INTRODUCTION...................................................................................................................... 2
1.1 Background ................................................................................................................................... 21.1.1 Internet Telephony.................................................................................................................. 21.1.2 Service Architecture ............................................................................................................... 31.1.3 Mobile agents ......................................................................................................................... 4
1.2 Contributions and Outline ........................................................................................................... 5
1.3 Overview of My Publications....................................................................................................... 6
2. REQUIREMENTS, RELATED WORK AND MOTIVATIONS................................................ 10
2.1 Proposed Requirements ..............................................................................................................10
2.2 Emerging ITU-T and IETF Specifications ................................................................................102.2.1 H. 323 Service Architecture...................................................................................................102.2.2 SIP Service Architecture........................................................................................................112.2.3 An Evaluation ........................................................................................................................12
2.3 Alternatives ..................................................................................................................................122.3.1 IN Based Service Architectures for Internet Telephony........................................................122.3.2 An Evaluation ........................................................................................................................13
2.4 Justification for Mobile Agent Based Architectures.................................................................132.4.1 The Precursors .......................................................................................................................132.4.2 Motivating Mobile Agent Based Service Architectures for Internet Telephony ...................13
2.5 Conclusions ..................................................................................................................................14
3. THE COMPONENTS AND INTERFACES ............................................................................ 16
3.1 A System View .............................................................................................................................163.1.1 Mobile Service Agents ..........................................................................................................173.1.2 Service Management Units....................................................................................................173.1.3 Interfaces ...............................................................................................................................17
3.2 An Implementation View ............................................................................................................183.2.1 Software Architecture............................................................................................................183.2.2 Prototype................................................................................................................................19
Conclusions ..................................................................................................................................................20
4. UPGRADING MOBILE SERVICE AGENTS ......................................................................... 23
4.1 Requirements and related work .................................................................................................23
4.2 Our Framework: Two Schemes..................................................................................................234.2.1 Agent Swapping ....................................................................................................................244.2.2 Self Upgrading.......................................................................................................................24
4.3 Our Framework: Prototypes and Measurements .....................................................................254.3.1 Agent Swapping ....................................................................................................................254.3.2 Self Upgrading.......................................................................................................................26
4.4 Conclusions ..................................................................................................................................27
5. ADAPTING MOBILE SERVICE AGENTS TO HOST VARIATION....................................... 29
5.1 Requirements and Related Work...............................................................................................29
5.2 Framework: Components ...........................................................................................................29
5.3 Measurements ..............................................................................................................................315.3.1 Inter-partition Communication ..............................................................................................315.3.2 Partitioning ............................................................................................................................315.3.3 Re-assembly...........................................................................................................................325.3.4 Memory Usage ......................................................................................................................32
5.4 Conclusions ..................................................................................................................................33
6. A MOBILE AGENT BASED MULTIPARTY EVENT SCHEDULER...................................... 35
6.1 Background ..................................................................................................................................356.1.1 Problem Statement.................................................................................................................356.1.2 Related Work.........................................................................................................................356.1.3 Expected Benefits ..................................................................................................................36
6.2 The Prototype...............................................................................................................................366.2.1 The Mobile Agent Based Multiparty Event Scheduler ..........................................................366.2.2 The Counterparts Client/Server Applications ........................................................................38
6.3 The Measurements ......................................................................................................................396.3.1 Network Load Data Analysis.................................................................................................396.3.2 Response Time Data Analysis ...............................................................................................40
6.4 Conclusions ..................................................................................................................................41
7. CONCLUSIONS..................................................................................................................... 43
7.1 Summary of the Contributions...................................................................................................437.1.1 A Comprehensive Set of Requirements for Service Engineering in Internet Telephony.......437.1.2 Components for a Novel Mobile Agent Based Service Architecture ....................................437.1.3 A Novel Framework for Upgrading Mobile Service Agents .................................................447.1.4 A Novel Framework for Adapting Mobile Service Agents to Host Variation.......................447.1.5 A Novel Mobile Agent Based Multiparty Event Scheduler...................................................45
7.2 Items for Further Work ..............................................................................................................457.2.1 Security..................................................................................................................................457.2.2 Refinements to the Upgrading Framework............................................................................457.2.3 Refinements to the Adaptability Framework.........................................................................467.2.4 Multi-Mobile Agent Based Services......................................................................................46
LIST OF TABLES AND FIGURES
TABLES
Table 2. 1: Evaluation of H. 323 and SIP service architectures..............................................................12
Table 2.2: Evaluation of IN-Based Service Architectures......................................................................13
FIGURES
Figure 3. 1: Simplified View of the Architecture .....................................................................................16
Figure 3. 2: MSA Software Architecture..................................................................................................18
Figure 3. 3: SMU Software Architecture..................................................................................................19
Figure 3. 4: The Time it Takes to Construct an MSA of an Increasingly Big Size ...............................20
Figure 4. 1: The Upgrading Framework ..................................................................................................24
Figure 4. 2: The Time to Dispatch Back and Forth an MSA of an Increasing Size using Voyager ....25
Figure 4. 3: Response Time as a Factor of the Number of Clones..........................................................26
Figure 4. 4: Response Time........................................................................................................................27
Figure 5. 1: A Simplified Framework .......................................................................................................30
Figure 5. 2: Inter-Partition Communication Time ..................................................................................31
Figure 5. 3: Memory Required for Instantiation .....................................................................................32
Figure 5.4: Memory Required after Instantiation....................................................................................32
Figure 6. 1: High Level Architecture ........................................................................................................36
Figure 6. 2: Software Architecture ...........................................................................................................37
Figure 6. 3: Implementation View of the Optimized Client/Server........................................................38
Figure 6. 4: Network Load for the Average Case Scenario (I = M/2 = 15th day) ..................................39
Figure 6. 5: Response Time for the Worst Case Scenario (I = M = 30th day) ........................................40
1
CHAPTER 1
2
1. INTRODUCTION
Internet Telephony defined as real time voice or multimedia communications over packet switchednetworks (PSN) is no longer novel. The very first phone call over a PSN was made in December 1973 aspart of the Network Secure Communications project ran by the Advanced Research Projects Agency(ARPA). The project implemented an infrastructure for local and trans-net real time voicecommunications. The chief objective of Network Voice Protocol (NVP) [13], the heart of theimplementation, was to demonstrate the feasibility of secure, high quality, low bandwidth, real time, twoparty phone calls over a PSN.
Advanced services, or more simply services, can be defined as anything that goes beyond two party voicecalls. They are differentiating factors and are critical to service providers’ success and survival. They areusually grouped under two umbrellas: telephony services and non-telephony services. Telephony servicesinteract with call control. Some examples are originating call screening and call diversion. Non-telephonyservices do not involve call control. They include customised stock quotes and surfing from a cellularphone. In this introduction, I give background information, sketch my contributions, outline the thesis andgive a very brief overview of the papers I have published as part of this research work.
1.1 Background
This thesis is built around three concepts: Internet Telephony, service architecture and mobile agents.
1.1.1 Internet Telephony
Although the very first voice call over a PSN was made in the early 70s, widespread standards did notemerge until the mid-90s. Two sets of standards have emerged: H. 323 from the ITU-T, and the sessioninitiation protocol (SIP) from the Internet Engineering Task Force (IETF).
Recommendation H. 323 [52] is the principal standard of the H. 323 set. It is an umbrella standard thatrefers to many other standards. It was first released in 1996, then subsequently in 1998, 1999, and 2000.The SIP Request for Comments (RFC) [42] is the principal IETF proposed standard for Internet Telephony.It was released in 1999 and relies on many other IETF specifications.
As is customarily done in this industry, in this thesis we use H. 323 to refer to the set of ITU-Trecommendations for Internet Telephony, including the H. 323 recommendation itself, and SIP to refer tothe set of IETF specifications for Internet Telephony including the SIP RFC. Several tutorials have beenpublished on H. 323 [88,120,121] and SIP [8,108,110,111]. The next paragraphs provide a cursoryintroduction.
The components of H. 323 are the terminal, the gatekeeper, the gateway, and the multi-point control unit.A terminal is an end-point that caters to real time two-way multimedia communications with another H.323 terminal. The gatekeeper controls how the terminals access the network and provides addresstranslation functionality. The gateway is an end point in the H. 323 network that provides two-waycommunications between H. 323 terminals and terminals in the public switched telephone networks. Themulti-point control unit is an end-point that provides centralised conferencing functionality.
The signalling and control protocols of H. 323 are described in Recommendations H. 225. 0 [50], Q. 931[64], and H. 245 [51]. H. 225. 0 is used between end points and gatekeepers. It allows an end-point toregister with the gatekeeper, to request call admission and bandwidth allocation, to inquire about the statusof other end-points. It also allows end points to discover the gatekeeper. It is used only when there are
3
gatekeepers in the network. Q. 931 is the call signalling protocol. H. 245 is used for connection control. Itallows end points to negotiate media processing capabilities.
The components of SIP are the user agent, the registrar, the proxy server, and the redirect server. Useragents initiate requests and are usually the final destination of requests. Registrars keep tract of userswithin their domains. Proxy servers are application level routers that forward SIP requests and methods. Aredirect server redirects requests to the location of a user agent, or a proxy server that knows where the usermay be found.
The main signalling and control protocols of SIP are the SIP RFC itself and the session description protocol(SDP) [43]. SIP is used to set up, modify, and tear down sessions. SDP is used to describe multimediasessions. Other examples of IETF protocols that are part of SIP are the real time protocol (RTP) [107] andthe session announcement protocol (SAP) [44]. RTP transports audio, video and other real time sensitivedate. SAP announces multicast sessions.
1.1.2 Service Architecture
Service architecture can be defined as set of concepts, rules, and principles to support the service life cycle.The concept of a service life cycle was introduced by TINA-C [126]. There are four phases in this cycle:construction, deployment, utilisation, and withdrawal. They are briefly outlined below.
� The construction phase allows a refinement of the activities related to what is traditionally calledservice creation. Service requirements specification, service logic design, and service logic testingare included in this phase. In this thesis we will stick to the traditional terminology and use servicecreation instead of service construction.
� Service deployment includes service planning, installation, and activation (at the network level). Inclassical telephony, services need to be activated at the network level prior to their activation forspecific end users. This is not the case in Internet Telephony where services are applicationsrunning on either end users' devices or servers residing at the edges of the network. Activation anddeactivation are done at the edges of the network, generally at the server level.
� Service withdrawal encompasses deactivation at the network level and eventual removal from thenetwork. In Internet telephony, activation and deactivation are done at the edges of the network,generally at server level.
� Users need to subscribe to most services in order to use them. These services can be activated or de-activated. Activation and deactivation for specific users are part of service utilization. Serviceutilization also includes service execution. A specific aspect of service execution in InternetTelephony is termed in this thesis, service execution related signaling. It comprises the messagesexchanged by Internet Telephony entities as part of service execution, but also includes the rules andprocedures that govern this exchange.
In the early days of telephony, there was no service architecture. Service implementation was embedded inswitching software and all the phases of the life cycle suffered. Creation and deployement were slow,while utilisation and withdrawal difficult. The intelligent network (IN) architecture [65] was the very firstservice architecture that emerged for telephony. It emerged in the 1980s and stipulate the implementationof services in separate and dedicated nodes. IN remains the most comprehensive service architecture forcircuit switched telephony.
4
1.1.3 Mobile agents
Several tutorials [11,73,78,101] have been published on mobile agents. A mobile agent is a program thatcan start execution in a node, stop execution, then move to another node to resume execution. Theexecution requires a special execution environment known as agent execution environment or platform.Proponents of mobile agents claim scores of advantages. However, there are many hindrances to their widescale deployment.
Mobile agent platforms provide the basic facilities:
� Mobility – This is used for the transportation of the agent between physical nodes
� Communications – This is used for the communication of the agent with the external world
� Naming and location – Mobile agents like all entities need to be named. Furthermore it is importantto know at which nodes they are at any given time.
� Security: Mobile agents need to be protected against hosts and hosts need to be protected againstmobile agents.
Nowadays, most mobile agent platforms are implemented as Java applications that run on top of operatingsystems. Attempts have been made in the past to implement platforms as extensions to operating systems,but they were not very successful. Some examples of commonly used platforms are Aglets [47],Grasshopper [48] and Voyager [95].
Some examples of claims are given below.
� Mobile agents can continue roaming and working on behalf of users even when users aredisconnected.
� Mobile agents can improve performance compared to the client/server approach, if specificconditions are met.
� Mobile agents make programming easy because they allow an intuitive and natural representation ofmany applications.
� Mobile agents allow easy customisation of applications.
Mobile agents have so far been mainly used in experimental settings. The deployment has been hinderedby two main factors:
� The lack of maturity – Although the technology has been around for a few years, some technicalissues such as security have not yet been solved in a satisfactory manner.
� The lack of interoperability standards. The Object Management Group (OMG) has produced aspecification, known as MASIF (Mobile Agent System Interoperability Framework) [96]. Howevermost of today’s mobile agent platforms do not support it. As a consequence, they cannot inter-operate.
5
1.2 Contributions and Outline
The main contributions of this thesis are outlined below:
1. A comprehensive set of architectural requirements for service engineering in Internet Telephony. Theyare TINA-C flavoured. I have introduced them in section 2 of reference [29]. I have used them asbasis for a critical review of related work in section 3 and 4 of reference [29], and in sections 2 and 3of reference [31]. I have also used them to motivate the use of mobile agents as the cornerstones of anovel architecture in section 2 of reference [35].
2. A novel mobile agent based – architecture that meets the proposed requirements. Its components arethe mobile service agent (MSA), the service management unit (SMU), and the service creation unit(SCU). The key component is the MSA. It acts as a folder and carries the services to which the end-user has subscribed. I have presented a system view and an implementation view of this architecture insections 3 and 4 of reference [35]. References [27,118,119] describe the very early versions.
3. A novel framework for upgrading mobile agents. The MSA needs to be upgraded when new versionsof service logic are available and when end-users make changes to service data. I have presented thisframework in sections 4 and 5 of reference [36]. It includes two schemes. In the first, the MSA isswapped with a new MSA and in the second, the MSA upgrades itself. Early versions of theseschemes are described in references [2,30]. The framework is general and can be applied to any othermobile agent, provided that the agent meets the basic set of assumptions I have made in section 4 ofreference [36].
4. A novel framework for adapting mobile agents to host variation. Adapting the MSA to host variationis required because end-users will have a wide range of devices for use with Internet Telephony. Theframework is presented in sections 4 and 5 of reference [37]. The components of the framework arethe partition storage agent, the partition selector, and the partition dispatcher. Although the frameworkhas the MSA as its prime target it is general and can be applied to any other mobile agents, providedthe agent meets the basic set of assumptions I have made in section 3 of reference [37].
5. A novel mobile agent based - multiparty event scheduler. A key advantage of the novel architecture isthat it enables the development of mobile agent based-services. This scheduler is presented as a casestudy on mobile agent base information retrieval in sections 3,4, and 5 of reference [38]. I have used itto show that mobile agent based - information retrieval applications can outperform their client/servercounterparts, even when the evaluation is not biased in favour of mobile agents, as is usually done.
The chapters of this thesis are introduced below.
� Chapter 2 is based on appendices A and B. It derives the TINA-C flavoured requirements, reviewsrelated work, and motivates the use of mobile agents, as the pillars of a novel architecture. Therelated work encompasses the ITU-T, the IETF and the IN based service architectures for InternetTelephony.
� Chapter 3 is based on appendix C. It introduces the components of the novel architecture and showshow they aid in meeting the requirements. Both the system and the implementation views arepresented. The prototype is described.
� Chapter 4 is based on appendix D. It presents the framework for upgrading the MSA. It derivesrequirements and introduces the agent swapping and the self-upgrade schemes. The measurementsmade are presented.
6
� Chapter 5 is based on appendix E. It is devoted to the novel framework for adapting the MSA tohost variation. It derives requirements, identifies the components and describes the algorithms. Theperformance measurements made are presented.
� Chapter 6 is based on appendix F. It is devoted to the novel mobile agent based multiparty eventscheduler. The semantics of the application is described, and the implementation architecturepresented. This implementation is contrasted to the client/server counterparts and the measurementsmade are presented.
� Chapter 7 concludes and identifies the items for further work. These items include the addition ofsecurity to the architecture, the refinements of the adaptability and upgrading frameworks, and thedevelopment of mobile multi-agent based services.
The following papers make up the appendices:
� Appendix A: R. H. Glitho, Advanced Service Architectures for Internet Telephony: A CriticalOverview, IEEE Network Magazine, July/August 2000, Vol. 14 No. 4, pp. 38-44
� Appendix B: R. H. Glitho, Alternatives to Today’s IETF and ITU-T Advanced ServiceArchitectures for Internet Telephony: IN and Beyond, Elsevier Computer Networks 35 (2001), April2001, pp. 551-563
� Appendix C: R. H. Glitho, MARITA: A Novel Mobile Agent based Service Architecture forInternet Telephony, Elsevier Computer Networks, submitted
� Appendix D: R. H. Glitho, Mobile Agents and Their Use for Service Engineering: A NovelUpgrading Framework, IEEE Transactions on Software Engineering, submitted
� Appendix E: R. H. Glitho, S. Methot and S. Pierre, A Novel Framework for Adapting MobileAgents to Host Variation, ACM Transactions on Internet Technology, submitted -
� Appendix F: R. H. Glitho, E. Olougouna and S. Pierre, Using Mobile Agents for InformationRetrieval: A Brief Overview and an Elaborate Case Study, IEEE Network Magazine,January/February 2002, pp . 34-41
My contribution to the appendices with multiple authors is stated in the next sub-section. The sub-sectionlists all the papers I have published as part of this research work.
1.3 Overview of My Publications
Four referred journal papers (including three of the appendices) and four refereed conference/workshoppapers that I have authored/co-authored as part of this research work have already been published.Furthermore three other papers (the remaining three appendices) are currently being considered forpublication in refereed journals. All these papers are listed below with a very brief summary of the content.My contribution to the papers with multiple authors is also clearly stated.
� R. H. Glitho, Advanced Service Architectures for Internet Telephony: A Critical Overview,IEEE Network Magazine, July/August 2000, Vol. 14 No. 4, pp. 38-44
In this paper, I derive a consistent set of architectural requirements for services in Internet Telephony.They are used to critically evaluate the services architectures that come with H. 323 and SIP. Therequirements that are not met are identified. IN and mobile agents are also identified as potential pillars fornovel architectures.
7
� R. H. Glitho Alternatives to Today’s IETF and ITU-T Advanced Service Architectures forInternet Telephony: IN and Beyond, Elsevier Computer Networks 35 (2001), April 2001, pp.551-563
In this paper, I introduce IN, the emerging IN based service architectures for Internet Telephony, and showthat these architectures cannot meet the requirements. I also introduce the concept of mobile agent, reviewthe mobile agent based service architectures proposed in the past for circuit switched telephony, and showthat soundly designed mobile agent based architectures can meet the requirements identified in the previouspaper.
� S. Desrochers, R. Glitho, and K. Sylla, Experimenting with PARLAY in a SIP environment:Early Results, IPTS workshop, Atlanta, July 2000, pp. 7-12
This paper explores the use of protocol neutral application programmer's interface (API) as alternative tothe service architectures that come with H. 323 and SIP. It shows that these APIs are not suitable becauseSIP and H. 323 have features that are not accessible via the APIs. I have contributed to the identification ofthese features.
� J. Tang, T. White, B. Pagurek and R. H. Glitho, Advanced service architecture for H. 323Internet Telephony Protocol, Journal of Computer Communications, April 2000, Vol. 23, No8,pp. 740-753
This paper is the very first attempt to use mobile agents as the pillars of a novel architecture. It proposes anarchitecture where all the services to which the end-user has subscribed are carried by a single MSA. Ioriginated the idea and played a leading role in the design of the architecture.
� R. H. Glitho and A. Wang, A Mobile Agent Based Service Architecture for InternetTelephony, International Switching Symposium (ISS) , Birmingham, May 2000,
This paper is the second attempt to use mobile agents as the pillars of a novel architecture. It proposes anarchitecture where the originating services are carried by an MSA and the terminating services by anotherMSA. I originated the idea, lead the design of the architecture, and supervised the prototyping activities.
� R. H. Glitho, MARITA: A Novel Mobile Agent based Service Architecture for InternetTelephony, Elesevier Computer Networks, submitted
In this paper, I propose the novel architecture. I introduce the components along with a scenario, presentthe software architecture and describe the proof-of-concept prototype that has been built. This architectureis a generalisation of the architectures proposed in the two previous papers.
� R. H. Glitho B. Lenou and S. Pierre , Handling Subscription in a mobile agent based serviceenvironment for Internet telephony: Swapping Agents, Second International Workshop onMobile Agents for Telecommunications Applications (MATA), Paris, September 2000, pp. 50-66
This paper focuses a specific aspect of the MSA upgrading problem: upgrading resulting from subscriptionto new services. Requirements are derived, schemes based on agent swapping are proposed, and the partialprototype is described along with the measurements. I have played the leading role in the design of theschemes and have supervised the prototyping activities.
� Th. Bah, S. Pierre, and R. H. Glitho, Novel Schemes for Updating Mobile Agents in VHE,International Communications Conference (ICC). New York, May 2002, accepted forpresentation
8
This paper focuses on another aspect of the MSA upgrading problem: upgrading resulting from theavailability of new versions of service logic and also from the changes made to service data by end-users.Requirements are derived, centralised and decentralised schemes are proposed, and the prototype isdescribed along with the measurements. I have played the leading role in the design of the schemes andhave supervised the prototyping activities.
� R. H. Glitho, Mobile Agents and Their use for Service Engineering: A Novel UpgradingFramework, IEEE Transactions on Software Engineering, submitted
In this paper I state the MSA upgrading problem in general terms, derive requirements, and propose a novelframework. The framework includes two schemes: agent swapping and agent self-upgrading. Theseschemes are evolved versions of the schemes described in the two previous papers. I also present theprototype and the measurements.
� R. H. Glitho, S. Methot and S. Pierre, A Novel Framework for Adapting Mobile Agents toHost Variation, ACM Transactions on Internet Technology, submitted
This paper proposes a novel framework for adapting mobile agents to host variation. The components,operations and algorithms are introduced. The framework is applied to the MSA and the prototype isdescribed along with the measurements.
I am the main contributor. The original idea of partitioning mobile agents to adapt to host variation ismine. I have contributed the assumptions, requirements and general framework. Furthermore theframework was applied to the MSA under my supervision. The prototype was built and the measurementsmade under my supervision.
� R. H. Glitho, E. Olougouna and S. Pierre, Using Mobile Agents for Information Retrieval: ABrief Overview and an Elaborate Case Study, IEEE Network, January/February 2002, pp. 34-41
This paper shows how the novel architecture can enable performance gains in terms of network load andresponse time for some classes of services - It proposes a novel mobile agent based multiparty eventscheduler and shows how it performs its client/server counterparts including the optimally designed ones.
I am the main contributor. The original idea of using mobile agents for multiparty session scheduling ismine. The same applies to the idea of building an optimised client/server counterpart. Furthermore, I havecontributed the high level architecture. The detailed architecture was designed under my supervision. Thesame applies to the prototype and the measurements.
9
CHAPTER 2
10
2. REQUIREMENTS, RELATED WORK AND MOTIVATIONS
Sound and comprehensive architectures are needed for services engineering in Internet Telephony.Specifications are emerging as part of H. 323 and SIP. Alternatives to these specifications are also beingresearched. This chapter is based on appendices A and B. It provides a critical overview of the emergingspecifications and the alternatives that are being researched. It also motivates the use of mobile agents asthe pillars of a novel architecture. I start by the requirements. The emerging specifications and thealternatives are successively reviewed after that. The last section motivates the use of mobile agents.
2.1 Proposed Requirements
The requirements are listed below. Appendix A gives more details.
1. Support of a wide range of services
2. Rapid service creation and deployment
3. Tailored services
4. Independent evolution of network and service infrastructures
5. Support for multi players environment
6. Service manageability
7. Universal access
8. Inter-working with other advanced service architectures
2.2 Emerging ITU-T and IETF Specifications
H. 323 and SIP service architectures are introduced. A critical evaluation is provided after that. AppendixA gives more details.
2.2.1 H. 323 Service Architecture
This architecture follows a “service by service” approach and focuses on the utilisation phase. The mainconcept is the supplementary service control entity. Supplementary service control entities reside in H. 323components and exchange messages in order to support supplementary services. The generic architectureis specified in Recommendation H. 450. 1 [53] while architectures for specific services are specified inseparate recommendations. Architectures have been specified so far for the following services:
11
� Call transfer [54]
� Call diversion [55]
� Call hold [56]
� Call park and pick up [57]
� Call waiting [58]
� Message waiting indication [59]
� Name identification [60]
� Call completion [61]
� Call offer [62]
� Call intrusion [63]
Call offer allows a calling party "A" encountering a busy condition with a called party "B" to camp-on tothe busy called party. What the other services do is self-explanatory.
2.2.2 SIP Service Architecture
The architecture relies on existing Internet tools, and focuses on the creation and utilisation phases.
Service creation
Three tools have been specified for service creation: The call processing language (CPL) [83,84], the SIPcommon gateway interface (CGI) [85], and the SIP servlet application programmer interface (API) [80].CPL targets end users while SIP CGI and the SIP servlet API target experienced and trusted developers.Besides these tools, header fields can be used to create services. The header fields are extensions to the SIPcore RFC. The services that can be created are currently limited to services that allow callers to expresstheir preferences about how calls should be handled [109].
Service utilisation
The architecture provides a tool kit for service execution related signalling. The kit consists of two types oftools:
� SIP request methods
� Header fields
The request methods are INVITE, BYE and OPTIONS. The header fields are either part of the core SIPRFC [42] or specified as extensions to the core RFC. Contact is an example of header field that is part ofthe SIP RFC. Some examples of header fields specified as extensions are Also, Requested-By, andReplaces [110].
12
2.2.3 An Evaluation
Table 2. 1 summarises the evaluation.
Table 2. 1 Evaluation of H. 323 and SIP Service Architectures
Requirements H. 323 SIP1. Support for a wide range of services No Yes2. Rapid service creation and deployment No Yes3. Tailored services No No4. Independent evolution of network and service infrastructures Yes No5. Support for multiparty environment No Yes6. Service manageability No No7. Universal access No No8. Inter-working with other service architectures No No
2.3 Alternatives
Two chief alternatives are emerging: the use protocol neutral application programmer interface (API) suchas PARLAY [99] and IN based - service architectures. PARLAY has been applied to Internet Telephony[14,36]. However, so far, no extension has been made to PARLAY to cater to the specifics of InternetTelephony. This makes the alternative of little interest and we do not discuss it any further in this thesis.This section focuses on the IN based service architectures for Internet Telephony. The key characteristicsof the architectures are presented first and the evaluation is made after that. Appendix B gives moredetails.
2.3.1 IN Based Service Architectures for Internet Telephony
There have been several attempts in the recent past to apply the old and well known IN architecturalprinciples to Internet Telephony [12,19,38,41,122]. IN is four-plane service architecture and severaltutorials [5,20,21,70,89] have been published on it. The planes of the IN based service architectures forInternet Telephony are briefly described below:
� The service plane remains as in the IN architecture for circuit switched networks
� In the global functional plane, the basic call processing mimics the basic call processing of circuitswitched networks.
� A new functional entity is introduced in the distributed functional plane. It is the IP serviceswitched function (IPSSF) also known as Soft service switched function (SoftSSF) [12,122].
� In the physical plane, the intelligent network application protocol (INAP) runs over IP instead ofsignalling number 7 (SS7). In the specific case of SIP, the SIP RFC can also be extended to carryINAP semantics [19].
13
2.3.2 An Evaluation
Table 2. 2 summarises the evaluation.
Table 2. 2 Evaluation of IN-Based Service Architectures
Requirements IN based1. Support for a wide range of services No2. Rapid service creation and deployment No3. Tailored services No4. Independent evolution of network and service infrastructures Yes5. Support for multiparty environment No6. Service manageability Yes7. Universal access No8. Inter-working with other service architectures No
2.4 Justification for Mobile Agent Based Architectures
The precursors from circuit switched telephony are discussed first. Then the motives for consideringmobile agents as basis for service architectures in Internet Telephony are presented second. Appendix Bgives more details.
2.4.1 The Precursors
Mobile agent based service architectures have been explored in the context of circuit switched networks[6,10]. The chief goal is to go beyond IN. The service logic that is traditionally implemented as code inService control point (SCP) is implemented as a mobile agent. These agents can clone themselves whenneeded. They can migrate to a service switching point (SSP) and interact with it locally instead of viaINAP as stipulated by IN.
These architectures introduce a large number of mobile agents in the network. There is at least one mobileagent per service. The management of these agents can become a significant issue. Besides the importantquestion of the number of mobile agents these architectures inject into the network, a key issue is that theydo not depart sufficiently from the IN paradigm. As a consequence, they inherit most of IN weaknesses.
2.4.2 Motivating Mobile Agent Based Service Architectures for InternetTelephony
The motives are detailed in section 3 of appendix B and in section 2 of appendix C. There are three criticalrequirements that none of the existing architectures meets in a satisfactory manner: tailored services, easyservice management and universal access. A mobile agent based - service architecture can aid in meetingthese requirements in an elegant and efficient manner.
Furthermore, the mobile agent infrastructure of the architecture can be re-used to develop mobile agentbased services. This will bring significant performance gain in terms of network load and response time forsome classes of services such as information retrieval based services. This gain is due to the fact that theagent can travel to the server that contains the information and perform the search at the source.
14
2.5 Conclusions
This chapter has proposed a set of requirements for service architectures in Internet Telephony. Therequirements have been used to critically evaluate the H. 323 service architecture, SIP service architecture,and IN based – service architectures. They have also been used to motivate the use of mobile agents as abasis for novel architectures. The main challenge is to design a novel architecture that avoids the pitfalls ofthe mobile agent based architectures proposed in the past for circuit switched telephony.
15
CHAPTER 3
16
3. THE COMPONENTS AND INTERFACES
The following observations are the pillars of the novel architecture:
� There is a need for a wide range of service creation paradigms in Internet Telephony
� The one-to-one-mapping between services and mobile agents, as done in the architecture for circuitswitched telephony, cannot be sustained in Internet Telephony
This chapter is based on appendix C. It introduces the components and interfaces of the architecture. Asystem view is presented first. The implementation view is presented after that. The last section presentsmy conclusions.
3.1 A System View
Figure 3. 1 depicts a simplified view of the architecture.
The key components are as follows:
� The mobile service agent (MSA),
� The service management unit (SMU)
� The service creation unit (SCU).
� Interfaces A, B, C and D
A
B
C D
Service Creation Unit Service ManagementUnit
Network Infrastructure
Figure 3. 1 - Simplified View of the Architecture
17
The SCU offers the environment required for service creation. The architecture relies on the SCU offeredby today's architectures. In addition, for the creation of mobile agent based services, it relies on thedevelopment environment offered by the mobile agent platforms. Furthermore, it can accommodate anyservice creation paradigm that may emerge in the future. We successively introduce the MSA, the SMU,and the interfaces.
3.1.1 Mobile Service Agents
The MSA reside on either a terminal or on a network server. This server can be in the service providerdomain or in the third party domain where the end-user has roamed. MSAs act as folders and carry theservices to which end-users have subscribed. In any given instantiation of the architecture, the maximumnumber of MSA per end-user is fixed. This is due to the fact that each MSA carries a specific type ofservice, and the type of services offered in any given environment, at any given time, is fixed. Allowingdifferent number of MSA in different instantiations of the architecture brings an additional degree offlexibility.
For every service, the MSA carries:
� the service logic and
� the service data
An MSA also includes a co-ordinator. The co-ordinator is the logic of the MSA itself. It allows the MSAto perform its functions. These functions include service execution, service upgrading, and MSApartitioning.
3.1.2 Service Management Units
The life cycles of the subscriber, the services to which he has subscribed, and the MSA that carries theseservices need each to be managed. This is the goal assigned the SMU. The SMU publishes through a Webpage, the list of all services to which end-users can subscribe at any given time. This list is updated everytime the SCU notifies the SMU that a new service is available. When an end-user subscribes to a service,the SMU makes it available to him.
Subscriber life cycle management is done mainly via user profile management. The profile is created thefirst time the user subscribes to service(s) and is subsequently updated. Besides the information userprofiles usually contain, this profile also contains the list of MSAs that carry the services to which the userhas subscribed. The SMU creates the MSA. Once created, next phases of their life cycle that needs to bemanaged by the SMU are roaming, upgrading and partitioning.
3.1.3 Interfaces
The main interfaces are described below.
Interface A: SCU/SMU
The SCU-SMU interface allows SCU to notify SMU of the availability of new services and the availabilityof new versions of old services.
18
Interface B: MSA /SCU
This interface allows a MSA to download executables from the SCU.
Interface C: SMU /MSA
This interface allows the SMU to manage a specific MSA.
Interface D: SMU /Network infrastructure
This interface allows the network infrastructure to notify the SMU about the end user's network location.
3.2 An Implementation View
The software architecture is presented first and the prototype second.
3.2.1 Software Architecture
We successively present the software architecture of the MSA, the SMU, and the interfaces.
3.2.1.1 The Mobile Service Agent
Figure 3. 2 depicts the MSA software architecture:
The MSA is made of two layers: the access layer, and the operation layer. The access layer allows theMSA to access the mobile agent platform in a platform independent manner. It also allows the MSA toaccess (and manipulate) the services it carries. This layer offers two applications programming interfaces(API): the platform access API and the service access API.
……… Operations …. .…
PlatformAccess API
Services
Platform Service logicService data
Access Layer
Operation Layer
Figure 3. 2 - MSA Software Architecture
The platform access API isolates the MSA from the specifics of the mobile agent platform. The serviceaccess API allows low-level operations on the services that are carried. The operation layer implements theoperations the co-ordinator requires for performing its functions.
3.2.1.2 The Service Management Unit
Figure 3. 3 depicts the SMU software architecture:
The SMU is implemented arepositories. The main reposecond layer implements the
3.2.1.3 The Interfaces
HTTP is used at the interfacuse inter-agent communicatiD are of the same type, a pinterfaces use JINI.
3.2.2 Prototype
The implementation is basedSCU is located on a PC equThe SMU is located on a Sother computers are used asprocessors. All the compute
� The MSA uses a simexecution have been i
Subsc n handler MSA Handler
Repositories
Handlers
riptio19
s a stationary agent and is made of two layers. The first layer contains thesitories are the service pointer repository and the user profile repository. The two main software modules: the subscription handler and the MSA handler.
e B because the sole goal of the interface is to allow code downloading. Weon at interface C since the SMU is implemented as an agent. Interfaces A andarty subscribes to given events and is notified when the events occur. Both
on Voyager [95]. It is made of several MSAs, one SMU and one SCU. Theipped with a 400/100 MHz Intel Pentium II, and running Windows NT 4. 0.un UltraSparc station running Solaris 2. 6 with a 333 MHz processor. Four terminals. They all run Windows NT 4. 0 with 266 MHz Intel Pentium IIrs are connected via a 100 Megabits Ethernet.
plified version of the platform access API. The operations related to servicemplemented.
User profile Service pointers
Figure 3. 3 - SMU Software Architecture
20
� As far as the SMU is concerned, the service pointer repository and the user profile repository havebeen implemented as files. The subscription handler has been implemented in its entirety.
� All the interfaces have been implemented. However, we have used HTTP at interface A since wehave only one SCU and only SMU. The same applies to interface D since we have only one SMUand only one SIP server.
Measurements help in evaluating the viability of architectural choices. As a first step, we have decided togain insights into the time that elapses between when the user subscribes to service(s) and when theservices are available for use. The results are obtained as a mean of 200 measurements over a two weeksperiod.
Experiments where run from 9 p. m. to 9 a. m. during weekdays and at any time during the weekends.This set-up was made to eliminate the adverse effects of others applications clogging the network duringregular day hours. The measurements we made indicate the time lag between when the user subscribes tonew services and when these services are made available to him is acceptable, even if the user subscribes toseveral services at the same time.
The measurements are shown below.
3.3 Conclusions
This chapter has described the components and the interfaces of a novel mobile agent based servicearchitecture. The key components are the MSA, the SMU and the SCU and the key interfaces A, B, C andD. A partial proof of concept prototype has been built to demonstrate its feasibility.
The architecture avoids the two chief pitfalls of the mobile agent based service architectures proposed inthe past (i. e. sole reliance on IN as service creation paradigm and one-to-one mapping between servicesand mobile agents):
� It allows service creation using any of the tools offered by the existing service paradigms forInternet Telephony. Furthermore services can be created as mobile agents and also using any newparadigm that may emerge in the future.
� It stipulates the grouping of services in order to avoid the one-to-one mapping. We haveexperimented with different ways of grouping. Reference [119] describes a grouping where all theservices are carried by one and only one MSA while reference [27] describes another groupingwhere the originating services are carried by an MSA and the terminating services are carried byanother MSA.
Construction de la y for a MS A conta ining a n incre a sing num be r of se rvice s
050
100150200250300350
0 - 0 503 -1
1044- 2
2606- 3
3109- 4
3623- 5
5212- 6
5715- 7
6229- 8
7818- 9
Se rvice data s iz e ( in byte s ) - Num be r o f s e rvice s
Con
stru
ctio
n de
lay
in
mill
isec
onds
(ms)
C o n s tr u c t io n d e la y fo r a n M S A c o n t a in in g in c r e a s in g n u m b e r o f s e r v ic e s
01 0 02 0 03 0 04 0 05 0 06 0 0
8 3 2 1- 1 0
1 6 1 9 0- 2 0
2 6 0 6 0 - 3 0
3 4 3 8 1 - 4 0
4 2 7 4 0 - 5 0
5 2 1 2 0- 6 0
6 0 4 4 1- 7 0
6 8 8 0 0- 8 0
7 8 1 8 0- 9 0
8 6 5 0 1- 1 0 0
S e r v ic e d a ta s iz e ( in b y te s ) - N u m b e r o f s e r v ic e s
MSA
Con
stru
ctio
n de
lay
in
mill
isec
onds
(ms)
Figure 3. 4 - The Time it Takes to Construct an MSA of an Increasingly Big Size
21
The architecture goes far beyond Internet Telephony. It can be applied to pure Internet services and thesame benefits can be expected. Netchaser, a mobile agent based architecture for pure Internet services,proposed by D. Stefano and C. Santoro [117] can benefit from the ideas proposed in this chapter. Thesame applies to the mobile agent based architectures proposed in the past for circuit switched telephony [6].We can even go beyond service engineering and apply the ideas to very different areas such as networkmanagement. Network management functions can be grouped in MSAs.
22
CHAPTER 4
23
4. UPGRADING MOBILE SERVICE AGENTS
Sometimes MSA needs to be upgraded. It is the case when new versions of service logic become available.It is also the case when end-users make changes to service data. This chapter is based on appendix D andproposes a novel framework for upgrading MSAs. This framework consists of an upgrading co-ordinatorresiding in the network and of specialised operations the MSA must perform. Our key assumption is thatthe MSA is designed with upgrading in mind and is able to perform the necessary operations.Requirements are derived and related work is scrutinised in the first section. The section after thatintroduces the framework. Following this I present the prototype and the measurements. I state myconclusions in the last section
4.1 Requirements and related work
The requirements are listed below. Appendix D provides more details.
1. No impact on service behaviour
2. Transparency
3. Easy deployment
4. Minimal service interruption
5. Minimal completion time
On-the-fly program modification [115] is closely related to the problem of upgrading the MSA. However,as shown in the appendix, none of the available schemes meets the requirements above in a satisfactorymanner. There are two main categories of schemes for on the fly program modification: dynamic updating[48] and dynamic linking [87].
The dynamic updating schemes break the easy deployment requirement. They usually require a specialisedenvironment (e. g. operating systems, languages, code generators). Dynamic linking does not cater to trueon-the-fly program modification. Although enhancements have been made to remedy to the situation, theresulting schemes from these enhancements are usually complex, which in turn makes them difficult todeploy.
4.2 Our Framework: Two Schemes
The framework relies on two schemes: agent swapping and self-upgrading. It utilises an upgrading co-ordinator and dedicated operations, which the MSA performs. Figure 4. 1 depicts the framework.
24
4.2.1 Agent Swapping
When an upgrade leads to major changes in the MSA, this scheme swaps the MSA (and its clones) with anew agent that contains the new version of the service logic (or the changed service data). Although thisimplies service interruption, the interruption is hardly noticeable by the end-user as shown by themeasurements. It is usually triggered by the availability of new versions of service logic.
The upgrading co-ordinator gets the customised data from the old MSA and creates a new MSA thatcontains the new service logic, the old service logic (if the MSA contains more than 1 service) and thecustomised data. It then creates as many clones of the new MSA as there are clones of the old MSA. Theold MSAs are deactivated and the new ones activated. As a result of the deactivation, the old MSAs ceaseto exist, and as result of the activation the new MSAs replace them.
In this scheme, the MSA must perform the following operations:
� Send customized data
� Deactivate MSA
� Activate MSA
4.2.2 Self Upgrading
When an upgrade leads to minor changes in the MSA, this scheme enables the MSA upgrade itself. Self-upgrade comes in two forms: centralised and decentralised. A self-upgrade is usually triggered by changes
Upgrading coordinator
Upgradingoperations
ServiceLogic
ServiceData
MSA ClonesUpgradingoperations
ServiceLogic
ServiceData
Upgradingoperations
ServiceLogic
ServiceData
Figure 4. 1 - The Upgrading Framework
25
in the service data. In the centralised form, the upgrading co-ordinator sends a request to the MSA andeach of the clones to request their self-upgrades. The request includes the changed service data (or newservice logic).
In the decentralised from, the upgrading co-ordinator builds a lightweight agent and dispatches it in thenetwork. The agent contains the changed service data (or new service logic). It tours the MSA and theclones and requests each MSA to locally self-upgrade. This form has the advantage of off loading theupgrading co-ordinator. The disadvantage is that it takes time before all of the MSAs are again consistentand upgraded. In this scheme, the MSA must perform only one operation, the self -upgrade operation.
4.3 Our Framework: Prototypes and Measurements
We have built the prototypes using the software architecture described in the previous chapter.
4.3.1 Agent Swapping
All the operations necessary for agent swapping have been implemented. The prototype has been used tomake measurements on the quantifiable requirements:
� Minimal completion time
� Minimal service interruption
As shown in appendix D, the key factors influencing the completion time are:
1. The time it takes to build the MSA
2. The time the MSA takes to move to target site. If we assume we have N clones, then T1 is the timeit takes to build the new MSA, T2 the time the MSA takes to the new site, the process will lastapproximately: N * (T1+T2).
The time it takes to build an MSA of an increasing size was depicted in the previous chapter by figure 3. 4.Figure 4. 2 depicts the time it takes to dispatch back and forth an MSA of an increasing size using Voyager[95].
Time to send back and forth an increasingly big MSA
18301840185018601870188018901900191019201930
0 - 0 503 -1
1044- 2
2606- 3
3109- 4
3623- 5
5212- 6
5715- 7
6229- 8
7818- 9
Service data size (in bytes) - Number of Services
Del
ay in
mill
isec
onds
(ms)
Time to send back and forth an increasingly big MSA
1850
1900
1950
2000
2050
2100
2150
8321- 10
16190- 20
26060- 30
34381- 40
42740- 50
52120- 60
60441- 70
68800- 80
78180- 90
86501- 100
Service data size (in bytes) - Number of services
Del
ay in
mill
isec
onds
(ms)
Figure 4. 2 - The Time to Dispatch Back and Forth an MSA of an Increasing Size using Voyager
26
With 5 clones and the biggest MSA considered in the experiment (86501 Kbytes), the process lasted around8 seconds. Service is interrupted between the time the old MSA is deactivated and the time the new MSAis activated, this is T2. If we assume as before that we have the biggest MSA considered in our experiment,T2 is equal to 1075 milliseconds, meaning a bit longer than 1 second.
4.3.2 Self Upgrading
As for agent swapping, we have made measurements on the two quantifiable requirements are:
� Minimal completion time
� Minimal service interruption
Service interruption (if any) is negligible. The interesting measurements we have made are related to thecompletion time. They have allowed us, to compare the centralised and the decentralised form in terms ofresponse time, but also in terms of load induced on the network. We have measured:
� The response time as a factor of the number of clones for both the centralised and the decentralisedforms of the scheme. This is depicted by figure 4. 3:
Preferences updatingResponse time versus number of terminals
-
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0
10.0
0 1 2 3 4 5 6 7Number of terminals
Tim
e (s
)
RMI approachAgent approach
Figure 4. 3 - Response Time as a factor of the Number of Clones
� The load induced on the network as a factor of the number of clones for both the centralised and thedecentralised forms of the scheme. This is depicted by figure 4. 4:
27
Preferences updatingNetwork load versus number of terminals
0.000
0.010
0.020
0.030
0.040
0.050
0.060
0.070
2 3 4 5 6Number of terminals
Net
wor
k lo
ad (M
byte
s)
RMI approachAgent approach
Figure 4. 4 - Response Time
In our experimental setting, the centralised form performs better in both cases. In the first case, it is due tothe extra time needed to construct a mobile agent. In the second case, it is due to the extra load an agentinduces.
4.4 Conclusions
This chapter has proposed a novel framework for upgrading MSA. 5 key requirements were identified.On-the-fly program modification is closely related to the upgrading problem. However none of its schemesproposed over the years meets the 5 requirements in satisfactory manner. The novel framework is made ofan upgrading co-ordinator and of dedicated operations the MSA performs. It includes two schemes: agentswapping and self-upgrading. Furthermore, self-upgrading comes in centralised and in decentralised forms.
The framework meets all the requirements. The first three requirements are not quantifiable. They are metthanks to the design the two schemes: customised data is not lost, end-user intervention is not required, anddeployment is easy. The last two requirements are quantifiable and the measurements we have presented inthis chapter show that they are met.
This framework goes far beyond the MSA of the architecture proposed in this thesis. It is applicable to anymobile agent that meets the basic set of assumptions presented in section 4 of appendix D. These agentsinclude the MSA for circuit switched telephony [5] and the MSA for pure Internet services [117]. The self-upgrading scheme can be applied to software upgrading in general, because service interruption (if any) isvery minimal.
28
CHAPTER 5
29
5. ADAPTING MOBILE SERVICE AGENTS TO HOST VARIATION
The current Internet infrastructure comprises an extensive range of hosts. Clients range from high-endpersonal computers (PC) with a lot of memory/processing power, to memory/processing power constrainedpersonal digital assistant (PDA) and embedded devices. Mobile agents that roam the Internet need to adaptto memory / processing power constraints. This applies to our mobile service agents. This chapter is basedon appendix E and proposes a novel framework for adapting mobile agents to host variation. Our chiefassumption is that the MSA has been designed with adaptability in mind and is able to perform a certain setof operations. The next section derives the requirements and examines related work. The novel frameworkand the measurements made are successively introduced after that. The last section gives someconclusions.
5.1 Requirements and Related Work
Our framework relies on partitioning. The MSA keeps what it can keep on the host and stores the restsomewhere else. The requirements are listed below. Appendix E provides more details.
1. No impact on service behaviour
2. Transparency
3. Easy deployment
4. Minimal service interruption
5. Minimal completion time
6. Dynamic partitioning
There have been several attempts over the years to partition applications. The most noticeable are processmigration [3,15,103] and mobile agent based - application partitioning [77]. Process migration is notsuitable because mobile agents are not parallel applications. Furthermore, the key assumption behindprocess migration is that the host has enough memory / processing power to accommodate the applicationin its entirety. Partitions residing on foreign hosts can always come back home, when they are evicted.The assumption does not hold for adapting mobile service agents to host variations.
Mobile agent based application partitioning is much more pertinent for the problem at hand. It consists ofbreaking the application in mobile agents that can reside on different hosts during execution. The keyproblem with the framework described in reference [77] is that when memory / processing power becomesabundant, the partitions continue using inter-agent communications mechanisms although they reside onthe same host. The penalty in terms of performance is quite heavy, as shown by the measurements we havemade. Our framework tackles this very issue.
5.2 Framework: Components
We assume that the SMU has enough space to accommodate the partitions the MSA elects to drop. Wealso assume that all hosts have the minimum space required for the execution of the mandatory partitions.The framework is made of the partition storage agent, the partition selector, the partition dispatcher, and thepartition handler. The high level operation the MSA must perform is the partition handling operation. Thisoperation relies on two low-level operations: partition selection and partition dispatching. Figure 5. 1depicts a simplified version of the framework.
30
Partition storage agent
The partition storage agent stores the partitions the agent being partitioned elects to drop. It is a mobileagent and resides on the SMU that is the closest to the MSA. By definition, the MSA never stores thesepartitions.
Partition selector
The partition selector selects the partitions to drop when memory / processing power is scarce and thepartitions to claim back when memory / processing power becomes abundant. This choice is based on a setof criteria including the real time/non real time nature of the partitions and the probability of its execution.The MSA stores these partitions if there is enough space on the host. Otherwise, the partition storage agentstores it.
Stored Partitions
Partition Selector(can reside in either the agent beingpartitioned or the partition storage
agent)
Partitiondispatcher
Partitionhandler
Agent being partitioned
Partition storage agent
Figure 5. 1 - A Simplified Framework
31
Partition handler
The partition handler is always part of the agent being partitioned. It co-ordinates the whole process andrelies on the partition selector and the partition dispatcher. The partition dispatcher sends the partitions tothe PSA and gets them back.
5.3 Measurements
We have implemented the framework using the software architecture described in the third chapter of thisthesis. Measurements have been made on inter-partition communications, partitioning, re-assembly, andmemory usage.
5.3.1 Inter-partition Communication
Inter-partition communication has an impact on the first requirement. If it takes too long, the user willnotice a difference in service behaviour. We have compared our framework to the framework described inreference [77]. We have measured the time that elapses between the invocation of a service by the co-ordinator and the beginning of the execution. The mobile agent based application partitioning was mimicby implementing the service to be invoked as mobile agent. Figure 5. 2. Depicts the inter-partitioncommunication time.
Our framework outperforms mobile agent based - application partitioning by a factor of more than 500.This is due to the fact that we use local communications instead of remote procedure call.
5.3.2 Partitioning
Partitioning time has an impact on the completion time before the migration of the agent. The timepartitioning takes depends on the time it takes to run the pre-migration algorithm, the time it takes to selectthe partitions to send away, and the time it takes to send them away. Our measurements have shown thatthe limiting factor is the time it takes to send the partitions away. Both partition selection and pre-migration algorithm run within acceptable time, 0. 5 millisecond and 80 milliseconds, respectively.
8.95E-03
1.73E-051.00E-05
1.00E-04
1.00E-03
1.00E-02
1.00E-01
Mobile-agent based partitioning
The framework
Figure 5. 2 - Inter-Partition Communication Time
32
5.3.3 Re-assembly
Re-assembly has an impact on the completion time when the agent reaches a new host. The timepartitioning takes depend on the time it takes to run the post-migration algorithm, the time it takes to get thepartitions that were sent away. The post-migration algorithm allows the agent to delete the proxies to thepartitions that were on the same SMU and can now be part of the agent. Our measurements have shownthat the limiting factor is the time it takes to get the partitions back. The post migration algorithm runswithin an acceptable time, 14 milliseconds.
5.3.4 Memory Usage
Memory usage has an impact on easy deployment. Some of the partitions are mandatory and the MSAneeds to always keep them. An example is the partition handler. We have measured the required memory.Two cases were considered: instantiation and execution. The measurements have shown that forinstantiation around 13 Kbytes are needed in addition to what is needed to create a mobile agent with nologic (around 68 Kbytes), using Grasshopper [48]. For execution, it is around 912 Kbytes in addition to the3568 Kbytes required by an agent with no logic. Figure 5. 3 depicts the memory required for instantiationand figure 5. 4 depicts the memory required after instantiation.
68
81
0
10
20
30
40
50
60
70
80
90
Mem
ory:
Kilo
-byt
es
MA without logic
MSA Co-ordinator
3568
4496
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
Agent without logic
MSA Co-ordinator
Mem
ory:
Byt
es
Figure 5.3 - Memory Required for Instantiation
Figure 5. 4 - Memory Required after Instantiation
33
5.4 Conclusions
This chapter has proposed a novel framework for adapting mobile service agents to host variability.Process migration and mobile agent based application partitioning propose mechanisms for adapting tovariability. However, they are ill suited for adapting the MSA to host variability. 6 requirements wereidentified. The proposed framework has 3 chief components: the partition storage agent, the partitionselector and the partition handler.
We have made measurements and they indicate that when it comes to inter-partition communication ourframework outperforms mobile agent based application partitioning by a factor of at least 500. They alsothat the memory required for instantiation and execution is acceptable in view of the capacity of today'ssmall footprint devices. We have actually run tests using some of these devices. They also indicate that thetime required to run the algorithms is small.
This framework, like the one described in the previous chapter, goes far beyond the MSA of thearchitecture proposed in this thesis. It is applicable to any mobile agent that meets the basic set ofassumptions presented in section 4 of appendix E. These agents include the MSA for circuit switchedtelephony [5] and the MSA for pure Internet services [117]. They include as well mobile agents fornetwork management.
34
CHAPTER 6
35
6. A MOBILE AGENT BASED MULTIPARTY EVENT SCHEDULER
One of the many benefits our novel mobile agent based – service architecture brings is that it enables thedeployment of services implemented as mobile agents side by side with services implemented as fixedcode. Many services have been implemented over the years as mobile agents [71,75]. However, very fewconvincing quantitative measurements show their advantages over the client/server technology. Worse, themeasurements made are usually biased in favour of mobile agents.
This chapter is based on appendix F and proposes a novel mobile agent based multiparty event scheduler.It shows using concrete measurements how the multiparty event scheduler outperforms the client/servercounterpart even when the later is optimally designed and the measurements are not biased as usually donein the state-of-the-art. The results are general and transposable to most information retrieval basedservices. Background information is given first. The prototype and the measurements are successivelypresented after that. Conclusions are stated in the last section.
6.1 Background
We successively state the problem, examine related work, and enumerate the advantages expected from theuse of mobile agents.
6.1.1 Problem Statement
A multiparty event is an event that requires the participation of several parties. They range from socialgatherings (e. g. family reunion) to business gatherings (e. g. teleconferences). Scheduling them canbecome a nightmare, especially when a large number of participants are involved. Let us assume that anorganiser wants to schedule an event. The key issue is the availability of participants. This issue is subjectto several constraints: participants’ preferences, priority of the event, duration, and time frame. The generalproblem we want to address is how to identify the date and time slot when all targeted participants (or aquorum) are available, under the specified constraints.
6.1.2 Related Work
� In Intranet environments, existing solutions rely on electronic agendas shared through centralizedcalendar/mail management systems. Most are client-server based (e. g. Microsoft Outlook [94]).These tools allow event organizers to download the calendars of potential participants, in order todetect the time slots where the potential participants are available. The chief weaknesses of thesetools are its scalability, lack of privacy, and also the load induced on the network.
� Attempts have been made in the past to model and automate multiparty events scheduling, usingdistributed intelligence artificial (DAI) [113,114]. They are usually based on heuristic strategies [9].The chief weaknesses are the lack of scalability, and the load induced on the network. Furthermore,they tie the user to a single device, the device where the intelligent meeting scheduler isimplemented.
� Although no event scheduling application has been implemented as a mobile agent, several mobileagent based -information retrieval applications have been described in the literature. Some of themare reviewed in the first section of appendix F. A key limitation is that very few quantitative
36
measurements have been made and when they made they are usually biased in favor of the mobileagent paradigm as evidenced by reference [71].
6.1.3 Expected Benefits
The main benefits expected from our mobile agent based implementation are as follows.
� Performance
� Easy customisation
� Enhanced privacy
� Automation
� Device independence
� Performance
It should be noted that both performance and easy customisation are key advantages. As explained inappendix F, it is hard and almost impossible to have both at the same time in a client/server setting.
6.2 The Prototype
The mobile agent based multiparty event scheduler was prototyped along with the counterpart’sclient/server applications against which it was compared.
6.2.1 The Mobile Agent Based Multiparty Event Scheduler
The high level architecture is depicted in Figure 6. 1:
Calendar API
Server Tracking
Calendars
SchedulerAgent
Negotiating agent 1
SupportAgent Negotiating agent 2
Negotiating agent N
Figure 6. 1 - High Level Architecture
37
The main components are the scheduler agent, the support agent, and the negotiating agents. The supportagent is fixed, keeps track of the negotiating agents that may be mobile, and intermediate between thescheduler agent and the negotiating agents for rescheduling events. It also does the actual re-scheduling.The software architecture is depicted in Figure 6. 2:
We have not implemented the negotiating agents and the support agent in order to focus on the informationretrieval aspects of the problem. The main software modules are:
� The mobile event scheduler agent: it includes the user interface, a proxy information retriever, aproxy date identifier, and a proxy notification sender.
� The master event planner: it resides on the calendar server. It contains the information retriever andthe date identifier.
� The bridge: It allows the mapping between the proxies and the real entities.
The prototype was built in Microsoft Outlook calendar environment and relied on the mail server ofEricsson Canada. All the software components described in the subsection above were implemented.Grasshopper [48] was used as a mobile agent platform. The proxy parts of the mobile event scheduleragent were implemented as a fixed event scheduler agent. The bridge was JIntegra [49] based. It was usedto generate the mobile event planner Java proxy interfaces. It acted as a bi-directional JAVA COM bridgefor communicating between the mobile event scheduler agent and the mobile event planner real entities
Mail server
JAVA COM
Bridge Calendar API
MESA = Mobile Event Scheduler AgentMEP = Master Event Planner
Agency
Calendars
MESA
Proxies
Negotiator
ORB DCOM
MEP
Retriever
Identifier
Notifier
Figure 6. 2 - Software Architecture
38
6.2.2 The Counterparts Client/Server Applications
We have built two applications: a plain client/server and an optimised client/server. We have restricted thescope in both cases to the steps that are meaningful for performance evaluation:
� Information retrieval: It is done on-line from the mail server, using Remote Procedure Call (RPC),instead of being retrieved locally on the mobile event planner node as in the mobile agent approach.
� Date identification: In the plain client server approach, all the information needed for identifying thedate is retrieved and stored in collection items before the beginning of the identification process. Inthe optimized client server approach, the information is retrieved chunk by chunk, and the dateidentification algorithm is applied to a chunk at a time.
Let us assume we have N targeted participants and M possible days. The algorithm used for the optimisedclient-server application can be illustrated as follows, based on a daily calendar granularity:
� Download the daily diary for one participant.
� In the best case, the date and time slot suitable for everybody are identified after having downloadedthe calendar of one day for the N participants.
� In the worst case, all the N calendars will be downloaded for the M days.
The implementation is depicted in Figure 6. 3:
Extended API SchedulerClientAgent
Outlook API Java API
Winsock Socket
TCP/IP data stream
Mail server Scheduler Client
Calendar repository
Figure 6. 3 - Implementation View of the Optimized Client/Server
39
6.3 The Measurements
Two metrics were used: the network load and the response time. The network load measures the amount ofdata transported by the network during the scheduling process. The response time measures the duration ofthe process. These two metrics, are influenced by three main factors:
� The number N of targeted participants.
� The order I of the day where everybody is available with 1 <=I <= M.
� The density of the calendar of each involved participant.
We have contrasted the mobile agent application, the plain client/server, and the optimized client serverassuming 5 <= N <= 30, and M = 30.
6.3.1 Network Load Data Analysis
The measurements indicate that the mobile agent based multiparty event scheduler outperforms by far itsplain client server based counterpart in all scenarios. However, it outperforms on “average” its optimisedclient server counterpart after a threshold. The threshold is equal to the average number of participants (e.g. N/2 = 15), when everybody is available the day that corresponds to the middle of the sorted list (I = M/2= 15th day) as shown below by figure 6. 4.
40
Communication cost : event scheduled on day 15
0
100
200
300
400
500
600
700
5 10 15 20 25 30
Number of participants
Amou
nt o
f dat
a in
kilo
byte
s
plain client-servermobile agentoptimised client-server
Figure 6. 4 - Network Load for the Average Case Scenario (I = M/2 = 15th day)
6.3.2 Response Time Data Analysis
The measurements indicate that mobile agent based multiparty event scheduler outperforms by far its plainclient server based counterpart in all scenarios. However, the threshold in the optimised client server,compared to the mobile agent case, is close to the maximum number of participants we have considered inthe experiment as shown by figure 6. 5. This indicates that the mobile agent approach still outperforms theoptimised client/server, although this happens only with conferences with at least 30 participants (themaximum number we have considered in the experiment).
41
Session scheduled on day 30
0
10
20
30
40
50
60
70
80
90
5 10 15 20 25 30
Number of participants
Res
pons
e tim
e in
sec
onds
plain client-servermobile agentOptimised client-server
Figure 6. 5 - Response Time for the Worst Case Scenario (I = M = 30th day)
6.4 Conclusions
In this chapter, we have built a case study based on multiparty event scheduling to show that mobile agentbased information retrieval applications can outperform their client/server counterparts, even when thelatter are optimally designed and the measurements are not biased. We have made measurements in termsof response time and network load. The results can be transposed to information retrieval based services ingeneral. This shows that the mobile agent infrastructure required by our architecture can be used todevelop end users services that will outperform on average their client/server counterparts.
42
CHAPTER 7
43
7. CONCLUSIONS
The service architectures proposed by IETF and ITU-T for Internet Telephony is rather weak. The sameapplies to the IN-based alternatives that are being researched. This thesis has proposed a novel mobileagent based service architecture for Internet Telephony that addresses the issues the IETF, the ITU-T, andthe IN-Based architectures fail to address. This chapter summarises the contributions of the thesis andsuggests items for further work.
7.1 Summary of the Contributions
The key contributions of this thesis are as follows.
7.1.1 A Comprehensive Set of Requirements for Service Engineering in InternetTelephony
In this thesis we have derived 8 principal requirements. The requirements have been used to evaluaterelated work and to motivate the use of mobile agents as the pillars of a novel architecture. The evaluationhas shown that there are three important requirements that none of the architectures proposed in relatedwork meets: tailored services, service manageability, and universal access requirements.
As shown in the thesis, a mobile agent based -service architecture can potentially meet these threerequirements. Furthermore, the infrastructure on which such architecture relies can be used to developmobile agent based-services that can potentially outperform their client/server counterparts.
7.1.2 Components for a Novel Mobile Agent Based Service Architecture
Our architecture solves the issues none of today's architectures addresses in a satisfactory manner. Its maincomponents are the MSA, the SMU, and the SCU
� The MSA acts as folder and carries the services to which the end-user has subscribed. It carriesservice logic, service data, and includes a co-ordinator that can perform a set of operations. Themaximum number of MSA per subscriber is fixed. The type of services the MSA carries are alsofixed.
� The SMU publishes the list of all services end-users can subscribe to at any given time via an URL.It gets the information on the available services through the notifications it receives from the SCUs.It manages the subscriber, the service and the MSA life cycles.
� Services are created in the SCU. They are created using the tools that come with the existingarchitectures. Furthermore they can be created using the tools that come with mobile agentplatforms.
The thesis has identified the interfaces between these components. A software architecture has beenproposed and a prototype built and evaluated. The architecture is layered and relies on agent technology.The prototype demonstrated the viability of the architecture based on measurements made of the time thatelapses between a request for subscription to service(s) and the availability of the requested services to theend-user.
44
7.1.3 A Novel Framework for Upgrading Mobile Service Agents
We have identified 5 key requirements for upgrading mobile service agents: no impact on servicebehaviour, transparency, easy deployment, minimal service interruption, and minimal completion time.Although on-the-fly program modification is closely related to the upgrading problem, we have shown thatnone of its scheme meets our requirements. We have proposed a novel framework that is applicable to anymobile agent, provided that the agent meets a basic set of assumptions that we have identified.
The novel framework is made of an upgrading co-ordinator and of dedicated operations the MSA performs.There are two schemes in the framework. The first targets major upgrades and consists of swapping theMSA for a brand new one, the second targets minor upgrades. The MSA upgrades itself. The upgradingco-ordinator either directly asks the MSA and each clone to upgrade itself or delegates the task to alightweight upgrading agent that tours the clones.
The two schemes have been prototyped and measurements have been made to show that the proposedframework meets all the requirements. The measurements made on the first scheme indicate that theservice interruption duration and the duration of the whole process is acceptable, even with service logic ofvery large size and several clones. Service is interrupted for around 1 second and the whole process lastsaround 8 seconds.
Service is not always interrupted in the second scheme and when it is interrupted, the interruption lastsaround 1 second, just as in the first scheme. The whole process takes less than a second, if thedecentralised form is used. We have compared the centralised and the decentralised forms using theresponse time and the network load. The centralised form fares much better than the decentralised one interms of response time and network load.
7.1.4 A Novel Framework for Adapting Mobile Service Agents to Host Variation
We have proposed a framework relying on application partitioning for adapting the MSA to host variation.Process migration is not suitable. Mobile agents are not parallel applications in nature. Furthermore theykey assumption behind process migration is that the host has enough space to accommodate all thepartitions because the hosts can always evict them. Mobile agent based application partitioning is morepertinent. However, its penalty in terms of performance is rather high because the partitions continuecommunicating using inter-agent communication mechanisms, even when they are on the same host.
We have identified 6 key requirements: No impact on service behaviour, transparency, easy deployment,minimal service interruption, minimal completion time and dynamic partitioning. The framework consistsof dynamically partitioning the agent when memory/processing power is scarce, and re-assembling it whenmemory/processing power is abundant. A key component is the partition storage agent. It is a dedicatedagent that resides on a host where memory/processing power is available, handles the partitions that cannotbe stored/executed in the host where the agent resides. The three other components are the partitionselector, the partition handler and the partition dispatcher.
The partition selector elects the partitions to be dropped while memory / processing power is scarce and theones to claim back when memory / processing power becomes abundant. The partition dispatcher sendsaway and gets back the selected partitions and the partition handler co-ordinates the whole partitioningprocess. The measurements we have made indicate that the overhead due to the partitioning / re-assembling is low. They also indicate that the framework outperforms mobile agent based applicationpartitioning by a factor of at least 500.
45
7.1.5 A Novel Mobile Agent Based Multiparty Event Scheduler
Many events require the participation of several parties. A prior knowledge of the date where most (if notall) targeted participants are available is often a pre-requisite for scheduling them. However, identifyingthis date can easily turn into a nightmare, especially when the number of targeted participants is large.Nowadays, electronic agendas (e. g. MS Outlook) are stored on servers. An application can access them,retrieve information on the availability of the targeted participants, and derive the date from theinformation.
One of the benefits of the novel architecture proposed in this thesis is that it enables the creation of servicesas mobile-agent based service. This brings significant performance gains in many cases. We havedemonstrated this by proposing a multiparty event scheduler where a mobile agent is dispatched in thenetwork, instead of retrieving the information using the client/server paradigm. The agent visits theservers, accesses the agendas, retrieves the information, and identifies the date.
Finding a date suitable for several potential participants may require the re-scheduling of some events thathave been previously arranged by some participants. We propose the use of agents that act as the personalagents of the participants for the negotiation inherent to this re-scheduling. A few quantitative studies existon mobile agents. However, the measurements are usually biased in favor of mobile agents.
The measurements we have made indicate clearly that the mobile agent based approach outperforms itsclient/server counterpart even when the measurements are not biased. These results can be easilytransposed to most information retrieval applications, and demonstrate, for this specific application domain,the performance benefit associated with mobile agents.
7.2 Items for Further Work
The thesis has proposed frameworks for upgrading the MSA and for adapting them to host variation. Animportant aspect that is missing is security. In addition, the upgrading and the adaptability frameworksneed to be further refined. Furthermore additional mobile agent based services need to be developed,especially multi-mobile agent based services.
7.2.1 Security
A server resident MSA has a loose itinerary. When the end-users roam, the MSA follows them andrelocates to servers located in the foreign domains. These hosts might not let the MSA go to serversbelonging to competitors.
V. Roth [105] has proposed an algorithm for recording the itinerary of mobile agents in order to detectattacks by malicious hosts. The general idea is based on the use of co-operating agents. In the proposedalgorithm, every agent A is dispatched in the network with an agent B that records its itinerary. Thealgorithm has some weaknesses. Much is not said about the itinerary of B. Furthermore, some attacks arenot detected. Future work should propose solutions to the weaknesses of this algorithm and see how wecan use it to protect the MSA.
7.2.2 Refinements to the Upgrading Framework
Our framework includes two schemes: agent swapping and self-upgrade. Although we know that the firstis more suitable for major upgrades and the second for minor upgrades, the upgrading co-ordinator does not
46
include an algorithm for deciding whether an upgrade is major or minor, in order to select the properscheme. This one of the issues we would like to tackle in the future. We will propose such an algorithm infuture work.
The agent swapping proposed in this paper is centralised. We will investigate decentralised forms in thefuture. In these forms, the upgrading co-ordinator will delegate the task to an upgrading agent that includesthe new agent. This upgrading agent will tour the clones. At each site, it will deactivate the old MSA, andthen launch the new MSA, which will replace the old one. This will have the advantage to off-load theSMU.
Although we have explored an agent based-scheme for decentralising self-upgrading, only one agent isdispatched in the network. In future work we will explore the dispatching of several upgrading agents.This may aid the decentralised scheme in terms of response time, although there will be a penalty in termsof the load induced on the network.
7.2.3 Refinements to the Adaptability Framework
Although the partition selection scheme proposed in this thesis relies on the ranking of criteria, we have notyet tackled the execution probability issue. In future work we will look at the schemes that will allow thecomputation of this probability using the history of execution. We have also assumed for all the schemesthat the partitions have the same size. This assumption will be lifted in future work
The framework as currently proposed relies on the assumption that there is a host in the network on whichall the partitions the agent cannot handle are off-loaded. In future work we will loosen the assumption byconsidered a set of hosts, each host having the possibility of accommodating some of the partitions, but notall. We will also consider the possibility of partitions being evicted from some hosts and having to berelocated.
7.2.4 Multi-Mobile Agent Based Services
This thesis has proposed a novel mobile agent based multiparty event scheduler. A single mobile agent isdispatched in the network. The agent tours all the servers. One way to reduce the response time is todispatch several mobile agents in the network. However, the penalty in terms of network load needs to beminimised. This penalty depends on how many agents are dispatched in the network and how manyservers each agent visits. Scheduling multiparty events, or more generally retrieving information, withseveral mobile agents raises many interesting issues we would like to tackle in the future.
The first issue is the algorithm. It needs to be distributed. The second is the co-ordination model. Today’sco-ordination models have been recently surveyed [7]. It will be interesting to evaluate their suitability formultiparty event scheduling or more generally information retrieval. This suitability will depend of courseon the distributed algorithm we will have designed. We will also go beyond multiparty event schedulingand examine other case studies. Our ultimate goal is to use several of these applications as test cases forinvestigating the properties of information retrieval systems where several co-operating mobile agents aredispatched in the network.
47
REFERENCES
1. Th. Bah, Gestion de la Mobilité des Services dans un environnement de téléphonie IP: Uneapproche basée sur les agents, (MSc thesis), Département de Génie Électrique et GénieInformatique, École Polytechnique de Montréal, août 2001
2. Th. Bah, R. Glitho and S. Pierre, Novel Schemes for Updating Mobile Agents in VHE, ICC2002,accepted for presentation
3. A. Barak and R. Wheeler, MOSIX: An Integrated Multiprocessor Unix, in D. Milojicic et al.(eds), Mobility, Processes and Agents, ACM Press, Addison Wesley, Reading, 1998, pp. 42-53
4. S. Bessler et al, A Service Platform for Internet-Telecom Services Using SIP, SmartNet 2000
5. M. Breugst and T. Magedanz, Mobile Agents: Enabling Technology for Active IntelligentNetwork Implementation, IEEE Network, May/June 1998, Vol. 12, No3, pp. 53-60
6. M. Breugst and al, Impacts of Mobile Agent Technology on Mobile Communications SystemEvolution, IEEE Personal Communications Magazine, Vol. 5, No4, August 1998, pp. 56-69
7. G. Cabri, and al. , “Agents for Information Retrieval: Issues of Mobility and Coordination,”Journal of Systems Architecture, Elsevier Science, 2000, pp. 1419-1433.
8. G. Camarillo, SIP Demystified, McGraw-Hill Professional Book Group, 2001. ISBN 0-07137340-3
9. A. Cesta and D. D'Aloisi, “Mixed-Initiative Issues in an Agent-Based Meeting Scheduler,”International Journal on User Modeling and User-Adapted Interaction, vol. 9(1/2), pp. 45-78,April 1999
10. F. G. Chatzipapadopoulos et al. , Mobile Agent and CORBA Technologies in the BroadbandIntelligent Network, IEEE Communications Magazine, June 2000 Vol. 38 No. 6, pp. 116 – 124
11. D. Chess et al. , Mobile Agents: Are They a Good Idea?, IBM Research Report, RC 19887(88465), 1994
12. T-C Chiang et al. , IN Services for Converged (Internet) Telephony, IEEE CommunicationsMagazine, June 2000, Vol. 38 No6, pp. 108-115
13. D. Cohen, Specifications for the Network Voice Protocol (NVP), RFC 741, November 1977
14. S. Desrochers, R. Glitho, and K. Sylla, Experimenting with PARLAY in a SIP environment:Early Results, IPTS workshop, Atlanta, July 2000, pp. 7-12
15. F. Douglis and J. Ousterhout, Transparent Process Migration: Design Alternatives and the SpriteImplementation, in D. Milojicic et al. (eds), Mobility, Processes and Agents, ACM Press,Addison Wesley, Reading, 1998, pp. 56-86
16. N. Edwards, SIP Support in PARLAY, Btexact, www. btexact. com, accessed December 2001
17. N. Edwards, PARLAY and SIP, Issue 1, British Telecoms plc (2000)
18. B. Emako-Lenou, Services sur Réseaux Mobiles: Architectures d'agents et maintenance,Mémoire de maîtrise (MSc thesis), Département de Génie Électrique et Génie Informatique,École Polytechnique de Montréal, décembre 2000
48
19. E. Evloguiva and R. Glitho, Plugging IN Service Control Points in SIP Networks, IEEE INWorkshop 2000, Cape Town, May 2000
20. I. Fayenberg, L. Gabuzda, M. Kaplan and N. Shah, The Intelligent Networks Standards: TheirApplications to Services, McGraw-Hill, 1997
21. T. Finin. KQML, a Language and Protocol for Knowledge and Information Exchange, CS94-02,Computer Science Department, University of Maryland, UMBC, 1993
22. M. Fisher, W. Chang and Th. Magedanz, Distributed IN services for mobile agent based Internet,IEEE IN Workshop, Cape Town, May 2000
23. M. Franz, Dynamic Linking Of Software Components, IEEE Computer, March 1997, pp. 74-81
24. A. Fuggetta et al. , Understanding Code Mobility, IEEETransactions on Software Engineering,Vol. 24, No5, 1998, pp/342-361
25. C. Gbaguidi et al, "An Architecture for the Integration of Internet and TelecommunicationServices EEE Openarch, 1999
26. D. Gifford, Outlook 2000 VBA, Programmer’s Reference, Wrox, 1999.
27. R. H. Glitho and A. Wang, A Mobile Agent Based Service Architecture for Internet Telephony,International Switching Symposium (ISS), Birmingham, May 2000
28. R. H. Glitho and Th. Magedanz (eds), Intelligent Networks in the New Millennium, IEEECommunications Magazine, June 2000, Vol. 38, No. 6
29. R. H. Glitho, Advanced Service Architectures for Internet Telephony: A Critical Overview, IEEENetwork Magazine, July/August 2000, Vol. 14 No. 4, pp. 38-44
30. R. H. Glitho B. Lenou and S. Pierre, Handling Subscription in a mobile agent based serviceenvironment for Internet telephony: Swapping Agents, Second International Workshop on MobileAgents for Telecommunications Applications (MATA), Paris, September 2000, pp. 50-66
31. R. H. Glitho, Alternatives to Today’s IETF and ITU-T Advanced Service Architectures forInternet Telephony: IN and Beyond, Elsevier Computer Networks 35 (2001), April 2001, pp. 551-563
32. R. Glitho, R. Hamadi and R. Huie, An Architectural Framework for Using Java Servlet in a SIPenvironment, ICN 2001, July 2001, Colmar, France, pp. 707-716
33. R. H. Glitho, A. Poulin, K. Sylla and O. Cherkaoui Using PARLAY for Centralised Conferencesin a SIP Environment, ICIN 2001, Bordeaux, October 2001,
34. R. Glitho, E. Olougouna, and S. Pierre, Mobile Agents and their Use for Information Retrieval: ABrief Overview and an Elaborate Case Study, IEEE Network, January/February 2002, pp. 34-41
35. R. H. Glitho, MARITA: A Novel Mobile Agent based Service Architecture for InternetTelephony, Elsevier Computer Networks, submitted
36. R. H. Glitho, Mobile Agents and their Use for Service Engineering: A Novel UpgradingFramework, IEEE Transactions on Software Engineering, submitted
37. R. H. Glitho, S. Methot and S. Pierre, A Novel Framework for Adapting Mobile Agents to HostVariation, ACM transactions on Internet Technology, submitted
49
38. C. Gourraud, IPVAS: an IN Based Value Added Service Architecture for IP Telephony,International Conference on Intelligence in Network (ICIN), Bordeaux, January 2000, pp. 41-46
39. S. Goutet, S. Pierre and R. H. Glitho, A Multi Agent Architecture for Intelligent Mobile Agents,Third International Workshop on Mobile Agents for Telcommunications Applications, MATA01,Lecture Notes on Computer Science, Vol. 2164, pp. 124-137
40. D. Gupta, and al. , A Formal Framework for On-line Software Version Change, IEEETransactions on Software engineering, Vol. 22, No 2, February 1996, pp. 120-131
41. V. Gurbani, Accessing IN services from SIP networks, Internet draft, June 1999, Work inprogress
42. M. Handley et al. , SIP: Session Initiation Protocol, RFC 2543, Internet Engineering Task Force,March 1999
43. M. Handley and V. Jacobson, Session Description Protocol, RFC 2327, Internet EngineeringTask Force, April 1998
44. M. Handley, C. Perkins, and E. Whelan, The Session Announcement Protocol, RFC 2974,October 2000
45. G. Hjálmtýsson and R. Gray, Dynamic C++ Classes, A lightweight mechanism to update code ina running program, USENIX Annual Technical Conference, New Orleans, Louisiana, June 1998.
46. M. Hicks et al. , Dynamic Software Updating, ACM SIGPLAN 2001 Conference onProgramming Language Design and Implementation (PLDI'01), June 2001
47. IBM Aglets, http://www. trl. ibm. com/aglets, accessed December 2001
48. IKV++ Grasshopper, http://www. ikv. de/products/grasshopper, accessed December 2001
49. JintegraTM Java COM bridge: http://www. linar. com/jintegra/doc/, accessed December 2001
50. ITU-T Recommendation H. 225. 0, Call signaling protocols and media stream packetization forpacket based multimedia communication systems, Geneva 1999
51. ITU-T Recommendation H. 245, Control Protocol for Multimedia Communication, Geneva, 2001
52. ITU-T Recommendation H. 323, Packet based multimedia communications systems, Geneva,2000
53. ITU-T Recommendation H. 450. 1, Generic functional protocol for the support of supplementaryservices in H. 323, 1998
54. ITU-T Recommendation H. 450. 2, Call transfer supplementary service for H. 323, Geneva, 1998
55. ITU-T Recommendation H. 450. 3, Call diversion supplementary service for H. 323, Geneva,1998
56. ITU-T Recommendation H. 450. 4, Call hold supplementary service for H. 323, Geneva, 1999
57. TU-T Recommendation H. 450. 5, Call park and pick up supplementary service for H. 323,Geneva, 1999
58. ITU-T Recommendation H. 450. 6, Call waiting supplementary service for H. 323, Geneva, 1999
50
59. ITU-T Recommendation H. 450. 7, Message waiting indication supplementary service for H.323, Geneva, 1999
60. ITU-T Recommendation H. 450. 8, Name identification supplementary service for H. 323,Geneva 2000
61. ITU-T Recommendation H. 450. 9, Call completion supplementary service for H. 323, Geneva2000
62. ITU-T Recommendation H. 450. 10, Call offer supplementary service for H. 323, Geneva, 2001
63. ITU-T Recommendation H. 450. 11, Call intrusion supplementary service for H. 323, Geneva,2001
64. ITU-T Recommendation Q. 931, ISDN User Network Interface Layer 3 Specification for BasicCall Control. Geneva, 1998
65. ITU-T Recommendation Q. 1201 (10/92) - Principles of intelligent network architecture, Geneva1992
66. ITU-T Recommendation Q. 1211, Introduction to intelligent network capability set 1, Geneva1993
67. ITU-T Recommendation Q. 1213, Global Functional Plane for Intelligent Network CS-1,Geneva 1995
68. R. Jain et al, A comparison of mobile agent and client-server paradigms for information retrievaltasks in virtual enterprises, Research Challenges, Academia/Industry Working Conference, 2000,pp. 209-213
69. R. Jain and F. Anjum, “Mobile agents for personalized information retrieval: When are they agood idea?” IEEE Wireless Communications and Networking Conference (WCNC), Vol. 1,2000, pp. 242 –245.
70. T. Jan, “Intelligent Networks”, Artech House, Mass. , 1994.
71. Dag Johansen, “Mobile Agent Applicability,” Proc. MA’98: Second International Workshop onMobile Agents, Lecture Notes in Computer Science, No. 1477, Springer-Verlag, Berlin, 1998, pp.80-98
72. Jini specifications, http://www. sun. com/jini/specs, accessed December 2001
73. A. Karmouch and V. A. Pham, Mobile Software Agents: An Overview, IEEE CommunicationsMagazine, July 1998, Vol. 36, No7, pp. 26-37
74. T. Kawamura and al. , “Quantitative Evaluation of Pairwise Interactions between Agents,” JointSymposium of ASA/MA 2000, pp. 192-205.
75. D. Kevin and al. , “Mobile Web Agents for Telemedecine”, First International Workshop onMobile Agents for Telecommunications Applications (MATA’99), pp. 405-417.
76. Kiniry and D. Aimmerman, “A Hands – On Look At Java Mobile Agents”, http://computer.org/internet/ic1997/w4021abs. htm, accessed December 2001
77. Oskari Koskimies, K. Raatikainen, Partitioning Applications with Agents, Second InternationalWorkshop on Mobile Agents for Telecommunication Applications (MATA 2000), pp. 79-93
51
78. D. Kotz and R. Gray, “Mobile Agents and the Future of Internet”, in ACM Operating SystemsReview, August 1999, pp. 7-13.
79. S. Krause and al. , Intelligent Agents: An Emerging Technology for Next GenerationTelecommunications Networks, IEEE INFOCOM, 1996
80. Anders Kristensen, The SIP Servlet API, Java Specification Request (JSR) 116, Java CommunityProcess, http://jcp. org/jsr/detail/116. jsp, accessed December 2001
81. D. B. Lange, Mobile Objects and Mobile Agents: The Future of Distributed Computing,European Conference on Object Oriented Programming, 1998, pp. 1-12
82. D. B. Lange, “Present and Future Trends of Mobile Agent Technology”, Second InternationalWorkshop on Mobile Agents '98 (MA '98) Stuttgart, Germany, September 1998.
83. J. Lennox and H. Schulzrinne, CPL: a language for user control of internet telephony services,Internet Draft, IETF, March 1999, Work in progress
84. J. Lennox and H. Schulzrinne, Call Processing Language Framework and Requirements, RFC2824, Internet Engineering Task Force, May 2000
85. J. Lennox, J. Rosenberg and H. Schulzrinne, Common Gateway Interface for SIP, RFC 3050,Internet Engineering Task Force, February 2001
86. J. Lennox, J. Rosenberg and H. Schulzrinne, Feature Interaction in Internet Telephony, SixthInternational Workshop on Feature Interactions in Telecommunications and Software Systems,May 2000
87. S. Liang and G. Bracha. Dynamic Class Loading in the Java Virtual Machine, Conference onObject-Oriented Programming Systems, Languages, and Applications '98, Vancouver, Canada,Oct. 1998,
88. H. Liu and P. Mouchtaris, Voice over IP Signaling: H. 323 and Beyond, IEEE CommunicationsMagazine, October 2000, Vol. 38, No10, pp. 142-148
89. Th. Magedanz and R. Popescu-Zeletin, Intelligent Networks: Basic Technology, Standards andEvolution, Thompson Computer Press, London, 1996
90. T. Magedanz and R. Popescu-Zeletin, Towards Intelligence on Demand – On the Impacts ofIntelligent Agents on IN, 4th International Conference on Intelligent Networks (ICIN), Bordeaux,France 1996
91. S. Malabarba and al, Runtime Support for Type-Safe Dynamic Java Classes, 14th EuropeanConference on Object-Oriented Programming, 2000.
92. S. Methot, Architecture de Partionement d'agents, (MSc thesis), Département de GénieÉlectrique et Génie Informatique, École Polytechnique de Montréal, juillet 2001
93. O. Miauno et al. , “Advanced Intelligent Network and the Internet Combination Service and ItsCustomization”, IEICE Transactions on Communication, No. 8, August 1998.
94. Microsoft Outlook: http://www. microsoft. com/office/outlook/.
95. Object space Voyager, http://www. objectspace. com/
96. OMG TC Document orbos/97-10-05, Mobile Agent System Interoperability FacilitiesSpecification, http://www. omg. org/
52
97. O. Olougouna, Architectures évolutives pour applications d'agendas électroniques base sur lesagents mobiles, (MSc thesis), Département de Génie Électrique et Génie Informatique, ÉcolePolytechnique de Montréal, mai 2001
98. P. Oreizy and al. , Architecture-Based Runtime Software Evolution, In Proceedings of theInternational Conference on Software Engineering, 1998.
99. PARLAY forum: http://www. parlay. org/
100. C. Perkins (ed), IP Mobility Support, IETF Request For Comments (RFC), October 1996
101. M. K. Perdikeas et al. , Mobile Agents Standards and Available Platforms, Computer Networks,Vol. 31, No19, August 1999, pp. 1999 – 2016
102. Personal Java Specification, version 1. 1. 3: http://java. sun. com/products/personaljava. accessedDecember 2001
103. M. Powell and B. Miller, Process Migration in DEMOS/MP, MOSIX: in D. Milojicic et al. (eds),Mobility, Processes and Agents, ACM Press, Addison Wesley, Reading, 1998, pp. 29-38
104. J. Rosenberg et al. , SIP: Session Initiation Protocol, RFC 2543-bis, Internet Engineering TaskForce, October 2001, work in progress
105. V. Roth, “Mutual Protection of Co-operating Agents”, in Secure Internet Programming, Vitek etJensen (Ed. ), Springer-Verlag, Berlin, Allemagne, 1998, pp 26-37.
106. V. Roth, “Secure Recording of Itineraries Through Cooperating Agents”, ECOOP Workshop onDistributed Object Security and 4th Workshop on Mobile Object Systems: Secure Internet MobileComputations, pp 147-154, INRIA, France, 1998.
107. H. Schulzrinne et al, RTP: a transport protocol for real time application, RFC 1889, InternetEngineering Task Force, Jan. 1996
108. H. Schulzrinne and J. Rosenberg, The Session Initiation Protocol: Providing Advanced ServicesAcross the Internet, Bell Labs Technical journal, October- December 1998, Vol. 3, pp. 144-160
109. H. Schulzrinne and J. Rosenberg, SIP Caller Preferences and Callee Capabilities, Internet draft,February 1999, Work in progress
110. H. Schulzrinne and J. Rosenberg, SIP Call Control Services, Internet draft, June 1999, Work inprogress
111. H. Schulzrinne and J. Rosenberg, The IETF Internet Telephony Architecture and Protocols, IEEENetwork, May/June 1999, pp. 18-23
112. H. Schulzrinne and J. Rosenberg, The Session Initiation Protocol: Internet Centric Signaling,IEEE Communications Magazine, October 2000, Vol. 38, No10, pp. 134 - 141
113. S. Sen, “Developing an automated distributed meeting scheduler,'' IEEE Expert, vol. 12, no. 4,July/August 1997, pp. 41-45
114. S. Sen and H. Durfee, “A Formal Study of Distributed Meeting Scheduling,” Group Decision andNegotiation, volume 7, 1998, pages 265-289.
115. M. Segal, and O. Frieder, On-The-Fly Program modification: Systems for Dynamic Updating,IEEE Software, March 1993, pp. 53-65
53
116. L. Slutsman et al, Framework and Requirements for the Internet Intelligent Networks (IIN),Internet Draft, March 2000, Work in progress
117. D. Stefano and C. Santoro: Agent Support For Personal Mobility, IEEE Internet Computing, Vol.4, No2, March / April 2000, pp. 74-79
118. J. Tang, T. White, B. Pagurek and R. H. Glitho, Advanced service architecture for H. 323 InternetTelephony Protocol, First International Workshop on Mobile Agents for TelecommunicationsApplications (MATA), Ottawa, October 1999
119. J. Tang, T. White, B. Pagurek and R. H. Glitho, Advanced service architecture for H. 323 InternetTelephony Protocol, Journal of Computer Communications, April 2000, Vol. 23, No8, pp. 740-753
120. G. Thom, H. 323: The Multimedia Communications Standard for Local Area Networks, IEEECommunications Magazine, December 1996, Vol. 34 No12, pp. 52-56
121. J. Toga and J. Ott, ITU-T standardization activities for interactive multimedia communications onpacket networks: H. 323 and related recommendations, Computer Networks 31 (1999), pp. 205-223
122. Third Generation Partnership Project (3GPP); Technical Specification Group Core Network;Feasibility Technical Report - CAMEL Control of VoIP Services, 3G TR 21. 978 version 2. 1. 0,January 2000
123. Third Generation Partnership Project (3GPP), Technical Specification 22. 121, The Virtual HomeEnvironment, 3rd generation partnership project, Technical specification group services andsystem aspects, http://www. 3gpp. org/, accessed December 2001
124. Third Generation Partnership (3GPP), Open Services Architecture, Application ProgrammingInterface, 3G TR 29. 998, http://www. 3gpp. org/, accessed December 2001
125. TINA- C, Business Model and Reference Points, version 4. 0, May 1997 – http://www. tinac.com/, accessed December 2001
126. TINA-C, Service Architecture, Version 5. 0, http://www. tina-c. com/, accessed December 2001
127. Wireless Application Protocol (WAP) architecture specifications - http://www. wapforum. org/,accessed December 2001
