Reactive mobility by failure: When fail means move

Information Systems Frontiers 7:2, 141–154, 2005C© 2005 Springer Science + Business Media, Inc. Manufactured in The Netherlands.

Reactive Mobility by Failure: When Fail Means MoveAlejandro Zunino, Marcelo Campo∗and Cristian Mateos†

ISISTAN Research Institute, UNICEN University, CampusUniversitario (B7001BBO), Tandil, Bs. As., ArgentinaE-mail: [email protected]

Abstract. Mobile agent development is mainly supported by Java-based platforms and tools. However, the weak mobility modelthey use, the lack of adequate support for developing inferenceand reasoning mechanisms, added to the inherent complexity ofbuilding location-aware software, impose strong limitations fordeveloping mobile intelligent agent systems. In this article wepresent MoviLog, a platform for building Prolog-based mobileagents with a strong mobility model. MoviLog is an extension ofJavaLog, an integration of Java and Prolog, that allows us to takeadvantage of the best features of the programming paradigmsthey represent. MoviLog agents, called Brainlets, are able to mi-grate among different Web sites, either proactively or reactively,to use the available knowledge in order to find a solution. Themajor contribution of MoviLog is its Reactive Mobility by Fail-ure (RMF) mechanism. RMF is a mechanism that acts when anagent needs a resource or service that is not available at the cur-rent executing site. RMF uses a distributed multi-agent system totransparently transport the executing agent to the site where theresource/service is available, thus reducing the development ef-fort with respect to the traditional mobile agent approach, whilemaintaining its advantages.

Key Words. mobility, mobile agents, intelligent agents, logicprogramming

1. Introduction

Many researchers envision the future Web as a globalcommunity where people and intelligent agents inter-act and collaborate (Hendler, 2001), sharing interestsas well as resources. In this scenario consisting of sitesproviding highly dynamic content, mobile users usingunreliable connections and small devices such as PDAsand cell phones, mobile agents will have a fundamen-tal role (Gray et al., 2001). A mobile agent is a com-puter program which represents a user in a computernetwork and is capable of migrating autonomously be-tween hosts to perform some computation on behalfof the user. Such a capability is particularly interesting

when an agent makes sporadic use of a valuable sharedresource. Also, efficiency can be improved by movingagents to different hosts to query a large database. Thisapproach may also improve the response time and theavailability when compared to performing the interac-tions over network links that are subject to long delaysor interruptions.

Despite the well known advantages of mobileagents (Lange and Oshima, 1999), their usage is stilllimited to small applications, mainly due to the follow-ing factors:

Development effort: mobile agents are inherentlymore complex than traditional stationary systems.Clearly, mobile agent developers have to providemechanisms to decide an agent’s itinerary. There-fore, though agents’ location awareness may bevery beneficial, it also adds further complexity tothe development of intelligent mobile agents, spe-cially with respect of stationary applications (Picco,Carzaniga, and Vigna, 1997; Silva et al., 2001).

Lack of standards for accessing resources, includinglegacy systems: there is a need for developing mech-anisms to allow agents to access resources offered bysites. In particular, mobile agent technology shouldbe capable of using existent resources such as Webpages and Web-accessible programs and devices.

Security concerns: this has been deeply studied, andsome good results have been achieved (Gray et al.,1998; Tripathi et al., 2002). Though recent platformshave shown that it is perfectly feasible to build secure

∗Present address: National Council for Scientific and Technical Re-search of Argentina (CONICET).†Present address: Council for Scientific Research of Buenos Aires,Argentina (CIC).

141

142 Zunino, Campo and Mateos

mobile agent systems, there are still psychologicalreasons against mobile agents (Wagner and Turban,2002), thus we will limit the scope of the paper tothe first two points.

In this paper we describe MoviLog, a platform for mo-bile agents that aims at reducing the development effortby automating decisions on when and where to move anagent, based on resource needs. MoviLog is an exten-sion of the JavaLog framework (Amandi, Zunino, andIturregui, 1999; Zunino, Berdun, and Amandi, 2001)which implements an extensible integration betweenJava and Prolog (see Appendix A for an introductionto Prolog).

MoviLog provides mobility enabling mobile logic-based agents, called Brainlets, to migrate between Websites by using a strong mobility mechanism. Strong mo-bility implies that an agent’s execution state is trans-ferred and resumed at the remote site. On the otherhand, weak mobility, the mechanism implemented bymost Java-based mobile agent platforms, is not able totransfer the execution state thus the agent forgets thepoint at where its execution was. Besides extendingProlog with operators to implement proactive strongmobility, the most interesting aspect of MoviLog isthe incorporation of the notion of reactive mobility byfailure (RMF). This mechanism acts when a speciallydeclared Prolog goal fails, by transparently moving aBrainlet to another Web site to satisfy its resource andservice needs.

The article is structured as follows. The next sec-tion briefly describes the JavaLog framework. Sec-tion 3 introduces the MoviLog platform. Section 3.3presents the integration of MoviLog with Web services.In Section 3.4 the evaluation algorithm is briefly de-scribed. Section 4 reports some experimental results.Then, Section 5 discusses the most relevant relatedworks. Finally, in Section 6 concluding remarks andfuture works are presented.

2. The JavaLog Framework

Intelligent agents are usually developed by usinggeneral purpose object oriented languages such asC++ or Java due to the advantages that encapsu-lation and inheritance offer (Crnogorac, Rao, andRamamohanarao, 1997). Despite these advantages,object-oriented languages do not provide specific ab-stractions for building agents such as reasoning mech-

anisms, inference, learning or knowledge representa-tion. As a consequence, developers are forced to useprogramming abstractions not well suited for agents orhand code these mechanisms before building agents.

On the other hand, a logic-oriented programmingapproach is a straightforward consequence of the re-quirement of managing knowledge and reasoning. Forthis reason, logic languages such as Prolog (Nilssonand Maluszynaski, 1995), Agent0 (Shoham, 1997),Metatem (Fisher, 1994) and Gaea (Noda, Nakashima,and Handa, 1999) are considered good alternatives forprogramming intelligent agents (Dix, 1998).

Certainly, multi-paradigm languages integratingboth logic and object-oriented paradigms are conve-nient choices for the definition of agent program-ming languages because they offer the best of bothworlds. Examples of multi-paradigm languages appro-priate for programming agents are discussed in VanRoy and Haridi (1999), Yamazaki et al. (2001), Lee andPun (1997), Ng, Huang, and Sun (1998) and Amandi,Zunino, and Iturregui (1999).

