Designing Distributed Applications
`with Mobile Code Paradigms
`
`Antonio Carzaniga
`Politecnico di Milano
`Piazza Leonardo d a Vinci, 32
`20133 Milano, Italy
`+39-2-239 9-36 38
`carzaniga@elet.polimi.it
`
`Gian Pietro Picco
`Politecnico di Torino
`Corso Duca degli Abruzzi, 24
`10129 Torino, Italy
`+39-11-564-7008
`polito .it
`picco@athena
`
`Giovanni Vigna
`Politecnico di Milano
`Piazza Leonardo da Vinci, 32
`20133 Milano, Italy
`f39-2-2399-3666
`vigna@elet.polimi.it
`
`A B S T R A C T
`Large scale distributed systems are becoming of
`paramount importance, due to the evolution of technol-
`ogy and to the interest of market. Their development,
`however, is not yet supported by a sound technologi-
`cal and methodological background, as the results de-
`veloped for small size distributed systems often do not
`scale up. Recently, mobzle code languages (MCLs) have
`been proposed as a technological answer to the problem.
`In this work, we abstract away from the details of these
`languages by deriving design paradigms exploiting code
`mobility that are independent of any particular tech-
`nology. We present such design paradigms, together
`with a discussion of their features, their application do-
`main, and some hints about the selection of the correct
`paradigm for a given distributed application.
`Keywords
`Mobile code, design paradigms, distributed applica-
`tions.
`I N T R O D U C T I O N
`Distributed systems have been investigated for years,
`but recently research on this subject has gained a new
`impetus, partially due to the explosive growth of the In-
`ternet. Being the largest distributed system ever built,
`Internet is making distributed systems available to the
`general public, taking advantage of both the achieve-
`ments in network technology and the ever-increasing
`interest of markets in long-haul communications. Con-
`sequently, a great deal of research is focusing on the
`exploitation of new broadband communication devices
`and in the provision of new services on large scale dis-
`tributed systems, such as the Internet.
`The technological and methodological background de-
`veloped for conventional distributed systems often fails
`to scale up when applied to the problem of providing
`
`Permission to make digitalhard copies of all or part of this material for
`personal or cl'wsroom use is granted without fee provided that the copies
`are not made or distributed for profit or commercial advantage, the copy-
`right notice, the title ofthe publication and its date appear, and notice is
`given that copyright is hy pemiission of the ACM, Inc. To copy otherwise,
`to republish, to post on servers or to redistribute to list?, requires specific
`permission and/or fee
`ICSE 97 Boston MA USA
`Copyright 1997 ACM 0-89791-914-9197/05 ..$3.50
`
`large scale distribution. As often happens, researchers
`tried to overcome the problem with a bottom-up ap-
`proach, by developing technology providing ad hoc sup-
`port for this kind of systems.
`One of the outcomes of this research is the recent pro-
`posal of a number of new programming languages, espe-
`cially conceived for the Internet, that are all character-
`ized by the capability to provide some sort of code m o -
`bility, i.e., the capability to reconfigure dynamically, at
`run-time, the binding between the software components
`of the application and their physical location within a
`computer network. Work on code mobility is not new;
`other approaches [3, 81 already investigated the capabil-
`ity to provide.code mobility at the language level. The
`novelty of the new approaches is in their emphasis on
`the application of code mobility to a large scale setting.
`In our view, good technology addresses only a part of
`the problem. Software engineering taught us that a
`good software product does not come just from tech-
`nology. Rather, higher level phases in the development
`process, such as specification and design, play a cen-
`tral role in the final success [1, 161. Research on dis-
`tributed systems partially fails to address these issues
`within a well-established framework able to guide an
`engineer through the development of a distributed ap-
`plication, and this deficiency is even more evident when
`large scale systems are involved.
`In this paper, we are concerned mainly with the design
`of distributed applications, that aims at identifying the
`distributable components and their interactions which
`together satisfy the system requirements [lo]. Our goal
`is to develop a repertoire of design paradigms [15] that
`can be used to design distributed applications exploiting
`code mobility. We achieve this by leveraging off of the
`experience we gained in our ongoing research [4] about
`programming languages supporting code mobility, of-
`ten called mobile code languages (MCLs). We proceed
`bottom-up, trying to abstract away from MCLs and
`conceptualize the design paradigms they embody. The
`resulting paradigms are quite general and independent
`of the specific technology one may choose for the im-
`plementation although, of course, each design paradigm
`
`22
`
`IBM-1014
`Page 1 of 11
`
`

`
`can be implemented more naturally by languages pro-
`viding specific features [6]. Independence of the design
`paradigm from the underlying technology is a major
`point in the general software engineering practice. As
`an example, the benefits of an object-oriented design do
`not stem from the availability of an object-oriented lan-
`guage to be used in the implementation. Rather, they
`are valuable per se, for example in terms of improved
`understandability and reusability of the design.
`The following section gives an overview of currently
`available MCLs, classifying them according to the de-
`gree of mobility they provide. Then, we give the ratio-
`nale for mobile code design paradigms, followed by their
`definition and explanation. Subsequently, we discuss
`why and when mobile code paradigms can be benefi-
`cial and we tackle the problem of choosing a particular
`paradigm via analysis performed at the design stage.
`The final section illustrates further directions for this
`work.
`A BRIEF OVERVIEW OF MOBILE CODE
`TECHNOLOGY
`The interest about code mobility has been raised mainly
`by a new family of programming languages, usually re-
`ferred to as mobile code languages (MCLs), that were
`proposed recently’. Although languages belonging to
`this family are being developed both in industry and
`academia, marketing forces are playing a fundamental
`role in the acceptance of such languages in the com-
`munity of potential users. This is proven by the fact
`that two of the most well-known MCLs, that is, Java
`by Sun Microsystems [18], and Telescript by General
`Magic [ 1 I], come from industry.
`Although both Java and Telescript are considered
`MCLs, they are at the extremes of a continuum repre-
`senting the degree of code mobility that can be provided
`by a programming language. Telescript provides a so-
`phisticated form of thread migration, in which a thread
`running on an interpreter (or engine, in the Telescript
`jargon) is able to migrate autonomously to a different
`engine, possibly run by a different machine, by execut-
`ing a go operation. This operation causes the engine to
`suspend the thread, serialize it (together with its state),
`and transmit it to the destination engine specified as ar-
`gument. There, it will be unserialized, and its execution
`will be resumed from the instruction following the go.
`Telescript is a very rich language, in which support for
`mobility of both the code and the associated state has
`been a driving factor for the whole language design.
`On the other hand, in Java there is no support for mi-
`
`IFor simplicity, we refer to the technologies mentioned here as
`“languages”, even when they are extensions of existing languages.
`Furthermore, we will describe only briefly problems and issues in
`MCLs. An in-depth discussion is provided in [4].
`
`gration of executing code. The only language feature
`that can be directly exploited for code mobility is pro-
`vided by a programmable class louder. Instead of hav-
`ing a fixed policy for resolving class names at run-time,
`Java provides the capability to program where the code
`corresponding to an unresolved class name has to be re-
`trieved. Hence, Java programs can download code from
`the net and link it dynamically at run-time.
`13etween these two extremes there is a full spectrum
`of MCLs that provide different degrees of mobility for
`(EU). Currently available MCLs
`their execution units’
`l~rovide support for at least one of the following:
`
`Strong mobility is the ability of an MCL (called
`strong MCL) to allow EUs to move their code and
`execution state to a different site. Executing units
`are suspended, transmitted to the destination site,
`and resumed there. For instance, Telescript, is a
`strong MCL.
`
`‘Weak mobility is the ability of an MCL (called weak
`MCL) to allow an EU in a site to be bound dynam-
`ically to code coming from a different site. This
`encompasses two cases: either the EU dynamically
`links code downloaded from the network (as can be
`done in Java), or the EU receives its code from an-
`other EU. In the latter case, two more options are
`possible. Either the EU in the destination site is
`created from scratch to run the incoming code, or
`a pre-existing EU links the incoming code dynam-
`ically and executes it.
`
`Strong MCLs are a minority, because of the challenging
`problems they pose in both defining and implementing
`the semantics of strong mobility. Besides Telescript, the
`family of strong MCLs includes languages such as Ty-
`coon, Agent Tcl and Emerald. Tycoon [la] provides
`thread migration like Telescript, but lacks Telescript’s
`richness of abstractions and features. Agent Tcl[7] pro-
`vides strong mobility where the whole image of the in-
`terpreter can be transferred to a different site by execut-
`ing a jump instruction. Agent Tcl also supports weak
`mobility, as it provides a submit instruction that al-
`lows transmission of Tcl [14] procedures, together with
`a portion of their global environment, to an interpreter
`running on a different site. Emerald [3] also provides
`a form of strong mobility, though it is not completely
`under programmer’s control.
`Weak mobility has been around for quite a long time un-
`der many shapes. For example, the well-known UNIX
`s h shell language together with the run-time support
`
`”ereafter, we will use the term execution unit to refer to the
`run-time representation of a single flow of computation, e.g., a
`UNIX process or a thread in a multithreaded environment.
`
`23
`
`IBM-1014
`Page 2 of 11
`
`

`
`provided by the r s h d daemon can be regarded as a lan-
`guage implementation supporting weak mobility, in that
`it allows a user to send a shell script to be executed on a
`remote machine. In addition, the REV [8] system, that
`inspired much of the work on code mobility, provides an
`extension to remote procedure call (RPC) that allows
`one to send both the actual parameters and the code for
`a procedure to be executed on a remote machine. More
`recent approaches have been inspired by applications de-
`velopment on the Internet. As we mentioned, the Java
`class loader allows the programmer to customize the res-
`olution of a class name, possibly downloading the cor-
`responding code from any machine on the network. An
`extension of Java, called MOLE [17], adds the capabil-
`ity of sending code to another Java interpreter without
`modifying the Java interpreter. TACOMA [9] is an ex-
`tension of Tcl that allows the programmer to send code
`together with any kind of data to a remote machine, in
`order to be executed there. Facile [5] is a higher-order
`functional language conceived for concurrent distributed
`programming where code mobility is naturally achieved
`because Facile functions are first class elements of the
`language. MO [19] differs from the above languages in
`that it is not conceived to be the language in which
`mobile code applications are programmed. Rather, its
`goal is to provide a middleware layer supporting code
`mobility for higher level layers.
`DISTRIBUTED APPLICATIONS AND CODE
`MOBILITY
`When designing the architecture of a distributed ap-
`plication, interaction among the various components is
`usually considered independent of the components’ lo-
`cation. The location of components is simply regarded
`as an implementation detail. In some cases, such de-
`tails are explicitly stated by the programmer in the im-
`plementation stage. In other cases, they are automat-
`ically defined by some middleware layer. For example,
`CORBA [13] intentionally hides the location of com-
`ponents to the programmer. In this framework, there
`is no distinction between interaction involving compo-
`nents residing on the same host and components resid-
`ing on different hosts of a computer network.
`This, however, is not the only possible approach to the
`design of distributed applications. There are cases when
`the concepts of location, binding of computational re-
`sources to locations, and migration to different locations
`need to be taken into account during the design stage.
`In some cases, the interaction among components resid-
`ing on the same host is remarkably different with re-
`spect to the case where components reside on different
`hosts of a computer network, in terms of latency, access
`to memory, partial failure, and concurrency. As stated
`in [20], hiding such differences can lead to unexpected
`performance and reliability problems.
`
`In this paper, we address the class of applications for
`which the concepts of location and mobility are so im-
`portant that they affect the conceptual structure of the
`application as it is conceived in the design stage. The
`next section illustrates a number of design paradigms
`that emerged from our research. Such paradigms are
`general and provide a repertoire of architectural pat-
`terns that can be used to design distributed mobile ap-
`plications in a systematic fashion.
`MOBILE CODE PARADIGMS
`In this section we will abstract away from the specific
`features provided by the language in which a distributed
`application is written. Our goal is to identify design
`paradigms encompassing code mobility which can pro-
`vide guidance for the design of distributed applications.
`Design paradigms will be defined in terms of the follow-
`ing basic abstractions:
`
`Components are the composing elements of an archi-
`tecture. They can be further divided into:
`Resource components embody architectural el-
`ements representing passive data or physical
`devices, e.g., a file, a network device driver, or
`a printer driver. A particular kind of resource
`is represented by code components which con-
`tain the know-how necessary for the execution
`of a particular task.
`Computational components embody a flow of
`control. An example is a process, or a thread.
`They are characterized by a state, which in-
`cludes private data, the state of their execu-
`tion, and bindings to other components, in
`particular to code components and resource
`components.
`Interactions are events that involve two or more com-
`ponents. For example, a message exchanged be-
`tween two computational components can be re-
`garded as an interaction between them.
`Sites are execution environments; they host compo-
`nents and provide support for the execution of com-
`putational components.
`In our paradigms, sites
`embody the intuitive notion of location. Hence, in-
`teractions among components residing in the same
`site are considered less expensive than interactions
`taking place among components located in different
`sites.
`
`Implicitly, we assume the existence of an underlying net-
`work which provides support for all the communication
`facilities.
`We will present our design paradigms in terms of inter-
`actions patterns that define the coordination and reloca-
`
`24
`
`IBM-1014
`Page 3 of 11
`
`

`
`tion of components needed to perform a service. To this
`end, we consider a computational component A, located
`at a site SA, that needs the results of the computation
`of a service. We assume the existence of another site
`S g , which will be involved in the delivery of the ser-
`vice. In order to obtain the service results, A starts the
`interaction pattern that leads to service delivery. Ser-
`vice execution involves a set of resources, the know-how
`about the service (its code), and a computational com-
`ponent responsible for the execution of the code. In
`order to accomplish the service, these elements must be
`present at one site ut the same time.
`In this context, we identify three main design paradigms
`that extend the well-known client-server paradigm to
`exploit code mobility. We will call them: remote eval-
`uation, code on demand, and mobile agent. We distin-
`guish the design paradigms according to the location
`of the different components before and after the execu-
`tion of the service, the computational component that
`is responsible to execute the code, and where the com-
`putation actually takes place (see Table 1).
`The presentation of the paradigms is based on a real
`life scenario where two friends-Louise and Christine-
`interact and cooperate to makc a chocolate cake. In or-
`der to make the cake (the results of a service), a recipe
`is needed (the know-how about the service), as well as
`the ingredients (the resources that can be moved), an
`oven to bake the cake (a resource that can hardly be
`moved), and a person to mix the ingredients following
`the recipe (a computational component responsible for
`the execution of the code). To prepare the cake (to ex-
`ecute the service) all these elements must be co-located
`in the same home (site). In the following, Louise will
`play the role of component A, i.e., she is the initiator of
`the interaction, and the one interested in its effects.
`Client-Server (CS)
`
`Louise would like to have a chocolate cake, but
`she doesn’t know the recipe, and she has at
`home neither the required ingredients nor an
`oven. Fortunately, she knows that her friend
`Christine knows how to make a chocolate cake,
`and that she owns everything needed at her
`place. Since Christine is usually quite happy
`to prepare cakes on request, Louise phones her
`asking: “Please, can you make me a chocolate
`cake?”. Christine makes the chocolate cake
`and delivers it back to Louise.
`
`the server to draw a filled rectangle passing the coordi-
`nates of the upper-left and lower-right corners. As a
`consequence, the server executes the procedure that ac-
`tually draws the rectangle driving the physical display.
`In this paradigm, a computational component B (the
`server) offering a set of services is placed at site Sg.
`Resources and know-how needed for service execution
`are hosted by site SB as well.
`The client component A, located on SA, requests the ex-
`ecution of a service with an interaction with the server
`component B . As a response, B performs the service re-
`quested by executing the corresponding know-how and
`accessing the involved resources co-located with B. In
`general, the service produces some sort of result that
`will be delivered back to the client with an additional
`inter action.
`Actually, a server may rely on other components in or-
`der to perform parts of the required service or to retrieve
`parts of the required data, but, in this case, the server
`would act as a client in another client-server interaction.
`From the original client’s viewpoint the server owns all
`necessary data and knowledge.
`Remote Evaluation (REV)
`
`Louise wants to prepare a chocolate cake. She
`knows the recipe but she has at home nei-
`ther the required ingredients nor an oven. Her
`friend Christine has both at her place, yet she
`doesn’t know how to make a chocolate cake.
`However, Louise knows that Christine is happy
`to try new recipes, therefore she phones Chris-
`tine asking: “Can you make me a chocolate
`cake? Here is the recipe: take three eggs...”.
`Christine prepares the chocolate cake following
`Louise’s recipe and delivers it back to her.
`
`There are several examples of a remote evaluation de-
`sign paradigm3 implemented using the available tech-
`nology. For example, in the UNIX world, the rsh com-
`mand allows a user to have some script code executed
`on a remote host. Another example is the interaction
`between an application (e.g., a word-processor) and a
`PostScript printer. The resources involved in this inter-
`action are the printing devices (e.g., laser raster, paper
`tractor, and so on), while the code is the PostScript file,
`.which is executed by the PostScript interpreter hosted
`by the printer.
`
`The client-server paradigm is well-known and widely
`used. An example is the X Windows system. In this
`case, the server manages a physical display while client
`applications use the display through the services pro-
`vided by the server. For instance, one client may request
`
`3Hereafter, by ‘Iremote evaluation” we will refer to our design
`paradigm. Although it has been inspired by work on the REV
`system [8], they have to be kept definitely distinct. Our REV is a
`design paradigm, while the REV system is a technology that may
`be used to actually implement an application designed using the
`REV paradigm.
`
`25
`
`IBM-1014
`Page 4 of 11
`
`

`
`Paradigm
`
`Clien t-Server
`
`SA
`
`A
`
`Remote
`Evaluation
`
`know-how
`A
`
`Code on
`Demand
`
`resources
`A
`
`Mobile
`Agent
`
`know-how
`A
`
`Before
`
`After
`
`SB
`know-how
`resources
`B
`
`resources
`B
`
`know-how
`B
`
`S A
`
`A
`
`A
`
`resources
`know-how
`A
`
`resources
`
`-
`
`SB
`know-how
`resources
`B
`know-how
`resources
`B
`
`B
`
`know-how
`resources
`A
`
`Table 1: Mobile code paradigms. This table shows the location of the components before and after the service execu-
`tion. For each paradigm, the computational component in bold face is the one that executes the code. Components
`in italics are those that have been moved.
`
`In the REV paradigm, a component A has the know-
`how necessary to perform the service but it lacks the
`required resources, which happen to be located at a re-
`mote site SB. Consequently, A sends the service know-
`how to a computational component B (which we call
`“executor”) located at the remote site that, in turn, ex-
`ecutes the code using the resources available there. An
`additional interaction delivers the results back.
`Given the above definition, it may be argued that REV
`is nothing more than a special case of the client-server
`paradigm in which the server exports an execute-code
`service that takes a code fragment as parameter. To
`some extent, this is true. Yet, we believe that it is useful
`to distinguish between the two paradigms. In particular,
`it is the ability of the server/executor to offer customiz-
`able services that makes the difference. A server in the
`client-server paradigm exports a set of fixed function-
`alities. In turn, an executor in the remote evaluation
`paradigm offers a service that is programmable with a
`computationally complete language.
`Code on Demand (COD)
`Louise wants to prepare a chocolate cake. She
`has at home both the required ingredients and
`an oven, but she lacks the proper recipe. How-
`ever, Louise knows that her friend Christine
`has the right recipe and she has already lent it
`to many friends. So, Louise phones Christine
`asking “Can you tell me your chocolate cake
`recipe?”. Christine tells her the recipe and
`Louise prepares the chocolate cake at home.
`
`Many upcoming Internet applications are based on this
`paradigm. For example, consider a generic terminal that
`
`is able to download, link, and execute some code from
`the net. The terminal could get documents that come
`in a particular format that the terminal is unable to
`elaborate. The header of the document may contain
`a reference to the code that is needed to interpret the
`document so that the terminal, after downloading the
`data, could fetch the necessary code.
`In the COD paradigm, component A is already able to
`access the resources it needs, which are co-located with
`it within SA. However, no information about how to
`process such resources is available at SA. Thus, A inter-
`acts with a component B contained in SB by requesting
`the service know-how, which is in SB as well. A second
`interaction takes place when B delivers the know-how
`to A, which can subsequently execute it.
`Mobile agent (MA)
`
`Louise wants to prepare a chocolate cake. She
`has the right recipe and ingredients, but she
`has not an oven at home. However, she knows
`that her friend Christine has an oven at her
`place, and that she is very happy to lend it.
`So, Louise prepares the chocolate dough and
`then goes to Christine’s home, where she bakes
`the cake.
`
`As an example of an application that is conveniently
`modeled with mobile agents, consider a network man-
`agement activity. The network manager would like to
`test the status of a set of network nodes and perform
`some corrective actions on each faulty node following the
`net topology (e.g., because the faults may be caused or
`propagated by adjacent nodes). Current mainstream
`
`26
`
`IBM-1014
`Page 5 of 11
`
`

`
`protocols for network management, e.g. SNMP, are
`based on a pure client-server paradigm where a man-
`agement station continuously polls and updates data on
`the network devices by means of very low-level get/set
`operations. As discussed in [Z] , this is likely to generate
`a huge network traffic in proximity of the management
`station, thus worsening the situation that management
`is supposed to solve. A mobile agent, in turn, could be
`composed of a diagnostic routine that travels among the
`faulty nodes performing all the needed get/set opera-
`tions locally, without overloading the network.
`In the MA paradigm, the service know-how is owned by
`A, which is initially hosted by SA, but some of the re-
`quired resources are located on Sg. Hence, A migrates
`to SB carrying the know-how and possibly some inter-
`mediate results with itself. After it has moved to S B ,
`A completes the service using the resources available
`there.
`The mobile agent paradigm is different from other mo-
`bile code paradigms in that the associated interactions
`involve the mobility of an existing computational com-
`ponent. In other words, while in REV and COD the
`focus is on the transfer of code between components, in
`the mobile agent paradigm a whole computational com-
`ponent, together with its state, the code it needs, and
`some resources required to perform the task, are moved
`to a remote site.
`DISCUSSION
`The mobile code design paradigms introduced in the
`previous section define a number of abstractions that
`provide an explicit model for the bindings between com-
`ponents, locations, and code and their dynamic re-
`configuration. Our initial experience in applying the
`paradigms [a, 61 suggests that these abstractions are
`effective in the design of distributed applications. Fur-
`thermore, their independence of the particular language
`or system in which they are ultimately implemented is
`an additional asset.
`Mobile code paradigms model explicitly the concept of
`location. The site abstraction is introduced at the archi-
`tectural level in order to take into account the location
`of the different components. Following this approach,
`the type of interaction between two components is de-
`termined by both components’ code and location. In-
`troducing the concept of location makes it possible to
`model the cost of the interaction between components
`at the design level. In particular, an interaction between
`components that share the same location is considered
`to have a negligible cost when compared to interaction
`that is carried out through a communication network.
`Most well-known paradigms are static with respect to
`code and location. Once created, components cannot
`change either their location or their code during their
`
`lifetime. Therefore, the types of interaction and its qual-
`ity (local or remote) cannot change.
`Mobile code paradigms overcome these limits by pro-
`viding component mobility and remote code linking.
`By changing their location, components may dynami-
`cally change the quality of interaction, reducing inter-
`action costs. To this end, the REV and MA paradigms
`allow the execution of code on a remote site, encompass-
`ing local interactions with components located there.
`Components that are able to link code dynamically can
`extend the types of interaction they support. The COD
`paradigm enables components to retrieve code from
`other remote components, providing a flexible way to
`extend dynamically the behavior of a component.
`SOME SCENARIOS FOR CODE MOBILITY
`In this section, we depict informally some scenarios that
`are expected to gain great benefit from the exploitation
`of a mobile code paradigm, in order to show how they
`can help in building distributed applications.
`Deployment and Upgrade of Distributed Appli-
`cat ions
`Code mobility can be exploited to support software de-
`ployment and maintenance. Traditional software engi-
`neering addresses the problem of minimizing the work
`needed to extend an application and to keep trace of
`the changes in a rational way, by emphasizing design
`for change and the provision of suitable development
`tools. In a distributed setting, however, the action of
`installing or rebuilding the application at each site still
`have to be performed locally by an operator.
`‘The REV and MA paradigms could help in providing
`automation of the installation process. A scheme could
`be devised where the installation process is coded in a
`program that is transferred to a set of network nodes.
`On each node, the program could analyze the features of
`the local hardware/software platform and perform the
`correct configuration and installation steps.
`Code mobility can go even further. For instance, let
`us suppose that a new functionality has to be added
`to an application; say, a new dialog box must be shown
`when a particular button on the user interface is pushed.
`In a distributed application designed with conventional
`techniques, the new functionality needs to be introduced
`by reinstalling or patching the application at each site.
`This process can be lengthy and, even worse, it is put in
`place even if the user never activates the corresponding
`functionality.
`The COD paradigm could help in many ways. First, all
`changes would be centralized in the code server reposi-
`tory, where the latest version is kept. hrxeover, changes
`would not be performed proactively by an operator on
`each site, rather they could be performed reactively by
`
`27
`
`IBM-1014
`Page 6 of 11
`
`

`
`the application itself, that would request automatically
`the new version to the cent,ral repository, as soon as
`the corresponding functionality is activated. Hence,
`changes could be propagated in a lazy way, concentrat-
`ing the upgrade effort only where it is really needed.
`Customization of Services
`Conventional distributed applications built following a
`client-server paradigm provide, by their nature, an u-
`priori fixed set of services accessible through a statically
`defined interface. It is often the case that this set of ser-
`vices, or their interfaces, are not suitable for unforeseen
`client needs. A common solution to this problem is to
`upgrade the server with new functionality, thus increas-
`ing both its complexity and its size, without increasing
`its flexibility.
`The REV and MA paradigms could help in increasing
`server flexibility, yet keeping both the size and com-
`plexity of the server limited. In these paradigms, in
`fact, the server actually provides a unique service, the
`execution of remote code; as a consequence, it does not
`need to be changed, unless the language in which code
`is programmed and executed is changed. Hence, the
`server provides the maximum flexibility, in that it can
`execute a7ty service requested by a client. By converse,
`each client is responsible for the correct specification of
`the service it needs, described by the code sent to the
`remote server.
`This approach is well-known in certain fields of com-
`puter science. For example, it is just the way distributed
`relational databases work; the DBMS server is not re-
`sponsible for providing answers to specific and pre-built
`queries, rather, the only service it provides is the execu-
`tion of SQL code that comes from application programs
`or SQL shells acting on the client side.
`However, the paradigm exploited by SQL systems dif-
`fers in two respect with the ones we proposed. First,
`the MA paradigm defines migration of a computation
`that is already in e