Dynamic Service Discovery for Mobile Computing: Intelligent Agents Meet Jini in the Aether

Cluster Computing 4, 343–354, 2001 2001 Kluwer Academic Publishers. Manufactured in The Netherlands.

Dynamic Service Discovery for Mobile Computing:Intelligent Agents Meet Jini in the Aether ∗

HARRY CHEN, ANUPAM JOSHI and TIMOTHY FININDepartment of Computer Science and Electrical Engineering, University of Maryland, Baltimore County, 1000 Hilltop Circle,

Baltimore, MD 21250, USA

Abstract. The emergence of ad-hoc pervasive connectivity for devices based on Bluetooth-like systems provides a new way to createapplications for mobile systems. We seek to realize ubiquitous computing systems based on the cooperation of autonomous, dynamic andadaptive components (hardware as well as software) which are located in vicinity of one another. In this paper we present this vision.We also describe a prototype system we have developed that implements parts of this vision – in particular a system that combines agentoriented and service oriented approaches and provides dynamic service discovery. We point out why existing systems such as Jini are notsuited for this task, and how our system improves on them.

Keywords: service discovery, Jini, multi-agent system

1. Introduction

In the past year or two, the research community has seenplenty of hype associated with wirelesss, pervasive, mobileand ubiquitous computing. Mobile Commerce (M-Com-merce) in particular was declared as the “killer app” drivingthe wireless revolution. Cell phones and wirelessly con-nected PDAs essentially became mobile storefronts for e-tailers. We are all familiar with the ads of people buying stuffvia their cellphones from the beach. The drawbacks of thisidea are not hard to identify, as an increasing number of re-cent critical commentaries show. This approach essentiallyreplaces the desktop computers with the palmtop devices al-lowing users to order goods and access information in ananywhere and any time fashion. This client-proxy-server ap-proach has been developed by the academia over the last fiveor six years in contexts such as web access from mobile plat-forms (for instance [2,3,11–13,15,17])or transaction supportfor database access [8].