JavaLog is a multi-paradigm language that inte-grates Java and Prolog (Amandi, Zunino, and Iturregui,1999; Zunino, Berdun, and Amandi, 2001). The Java-Log support is based on an extensible Prolog inter-preter designed as a framework (Fayad and Johnson,1999). This means that the basic Prolog engine can beextended to accommodate different extensions, such asmulti-threading, modal logic operators, or mobility, forexample.

JavaLog defines the logic module (a list of Pro-log clauses) as its basic concept of manipulation. Inthis sense, both objects and methods from the object-oriented paradigm are considered as modules encap-sulating data and behavior, respectively. The elementsmanipulated by the logic paradigm are also mapped tomodules.

Each agent possesses an object called brain. Thisobject is an instance of an extended Prolog interpreterimplemented in Java which enables developers to useobjects within logic clauses, as well as to embed logicmodules within Java code. In this way, each agent is aninstance of a class that can define part of its methodsin Java and part in Prolog. The definition of a class caninclude several logic modules defined within methodsas well as referenced by instance variables.

The JavaLog language defines some interaction con-straints between object-oriented and logic modules.These interaction constrains are classified by referring,communication and composition constraints. Referring

Reactive Mobility by Failure 143

constraints specify the composition limits of differentmodules. Communication constraints specify the roleof objects in logic modules and the role of logic vari-ables in methods. Composition constraints specify howlogic modules can be combined.

3. The MoviLog Platform

MoviLog is an extension of the JavaLog frameworkto support mobile agents on the Web. MoviLog im-plements strong mobility for a special type of agentscalled Brainlets. The MoviLog inference engine is ableto process several concurrent threads and to restart theexecution of an incoming Brainlet at the point where itmigrated, either pro-actively or reactively, in the orig-inal host. Some early ideas about MoviLog are de-scribed in Zunino, Campo, and Mateos (2002). Thispaper is mainly focused on the novel mobility mecha-nism supported by MoviLog and the conceptual modelbehind it.

In order to enable mobility across sites, each Webserver belonging to a MoviLog network have to be ex-tended with a MARlet (Mobile Agent Resource). AMARlet is a Java servlet encapsulating the MoviLoginference engine and providing services to access itthrough the Web. In this way, a MARlet represents aWeb dock for Brainlets. Additionally, a MARlet is ableto provide intelligent services under request, such asadding and deleting logic modules, activating and de-activating modules, and answering logic queries. In thissense, a MARlet can also be used to provide inferentialservices to legacy Web applications or agents.

sites([www.offers.com,www.freemarket.com,...]).preference(car,[ford, Model, Price]) :- Model > 1998, Price < 60000.preference(tv,[sony, Model, Price]) :- Model = 21in, Price < 1500.lookForOffers(A,[], ,[ ]).lookForOffers(A,[S} R], [O}RO], [O}Roff]):-moveTo(S), article( A, Offer, URL), O= (S,Offer,URL),lookForOffers(A, R, RO,ROff).

lookForOffers(A,[S} R], [O}RO], [O} Roff]):- lookForOffers(A, R, RO,ROff).buy(Art):-sites(Sites), lookForOffers(Art, Sites,R,Offers), selectBest(Offers, (S,O,E)),moveTo(S), buy article(O,E), return.

