Software Update via Mobile Agent Based ... - Semantic Scholar



Software Update via Mobile Agent Based Programming Lorenzo Bettini

Rocco De Nicola

Michele Loreti

Dipartimento di Sistemi e Informatica, Universita` di Firenze Via Lombroso 6/17, 50134 Firenze, Italy

fbettini,deni ola,loretigdsi.unifi.it

Abstract We describe a system that permits maintaining the software installed on several heterogeneous computers distributed over a network by taking advantage of the mobile agent paradigm. The applications are installed and updated only on the central server. When a new release of an application is installed on the server, agents are scattered along the network to update the application on the clients. To build a prototype system we use X-K LAIM, a programming language specifically designed to program distributed systems composed of several components interacting through multiple tuple spaces and mobile code.

Keywords Mobile Agents, Mobile Code, Distributed Software Update.

1.

Introduction

A typical way of updating software in a network is to store the applications and the updates in a central server; the clients can then download the latest version of the software (pull strategy), and manually update their own computers. In this paper, we describe how to use mobile agents [7, 13] to develop a prototype system that permits automatically maintaining the software installed on several heterogeneous computers distributed over a network. The applications are installed and updated only on the central server, where clients register for applications. When a new release of an application is installed on the server, some agents are scattered along the network to update the application on the clients. These mobile agents implement a push strategy: subscribed customers are provided with the latest software as soon as it is available. In order to build a prototype system supporting the movement of agents to different machine and the update of software we use X-K LAIM, a programming language specifically designed to program distributed systems composed of several components interacting through multiple tuple spaces and mobile code. We chose to use X-K LAIM because it has many features that make implementing a distributed applications easy and also This work has been partly supported by MURST Projects SALADIN and TOSCA, and by Microsoft Research Ltd.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC 2002, Madrid, Spain c 2002 ACM 1-58113-445-2/02/03 : : : $5.00.

supports strong mobility (a key concept in mobile agent programming). In the literature concerning mobility (see e.g. [12, 8, 9] and the references therein) one often reads that the main advantage of using mobile agents is that they make distributed applications more efficient because they reduce network communications and interactions. Indeed when applications over a global network rely on communication protocols that require multiple interactions, network is heavily exploited; this often results in high network traffic and, in absence of dedicated and fast communication channels or private subnets, the performance decreases significantly. However, reduced network communication is not always the principal motivation of using mobile agents. There are some results about mobile agent performance [2, 11] showing that a mobile agent may require more network traffic than other paradigms, mainly because of the data and code that have to be transported during the migration from one site to another. Indeed, the application proposed here is only marginally concerned with traffic efficiency, we are instead interested in the design of distributed applications. In fact we think that the mobile agent paradigm has some good points for dealing with distributed maintenance:  the designer of the updating procedure can use mobile agents to run the program completely locally on the machine where the installation has to take place. Thus, such an agent is not much different from a procedure built for updating local applications and the same code can be easily adapted (or completely reused) also for updating the applications over a network;  mobile agents for updating programs guarantee also greater flexibility: a new release of an application often requires modifying also the installation procedure. This can be made transparent to the end user: the update agent can carry all the needed information for the installation;  mobile agents can encapsulate transactions, which take place locally, with no other network connection, apart from that needed to send the agent to a remote computer.

The rest of the paper is organized as follows: Section 2 introduces the X-K LAIM programming language, and Section 3 describes the system for software maintenance via mobile agents and a possible implementation in X-K LAIM. Section 4 concludes the paper.

2. An overview of X-Klaim X-K LAIM (eXtended K LAIM) [4] is an experimental programming language specifically designed to program distributed systems composed of several components interacting through multiple

tuple spaces and mobile code. It is based on the kernel language K LAIM (Kernel Language for Agent Interaction and Mobility) [5] and is inspired by the coordination language Linda [6], hence it relies on the concept of tuple space. A tuple space is a multiset of tuples; these are containers of information items (called fields). There are two kinds of fields: actual fields (i.e. expressions, processes, localities, constants, identifiers) and formal fields (i.e. variables). Syntactically, a formal field is denoted with !ide, where ide is an identifier. Tuples are anonymous and content-addressable; pattern-matching is used to select tuples in a tuple space:  two tuples match if they have the same number of fields and corresponding fields have matching values or formals;  formal fields match any value of the same type, but two formals never match, and two actual fields match only if they are identical.

For instance, tuple ("foo", "bar", 100 + 200) matches with ("foo", "bar", !Val). After matching, the variable of a formal field gets the value of the matched field: in the previous example, after matching, Val (an integer variable) will contain the integer value 300. In Linda there is only one global shared tuple space; K LAIM extends Linda by handling multiple distributed tuple spaces. Tuple spaces are placed on nodes (or sites), which are part of a net. Each node contains a single tuple space and processes in execution, and can be accessed through its locality. There are two kinds of localities:  Physical localities are the identifiers through which nodes can be uniquely identified within a net.  Logical localities are symbolic names for nodes. A reserved logical locality, self, can be used by processes to refer to their execution node.

node that can be accessed by the other nodes only if the creator communicates the value of variable l, which is the only means to access the fresh node. During tuple evaluation, expressions are computed and logical localities are translated into physical ones. Evaluating a process implies substituting it with its closure (i.e. the process together with the environment of the node where the evaluation is taking place). The difference between operation out(P)@l and eval(P)@l is that out adds the closure of P to the tuple space located at l, while eval sends P, not its closure, for execution at l. Therefore, if node s1 performs an out of P to node s2 , when P is executed at s2 , self will actually refer to s1 . This means that static scoping is used. On the contrary, if s1 spawns P at s2 with eval, no closure is sent: P will refer to s2 when using self and dynamic scoping is used. X-K LAIM extends K LAIM with a high level syntax for processes: it provides variable declarations, operations enriched with time-out1 , assignments, conditionals, sequential and iterative process composition. The implementation of X-K LAIM consists of K LAVA, a Java [1] package that provides the run-time system for K LAIM operations, and a compiler, which translates X-K LAIM programs into Java programs that use K LAVA. X-K LAIM syntax can be found in Table 1. RecProcDefs

::= ::=

formalParams paramlist procbody declpart decl

::= ::= ::= ::= ::=

j

j j j

idlist proc

::= ::= j j j

Physical localities have an absolute meaning within the net, while logical localities have a relative meaning depending on the node where they are interpreted and can be thought as aliases for network resources. Logical localities are associated to physical localities through allocation environments, represented as partial functions. Each node has its own environment that, in particular, associates self to the physical locality of the node. K LAIM processes may run concurrently, both at the same node or at different nodes, and can execute the following operations over tuple spaces and nodes:  in(t )@l: evaluates tuple t and looks for a matching tuple t 0 in the tuple space located at l. Whenever a matching tuple t 0 is found, it is removed from the tuple space. The corresponding values of t 0 are then assigned to the formal fields of t and the operation terminates. If no matching tuple is found, the operation is suspended until one is available.  read(t )@l: differs from in(t )@l only because the tuple t 0 selected by pattern-matching is not removed from the tuple space located at l.  out(t )@l: adds the tuple resulting from the evaluation of t to the tuple space located at l.  eval(P)@l: spawns process P for execution at node l.  newloc(l ): creates a new node in the net and binds its physical locality to l. The node can be considered a “private”

j j

KAction

::=

tuple procCall actuallist id type

::= ::= ::= ::= ::=

j

rec id formalparams procbody rec id formalparams extern RecProcDefs ; RecProcDefs ε j [ paramlist ] ε j id : type j paramlist , paramlist declpart begin proc end ε j declare decl const id := expression locname id var idlist : type decl , decl id j idlist , idlist KAction j nil id := expression j proc ; proc if expression then proc else proc endif while expression do proc enddo if KAction within expression then proc else proc endif procCall j id j ( proc ) out( tuple )@ id j in( tuple )@ id j go@ id eval( proc )@ id j read( tuple )@ id j newloc( id ) expression j proc j ! id j tuple , tuple id ( actuallist ) ε j expression j proc j id j actuallist , actuallist string int j str j loc j process j ts j bool

Table 1: X-K LAIM process syntax Comments start with the symbol #, and local variables of processes are declared in the declare section of the process definition. Standard base types are available (str, int, etc...) as well as X-K LAIM typical types, such as loc for locality variables, process for process variables and ts, i.e. tuple space, for implementing data structures by means of tuple spaces, e.g. lists, that can be accessed through standard tuple space operations. Logical localities are declared by using the type locname. X-K LAIM also provides strong mobility by means of the action go@l [3] that makes an agent migrate to l and resume its execution at l from the instruction following the migration. Also I/O operations in X-K LAIM are implemented as tuple space operations. For instance the logical locality screen is actually attached to the output device. Hence, operation out("foonn")@screen corresponds to printing the string "foonn" 1 Time-outs can be used when retrieving information for avoiding that processes block due to network latency bandwidth or to absence of matching tuples.

on the screen.

3.

The system

In our system the applications are installed on a centralized server, at which the clients will subscribe. Upon subscription the client will get the most recent release of the requested applications. Subscription may require a registration and possibly a payment, but we are not addressing these issues, that can be easily added to the system. The delivery of an application and of new releases are made by means of mobile agents, that will migrate to the client’s site, and install all the necessary modules. We want to avoid distributed transactions for guaranteing the correct installation of applications and of new releases. One of the advantages of mobile agents is that they encapsulate transactions, which will take place locally, with no other network connections, apart from the one for sending the agent to a remote computer. When the update agent arrives at the client’s site, the installation of the new release may have to wait for approval by the client; for instance the client could disable the update if that application is already running. The agent will wait for approval before updating the application. Subscription and update are depicted in Figure 1. Subscription Client

Server subscribe for ‘‘Appx’’ send an agent for installing ‘‘Appx’’

Update

send UpdateAgent

Listing 1: The process that registers the client at the server rec RegisterAgent [ ClientLoc : loc , PrivateLoc : loc , AppName : str ] declare locname ClientDB, screen ; var Version , ClientNum : int begin # choose the application according to name and version read( AppName, !Version )@ClientDB ; out ( "Registering Client ", ClientLoc, PrivateLoc, AppName )@screen ; in ( ! ClientNum )@ClientDB ; ClientNum := ClientNum + 1; out ( ClientNum, ClientLoc , PrivateLoc , AppName, Version )@ClientDB; out ( ClientNum )@ClientDB ; eval ( out ( true )@self ; out ( AppName, Version )@self )@PrivateLoc end

Listing 2: The remote process that registers a client at the server

the agent installs the application

Client

rec RegisterAgent [ ClientLoc : loc , PrivateLoc : loc , AppName : str ] extern; rec RegisterApp [ ServerApp : loc , MyLoc : loc , AppName : str ] declare var PrivateLoc : loc ; var result : bool begin newloc( PrivateLoc ) ; eval ( RegisterAgent ( MyLoc, PrivateLoc , AppName ) )@ServerApp ; in ( ! result )@PrivateLoc; if result then # OK else # handle error endif end

Server a new release of ‘‘Appx’’ is installed

UpdateAgent installs the new release

Figure 1: Subscription and Update

3.1 A prototype implementation in X-K LAIM In the X-K LAIM implementation clients will communicate to the server, upon subscribing for an application, the locality of a private site, where the server will send agents for execution. This locality is private in the sense that it is created by the clients (with a newloc), and it is known only to the creator and to all the sites to which it is communicated. This private site can be used by agents for communicating, without interferences from the external world, and it will probably reside on the client’s computer (indeed many X-K LAIM nodes can reside on the same computer). The process that the client uses to register itself on the server for a specific application is shown in Listing 1. The eval(RegisterAgent(: : :))@ServerApp is considered as a remote invocation, since RegisterAgent is defined on the server and is shown in Listing 2. ClientDB is a logical locality that is mapped, on the server, to a private physical locality which is known only to the server. It is used to register all the clients and to store information about them (e.g. the applications they subscribed to and their current version numbers). Since this locality is not known to the other clients, the server is sure that a client is not able to know the applications installed in another client, and that clients cannot interfere with each other. The secrecy of this locality is obtained by exploiting the locality evaluation mechanism provided by K LAIM: the clients cannot access the code of RegisterAgent, and thus the locality name ClientDB is unknown to them. That locality will only be mapped

to a physical locality dynamically (at run time), through the allocation environment of the server, which is unaccessible by the other nodes. Moreover every client communicates a private locality to the server. Since that locality is known only to the client and to the server, it can be used for privately communicating. It is assumed, of course, that a client trusts the server, and that the latter will not communicate private localities to other clients. The client executes the process RunAppli ation, shown in Listing 3, that checks for the availability of new updates, provided by the update agents (shown later). This process receives an update through the tuple ("Update", AppName, !App, !Version) at the private locality, and notifies the update agent that the update can be performed, by means of the tuple ("UpdateOK", AppName). Then, in case a previous version of the application is running, it stops it, it waits for the application to terminate, and it executes the new version. Notice that the application has the opportunity of releasing all the resources before terminating. Alternatively it would be possible to modify such process in order to only record that a new version is available and use such new version the next time the application is started. The updating procedure can also be postponed by delaying the tuple ("UpdateOK", AppName). When the client wants to launch the application, it issues the command eval( App )@loc, where lo is the locality where the application App will be executed, in this case PrivateLo . Alternatively the client may install the same application on other computers, so that it acts as an application server for other clients; thus a hierarchical structure of servers and clients could be easily built.

3.2 The update agents When a new release of an application is installed on the server, by inspecting ClientDB, the server will be able to know all the clients that have to be updated, and an update agent is spawned on every such client’s site (Listing 4). Upon arrival at the client’s site, the update agent (Listing 5) notifies its presence, so that it can be granted permission to update the software. After updating the application, the agent also records that

rec RunApplication [ AppName : str , PrivateLoc : loc ] declare var Version : int ; var App : process begin while true do in ( "Update", AppName, !App, !Version )@PrivateLoc ; out ( "UpdateOK", AppName )@PrivateLoc ; if in ( "running", AppName )@PrivateLoc within 1000 then out ( "terminate", AppName )@PrivateLoc; in ( "terminated", AppName )@PrivateLoc endif ; eval ( App )@PrivateLoc enddo end

Listing 3: The process executed by the client that checks for new updates. rec CheckUpdate[ AppName : str, update agent : process , Version : int ] declare var ClientNum, iterator , ClientVersion , PrevVersion : int ; var ClientAppName : str ; var ClientLoc , PrivateLoc : loc ; locname ClientDB, screen begin in ( AppName, !PrevVersion )@ClientDB ; out ( AppName, Version )@ClientDB ; out ( "New version " )@screen ; out ( AppName, Version )@screen ; in ( ! ClientNum )@ClientDB ; iterator := 1 ; while iterator = ClientNum do read( iterator , ! ClientLoc , ! PrivateLoc , !ClientAppName, !ClientVersion )@ClientDB ; if AppName = ClientAppName and Version ClientVersion then eval ( update agent )@PrivateLoc endif ; iterator := iterator + 1 enddo ; out ( ClientNum )@ClientDB end




Listing 4: The process for spawning an agent on every registered agent. a new version is installed in this node, and then notifies the server that this client has the new version. rec UpdateAgent1[ AppName : str, Version : int , App : process , server : loc ] declare var CurrentVersion : int ; locname screen begin out( "Updating ")@screen; out( AppName, Version )@screen; out ( "Update", AppName, App, Version )@self ; in ( "UpdateOK", AppName )@self ; out( "Updating done\n")@screen; in ( AppName, ! CurrentVersion )@ self; out ( AppName, Version )@self ; out ( "Updated", AppName, Version, self )@server end

Listing 5: A first example of update agent. We would like to point out that also the update agent could be updated: when a new release of an application is to be installed on the client, a new version of the agent could be sent as well. Indeed the whole system relies on a specific protocol, but the processes that execute it could easily be changed, as long as they execute the same protocol. For instance the new release of an application may have to rely on some other application or module, which the client is unaware of (so it couldn’t have registered for it); in that case the update agent could provide the client with the additional modules as well. In Listing 6 another update agent is shown that installs an

additional module, before installing the application itself. rec UpdateAgent2[ AppName : str, Version : int , App : process, App2 : process , server : loc ] declare var CurrentVersion : int ; locname screen begin out("Updating ")@screen; out( AppName, Version )@screen; out ( "Preinstallation pro edure...\n" )@screen ; out ( "Module", App2 )@self ; out ( "Preinstallation done\n" )@screen ; out ( "Installation pro edure...\n" )@screen ; out ( "Update", AppName, App, Version )@self ; in ( "UpdateOK", AppName )@self ; out("Updating done\n")@screen; in ( AppName, ! CurrentVersion )@ self; out ( AppName, Version )@self ; out ( "Updated", AppName, Version, self )@server end

Listing 6: Another update agent that also installs an additional module. Screenshot 1 shows a client receiving an update agent. This agent is an UpdateAgent1 in Listing 5. Notice that the previous release of the application TestApp is terminated and the new version is running after the update. In Screenshot 2 the same client receives an UpdateAgent2 (Listing 6) that, before installing the new release of the application, also installs the additional module (called TestAppModule). The client is unaware of such module. What we have shown here is only a simplified version of update agents; in a real application these agents will perform more complex operations, but the architecture of the system is unchanged. Moreover such system is flexible in many other parts: for instance the application server, instead of spawning a different agent to every client site, could spawn a single “itinerant” agent that visits every client performing the installation. This could be made if the application server manages a local subnet, where the connections are more reliable, and it is unlikely that an agent gets stuck in some client’s computer. For instance the code of the itinerant update agent can be similar to the one shown in Listing 7, where the code in < > is to be considered pseudo code and clients is the list (implemented through a tuple space) of the clients that have to be visited. Alternatively also a pull strategy can be adopted by some clients: every now and then a client can spawn an agent to the application server to discover whether new versions of applications are available, and call for updating.

4. Conclusions We have described a prototype system for software update in a network, by exploiting mobile agent technology. The system has been implemented using the programming language for mobile agents X-K LAIM, that provides many useful features for distributed programming with mobile code. The paper presents the architecture of a real prototypical tool that can actually be used to distribute and update software written using X-K LAIM, the same language used for writing the system itself, or Java [1], since such language is compiled into Java2 . The real life implementation of such system, that permits handling also other languages and tackling security aspects and network failures would require much bigger efforts. Here we wanted to mainly present and advocate the overall agent-based architecture and investigate its usefulness. Of course the system that we showed can also be implemented by using traditional approaches such as Client/Server, but the code 2 Indeed

the TestApp used in the example is written in Java.

rec ItinUpdateAgent [ AppName : str , update process : process, clients : ts , Version : int ] declare ... begin while read ( ! ClientLoc , ! PrivateLoc )@ clients within 0 do go@PrivateLoc ; if < client needs update > then eval ( update process )@PrivateLoc endif enddo end

Listing 7: An itinerant update agent. vate data cannot be eavesdropped by sniffers (indeed agents have to be protected from a potentially malicious server that might try to “brainwash” them, modifying their own private data [14]). However we consider these topics as orthogonal to the main issue of this paper.

5. REFERENCES Screenshot 1: A screenshot of an updating.

Screenshot 2: A screenshot of an updating with the installation of an additional module. would be cluttered with network communications and blocks to handle possible failures and it would require distribute transactions for the correct installation of applications and of new releases. We did not tackle the issue of software quality and wiseness of updates because we consider these as orthogonal to the issue of handling updates via mobile agents. We did not investigate problems connected to network failures either; they would be the same for most applications over networks. Indeed, since in our system the number of communications is limited (basically the migration of the agent, and the acknowledgment to the application server of a successful update), the risk of network failures is kept to the minimum. Other problems such as ‘single point of failures’ and ‘reliability and robustness’ are not investigated either; the standard solutions to this problem (mirrors, redundancy, replication, etc.) can be adapted to our system quite straightforwardly. Also ‘crashes and corrupted updates’ are not specific to our system: checksums can always be used to test the integrity of an update. Security is a key concept when dealing with code downloaded from sites over the net, and with agents that arrive from other computers [10]. We are developing tools and extensions for digitally signing agents, so that clients are able to accept only code that comes from the server, and for crypting tuple contents, so that pri-

[1] K. Arnold, J. Gosling, and D. Holmes. The Java Programming Language. Addison-Wesley, 3rd edition, 2000. [2] M. Baldi and G. P. Picco. Evaluating the Tradeoffs of Mobile Code Design Paradigms in Network Management Applications. In Proc. of the 20th Int. Conf. on Software Engineering, pages 146–155. IEEE CS Press, 1998. [3] L. Bettini and R. De Nicola. Translating Strong Mobility into Weak Mobility. In Proc. of the Fifth IEEE Int. Conf. on Mobile Agents (MA 2001), 2001. To appear. [4] L. Bettini, R. De Nicola, G. Ferrari, and R. Pugliese. Interactive Mobile Agents in X-K LAIM. In Proc. of WETICE, pages 110–115. IEEE Computer Society Press, 1998. [5] R. De Nicola, G. Ferrari, and R. Pugliese. K LAIM: a Kernel Language for Agents Interaction and Mobility. IEEE Transactions on Software Engineering, 24(5):315–330, 1998. [6] D. Gelernter. Generative Communication in Linda. ACM Transactions on Programming Languages and Systems, 7(1):80–112, 1985. [7] C. Harrison, D. Chess, and A. Kershenbaum. Mobile agents: Are they a good idea? Research Report 19887, IBM Research Division, 1994. [8] F. Knabe. An overview of mobile agent programming. In Proc. of LOMAPS, number 1192 in LNCS. Springer, 1996. [9] D. Lange and M. Oshima. Seven good reasons for mobile agents. Communications of the ACM, 42(3):88–89, March 1999. [10] J. Ordille. When agents roam, who can you trust? In Proc. of the 1st Conf. on Emerging Technologies and Applications in Communications, 1996. [11] M. Straßer and M. Schwehm. A Performance Model for Mobile Agent Systems. In Proc. of the Int. Conf. on Parallel and Distributed Processing Techniques and Applications PDPTA’97, volume II, pages 1132–1140, 1997. [12] T. Thorn. Programming Languages for Mobile Code. ACM Computing Surveys, 29(3):213–239, 1997. [13] J. E. White. Mobile Agents. In J. Bradshaw, editor, Software Agents. AAAI Press and MIT Press, 1996. [14] B. Yee. A Sanctuary For Mobile Agents. In J. Vitek and C. Jensen, editors, Secure Internet Programming: Security Issues for Distributed and Mobile Objects, number 1603 in LNCS, pages 261–273. Springer, 1999.