Variants of this approach are now emerging from sev-eral commercial companies in the form of systems that al-low phone based “microbrowsers” or PDAs to access do-main specific internet content, such as headline news, stocks,sports, etc., from designated portals. The WAP consortium(http://www.wap.com/) is leading efforts among telecommu-nication companies and service providers to evolve a stan-dard mechanism and markup language to support this. Therehave also been efforts, mostly from startups and e-tailers, toallow people to buy goods using the phone microbrowsers orPDAs. In some sense, one can think of this as a supermarketapproach, where a few identified service providers exist andthe traffic in services is one-way.

∗ This work was funded in part by NSF awards IIS 9875433 and CCR0070802, and an award from DARPA under the DAML program.

Viewed in a broader perspective however, M-Commercein particular, and Mobile Computing in general, have yetto be fully articulated or explored, especially in the contextof emerging mobile ad-hoc networks. Staying with the M-Commerce idea, let’s consider a move away from the pre-vailing mobile storefront vision. In the future, instead ofjust interacting with the “buy-it-yourself” web storefronts,consumers will be able to interact with service providers ina personalized way via automated service-oriented eMarketmodels. The selling of tangible goods will be one such ser-vice. Other services would include data, information, soft-ware components or even processing time/storage on net-worked machines. There will be no explicit clients andservers – but peers, often other persons/machines in onesvicinity, which can be both consumers and providers of dif-ferent services. M-Commerce will thus be transformed intowhat we refer to as Me-Commerce, or more generally, intoMe-Services – a personalized view of services dynamicallyavailable from fixed providers on the wired side, as well aswirelessly connected peers in the vicinity.

In this paper we describe our initial research efforts torealize ubiquitous computing systems based on the cooper-ation of autonomous, self-describing, highly interactive andadaptive components that are located in “vicinity” of one an-other. In such dynamic environments, service discovery be-comes a critical research problem. Hardware and softwarecomponents will automatically become aware of each otherand establish basic communication. They will also be ableto discover and exchange services with each other. In sec-tions 2 and 3, we describe our vision of the future mobilecomputing environment. The next section 4 discusses theweakness in the current service discovery schemes, whilesection 5 evaluates the Jini service discovery mechanism in amobile computing environment in light of these deficiencies.In section 6 we describe the design goals and the architec-

344 CHEN, JOSHI AND FININ

ture of the Ronin Agent Framework. In section 7 we presenta restaurant recommendation system called Agents2Go thatwe have developed based on the Ronin Framework. Our re-search findings are summarized in section 8.

2. Sojourns into the future

We envision our protagonist (Jane) driving down I95. Apalmtop and cellular phone are in her purse, and the carhas its own onboard computer. All these devices are net-worked using Bluetooth. The car’s onboard computer con-nects with computers in nearby cars using Bluetooth, and ex-changes information necessary to coordinate their driving ina Distributed Traffic Management Environment. Sometimeswhen the driver is not sure of things (where the nearest gasstation with a car wash is, for example), the computer canask the other cars around it. Every five miles or so downthe highway, while the car is within range of an electronic-sign or a rest area, it is connected to broadband high speedwireless LAN. While driving, Jane receives a page on thepalmtop alerting her that her office is sending her a fax. Herpalmtop dials out on the phone to retrieve the fax and re-quests that it be converted to an audio stream that can beplayed on her car’s sound system. The server cannot honorthis request, so the palm activates a proxy agent when thecar passes the next e-sign. This agent locates and negotiateswith fax-to-audio conversion services in the vicinity to ef-fect the conversion, and migrates to the next e-sign the carwill pass. When the car is in range, the proxy agent streamsthe audio to the car. After listening, Jane decides that thisis something she will need to read carefully. It is gettingclose to 7 in the evening, so Jane decides to call it a day.She tells her palmtop to book her a room at the next Chariotthotel and have the fax print there. She wants to have din-ner at a Mexican restaurant before going to the hotel. At thenext e-sign, the Palm device contacts the proxy agents forthe local hotel/motel and restaurant associations. It negoti-ates to get Jane the best possible deal on the room she wants(non smoking, king). It also finds out that the hotel and theMexican restaurant are at some distance, but that there is aTex-Mex restaurant close to the hotel which serves Jane’sfavorite dish. The Tex-Mex restaurant also agrees to printher fax at no extra charge, and the agent reserves her a table,downloads directions into her car’s computer and routes thefax to the restaurant’s printer.

3. Background and rationale

The basic assumption behind our work is that at the level ofcomputing and networking hardware, we will see dramaticchanges in the next few years. More specifically, we pre-dict the emergence of (i) palmtop and wearable/embeddablecomputers, (ii) Bluetooth-like systems which will provideshort range, moderate bandwidth connections at extremelylow costs, and (iii) widely deployed, easily accessible wire-less LANs and satellite WANs. We assume that there will

be a mixture of traditional low bandwidth systems and nextgeneration high speed ones. These developments will lead towireless networks that will scale all the way from ad hoc lo-cal area networks to satellite WANs, and link together super-computers, “walkstations” and embedded controllers. Thereis ongoing research in creating the hardware and low levelnetworking protocols that are needed to realize this vision.

The industry’s present vision of the use of Bluetooth-likedevices is fairly narrow – essentially as point-to-point com-municators to replace cables, similar to IrDA for computersand printers. However, both industry and academia have oflate realized that these devices can also be used in creating adhoc networks – e.g., when police and emergency personnelrespond to a call, their computers would automatically getnetworked when they come in each others’ vicinity. Thereis significant ongoing work in solving various network layerproblems associated with mobile ad hoc systems. The pointof departure for us is the creation of a software infrastruc-ture that can actually exploit ubiquity arising from ad hocnetworking, and enable a new class of applications.

In order for an entity to cooperate with others in its vicin-ity, it first needs to discover other entities as it moves intoa new location. This problem of “service discovery”1 hasrecently been explored in the context of distributed systemsand elsewhere. State of the art systems such as Jini [1], Salu-tation [20], Universal Plug and Play (UPnP) [16], as well asIETF’s draft Service Location Protocol [18,23] provide fornetworked entities to advertise their functionality. Withinthese newly emerged distributed systems, our evaluation [6]shows that Jini provides a more flexible and robust servicediscovery infrastructure for building distributed componentscomparing to other systems.

The Jini discovery infrastructure supports both unicastand multicast service discovery protocol. This infrastructureallows services to be found in a uniform way, either on a lo-cal or a remote network. The service advertisement takes theform of interface descriptions. This simple form of the ad-vertisement mechanism can be easily employed to providehigh-level of abstractions for both software and hardwareentities in the network. This is how a Jini-enabled printercan talked to a Jini-enabled digital camera. It is clear thatthe Jini discovery infrastructure provides a good base foun-dation for developing a system with distributed componentsneed to discover each other in the network. However, theJini discovery process is tightly bounded to the Java classinterface description advertisement. The simplicity of thismechanism is also the major weakness of the Jini servicediscovery architecture.

4. Defeciencies in existing service discoveryarchitectures

Architectures and systems like Service Location Protocol(SLP), Jini, Universal Plug and Play (UPnP) and Salutationhave recently been developed to explore the service discov-ery issues in the context of distributed systems. While many

DYNAMIC SERVICE DISCOVERY FOR MOBILE COMPUTING 345

of the architectures provide good base foundations for devel-oping systems with distributed components in the network,we argue that they are not sufficient for building the Me-Services environment due to the following:

• Lack of rich representations:Services in the Me-Services world are heterogeneous innature. These services are defined in terms of the theirfunctionalities and capabilities. The functionality and ca-pability descriptions of these services are used by the ser-vice clients to discover the desired services. The exist-ing service discovery infrastructures lack expressive lan-guages, representations and tools that are sufficient forrepresenting a broad range of service descriptions andare also useful for reasoning about the functionalitiesand the capabilities of the services [4]. In the Jini ar-chitecture, service functionalities and capabilities are de-scribed in Java object interface types [1]. Service capa-bility matchings are processed at the syntax-level onlyusing objects.

• Lack of constraint specification and inexact matching:Most of the discovery protocols only allow service re-quests to match exactly with service descriptions, andhave simplistic notion of contraints. For instance, thedefault registry that comes with Jini allows a serviceclient to find a printing service that supports B/W print-ing, but will not return a color printing service if itcan’t find a B/W one. The protocols do exact syntac-tic matching while finding out a service. Thus they lackthe power to give a close match even if it was avail-able. Similarly, the protocol will allow finding a printerat a given location or with a given sized print queue, butthe registry is not powerful enough to find a geograph-ically closest printing service that has the shortest printqueue.

• Lack of ontology support:Services need to interact with clients and other servicesin the vicinity. Service descriptions and informationneed to be understood and agreed among various par-ties. In another words, well-defined common ontologymust be present before any effective service discoveryprocess can take place in dynamic ad-hoc network sys-tems.We found that common ontology infrastructures are of-ten either missing from or not well represented in theexisting service discovery architectures. Architectureslike Service Location Protocol, Jini and Salutation doprovide some sort of mechanisms to capture ontol-ogy among services. However, these mechanisms likeJava class interfaces and ad-hoc data structures are un-likely to be widely adapted and become standards. Inthe Universal Play and Plug (UPnP) architecture, ser-vice descriptions are represented in XML (eXtensibleMarkup Language), which provides a good base foun-dation for developing extensible and well-formed ontol-ogy infrastructure [16]. However, service descriptionsin UPnP does not play a role in the service discovery

process [19]. Newer XML based semantic standards,such as RDF or DAML [7] are perhaps better suited forservice description.

5. Evaluating the Jini service discovery in a mobileenvironment

Jini provides an infrastructure for providing services in anetwork, and for creating spontaneous interactions betweenprograms use these services [1]. Services can join and leavethe network in a robust fashion. The Jini service leasingmechanism allows clients to be well informed of the avail-ablity of visible services.

Our studies show that the service discovery infrastructureis one of the shortcomings of Jini [6]. The weaknesses arethe following: (1) it is difficult to discover services that re-quire specific attribute value that are depended on the dy-namic content of the environment, (2) it is difficult for cross-domain services to discover and interoperate when servicedescriptions are expressed in the object-level and syntax-level.

The existing Jini architecture requires service advertise-ments to be expressed in the form of Java interface descrip-tions. For example, a printing service may advertise itselfas a generic printing service by implementing an interfacecalled Printer. If the printing service wants to advertiseitself as a color printer, then it may add an extra service at-tribute entry class called TypeOfPrinter with the stringvalue “Color Printer”. A client that is looking for acolor printer will ask the Jini Lookup Service to match foran advertised service that implements the Printer inter-face and has an attribute entry class TypeOfPrinterwiththe string value “Color Printer”.

When the Jini Lookup Service performs matching, thematching is done based on comparing the Java class inter-face types and the string values of the service attribute en-tries. This syntax level matching creates the obvious seman-tic interoperability problem. For example, two services arein the printer domain. One service implements an interfacecalled PrinterInterface, and the other implements thePrinter interface. Both of these have the same function-ality. Yet if a client is looking for a printing service usingthe Printer interface, then the Jini Lookup Service wouldnot match the service that uses the PrinterInterface.Similarly, when service descriptions are expressed in theobject-level and syntax-level, it is difficult for cross-domainservices to discover and interoperate with each other. Forexample, a digital camera client is looking for a printing ser-vice that is capable of printing 30 pictures with resolution1024 × 768 pixels in 30 min. It will be difficult for the JiniLookup Service to find a matching printing service if theprinting service domain uses dots per inch (dpi) instead ofpixels as the unit for measuring printing resolutions.

Another problem is that the Jini Lookup Service cannotperform inexact matching. For example, consider a printerservice that has advertised an attribute entry TypeOf-Printer with value “Color Printer”. When a client


is looking for a printer service that has an attribute entryTypeOfPrinter with value “Black and White”, itis intuitively obvious that the Color Printer should be re-turned as a match, especially if no B/W printers are found.However, the Jini Lookup Service is not capable of doingsuch type of reasoning.

Furthermore, due to the limitation of the Jini matchingstrategy, it is difficult to discover services that require spe-cific dynamic attribute values. For example, a client caneasily discover a color printer service, but it is difficult todiscover a printer service that is geographically the closest,since the notion of a “least of all X” type constraint is notpresent in Jini’s matching approach.

One way to enhance the Jini discovery mechanism is tore-implement or expand the existing Jini lookup process, forexample, by adding XML support as a rich service descrip-tion and lookup mechanism and by permitting fuzzy matchesand complex constraints. We have created such as systemcalled XReggie [14]. Another approach, which we will de-scribe in detail in this paper, is to apply the agent-orienteddesign model to the Jini service designs. In particular, clientslooking for services look to find broker agents using sim-ple Jini type approaches, and can then negotiate with thesebrokers using richer representations. The brokers can alsouse significantly more “intelligence” in the matching processthan Jini does.

6. Ronin agent framework

The Ronin Agent Framework introduces a hybrid approachto developing dynamic distributed systems based on thecomposition of the agent-oriented and service-oriented pro-gramming design [4]. The framework not only creates aflexible and robust development solution for creating multi-agent systems, but it also enhances the existing Jini servicediscovery, allowing services to be discovered based on thedomain-independent agent attributes. The proxy-orientedRonin Agent Deputy design allows remote hardware andsoftware services to be used as if they were local services.

6.1. Ronin design goals

The Ronin Agent Framework is designed to aid the devel-opment of dynamic distributed/mobile systems, taking theadvantages of the Jini architecture and the agent technology.The design goals of the framework are the following:

• Enhancing the service discovery mechinsim: By incorpo-rating agent attributes into the service discovery process,agents should be able to find each other as well as domainspecific brokers.

• Making knowledge sharing possible: The frameworkshould provide an infrastructure that allows distributedcomponents in a network to share and exchange knowl-edge easily.

• Supporting interagent communication using ACLs:Agent Communication Languages (ACLs) [9,10] such

as KQML or FIPA-ACL provide a great communica-tion infrastructure for heterogeneous agents to exchangecontent-rich knowledge about their environment. UsingACL communication, the protocols and the conversationsamong agents can be formally modeled and precisely de-fined.

• Promoting distributed AI tools: AI tools, such as knowl-edge representation systems, inference engines, logicprogramming tools, are very useful to the developmentof the future Me-Services environment, in particular increating sophisticated service discovery systems. Thesepowerful AI tools should be made available to the light-weight distributed components in the network.

• Handling mobility related constraints: Mobile networkspresent well known problems of low bandwidth and elec-tive disconnections. The system should hide these prob-lems as much as possible.

• Enhancing the Jini service development process: It is im-portant not to create a solution that is more complicatedthan the original problem. The Ronin framework shouldenhance and simplify the deployment process, overcom-ing the weakness of the existing Jini development envi-ronment.

6.2. Ronin architecture overview

Ronin is written in Java. The framework is built on theexisting Jini technology (Jini Technology Starter Kit, ver-sion 1.1 beta 2). The Ronin package provides an agent-oriented development abstraction to the existing service-oriented Jini development; enhances the Jini service devel-opment processing and provides a Jini Prolog Engine Ser-vice, which provides reasoning, knowledge representationand logic programming functionalities.

The key components of Ronin are the following: (1) Ro-nin Agent, (2) Ronin Agent Deputy, (3) Ronin Agent At-tributes and Domain Attributes, (4) Jini Prolog Engine Ser-vice (JPES). In the following subsections, we will describethese key components and their related components in detail.Specifically, we will concentrate our discussion on the Roninagent architecture, the agent communication infrastructure,the agent description facility and the logic programming fa-cility.

6.2.1. Ronin agentA Ronin agent is a metaphor for defining an integerated col-lection of Java classes and interfaces that funcations accord-ing to certain pre-defined agent behavior. It is not the classsignatures that define a Ronin agent; it is the combined be-havior of the classes that defines an agent.

A Ronin agent has two sets of behaviors: the genericagent behaviors and the domain specific behaviors. Thegeneric agent behaviors are the actions that are common toall Ronin agents. For example, all Ronin agents need toadvertise a set of agent attributes that describe their func-tionality and capability to the Lookup Service. On the other


hand, the domain behaviors differ from one agent to another.These behaviors uniquely define an agent in the system. Forexample, the domain behavior of a Ronin agent that man-ages the printing service is very different from the domainbehavior of a Ronin agent that provides restraurant recom-mendation services.

Ronin provides facilities (classes and interfaces) that de-fine the generic agent behaviors of an agent. These facilitiesdefine the infrastructures for (1) the Ronin Agent Deputyrealization, (2) the agent capabilities and funcationality de-scriptions and (3) interagent communication. All Roninagents are required to have at least one Agent Deputy. AnAgent Deputy acts as a proxy for the Ronin agent to otheragents in the network.

Ronin agents are required to provide descriptions abouttheir capabilities and funcationalities using the Ronin AgentDescription Facility. Agents are described in terms oftheir agent attributes (those attribute classes implement theAgentAttribute interface) and their domain attributes(those attribute classes implement the DomainAttributeinterface). The descriptions of an agent are advertised to theLookup Service the same way as any other Jini service en-tries.

Ronin agents communicate with other agents using anAgent Communication Language. However, Ronin does not

have any restriction on the ACL that agents can use. Roninleaves the decision of adapting the kinds of ACL standard tothe agent developers.

In contrast to the generic agent behavior facilities that arespecified and provided by Ronin, it does not specify howthe agent domain behaviors should be implemented. Roninleaves the decision of crafting agent domain behaviors to theagent developers.

6.2.2. Ronin agent deputyA Ronin Agent Deputy is an object that acts as a proxy forthe Ronin Agent in the network. The main duties of an AgentDeputy are (1) mediating agent communication on the behalfof the owner agent and (2) providing a local agent represen-tation of the owner agent in the network. Figure 1 showsthe interactions between two Ronin agents and the AgentDeputy.

A concrete Agent Deputy implementation is a serializableclass that implements the AgentDeputy interface (see fig-ure 2). All of the concrete Agent Deputy implementationclasses are required to confront to the functional specifica-tion of the AgentDeputy interface methods.

The funcational specification of the deliveryMes-sage()method defines that this method is to be invoked bya message-sending agent when it requests the Agent Deputy

Figure 1. The interactions between the Ronin agents and Agent Deputy.

public interface AgentDeputy {public void deliveryMessage(Envelope e, boolean wait);

public void addDeliveryNotificationListener(DeliveryNotificationListnerlistener);

public void removeDeliveryNotificationListener(DeliveryNotificationListenerlistener);

}

Figure 2. AgentDeputy interface.


of the message-receiving agent to delivery a message to itsowner agent. The message is wrapped within an Envelopeobject.

The message delivery scheme can be implemented eitheras a synchronous or an asynchronous process. For exam-ple, a synchronous delivery scheme can be implemented us-ing socket communication procedures between the ownerRonin agent and the Agent Deputy. An asynchronous deliv-ery scheme can be implemented as a set of Remote MethodInvocation (RMI) calls [21], based on the Remote EventModel [1,22] between the owner Ronin agent and the AgentDeputy.

The AgentDeputy interface class also provides anevent notification mechanism that allows message-sendingagents to receive notifications regards the status of individ-ual message delivery process. (More details on the messagedelivery notification mechanism can be found in [4].)

The Ronin framework provides two abstract Agent Depu-ty implementation classes, AbstractDeputy andAbstractAdminDeputy. Both classes implement theAgentDeputy interface. The AbstractAdminDeputyclass extends the AbstractDeputy class and implementsthe net.jini.admin.Administratable interface,which provides common ways to export particular admin-istrative funcationality [1].

The AbstractDeputy class provides a basic imple-mentation of the AgentDeputy interface. In addition itdefines a flexible design pattern that allows agent developersto customize the transport mechanism for delivering the En-velope object from the Agent Deputy to the owner agent.The transport mechanism that is used by an Agent Deputyis encapsulated within the logic of the Transport objectimplementation (see figure 4). Every instance of the Ab-stractDeputy class contains an Transport object. Anagent developer can configure the AbstractDeputy classto use any Transport implementation of his/her choice.This achieves the goal of creating Agent Deputies with func-tionality that is independent from the low-level message de-livery mechanism.

public interface DeputyLocator {AgentDeputy getAgentDeputy();

}

Figure 3. DeputyLocator interface.

The benefits of using this particular pattern can be ob-served from the the following example. At runtime whenthe deliverMessage() method is invoked on the Abs-tractAgentDeputy object, the deputy delegates themessage transport task to the contained Transport ob-ject. The Transport object might decide the appropriatenetwork communication (using RMI, network socket calls,etc.) and the protocol (HTTP, HTTPS, etc.) to use to de-liver the message. It might also decide to provide more so-phisticated message delivery managements, such as messagefiltering, message store-and-forward, message multiplexingand message demultiplexing [1,22].

There are two possible ways to locate an Agent Deputy.One way is to locate an Agent Deputy through the use ofthe Jini Lookup and Discovery Protocol, and then to down-load the Agent Deputy from the Jini Lookup Service. Thesecond way is to extract an Agent Deputy by calling thegetAgentDeputy() method on the DeputyLocatorobject. This object can be extracted from the Envelopeobject by invoking the getSenderDeputyLocator()method.

The Envelope object is a container class that con-tains the message that is to be delivered to the message-receiving Ronin agent. In addition it also has a referenceto a DeputyLocator object that can be used to extractthe AgentDeputy object of the message-sending agent.

The DeputyLocator interface has only one method(see figure 3), getAgentDeputy(), which returns aninstance of the AgentDeputy class. The Abstract-Deputy class does not define the actual implementation ofthis method. The decision of how to extract an Agent-Deputy instance is left to the agent developers to decide.The goal of such design is to allow an individual devel-oper to create his/her own solution to the problem of re-turning a reference to the AgentDeputy object to the re-questor.

In some systems, it might be desirable for the developerto create a DeputyLocator that contains a direct refer-ence to a serialized AgentDeputy object. When the get-AgentDeputy() method is invoked, the reference to theAgentDeputy object is simply returned. On the otherhand, sometimes it might be desirable for the developer tocreate a DeputyLocator that dynamically discovers or

public abstract class AbstractDeputy implements AgentDeputy, Serializable {protected Transport transport;protected EventListenerList nofitificationListners;

public AbstractDeputy(Transport transport){...}public void addDeliveryNotificationListener(DeliveryNotificationListener

listner){...};public void fireDeliveryNotificationEvent(DeliveryNotificationEvent e){...}public Transport getTransport(){...}public void removeDeliveryNotificationListener(DeliveryNotificationListener

listener){...}}

Figure 4. AbstractDeputy abstract class.


Figure 5. The class diagram of the Agent Attribute classes.

downloads an AgentDeputy from the network when thegetAgentDeputy() method is invoked.

6.2.3. Ronin Agent Attributes and Domain AttributesThe Ronin Agent Attributes provide a basic agent ontologyfor Ronin agents. These attributes describe the capabilityand the functionality of an agent in a domain-independentfashion.

The Ronin Agent Attributes consist of five Java classes:AgentID, AgentLang, AgentOntology, Agent-Owner and AgentRole. All of these classes extend thenet.jini.entry.AbstractEntry from the JiniTechnology Core Platform and implement the Agent-Attribute interface from the Ronin Agent Framework.Figure 5 shows the class diagram of the Ronin Agent At-tribute classes.

Ronin defines the semantic meanings of the Ronin AgentAttributes. The AgentID attribute contains a uniqueagent identifier. The format of this identifier is expressedin the email address format. For example, [email protected].

The AgentLang attribute specifies the Agent Commu-nication Language that one agent can understand. Thisattribute is defined in terms of three string fields: for-mat, language and ontology. The format field de-fines the encoding scheme of the Agent CommunicationLanguage. For example, the scheme might simply be thejava.lang.String. The language field specifies thename of the Agent Communication Language (for example,KQML, FIPA, etc.). The ontology field is an ontologyidentifier of the Agent Communication Language (for ex-ample, AGENTS2GO-ONT).

The AgentOntology attribute contains the ontologyidentifer of the Ronin agent. The ontology of the agent ispredefined prior to the development of the agent. This at-tribute is mainly used in the agent lookup process by the JiniLookup Service.

The AgentOwner attribute specifies the name of the in-stitution or the organization that owns the agent. This at-tribute is defined as a single string field, namely “owner”.

The AgentRole attribute specifies the acting role of theagent in the system. A Ronin agent can take on one of thesix possible acting roles: BROKER, MATCHER, MEDIATOR,PROBLEM SOLVER, PROXY or DEFAULT. The DEFAULTrole is assumed to be the default role of an agent if no otherrole values is supplied.

These agent attributes are required to be supplied by theindividual Ronin agent. When Ronin agents come alive, theyregister these agent attributes as the Jini service attributeswith the Jini Lookup Service.

6.2.4. Jini Prolog Engine ServiceJini Prolog Engine Service [5] is a Jini service that providesthe remote Prolog engine accesses to Jini-enabled compo-nents in the network. JPES provides a simple solution tobring inference engine and knowledge base facilities to thedistributed system.

Like other Jini services, JPES defines a generic Prologengine service interface, which allows users to perform Pro-log operations without caring about the underlying imple-mentation and the location of the actual Prolog engine. Italso allows users to load predefined prolog statements froma URL.

The current version of JPES uses the SICStus Prolog im-plementation as its core Prolog engine. However, the designof the JPES allows the replacement of the core Prolog enginewith any other Prolog implementations without affacting theJPES client implementations The main reason we choose touse the SICStus Prolog implementation as the core Prologengine is because the SICStus Prolog implementation comeswith a simple Java JNI API library, namely Jasper, that al-lows Java programs to access the Prolog engine.

Figure 6 shows the JPEServer interface class that areused by the JPES clients to access the remote Prolog en-gine. The loadSourceFile method allows the serviceclient to load a set of predefined Prolog statments into theProlog engine from a URL. The query, queryAll andqueryCutFail methods are provided to the clients tomake queries to the Prolog engine.

One of the advantages of using JPES with Ronin agents isthat it eliminates the requirement of the existence of heavy-


public interface JPEServer extends java.rmi.Remote{

public void loadSourceFile(java.net.URL url)throws java.rmi.RemoteException;

public JPESResult query(JPESQuery query)throws java.rmi.RemoteException;

public JPESResult[] queryAll(JPESQuery query)throws java.rmi.RemoteException;

public JPESResult queryCutFail(JPESQuery query)throws java.rmi.RemoteException;

}

Figure 6. JPEServer interface.

weighted Prolog engines on the physical machines where theagents are executed. In addition, sharing one JPES servicebetween a group of agents provides a simple way for agentsto share knowledge.

7. Agents2Go: a smart restaurant recommendationsystem

We have defined a scenario to demonstrate the feasibility ofusing the Ronin Agent Framework to support mobile com-puting, called Agents2Go.

The Agents2Go project strives to create a smart restau-rant recommendation system in the future mobile comput-ing environment. A typical Agents2Go usage scenario canbe described as the following: You are on a business tripfrom a foregin country visiting Baltimore. During the lunchhour, you are walking down the street looking for a restau-rant. Since you are not familiar with the Baltimore area anddo not have a traveler’s guide to the local restaurants, youturn on your PDA or cell phone and ask it to help you tofind a restaurant. Given that your device is connected to thelocal network wirelessly, your agent that lives on the devicefinds one or more local restaurant recommendation services,and interacts with these services. It provides them with yourpreferences regarding cuisines, costs, wait times, etc., andreturns back to you with a list of recommended restaurants.You can then makes reservation at one of the restaurats onthe list.

7.1. The existing restaurant recommendation system

At first it might seem to be trivial to realize such scenario. Infact a number of Yellow Page like portal services are avail-able on the Internet today (e.g., zagat.com) that providessimilar restaurant recommendation services. Some of thesealso allow users to make requests through WAP-enabled cellphones and wireless PDAs (e.g., citysearch.com and restau-rantrow.com).

However, the restaurant information that is provided bymost of the existing services is stored in centralized data-bases. Further, they provide only static attributes, such asa restaurant’s location, cuisine etc. Clients access the infor-

mation by communicating with centralized server applica-tions. Such systems cannot easily make use of the dynamiclocation-depedent information as a part of the recommenda-tion process. For example, it is difficult for these servicesto consider the current waiting times of the restaurants, orthe current traffic conditions, or any specials/discounts therestaurants may be offering, when making the recommenda-tions to users.

7.2. Agents2Go architecture overview

The Agents2Go restaurant recommendation system is builton top of the Ronin. Agents2Go provides a dynamic andpersonalized system that is capable of making recommen-dations to users based on the dynamic location-dependentinformation.

At its core, the Agents2Go recommendation system is nota centralized server application. Instead it takes a distributedapproach, the Agents2Go system is built based on a collec-tion of distributed restaurant agents, restaurant recommen-dation broker agents and personal agents. Agents are real-ized using the Ronin Agent Framework. When agents comealive, they discover the local Lookup Services and registertheir Agent Deputies. Taking the advantages of the Jini Dis-covery and Lookup Protocols, these agents are capable ofdynamically joining and leaving the system in a flexible androbust fashion.

Figure 7 shows an architecture diagram of the Agents2Gosystem. The restaurant agents represent the restaurants inthe community. These agents are responsible for providingboth static and dynamic restaurants information to the per-sonal agents and the local restaurant recommendation brokeragents. The restaurant agents provide information to otheragents by extracting data from their local SQL databases.With this approach, dynamic information of the restaurantssuch as the current waiting time and the chef’s spcial ofthe day can be updated in the local SQL database. Newinformation is made available to agents in system instanta-neously. The tasks that are currently assigned to the restau-rant agents are (1) maintaining and updating the restaurantdatabases, (2) providing information about the restaurantswhen query requests are received from the recommendationbroker agents, (3) providing reservation services to the per-sonal agents and (4) discovering new Jini Lookup Servicesand registering the Agent Deputies of the restaurant agentswith the Jini Lookup Services.

The recommendation broker agents are responsible formaking restaurant recommendations to the human users.The broker agents periodically discovers the existence of thelocal restaurant agents that are within their contact range.(In the current implementation, the broker agent only pullsthe restaurant agents that are registered with the Lookup Ser-vice.) The broker agents share the set of restaurant recom-mendation ontology with the local restaurant agents. Whena broker agent is asked to make a recommendation by a userspersonal agent, but it does not have sufficent information inknowledge base about the local restaurants, it queries the lo-


Figure 7. Agents2Go architecture.

cal restaurant agents to retrieve updated information aboutthe restaurants. For example, in the current implementation,the query action is taken by the broker agent when the wait-ing time of the local restaurants are out of date.

The Agents2Go system is targeted to work with userswho have handheld devices that are capable of executingJini-enabled Java applications. However, due to the com-putation resource limitation of the existing handheld deviceslike Palm(III, V, VII), the current mobile application that ex-ecutes on the Palm device relies on a Ronin agent actingas a proxy that lives in a computer on the wired side. Themobile application on the palm is responsible for renderingGUI display, taking input from the user and mediating thecommunication between the user and the personal agent.

7.3. Developing the restaurant agents

In the current implementation, a restaurant agent consistsof the following components: (1) a connnection handle tothe database of the restaurant it represents, (2) an agentlogic/behavior component, which contains logic for theagent to interact with others in the system, (3) a set of AgentAttributes and Restaurant Domain Attributes, (4) an AgentDeputy, which acts a proxy for the agent in the Ronin agentworld.

When a restaurant agent comes alive, it first creats an in-stance of the Agent Deputy, then initializes its Agent At-tributes and Restaurant Domain Attributes accorrding to therestaurant attribute definitions that are given in the agentconfiguration file. Once the Agent Deputy is properly con-figured, the agent executes the Jini Discovery Protocol trying

to find Jini Lookup Services in the local community. If a JiniLookup Service is discovered, the restaurant agent registersthe Agent Deputy with the Jini Lookup Service along withthe Agent Attributes and the Restaurant Domain Attributes.These attributes are registered as the Jini service entries. Ifthe registration process succeed, then the restaurant agentgoes into a waiting mode – waiting to receive ACL mes-sages from either the restaurant broker agents or the personalagents.

The restarurant agents can be thought as the representa-tives of the restaurants in the Agents2Go world. The currentdesign that distributes the individual restaurant informationamong agents has many advantages over the design of stor-ing restaurant information in a centralized server applica-tion. With the distributed agent approach, individual restau-rant agent only has to manage a relatively small set of infor-mation that is only related the restaurant(s) that it represents.Furthermore, this information can be stored and structured inany way that the restaurant’s system desires. As long as allagents in the system share the same ontology and the ACLmessages schema, any changes that are made to the internalrestaurant systems would not affact the overall system. Thisreduces the maintainence overheads that are often encountedby the centrailized database-driven systems.

7.4. Developing the restaurant recommendation brokeragents

In the current implementation, a broker agent consists of thefollowing components: (1) a proxy object of a JPES service,(2) an agent logic/behavior component, which contains log-


ics for the agent to interact with others in the system, (3) a setof Agent Attributes and Restaurant Domain Attributes thatidentifies the agent as a broker agent, (4) an Agent Deputy,which acts a proxy for the agent in the Ronin agent world.

The broker agent uses the Prolog engine that is providedby the JPES as its inference engine and knowledge base.During the initialization stage, the broker agent instructs theJPES service to load a set of restaurant recommendation Pro-log rules from a remote URL to setup its inference engineand knowledge base.

During the recommendation stage, when the broker agentis requested by the personal agents to provide restaurant rec-ommendations, the broker agent first converts the incomingrequest into a set of Prolog facts and rules expressing thepreferences (e.g., cuisine is Japanese) and constraints (e.g.,cost < $15) of the user, and then inserts these into the JPESinference engine. Once all rules and facts have been in-serted, the broker agent executes the recommendation rulesto seek for restaurants that have attributes that satisfy the re-quest contraints. Thus a more intelligent match can be donecompared to Jini’s limited syntactic match.

At any stage if information about certain restaurants is ei-ther missing or out of date, the broker agent will send outrequest for information to the restaurant agents to update itsknowledge base. Once requested information are received,the broker agent converts the information into Prolog factsand inserts them into its knowledge base using the JPES ser-vice.

7.5. Developing the personal agent

Ideally a personal agent should live on the handheld deviceof the user, so that personalized services can be constantlyavailable to the user at all time. When a user has activated thepersonal agent, it dynamically discovers the broker agents inthe system. Then the recommendation process begins.

However, due to the computation limitation of the exist-ing handheld devices, the current implementation of the per-sonal agent is seperated into two parts, a mobile applicationpart (Agents2Go Mobile) that executes on the handlehandPalm device and a Ronin personal agents proxy that exe-cutes on the wired side. These two components cooperatewith each other to fulfill the tasks of the personal agent.

The Agents2Go Mobile is a program that executes on aPalm device that is connected via a CDPD network (see fig-ure 8). This Palm application is implemented in the C pro-gramming language. It is responsible for rendering graphicdisplay on the Palm device and interacting with the user. Itis also responsible for transmitting user input requests to theRonin personal agent on the local network machine. Whenthe Agents2Go Mobile is activated, it makes a wireless net-work connection with the Ronin personal agent through theOmniSky wireless network. The contact information of theRonin personal agent on the network is pre-configured as apart of the Agents2Go Mobile program preferrences.

If the connection is made successfully, then theAgents2Go Mobile downloads the restaurant recommenda-

Figure 8. A snapshot of the Agents2Go Mobile Palm application.

tion form data from the the personal agent and renders theform on the screen. This form provides the data model forthe Agents2Go Mobile to display the form. The data modelis simply expressed as key-value pairs in strings. This allowsdifferent brokers to potentially provide different forms thatare tailor-made to the recommendation service they provide.For example, the broker would provide only those cuisinetypes as choices that it knew corresponded to local restau-rants.

Before any recommandation request is made, the userfirst authenticates himself/herself with the Agents2Go Mo-bile. If the authentication process succeed, then the Agents-2Go Mobile instructs the running personal agent to start theJini discovery process to find an local restaurant broker agentin the community. From this point on, any requests that aresubmitted to the Agents2Go Mobile from the user is directlydelivered to the personal agent.

After a personal agent has received a discovery requestfrom the Agents2Go Mobile over the network, it starts thestandard Jini Discovery and Lookup Protocols. It first tries todiscover a close-by Jini Lookup Service, and then it tries tolookup a restaurant recommendation agent using the RoninAgent Attributes and the Restaurant Domain Attributes.

If there is an appending recommendation request fromthe Agents2Go Mobile, the personal agent starts a restau-rant recommendation ACL conversation with the availablerecommendation broker agent. It then returns the recom-mendation results back to the Agents2Go Mobile. All ACL


communication messages are expessed in KQML, and thecontent messages are expressed in Prolog-like rules.

8. Conclusion

Computing is no longer a discrete activity bound to a desk-top; mobile computing is fast becoming a part of everydaylife. The emerging mobile networking technologies will cre-ate a world where persons and devices will wirelessly inter-act with other devices all around them, in addition to inter-acting with tethered networked entities. In order to developa mobile e-services system which will use such networks,these hardware/software components need to be aware ofothers components in their vicinity, and interact and inter-operate with them.

The Ronin Agent Framework, which we present in thispaper, introduces a hybrid architecture, a composition ofservice-oriented and agent-oriented architectures, that pro-vides a simple and uniform scheme for deploying highlydynamic distributed “intelligent” components in a mobileworld that easily discover and communicate with otherscomponents. We also present the Agents2Go system whichuses Ronin to create a restaurant recommender system forthe mobile scenario that provides for discovery and intelli-gent matching in a dynamic environment.

Note

1. We use the term service here in a broad sense.

References

[1] K. Arnold, A. Wollrath, B. O’Sullivan, R. Scheifler and J. Waldo, TheJini Specification (Addison-Wesley, Reading, MA, USA, 1999).

[2] H. Bharadvaj, A. Joshi and S. Auephanwiriyakyl, An active transcod-ing proxy to support mobile web access, in: Proc. IEEE Symp. onReliable Distributed Systems (October 1998).

[3] E.A. Brewer, R.H. Katz, Y. Chawathe, A. Fox, S.D. Gribble, T. Hodes,G. Nguyen, T. Henderson, E. Amir, H. Balakrishnan, A. Fox, V. Pad-manabhan and S. Seshan, A network architecture for heterogeneousmobile computing, IEEE Personal Communications Magazine 5(5)(1998) 8–24.

[4] H. Chen, Developing a dynamic distributed intelligent agent frame-work based on the Jini architecture, Master’s thesis, University ofMaryland Baltimore County (January 2000).

[5] H. Chen, Jini prolog engine service (jpes) (2000). Available onlinefrom http://gentoo.cs.umbc.edu/jpes/.

[6] H. Chen, D. Chakraborty et al., Service discovery in the future elec-tronic market, in: Proc. Workshop in Knowledge Based ElectronicMarket, AAAI (AAAI Press, 2000).

[7] J. Davis, The semantic web, Daily Insight, INSIGHTS Online News(September 2000). http://www.business2.com/content/insights/dailyinsights/2000/09/27/1996%9.

[8] M. Dunham, A. Helal and S. Balakrishnan, A mobile transac-tion model that captures both the data and movement behavior,ACM/Baltzer Journal of Mobile Networks and Applications 2(2)(1997) 149–162.

[9] T. Finin, Y. Labrou and J. Mayfield, Kqml as an agent communicationlanguage, in: Software Agents, ed. J. Bradshaw (MIT Press, 1997).

[10] FIPA, Geneva, Switzerland, FIPA ACL Message Structure Specifica-tion, 2000/08/01 edition (August 2000).

[11] A. Joshi, S. Weerawarana and E.N. Houstis, Disconnected browsingof distributed information, in: Proc. 7th IEEE Int. Workshop on Re-search Issues in Data Engineering, IEEE (April 1997) pp. 101–108.

[12] A. Joshi, On proxy agents, mobility and web access, ACM/BaltzerJournal of Mobile Networks and Applications (2000) (accepted forpublication, also available as UMBC CS TR 99-02).

[13] R.H. Katz, E.A. Brewer, E. Amir, H. Balakrishnan, A. Fox, S. Gribble,T. Hodes, D. Jiang, G.T. Nguyen, V. Padmanabhan and M. Stemm,The bay area research wireless access network (barwan), in: Proc.Spring COMPCON Conference (1996).

[14] L. Xu, Using Jini and XML to build a component based distributedsystem, Technical report, University of Maryland Baltimore County(2000).

[15] M. Liljeberg, M. Kojo and K. Raatikainen, Enhanced services forworld-wide web in mobile wan environment, http://www.cs.Helsinki.FI/research/mowgli/mowgli-papers.html (1996).

[16] Microsoft Corporation, Universal Plug and Play Device ArchitectureReference Specification, version 0.9 edition (1999).

[17] B.D. Noble, M. Satyanarayanan, D. Narayanan, J.E. Tilton, J. Flinnand K.R. Walker, Agile application-aware adaptation for mobility, in:Proc. 16th ACM Symp. on Operating System Principles.

[18] C. Perkins, Rfc 2002: Ip mobility support, Technical report, IBM(1996).

[19] R. John, UPnP, Jini and Salutaion – A look at some popular coordi-nation framework for future network devices, Technical report, Cali-fornia Software Labs (1999). Available online from http://www.cswl.com/whitepaper/tech/upnp.html.

[20] The Salutation Consortium Inc., Salutation Architecture Specification(Part-1), version 2.1 edition (1999).

[21] Sun Microsystems, 901 San Antonio Road, Palo Alto, CA 94303,USA, Java Remote Method Invocation Specification, revision 1.5, jdk1.2 edition (October 1998).

[22] Sun Microsystems, 901 San Antonio Road, Palo Alto, CA 94303,USA, Jini Distributed Event Specification, revision 1.0 edition (Janu-ary 1999).

[23] SVRLOC Working Group, SLP White Paper, SVRLOC WorkingGroup (May 1997).

Harry Chen is a Ph.D. student and a Graduate Re-search Assistant of Computer Science and Electri-cal Engineering at UMBC. He obtained both Bach-elor of Science degree and Master of Science de-gree in computer science from UMBC in 1998 and2000, respectively. His research interests are inthe fields of mobile computing and artificial intelli-gence. He is the author of Ronin Agent Frameworkand the co-author of the Agents2Go system. In thesummer of 2000, he did his research internship withHP Labs in Palo Alto, CA. In 2001, he is awardedthe Ph.D. research fellowship of HP Labs. He is astudent member of ACM and IEEE.E-mail: [email protected]

Anupam Joshi is an Associate Professor of Com-puter Science and Electrical Engineering at UMBC.Earlier, he was an Assistant Professor in the CECSdepartment at the University of Missouri, Columbia.He obtained a B. Tech degree in electrical engi-neering from IIT Delhi in 1989, and a Mastersand Ph.D. in computer science from Purdue Uni-versity in 1991 and 1993, respectively. His re-search interests are in the broad area of networkedcomputing and intelligent systems, and in partic-ular in mobile computing and mobile data man-


agement. He has worked on the problem of cre-ating intelligent agent based middleware to supportmobile access to networked computing and multi-media information resources. He is also interestedin Web Mining and Personalization, Content-basedretrieval of video data from networked repositories,and networked HPCC. He has published over 50technical papers, and has obtained research sup-port from NSF, NASA, DARPA, AetherSystems,IBM, AT&T and Intel, including the prestigiousCAREER award from the National Science Foun-dation in 1999 to work on Multiagent Systems forMobile Information Access. He has presented tu-torials in conferences, served as guest editor forspecial issues for IEEE Personal Comm., Comm.ACM, etc., and serves as an Associate Editor ofIEEE Transactions of Fuzzy Systems. At UMBC,Prof. Joshi teaches courses in Operating Systems,Mobile Computing, and Web Mining.E-mail: [email protected]

Timothy W. Finin is a Professor of computer sci-ence and electrical engineering at the University ofMaryland Baltimore County. He has had over 25years of experience in the applications of ArtificialIntelligence to problems in database and knowl-edge base systems, intelligent information systems,natural language processing, intelligent interfacesand robotics. His current research is focused onthe theory and applications of intelligent softwareagents. Prior to joining the UMBC, he was a Tech-

nical Director at the Unisys Center for AdvancedInformation Technology, a member of the facultyof the University of Pennsylvania, and on the re-search staff of the MIT AI Lab. He holds an SBdegree in EE from MIT and a Ph.D. in computerscience from the University of Illinois. Finin is theauthor of over 120 refereed publications and hasreceived research grants and contracts from a va-riety of sources including NSF, DARPA, AFOSR,ARO, NASA, NIST, NSA, IBM, HP, TI, DEC andFujitsu. He has been the past program chair andgeneral chair of the IEEE Conference on ArtificialIntelligence for Applications, the general chair ofthe first two ACM Conferences on Information andKnowledge Management and the program co-chairof the Second ACM Autonomous Agents confer-ence. He is currently on the editorial board of fourjournals, a former AAAI councilor and sits on theboard of directors of the Computing Research As-sociation.E-mail: [email protected]

Dynamic Service Discovery for Mobile Computing: Intelligent Agents Meet Jini in the Aether

Documents

Transcript of Dynamic Service Discovery for Mobile Computing: Intelligent Agents Meet Jini in the Aether