?- buy(#Art).

From the mobility point of view, MoviLog providessupport to implement Brainlets with typical pro-activecapabilities, but more interesting yet, it implements a

mechanism for transparent reactive mobility by failure(RMF). This support is based on a number of station-ary agents distributed across the network. These agentsprovide intelligent mechanisms to automatically mi-grate Brainlets based on their resource requirements.Further details on this will be explained in Section 3.2.

3.1. Proactive strong mobilityMoviLog strong mobility mechanism allows a Brain-let to proactively migrate its execution. Migration isachieved by invoking a MoviLog predicate moveTo(S),where S is the destination site. The migration mecha-nism implemented by moveTo works as follows. Beforetransport, MoviLog serializes the Brainlet and its exe-cution state—i.e. its knowledge base and code, currentgoal to satisfy, instantiated variables, choice points, etc.Then, it sends the serialized form to its counterpart onthe destination host. In the remote host, MoviLog re-constructs the Brainlet and its execution state, and thenits execution is resumed. Eventually, after performingsome computation, the Brainlet can return to the orig-inating host by calling the return predicate.

The following example presents a simple Brainletfor e-commerce whose goal is to of find and buy anarticle in the network according to a number of prefer-ences provided by a user. The buy clause looks for offersavailable in different sites of the network, selects thebest and calls a generic predicate to buy the article (thisprocess is not relevant here). The lookForOffers predi-cate implements the process of moving around througha number of sites looking for the available offers for thearticle (we assume that we get the first offer). If there

is no offer in the current site, the Brainlet goes to thenext one in the list:

Although proactive mobility provides a powerfultool to take advantage of network resources, in the


case of Prolog, it also adds extra complexity due to itsprocedural nature. Particularly, when the mobile behav-ior depends on the failure or not of a given predicate,solutions tend to be more complicated. This fact ledus to develop a complementary mobility mechanism,called reactive mobility by failure.

3.2. Reactive mobility by failureIntelligent agents have been traditionally consid-ered as systems possessing several dimensions of at-tributes (Nwana, 1996; Shoham, 1997; Genesereth andKetchpel, 1994). For example, (Bradshaw, 1997) de-scribed mobile intelligent agents in terms of a threedimensional space defined by agency, intelligence andmobility: agency is the degree of autonomy and au-thority vested in the agent; intelligence is the degree ofreasoning and learning behavior; mobility is the degreeto which agents themselves travel through the network.

Based on these views we consider a mobile agentas composed of two separated and orthogonal behav-iors: stationary behavior and mobile behavior; the firstone is concerned with the tasks performed by an agenton specific places of the network, and the second oneis in charge of making decisions about mobility. TheMoviLog platform provides a new form of mobilitycalled Reactive Mobility by Failure (RMF) that is basedon the idea that those two functionalities or concernscan be treated independently at the implementationlevel (Garcia et al., 2001).

RMF aims at reducing the effort of developing mo-bile agents by automating some decisions about mobil-ity. In this way, programmers focus their efforts on thestationary functionality of mobile agents, and delegatemobility on RMF.

RMF is a reactive migration mechanism able to au-tomate decisions on when and where to migrate a Brain-let based on its resource needs. Reactive migrationmechanism are based on the idea that an entity externalto the Brainlet triggers mobility. In RMF those external

Fig. 1. Reactive mobility by failure.

entities are stationary agents (not able to move betweensites) that are part of the MoviLog platform thus pro-vide runtime support for RMF. Stationary agents inter-fere with the normal execution of a Brainlet when afailure occurs.

Conceptually, a failure occurs when a Brainlet triesto access a resource that is located at a remote site. Interms of Prolog, a failure occurs when a Brainlet eval-uates a specially declared goal that cannot be deducedfrom the clauses provided by the local site, as depictedin the step i of Fig. 1. At this point, the stationary agentsobtain a list of sites to try to probe the goal and migratethe Brainlet to one of these sites (ii of Fig. 1). In ad-dition, stationary agents may build an itinerary for theBrainlet in order to visit the sites according to somepolicy.

To sup up, RMF is able to automate two types ofdecisions about mobility:

� where to migrate: RMF selects the next destinationof the mobile agent. This decision can take into ac-count factors such as network traffic, CPU load, etc.Moreover, it may be necessary to visit several sites ina certain sequential order. For example, host1, host2and host3, or host2, host1 and host3. A problem hereis that Brainlets might not know the location of re-sources. As a consequence RMF has to manage in-formation about resources provided by sites capableof executing Brainlets.

� when to migrate: in the example, when a failure oc-curs, RMF migrate the mobile agent to host2. How-ever, it could be convenient to copy the requiredclauses from host2 to host1. Those decisions can betaken considering network traffic and time.

As shown in Fig. 1, RMF consists of:

� executing units or mobile agents called Brainlets.� mechanisms enabling Brainlets to specify on which

resources RMF is allowed to act.


� a platform supporting the execution of Brainlets andresponsible for taking decisions about mobility.

Each of these elements is described in detail in thefollowing sections.

3.2.1. Brainlets. A Brainlet is composed of the fol-lowing parts:

� code and data: consist of Prolog clauses and Java ob-jects implementing a Brainlet’s behavior and knowl-edge.

� execution state: one ore more threads encompass-ing a program counter, stack, variable bindings andchoice points. It is worth noting that these threadspersist after migrating an agent to a remote host.

� protocol clauses: are used to delegate mobility deci-sions on RMF.

The code of a Brainlet consists of two sections: Pro-tocols and Clauses. This first section contains protocoldeclarations. The second section contains clauses ex-pressed in JavaLog. Syntactically, the code of a Brainlethas the following form:

PROTOCOLS...

CLAUSES...

PROTOCOLSprotocol(article, 3).

CLAUSESpreference(car, [ford, Model, Price]) :- Model > 1998, Price < 20000.preference(tv,[sony, Model, Price]) :- Model = 21in, Price < 1500.lookForOffers(A, [O}RO], [O}Roff]) :- article( A, Offer, URL),

thisSite(ThisSite), assert( offer(ThisSite, Offer, URL)), fail.lookForOffers(A, , Offers) :- !, findAll(offer(S,O,E)), Offers).buy(Art) :- lookForOffers(Art,R,Offers), selectBest(Offers,(S,O,E)),

moveTo(S), buy article(O, E), return....?- buy(Art).

The next section is concerned with protocols and itsusage.

3.2.2. Protocols. A protocol describes an interfaceused to access a resource available at any site of thenetwork. When a Brainlet accesses one of these re-

sources, and the resource is not available at the localsite, the stationary agents are activated.

In terms of Prolog, protocol declarations have thesyntax protocol(functor, arity). Such a declaration en-ables RMF to act on failures of goals with the form:

functor(<argument1>, <argument2>, . . . .,<argumentArity>).

In this way, when a goal declared as a protocol by aBrainlet fails, stationary agents transparently move theBrainlet to another site having definitions for such aprotocol. Thereafter it continues the normal executionto try to solve the goal.

The following code shows the implementation of thecustomer agent combining both mobility mechanisms.This solution collects through backtracking the match-ing articles from the database until no more articles areleft. The article protocol makes the Brainlet to try allthe sites offering the same protocol before returning tothe origin site to collect (by using findall) all the of-fers in the local database of the Brainlet. Once the bestoffer is selected the Brainlet proactively moves to thesite offering that article to buy it. As can be noted, thesolution using RMF looks much like a common Prologprogram. Certainly, this solution is simpler than the oneusing just proactive mobility.It is worth noting that the protocol article is only a de-scription of a resource. The concrete realization of the

resource may be a set of Prolog clauses, a Java method,a relational database or a Web service. MoviLog ab-stracts the complexity of accessing these resources byproviding a simple access method.

RMF allows a programmer to adapt and extend thedifferent decision mechanisms that act when a failure


is detected. For example, it is possible to use severalpre-defined or user-defined algorithms and metrics forbuilding and updating an agent’s itinerary.

3.2.3. RMF execution support. RMF is imple-mented through a Multi-Agent System (MAS) com-posed of stationary agents in charge of mobility. It isworth noting that these agents act only when a fail-ure occurs on a goal declared as a protocol. The MASconsists of two types of stationary agents:� Protocol Name Servers (PNS): Each host capable of

executing Brainlets has one PNS. PNS are respon-sible for managing information on protocols offeredat each site. When a Brainlet needs a resource nothosted at the local site, RMF queries the PNS of thesite to obtain a list of sites offering that resource.A site offering resources registers with its PNS theprotocols of the resources. Then, the PNS announcesthe new protocols to other sites by using a multicast-based communication mechanism.

� Mobility agents: Mobility agents collaborate withPNSs in order to select the next destination of a Brain-let that failed, building an itinerary when a resourceis hosted in more that one site. All these decisionstake into account policies based on network traffic,link speed or user-defined metrics. In addition, mo-bility agents are able to decide whether to migratean agent or to transfer a resources from other sites tothe site where the Brainlet is located.

3.3. RMF and Web servicesLet us suppose a scenario consisting of a Note-book with a low bandwidth connection to a network.Servers S1, S2, . . . , Sn residing in this network havegood connectivity with the Internet (Fig. 2). In addition,these servers are able to execute Brainlets. A Brainlet

Fig. 2. MARlet acting as a proxy of a Web accessible service.

running at the Notebook requires accessing to a ser-vice offered by a server P located at the Internet. Dueto connectivity constraints, it might be advantageous tomigrate the Brainlet to P . However, P does not supportthe execution of Brainlets, so this approach is unfeasi-ble. An alternative is to migrate the Brainlet to one ofthe servers Si with good connectivity. From there, theBrainlet will interact with P by using a fast networklink, returning to the Notebook afterwards.

MoviLog supports interaction with Web Services toenable the usage of RMF in cases where the site hostinga required service cannot execute Brainlets. Web Ser-vices (Vaughan-Nichols, 2002)—Web-accessible pro-grams and devices—can be viewed as a set of programsinteracting cross a network with no explicit human in-teraction during the transaction. In order for programsto exchange data, it is necessary to define the com-munications protocol, the data transfer syntax, and thelocation of the endpoint. For building large, complexsystems, such service definitions must be done in a rig-orous manner: ideally, a machine-readable languagewith well-defined semantics, as opposed to parochialand imprecise natural languages.

The Web Services Description Language (WSDL)is an XML-based language for describing Web servicesas a set of network endpoints that operate on messages.A WSDL service description contains an abstract defi-nition for a set of operations and messages, a concreteprotocol binding for these operations and messages,and a network endpoint specification for the binding.

From a WSDL description a program can determinethe services provided by a server and how to invokeand use these services, independently of the networkprotocol or programming language. As a complementto WSDL, the WWW Consortium developed the Uni-versal Description, Discovery and Integration (UDDI)


specification. UDDI provides a method for publishingand finding service descriptions written in WSDL orany other service description mechanism.

In order to integrate MoviLog with Web services, weextended the PNS agents with capabilities of queryingUDDI registries, parsing WSDL documents and map-ping Prolog clauses to and from Web services. Whena PNS detects a failure, it first obtains the resourcesdirectly available as Prolog predicates, then it queriesa UDDI registry and obtains a list of Web-accessibleservices that match the protocol of the predicate caus-ing a failure. When the mobile agent effectively triesto access to a Web-accessible resource, a PNS agentdetermines whether to travel to the remote site or not,depending on its support for mobile agents, networkload, size of the mobile agent, etc.

Let us consider the usage of Web services not reg-istered in UDDI. A Brainlet can invoke Web servicesby using a special code section named services whichcontains, among other things:� pointers to WSDL descriptions of the services,

including their names, parameters and access points.For example, registerServices (’http://soap.amazon.com/schemas/AmazonWebServices.wsdl’) registers the services provided by Amazon(amazonComKeywordSearch-Request, amazonco-mAuthorSearchRequest, etc.) and associates theseservices to Prolog clauses.

SERVICESregisterServices(’http://soap.amazon.com/-schemas/-Amazon-Web-Services.wsdl’).articleAdapter(book(FeatureList), Offers, URLs) :-

% invokes the Web serviceamazoncomKeywordSearchRequest( [keyword:FeatureList, mode:books,

type:lite, format:xml, devtag: ’D26UGIDJJ9HCRX’], XMLresponse ),% transforms the XML response by using a XSL transformationtransformWith( XMLresponse, ’lite-data-to-prolog.xsl’, Offers ),% uses XPath to obtain the URLs of the booksxpath(XMLresponse, ’//ProductInfo/Details@url’), URLs).

PROTOCOLSprotocol(article, 3).

CLAUSESpreference(book, [author:A, keywords:[mystery, terror], price:P]) :-

(A == ’Stephen King’ ; A == ’Agatha Christie’), P < 20.lookForOffers(A, [O}RO], [O}Roff]) :- article( A, Offer, URL),

thisSite(ThisSite), assert( offer(ThisSite, Offer, URL)), fail.lookForOffers(A, , Offers) :- !, findAll(offer(S,O,E)), Offers).buy(Art) :- lookForOffers(Art,R,Offers), selectBest(Offers,(S,O,E)),

moveTo(S), buy article(O, E), return....?- buy(Art).

� a number of user-defined clauses to adapt a protocolclause to a Web service. This involves at least thefollowing steps:

– given a protocol clause and its parameters, the pro-grammer has to map these parameters to the inputparameters of a given Web service.

– the output of the Web service has to be convertedto Prolog structures. MoviLog assumes that Webservices output XML. MoviLog provides two al-ternatives: the usage of XPath1to query the XMLoutput, or the usage of XSL Transformations totransform the XML output to Prolog terms.

Let us consider, for example, the keyword searchservice provided by Amazon. The WSDL2 descrip-tion of the service KeyWordSearchRequest describesits parameters and types. The most important pa-rameters are keywords and type (brief or detailedresponse). In addition a WSDL document includesa description of the invocation method of the ser-vice. In this case, the service has to be invokedthrough a HTTP SOAP-encoded request to the URLhttp://soap.amazon.com/onca/soap. By know-ing this details it is easy for MoviLog to invoke Key-WordSearchRequest or any other service. Now, the pre-vious example of RMF can be extended to searchand buy books in both Amazon and the MoviLognetwork:


To sum up, in order to allow Brainlets to interact withlegacy systems not able to run mobile agents, MoviLogis able to invoke Web services. To do so, developershave to provide a set of Prolog clauses that map a pro-tocol description to a Web service and a method toextract the information from the response.

3.4. Evaluation algorithmIn this section we briefly describe the evaluation al-gorithm used by MoviLog. RMF can be understood byconsidering a classical Prolog interpreter with a stack S,a database D, and a goal g. Each entry of S containsa reference to the clause c being evaluated, a referenceto the term of c that is being proved, a reference tothe preceding clause and a list of variables and theirvalues in the preceding clause to be able to backtrack.MoviLog extends this structure by adding informationabout the distributed evaluation mechanism. The ideais to keep a history of visited MARlets and possibilitiesfor satisfying a given goal within a MARlet.

Protocol definitions create the notion of a virtualdatabase distributed among several Web sites. When aBrainlet defines a given protocol predicate in a MAR-let hn , MoviLog informs the PNS agents, which in turninform the rest of registered MARlets that the newprotocol is available in hn . In this way, the databaseof a Brainlet can be defined as a set D = {DL , DR},where DL is the local database and DR is a list ofclauses stored in a remote MARlet with the same pro-tocol clause as the current goal g. Now, in order toprobe g the interpreter has to try with all the clausesc ∈ DL such that the head of c unifies with g. If noneof those lead to probe g, then it is necessary to try toprobe g from one of the non-local clauses in DR . Toachieve this, MoviLog transfers the running Brainlet toone of the hosts in DR by using the same mechanismused for implementing proactive mobility. Once at theremote site, the execution continues trying to probe thegoal. However, if the interpreter at the remote site failsto probe g, it continues with the next host in DR . Whenno more possibilities are left, the Brainlet is moved tothe site from which the Brainlet originated.

To better understand these ideas, let us give a moreprecise description of the evaluation mechanism. Lets = 〈c, ti , V, H, L〉 be an element of the stack, wherec = h : −t1, t2, . . . , tn is the clause being evaluated, tiis the term of c being evaluated, V is a set of vari-able substitutions (ex. X = 1, X = Z ) and H = 〈Ht ,

Hv, P〉, where Ht is a list of MARlets not visited, Hv

is a list of MARlets visited and P is a list of candi-

date clauses at a given MARlet that match the protocolclause of c; and L is a list of clauses with the same nameand arity as ti (candidate clauses at the local database).

The interpreter has two states: call and redo. Whenthe interpreter is in state call, it tries to probe a goal.On the other hand, in state redo it tries to search foralternative ways of evaluating a goal after the failureof a previous attempt. Given a goal? − t1, t2, . . . , tn ,S = { } and state = call,

1: if state == call then2: the interpreter pushes into the stack:

〈t1, t2, . . . , tn, ti , V = {}, 〈Ht = 〈〉, Hv = 〈〉, PHt = 〈〉〉〉3: for all i such that 1 ≤ i ≤ n do4: if The MARlet is visited for the first time then5: the interpreter searches into the local database

for clauses with the same name and arity as ti .This result is stored into P (a list of clauses c j

at the current MARlet).6: else7: P is updated with the clauses available at the

current MARlet.8: end if9: Then, the more general unifier (MGU) for ti and

the head of c j is calculated. If there is no suchunifier for a given c j , then c j is removed from P .Otherwise, the substitutions for ti and the headof c j are stored into V . At this point, thealgorithm tries to probe c j by jumping to line 1.If every ti is successfully proved, then thealgorithm returns true.

10: If there is not a clause c j such as there is amore general unifier for ti and the head of c j , theinterpreter queries a PNS for a list ofMARlets offering the same protocol clauseas ti . This is stored into Ht . Then, the Brainletis moved to the first MARlet hd in Ht . The curr-ent MARlet is removed from Hv to avoidvisit it again.

11: If Hv is empty then state = redo12: end for13: else14: This point of the execution is reached when the

evaluation of a goal fails at the current MARlet.The step 9 of the algorithm selected a c j fromthe local database for proving ti . This selectionwas the source of the failure. Therefore, Movi-Log simply restores the clause by reversing


the effects of applying the substitutions in V ,selects another clause c j , sets state = calland jumps to line 4.

15: If there are no more choices left in P , thisimplies that it is not possible to prove ti fromthe local database. Therefore the top of the stackis popped and the algorithm returns false. This

may require migrating the Brainlet to thesite where the goal failed for the first time.

16: end if

3.4.1. Distributed backtracking and consistencyissues. The RMF model generates several tradeoffsrelated to the standard Prolog execution semantics.Backtracking is one of them. When a Brainlet movesaround several places, many backtracking points canbe left untried, and the question is how the backtrack-ing mechanism should proceed. The solution adoptedby MoviLog at the current version resides in the sta-tionary agents. These agents provide a sequential viewof the multiple choice points that is used by the rout-ing mechanism to go through the distributed executiontree.

Also the evaluation of MoviLog code in a dis-tributed manner may lead to inconsistencies. For ex-ample, MARlets can enter or leave the system, mayalter their protocol clauses or modify their databases.At this moment, MoviLog defines a policy that defineshow the local view of a Brainlet is updated when itarrives to a host. This involves automatically queryingthe PNS agents to obtain a list of MARlets implement-ing a given protocol clause and querying the currentMARlet in order to obtain a list of clauses matchingthe protocol clause being evaluated.

4. Experimental Results

In this section we report the results obtained withan application implemented by using MoviLog,µCode (Picco, 1998) (a Java-based framework for mo-bile agents) and Jinni (Tarau, 1998) (a Prolog-basedlanguage with support for strong mobility).

The application consists of a number of customeragents that are able to select and buy articles offeredby sellers based on users’ preferences. Both, customersand sellers reside in different hosts of a network. In thisexample, customers are ordered to buy books that hasto satisfy a number of preferences such as price, author,subject, etc.

The implementation of the application withMoviLog using RMF was easy (39 lines of code).On the other hand, to develop the application by us-ing µCode we had to provide support for represent-ing and managing users’ preferences. The size ofthe application was 741 lines of code.3 Finally, theJinni implementation was easier, although not as easyas with MoviLog, due to the necessity of managingagents’ code and data closure by hand. The size of thesource code in this case was 353 lines. This shows thatMoviLog provides more powerful abstractions for de-veloping intelligent mobile agents. From a design pointof view, the other platforms intend to be more general,as a consequence their usage for building intelligentagents require more effort.

We tested the implementations on three PentiumIII 850 Mhz with 128 MB RAM, running Linux andSun JDK 1.3.1. To compare the performance of theimplementations we distributed a database contain-ing books in the three computers. We ran the agentswith a database of 1 KB, 600 KB and 1.6 MB. Foreach database we ran two test cases varying the user’spreferences in order the verify the influence of thenumber of matched books (state that an agent has tomove) on the total running time. On each respectivetest case the user’s preferences matched 0 and 5 books(1 KB database), 3 and 1024 books (600 KB database,4004 books), and 2 and 1263 (1.6 MB, 11135 booksapprox.). We ran each test case 20 times and measuredthe running time. Fig. 3 (right) shows the average run-ning time as a function of the size of the database andthe number of products found.

On a second battery of tests we measured the net-work traffic generated by the agents using the completedatabase (1.6 MB, 11135 books approx.) distributedacross three hosts. Fig. 3 (left) shows the network traf-fic measured in packets versus the number of books thatmatched the user’s preferences. From the figure we canconclude that MoviLog and its RMF do not affect neg-atively neither the performance nor the network traffic,while considerably reducing the development effort.

We also ran the application on the Internet by us-ing a configuration of two hosts connected to the sameLAN and a third host connected to another LAN. BothLANs were connected through the Internet by using a256 Kbps DSL link. The idea of this test was to evaluateRMF in a real scenario, taking into account the over-head introduced by RMF and its infrastructure. Resultson this test are shown in Fig. 3 (bottom). As expected,RMF introduces some overhead due to its PNSs.


1 Kb 0 books1 Kb 5 books

600 Kb 3 books

500 Kb 1024 books

1600 Kb 2 books

1600 Kb 1263 books

Books

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Net

wor

k tr

affic

[IP

pac

kets

]

00

MoviLogJinniµCode

100 200 300 400 500 600 700 800 900 1000Books

0

50

100

150

200

250

300

350

400

Exe

cutio

n tim

e [m

s] (

LAN

)

MoviLogJinniµCode

200 400 600 800 1000Books

0

500

1000

1500

2000

2500

3000

3500

Exe

cutio

n tim

e [m

s] (

WA

N)

400

MoviLogJinniµCode

Fig. 3. Performance comparisons.

Despite this overhead, MoviLog is still competitivewith the others platforms.

The next section discusses previous work related toMoviLog.

5. Related Work

At present, the only agent programming languagethat supports interaction with Web services is Con-Golog (McIlraith, Son, and Zeng, 2001). ConGologis a model-based programming language that has beenused as a testbed for DAML-S (DARPA Agent MarkupLanguage for Web Services) in small applications. Themain advantage of MoviLog is its support for reactivemobility by failure that enables us to easily build mo-bile agents that use Web services.

With respect to the plethora of work on mobileagents, the most important are the Java-based platformssuch as Aglets (Lange and Oshima, 1998), Ajanta(Tripathi et al., 2002) and µCode (Picco, 1998). These

systems provide a weak mobility model, forcing a lesselegant and more difficult to maintain programmingstyle (Silva et al., 2001). Recent works such as NO-MADS (Suri et al., 2000) and WASP (Funfrockenand Mattern, 1999) extended the Java Virtual Ma-chine (JVM) to support strong mobility. Despite theadvantages of strong mobility, these extended JVM donot share some well known features of the standardJVM, such as its ubiquity, portability and compatibil-ity across different platforms.

The logic programming paradigm represents an ap-propriate alternative to manage agents’ mental atti-tudes. Examples of languages based on it are Jinni(Tarau, 1998) and Mozart/Oz (Haridi, Van Roy, andSmolka, 1997). Jinni (Tarau, 1998) is based on a lim-ited subset of Prolog. Jinni lacks adequate support formobile agents since its notion of code and data clo-sure is limited to the currently executing goal. Asa consequence developers have to program mecha-nisms for saving and restoring an agent’s code anddata. Mozart (Haridi, Van Roy, and Smolka, 1997) is a


multi-paradigm language combining objects, functionsand constraint logic programming based on a subset ofProlog. Though the language provides some facilitiessuch as distributed scope and communication channelsthat are useful for developing distributed applications,it only provides rudimentary support for mobile agents.

The main differences between MoviLog and otherplatforms are its support for RMF, which reduces de-velopment effort by automating some decisions aboutmobility, and its multi-paradigm syntax, which pro-vides mechanisms for developing intelligent agentswith knowledge representation and reasoning capabil-ities integrated with Web services.

6. Conclusion and Future Work

Intelligent mobile agents represent one of the mostchallenging research areas due to the different factorsand technologies involved in their development. Strongmobility and inference mechanisms are, undoubtedly,two important features that an effective platform shouldprovide. MoviLog represents a step forward in that di-rection. The main contribution of our work is the re-active mobility by failure concept. It enables the devel-opment of agents using common Prolog programmingstyle, making in it easier thus for Prolog programmers.This concept, combined with proactive mobility mech-anisms, also provides a powerful tool for exploitingWeb services and mobility.

MoviLog has been used in several research projects.For example, we have developed a distributed meetingscheduler that uses Brainlets to assist users on manag-ing their calendars. Those Brainlets migrate betweensites in order to negotiate meetings with the otherusers’ Brainlets. Each Brainlet manages user prefer-ences including preferred places, contacts, days, etc.These preferences are represented by a Bayesian Net-work. Another application related to RMF is MOVED,a debugger for mobile agents that supports the con-cept of RMF. MOVED supports features found in mosttraditional debugger, but with one very important dif-ference: all these features operate in a distributed andmobile way. This is, breakpoints and watchpoints areset on mobile code, thus MOVED has to take into ac-count mobility issues.

The weakest point of the approach for integratingMoviLog with Web services is that it does not takeinto account the semantics of Web services. As a con-sequence, the programmer has to ensure, for example,

that a protocol such as article, is mapped to Amazon’sKeyWordSearchRequest or Google’s doGoogleSearchin the category Shop. The same applies for the argu-ments and responses. One approach to solve these limi-tations is the usage of machine understable descriptionsof the concepts involved in Web services. We are en-riching MoviLog’s protocols and services sections withontologies based on the technologies of the SemanticWeb (Berners-Lee, Hendler, and Lassila, 2001).

Appendix A: Prolog

Prolog is a logic language that is particularly suited toprograms that involve symbolic or non-numeric com-putation. For this reason it is a frequently used languagein Artificial Intelligence where manipulation of sym-bols and inference about them is a common task.

Prolog, which stands for PROgramming in LOGic,is the most widely available language in the logic pro-gramming paradigm. Logic and therefore Prolog isbased on the mathematical notions of relations and logi-cal inference. Prolog is a declarative language meaningthat rather than describing how to compute a solution,a program consists of a database of facts and logicalrelationships (rules) which describe the relationshipswhich hold for the given application. Rather than run-ning a program to obtain a solution, the user asks aquestion. When asked a question, the run time systemsearches through the database of facts and rules to de-termine, by logical deduction, the answer.

Among the features of Prolog are logical variablesmeaning that they behave like mathematical variables,a powerful pattern-matching facility called unification,a backtracking strategy to search for proofs, uniformdata structures, and interchangeable input/output.

FactsIn Prolog we can make some statements by using facts.Facts either consist of a particular item or a relationbetween items. For example we can represent the factthat it is sunny by writing the program:

sunny.

Facts can have arbitrary number of arguments fromzero upwards. A general model is shown below:

relation( <argument1>, <argu-ment2>, . . .., <argumentN> ).


Relation names must begin with a lowercase letter. Forexample, the following fact says that a relationship likeslinks john and mary:

likes(john,mary).

It is worth noting that names of relations are defined bythe programmer. With the exception of a few relationsthat are built-in, the system only knows about relationsthat programmers define.

We can now ask a query by asking, for example,does john like mary?:

?- likes(john,mary)

To this query Prolog will answer “yes” because Prologmatches likes(john,mary) in its database.

VariablesHow do we say something like What does Fred eat?Suppose we had the following fact in our database:

eats(fred,apples).

To ask what Fred eats, we could type in something like:

?- eats(fred,what).

However Prolog will say “no”. The reason for this isthat what does not match with apples. In order to matcharguments in this way we must use a Variable. Theprocess of matching items with variables is known asunification. Variables are distinguished by starting witha capital letter. Thus we can find out what fred eats bytyping

?- eats(fred,What).

Prolog will answer “yes, What = apples”.

RulesRules allow us to make conditional statements aboutour world. Each rule can have several variations, calledclauses. These clauses give us different choices abouthow to perform inference about our world. Let us showan example to make things clearer. Consider the state-ment All humans are mortal. We can express this as thefollowing Prolog rule:

mortal(X) :- human(X).

The clause can be read as For a given X, X is mortalif X is human. To continue let us define a fact fred ishuman:

human(fred).

If we now pose the question to Prolog ?- mortal(fred).The Prolog interpreter would respond “yes”.

In order to solve the query ?- mortal(fred)., we usedthe rule we defined previously. This said that in orderto prove someone mortal, we had to prove them tobe human. Thus from the goal Prolog generates thesubgoal of showing human(fred). Then Prolog matchedhuman(fred) against the database. In Prolog we say thatthe subgoal succeeded, and as a result the overall goalsucceeded. We know when this happens because Prologprints “yes.”

BacktrackingSuppose that we have the following database:

eats(fred,oranges).eats(fred,meat).eats(fred,apples).

Suppose that we wish to answer the question What areall the things that fred eats?. To answer this we can usevariables again. Thus we can type in the query:

?- eats(fred, Food).

Prolog will answer “Food = oranges”. At this pointProlog allows us to ask if there are other possible solu-tions. When we do so we get the following: “Food =meat”. Then, if we ask for another solution Prolog willgive us: “Food = apples”.

If we ask for further solutions, Prolog will answer“no”, since there are only three ways to prove fred eatssomething. The mechanism for finding multiple solu-tion is called backtracking. This is an essential mecha-nism in Prolog.

We can also have backtracking in rules. For exampleconsider the following program.

likes(Person1,Person2):-hobby(Person1,Hobby), hobby(Person2,Hobby).hobby(john,tennis).hobby(tim,sailing).hobby(helen,tennis).hobby(simon,sailing).

If we now pose the query:

?- likes(X,Y).

Prolog will answer “X = john, Y = helen”. Then nextsolution that Prolog finds is “X = tim, Y = simon”.


ListsLists always start and end with square brackets, and theitems they contain are separated by commas. Here is asimple list [a,simon,A Variable,apple].

Prolog also has a special facility to split the first partof the list, called the head, away from the rest of thelist, known as the tail. We can place a special symbol }(pronounced ’bar’) in the list to distinguish between thefirst item in the list and the remaining list. For example,consider the following:

[first,second,third] = [A|B]

where A = first and B = [second,third]. The unificationhere succeeds. A is bound to the first item in the list,and B to the remaining list.

Notes

1. XPath Gottlob, Koch, and Pichler (2003) is a language for ad-dressing parts of an XML document.

2. The Amazon.com Web Services software development kitis available at http://associates.amazon.com/exec/

panama/associates/join/developer/kit.html.

3. Not counting the size of a library for handling symbolic user’spreferences.

References

Amandi A, Zunino A, Iturregui R. Multi-paradigm languages sup-porting multi-agent development. In Garijo FJ, Boman M, eds.Multi-Agent System Engineering, volume 1647 of Lecture Notesin Artificial Intelligence, Valencia, Spain: Springer-Verlag, 1999,128–139.

Berners-Lee T, Hendler J, Lassila O. The semantic Web. ScientificAmerican 2001;284(5):34–43.

Bradshaw, JM. Software Agents. Menlo Park, USA: AAAI Press,1997.

Crnogorac L, Rao AS, Kotagiri Ramamohanarao. Analysis of in-heritance mechanisms in agent-oriented programming. In Proc. ofthe 15th International Joint Conference on Artificial Intelligence(IJCAI). Morgan Kaufmann Publishers, 1997; 647–654.

Dix J. The Logic programming paradigm. AI Communications1998;11(3):39–43. Short version in Newsletter of ALP, Vol. 11(3),1998, pp. 10–14.

Fayad ME, Johnson R, eds. Domain-Specific Application Frame-works: Frameworks Experience by Industry. Wiley & Sons, 1999.

Fisher M. A survey of concurrent METATEM—the language and itsapplications. In: Gabbay DM, Ohlbach HJ, eds. Temporal Logic—Proceedings of the First International Conference (LNAI Volume827). Heidelberg, Germany: Springer-Verlag, 1994;480–505.

Funfrocken S, Mattern F. Mobile agents as an architectural conceptfor internet-based distributed applications—the WASP project ap-proach. In: Proceedings of KiVS’99 (Kommunikation in Verteil-tenSystemen). Springer-Verlag, 1999:32–43

Garcia A, Chavez C, Silva O, Silva V, Lucena C. Promoting advancedseparation of concerns in intra-agent and inter-agent software en-gineering. In: Workshop on Advanced Separation of Concerns inObject-Oriented Systems at OOPSLA’2001, 2001

Genesereth MR, Ketchpel SP. Software agents. Communications ofthe ACM 1994;37(7):48–53.

Gottlob G, Koch C, Pichler R. XPath processing in a nutshell. SIG-MOD 2003;32(2):21–27.

Gray RS, Cybenko G, Kotz D, Rus D. Mobile agents: Motivations andstate of the art. In: Bradshaw J. ed. Handbook of Agent Technology.AAAI/MIT Press, 2001.

Gray RS, Kotz D, Cybenko G, Rus D. D’Agents: Security in amultiple-language, mobile-agent system. In: Vigna G, ed. MobileAgents and Security, volume 1419 of Lecture Notes in ComputerScience. Springer-Verlag, 1998;154–187.

Haridi S, Van Roy P, Smolka G. An overview of the design ofDistributed Oz. In: Proceedings of the Second International Sym-posium on Parallel Symbolic Computation (PASCO ’97). Maui,Hawaii, USA: ACM Press, 1997;176–187.

Hendler J. Agents and the semantic web. IEEE Intelligent Systems2001;16(2):30–36.

Lange DB, Oshima M. Programming and Deploying MobileAgents with Java Aglets. Reading, MA, USA: Addison-Wesley,1998.

Lange DB, Oshima M. Seven good reasons for mobile agents. Com-munications of the ACM 1999;42(3):88–89.

Lee JHM, Pun PKC. Object logic integration: A multiparadigm de-sign methodology and a programming language. Computer Lan-guages 1997;23(1):25–42.

McIlraith S, Son TC, Zeng H. Semantic web services. IEEE Intelli-gent Systems, Special Issue on the Semantic Web 2001;16(2):46–53.

Ng KW, Huang L, Sun Y. A multiparadigm language for develop-ing agent-oriented applications. In: Proceedings of Technologyof Object-Oriented Languages and Systems (TOOLS). Beijing,China: IEEE, 1998.

Nilsson U, Maluszynaski J. Logic, Programming and Prolog. NewYork, NY: John Wiley & Sons, 1995.

Noda I, Nakashima H, Handa K. Programming language Gaea and itsapplication for multiagent systems. In: Workshop on Multi-AgentSystem and Logic Programming, 1999.

Nwana H. Software agents: An overview. Knowledge EngineeringReview 1996;11(3):205–244.

Picco G. µCode: A lightweight and flexible mobile code toolkit.In: Rothermel K, Hohl F, eds. Proceedings of the 2nd Interna-tional Workshop on Mobile Agents, volume 1477 of Lecture Notesin Computer Science. Heidelberg, Germany: Springer-Verlag,1998;160–171.

Picco GP, Carzaniga A, Vigna G. Designing distributed applicationswith mobile code paradigms. In: Taylor R, ed. Proceedings of the19th International Conference on Software Engineering, ACMPress, 1997;22–32.

Shoham Y. An overview of agent-oriented programming. In: Brad-shaw JM, ed. Software Agents, chapter 13. AAAI Press/The MITPress, 1997;271–290


Silva A, Romao A, Deugo D, Mira da Silva M. Towards a referencemodel for surveying mobile agent systems. Autonomous Agentsand Multi-Agent Systems 2001;4(3):187–231.

Suri N, Bradshaw JM, Breedy MR, Groth PT, Hill GA, Jeffers R,Mitrovich TS. An overview of the NOMADS mobile agent system.In: 6th ECOOP Workshop on Mobile Object Systems: OperatingSystem Support, Security and Programming Languages, 2000.

Tarau P. Jinni: A lightweight java-based logic engine for internet pro-gramming. In: Sagonas K, ed. Proceedings of JICSLP’98 Imple-mentation of LP languages Workshop, Manchester, U.K. invitedtalk, 1998.

Tripathi AR, Karnik NM, Ahmed T, Singh RD, Prakash A, Kakani V,Vora MK, Pathak M. Design of the ajanta system for mobile agentprogramming. Journal of Systems and Software 2002 (to appear).

Van Roy P, Haridi S. Mozart: A programming system for agent ap-plications. In: International Workshop on Distributed and InternetProgramming with Logic and Constraint Languages. Part of In-ternational Conference on Logic Programming (ICLP 99), 1999.

Vaughan-Nichols SJ. Web services: Beyond the hype. Computer2002;35(2):18–21.

Wagner C, Turban E. Are intelligent e-commerce agents partners orpredators? Communications of the ACM 2002;45(5):84–90.

Yamazaki K, Yoshida M, Amagai Y, Takeuchi I. Implementation oflogic computation in a multi-paradigm language TAO. InformationProcessing Society of Japan 2001;41(1).

Zunino A, Berdun L, Amandi A. Javalog: Un lenguaje parala programaciun de agentes. Inteligencia Artificial, RevistaIberoamericana de I.A. 2001;3(13):94–99. ISSN 1337-3601.

Zunino A, Campo M, Mateos C. Simplifying mobile agent devel-opment through reactive mobility by failure. In: Bittencourt G,Ramalho G, eds. Proceedings of the 16th Brazilian Symposium onArtificial Intelligence (SBIA’02), volume 2507 of Lecture Notes inComputer Science. Springer-Verlag, 2002;163–174.

Alejandro Zunino received a Ph.D. Degree in Com-puter Science from the Universidad Nacional del Cen-tro (UNICEN), Tandil, Argentina, in 2003, his MSc.in Systems Engineering in 2000 and the Systems En-gineer degree in 1998. He is a full time research as-sistant at UNICEN. He has published over 15 pa-

pers in journals and conferences. The main contri-butions of his recent Ph.D. dissertation are reactivemobility by failure and MoviLog. His current re-search interests include development tools for mobileagents, intelligent agents, and logic programming. Heis the chair of the VI Argentine Symposium on Arti-ficial Intelligence (ASAI). More info can be found athttp://www.exa.unicen.edu.ar/∼azunino.

Marcelo Campo received a Ph.D. Degree in ComputerScience from the Universidade Federal do Rio Grandedo Sul, Porto Alegre, Brazil in 1997 and the SystemsEngineer degree from the Universidad Nacional delCentro (UNICEN), Tandil, Argentina in 1988. Cur-rently he is an Associate Professor at Computer Sci-ence Department and Head of the ISISTAN ResearchInstitute of UNICEN. He is also a research fellowof the National Council for Scientific and TechnicalResearch of Argentina (CONICET). He has over 50papers published in conferences and journals aboutsoftware engineering topics. His research interests in-clude intelligent aided software engineering, softwarearchitectures and frameworks, agent technology andsoftware visualization. More info can be found athttp://www.exa.unicen.edu.ar/∼mcampo.

Cristian Mateos is a MSc. candidate at the Univer-sidad Nacional del Centro, working under the super-vision of Marcelo Campo and Alejandro Zunino. Heholds a Systems Engineer degree from UNICEN. Hehas implemented part of the run-time support for reac-tive mobility by failure in MoviLog. He is investigatingthe relationships between Semantic Web Services andmobile agents using reactive mobility by failure.

Reactive mobility by failure: When fail means move

Documents