for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be
obtained from the IEEE.
For more information, please see www.ieee.org/portal/pages/about/documentation/copyright/polilink.html.
MOBILE AND UBIQUITOUS SYSTEMS www.computer.org/pervasive
An Agent-Based Service Network for Personal Mobile Devices
Alessandro Genco, Salvatore Sorce, Giuseppe Reina, and Giuseppe Santoro
Vol. 5, No. 2 April–June 2006
This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works
may not be reposted without the explicit permission of the copyright holder.
An Agent-Based ServiceNetwork for PersonalMobile Devices
Pervasive computing aims to dispersesmart devices throughout the realworld to supply various services, butsuch devices should remain invisible tothe user—that is, pervasive computing
mustn’t become invasive computing. Yet, we can’thide devices designed to help humans interactwith an augmented environment—that is, the nat-ural environment enriched with smart devices.Furthermore, such interaction shouldn’t be the
same for all users. Designinguniversal interfaces that ignorethe differences in people’s needsand abilities could lead to sys-tem specifications that don’t sat-isfy anyone. We can avoid suchproblems by exploiting personal
mobile devices (such as PDAs and smart phones)for human-environment interaction. Such devicescould be suitable as remote controllers or personalI/O interfaces for remote applications.
We propose the Agent Network for BluetoothDevices, a system that uses personal mobiledevices as adaptive human-environment inter-faces to supply people with ad hoc informationand high-level services. The ANBD system oper-ates with a hierarchical framework of service-providing nodes, dynamically composed and man-aged by mobile agents.
Our system’s novelty lies in its ability to dynam-ically adapt itself to environmental changes. Fur-thermore, accessing system services requires littleoverhead in terms of users’ required technicalskills and the necessary software. We achieved
this result using Bluetooth implementations thatare available in most mobile devices. In addition,the services and access modes we propose arestraightforward, modifications can be madeonline, and the only hardware needed to accesssystem services is a cell phone.
System featuresWe designed our ANBD system with a mobile-
agent-based software framework to implementthe information retrieval function regardless ofthe physical network composition. (See the“Related Work in Mobile Agents” sidebar fordetails on other research.) We chose mobile agentsbecause they can move from one site to anotherwith no initial knowledge of the sites they need tovisit. We only need to tell them what to do in eachsite as they visit it. They can retrieve the addressof the next site they’ll visit while visiting their cur-rent site.
We also designed a framework to support thesystem’s hardware. It comprises fixed, networkeddevices (wired or wireless) hidden in the real-world environment. The framework’s architec-ture is hierarchical, and we divided the environ-ment into logical areas, each accomplishingspecific tasks within the network and each hav-ing an appropriate scope. Hence, ANBD is scal-able, modular, and general purpose. It could beuseful in various locations, including universities,hospitals, large stores, or museums, even if com-posed of small physical parts such as universitydepartments and classrooms, hospital wards, orwings of large stores or museums.
The Agent Network for Bluetooth Devices lets users access ad hocinformation and high-level services using personal mobile devicesenhanced with mobile agents.
Alessandro Genco, Salvatore Sorce,Giuseppe Reina, and Giuseppe SantoroUniversity of Palermo
The physical network’s definitiondepends on the physical environment’sconfiguration. In any case, the networkwill consist of an appropriate set ofdevices belonging to two groups:
� mobile devices, such as PDAs, smartphones, notebooks, or laptop com-puters, that are Bluetooth-enabled andequipped with the Java 2 Micro Edi-tion (J2ME) execution environment,and
� fixed devices, such as PCs exploited asdatabase or agent servers, and Blue-tooth access points that connectmobile devices with the fixed part ofthe system.
Another ANBD system goal is for sys-tem administrators to be able to make
services available to a large heteroge-neous audience, so the service network’susers shouldn’t need programming skills.Furthermore, the system shouldn’t requireadditional software or network accessfees. To this end, we restrict agents tooperate and move along fixed devices,and mobile devices are only devoted tothe human-environment interface.
ANBD layoutWe divide the environment in which
ANBD will be used into logical areas,each belonging to a given hierarchicallevel. The number of levels depends onthe physical environment’s size (see fig-ure 1). We can create two or more logi-cal areas to obtain a simple subnet, whichwe can then connect to other subnets toform a bigger network. Each area or sub-
net can be connected to (or disconnectedfrom) the network at any time, thus lead-ing to dynamic distribution levels. Eachlogical area acts as an autonomous entitywhen it’s disconnected from any othersubnet, and users within the area canonly access local services.
There are two main area types. Serviceareas (first-level areas) are the smallestentity within the ANBD framework. AnSA consists of networked Bluetooth basestations (BT-BSs), and its physical sizecorresponds to the signal coverage of itsBT-BSs. Users can access informationstored in the SA central server throughBT-BSs used as anchor nodes for mobiledevices. We can also connect each cen-tral server to a remote server to supplyusers with more services and to lightenthe SA’s central server load.
APRIL–JUNE 2006 PERVASIVEcomputing 55
I n some projects, researchers use PDAs or cell phones with
application execution environments as interfaces for devices
hidden in the environment.1 Takuya Maekawa and his colleagues
implemented a Web-browsing system for cellular phones.2 Users
of such a system can scroll a page on a remote display or follow
the available hyperlinks.
Personal mobile devices can also be used for indoor positioning.
We implemented a positioning system by measuring link quality val-
ues between mobile devices and fixed devices used as references.3
We obtained good results, and we’re carrying out experiments on
algorithms to improve accuracy and optimize the fixed devices’
layout.4
As far as service provision is concerned, the ICEBERG project5
deals with communication technologies integration. Compared
with our proposed system, Iceberg is mostly devoted to low-level
service provision, such as voice over IP.
Museums, meeting rooms, and classrooms are typical environ-
ments where we can use personal mobile devices’ I/O interfaces to
access pervasive services. Several projects support users in such
pervasive environments by providing them with ad hoc informa-
tion or media on mobile devices. In this field, Paolo Busetta and
his colleagues proposed a system that uses agents for dynamic
information generation within active museums,6 and En-Yi Chen
and his colleagues implemented an agent-based system for teach-
ing support in a smart classroom.7 All these projects require the
use of ad hoc software on mobile devices.
Our proposed system differs because the goal is to provide users
with services in the easiest and cheapest way. We use mobile agents
for system management (service definition and listing) and for ser-
vice management (information retrieval).
REFERENCES
1. T. Uemukai et al., “A Remote Display Environment: An Integration ofMobile and Ubiquitous Computing Environments,” Proc. IEEE WirelessCommunications and Networking Conf. (WCNC 02), vol. 2, IEEE Press,2002, pp. 618–624.
2. T. Maekawa et al., “A Java-Based Information Browsing System in aRemote Display Environment E-Commerce Technology,” Proc. IEEE Int’lConf. E-Commerce Technology (CEC 04), IEEE CS Press, 2004, pp. 342–346
3. F. Agostaro, A. Genco, and S. Sorce, “A Fuzzy Approach to BluetoothPositioning,” WSEAS Trans. Information Science and Applications, vol. 1,no. 1, 2004, pp. 393–398.
4. A. Genco, S. Sorce, and G. Scelfo, “Bluetooth Base Station MinimalDeployment for High Definition Positioning,” Proc. ACM/IEEE Int’l Conf.Mobile and Ubiquitous Systems (MobiQuitous 05), IEEE CS Press, 2005,pp. 454–460.
5. H.J. Wang et al., “ICEBERG: An Internet Core Network Architecture forIntegrated Communications,” IEEE Personal Communications, vol. 7, no.4, 2000, pp. 10–19.
6. P. Busetta et al., “Service Delivery in Smart Environments by ImplicitOrganizations,” Proc. IEEE Int’l Conf. Mobile and Ubiquitous Systems(MobiQuitous 04), IEEE CS Press, 2004, pp. 356–363.
7. E.-Y. Chen et al., “Seamless Provisioning of Service in the UbiquitousComputing Environment,” Proc. Int’l Conf. Machine Learning and Cyber-netics, vol. 3, IEEE Press, 2003, pp. 1904–1909.
Related Work in Mobile Agents
Second, resource areas (or nth-levelareas, n > 1) consist of a federation ofone or more lower-level areas that a con-trol server manages. The RA topologydepends on its hierarchical level. A sec-ond-level RA contains one or more SAs,and higher-level RAs contain lower-levelRAs and SAs. The highest-level RA is theroot area, which contains all the lower-level areas and doesn’t have any higher-level RAs.
Server-side implementationAll area servers and control servers
run the Java Agent Development Frame-work mobile-agent platform with one ormore local and remote containers, adatabase to store user information, anda Web server to access information. (Seethe “Java Agent Development Frame-work” sidebar for more details.) EachJADE platform performs specific tasks,selecting the agent most appropriate foreach task on the basis of the area in whichthe agent runs.
Common elements of our system alsoin a JADE platform, depending on thearea type, include
� a main container, which stores defaultJADE agents;
� one or more containers, which executesystem agents;
� a logger agent, which manages userlogins and routing services;
� a setup agent, which registers eacharea within the network during thestart-up phase;
� user agents, which represent each userlogged in within the area;
� connection agents, one for each BT-BS,which manage connections betweenmobile devices and servers; and
� service agents, one for each availableservice.
Communication among these agentstakes place with FIPA ACL (Foundationfor Intelligent Physical Agents AgentCommunication Language) messages,which are composed according to anappropriate protocol.
Each BT-BS defines a cell with a lim-ited coverage range, so we must optimizethe station’s layout to ensure that theentire area is covered. This could lead tooverlapping cells, so we defined a pro-tocol to let users with a device withintwo or more cells connect to the BT-BSwith the minimum number of active con-nections. Connection agents manage thisfeature to lower the amount of data asingle BT-BS must manage and transfer.
Figure 2 shows a sample JADE plat-form GUI for an SA with four BT-BSs.The figure shows a main container, aBluetooth_Station container for each BT-BS, and a Local_Services container whereservice agents run. Each Bluetooth_Sta-
56 PERVASIVEcomputing www.computer.org/pervasive
M O B I L E C O M P U T I N G
Administration
EngineeringUniversity of
Palermo
Italian universities
Economy
Library
University of Genova
Hierarchical areasService arealevel 1
Resource arealevel 2
Resource arealevel 3
Root arealevel 4
Literature
D.I.E.
DINFO
Figure 1. A resource area template forusing the Agent Network for BluetoothDevices system in a universityenvironment. The hierarchical areas indicate the hierarchical level within theANBD system. D.I.E stands forDipartimento di Ingegneria Elettrica, orDepartment of Electrical Engineering,and DINFO stands for Dipartimento diIngegneria Informatica, or Departmentof Computer Engineering.
T ILAB-Italy (Telecom Italia LAB, the research department of Telecom Italia) devel-
oped JADE, which is middleware for distributed-agent-based application develop-
ment fully implemented in Java that complies with the Foundation for Intelligent Physi-
cal Agents (FIPA) specifications (www.fipa.org). The framework supplies agents with
life-cycle services such as white pages, yellow pages, message transport, and message
encoding. The communication architecture offers flexible and efficient messaging
based on the FIPA Agent Communication Language.
Several third-party add-ons extend the default platform’s capabilities or improve
some features. In particular, the Lightweight Extensible Agent Platform (LEAP) add-on
replaces part of the JADE kernel (http://jade.cselt.it), forming a modified runtime envi-
ronment with a reduced memory footprint. JADE-LEAP (http://jade.tilab.com) is intended
for a range of devices varying from servers to Java-enabled cell phones. The JADE-S add-
on protects a JADE-based multiagent system against security attacks.
Java Agent DevelopmentFramework
APRIL–JUNE 2006 PERVASIVEcomputing 57
tion container runs a connection agentand a user agent for each user connectedvia the corresponding BT-BS.
The main steps to setting up an areaplatform are initialization and associa-tion. The initialization phase lets systemadministrators set parameters that willbe used during the association phase andservice access. During the associationphase, the root area or an SA links withan RA to extend the network. Once theassociation phase successfully ends, userswithin an SA can access services suppliedby another area.
System administrators don’t need toset up the entire network association atthe same time. In fact, the system can bestarted with only one subnet, and othersubnets can be added later. This is pos-sible because we implemented the ini-tialization and association protocolsusing agents.
The setup agent’s main task is to man-age interplatform communication dur-ing the initialization and associationphases. Setup agents store the area type,the services list, IDs of lower-level setupagents, and the ID of the higher-levelsetup agent. We store such informationin XML files, which setup agents fromother areas use to discover local avail-able services. We also use XML files tostore the way users can access local ser-vices. We made this choice for severalreasons:
� The client-side MIDlet can’t processbig files because of mobile devices’ lim-ited computing and memory resources.Furthermore, the Bluetooth data trans-fer rate (no more than 1 Mbit/sec.)should lead to long response delays.It’s worth noting that the average sizeof exchanged ACL messages is small(150 to 250 bytes).
� Each area contains files for local ser-vices only because system administra-tors can more easily manage decen-tralized information.
� Each area is autonomous, and even if anassociation attempt fails, users withinthat area can continue to access local
services. This makes the system modu-lar, scalable, and free from bottlenecks.
(A MIDlet is a program written andcompiled with Java 2 Micro Edition thatruns on small devices.)
Regardless of the area type, each areaplatform stores information needed toaccess the available services in a localXML file named Area.xml. The systemadministrator creates an SA’s Area.xmlfile. In this case, the file stores the list oflocally available services and informa-tion on how to access these services.
An RA’s Area.xml file is created by thelocal setup agent during the associationphase with another area. In this case, thefile stores the links to the Area.xml filesof the associated areas. In other words,both SAs and RAs store an Area.xml filebut use it in different ways. An SA usesit to store information needed to accesslocal services, while an RA uses it to listthe services provided by lower-level SAs.Setup agents use the Area.xml file to findinformation about sites they will visit tofulfill a service request. For instance, fig-ure 3 presents the Area.xml sectionwhere the setup agent of the Engineer-ing RA finds information about otherservice-providing sites.
Figure 2. A sample Java AgentDevelopment Framework platform GUIfor a service area with four Bluetoothbase stations (BT-BSs). In this case, onlyone user is connected to the service areavia the BT-BS number 4.
Figure 3. The Area.xml section where thesetup agent of the Engineering resourcearea finds information about otherservice-providing sites.
<ui> <list title = “Engineering”><item title = “D.I.E.”>
An SA stores another XML file namedIndex.xml. Setup agents create and man-age this file, and the client-side applica-tion uses it to list the available options forthat area. The Index.xml file is dynami-cally updated according to the currentSA’s linking status.
ACL message exchange between cor-responding setup agents allows the cre-ation of the link between an SA and RA,so we had to define an appropriate com-munication protocol. A sample ACLmessage between setup agents to associ-ate an SA (DINFO—the Department ofComputer Engineering) and an RA (Engi-neering) is
Login agents accomplish user loginand authentication tasks by finding theuser record containing personal logindata. Each user has a unique ID withinthe network that’s used as a primary keywithin the user’s distributed database.
Each area server stores a local data-base (the Logger database) that containsthe routing and login tables. The rout-ing table stores remote Logger databaseaddresses, and the login table stores local
user login data. The login table is initiallyempty, and records are written each timea user logs into the area. When a userattempts to connect to the area server, itslogin agent searches for the user’s logindata within the login table. If the agentdoesn’t find user login data, it searchesremote Logger databases using the rout-ing table. Once it finds the user logindata, the login agent writes it in the logintable. The next time the same userrequires services within the area, theagent will find the login data locally. Thisprinciple of operation is similar to aDomain Name System.
Client-side implementationWe implemented the interface between
users and system agents using a MIDletrunning on every mobile device support-ing Java 2 Micro Edition (J2ME) withMobile Information Device Profile(MIDP) 1.0 or greater APIs and BluetoothJSR-82 APIs. The MIDlet is the only soft-ware that must be executed on mobiledevices to access system services, and itconsists of a static part executed apartfrom the connection status and a dynamicpart that depends on the available ser-vices. The MIDlet negotiates a mobile-device connection with the network usinga connection agent (see figure 4).
Once the user is authenticated on aplatform, the connection agent sets up auser agent uniquely associated with that
user. From now on, the connection agentcan continue to manage incoming con-nection requests from other users, andthe MIDlet contacts the user agent forservice requests.
The user agent sends the appropriateGUI using an XML protocol message,thus letting system administrator dynam-ically define service access modes. Hence,administrators only need to create XMLfiles for appropriate GUI generation, thusavoiding MIDlet source rewriting foreach needed GUI.
We decided to do this, with no agentsrunning on mobile devices, for two rea-sons. First, we want people to use theircell phones in the same way they usuallydo, with the same graphical menu-styleinterface. We just change the choicesavailable in the menus according to theservices available in the user’s area. Thisway, we avoid installing ad hoc software,which could be a difficult task forunskilled users as well as produce dif-ferent results on different devices.
Our second reason deals with the JADELightweight Extensible Agent Platformimplementation (see the related sidebarfor details). As we discussed earlier, con-tainers are the agent execution environ-ments within a JADE platform. In aJADE-LEAP platform, containers are splitinto a FrontEnd (actually running on ahandheld device) and a BackEnd (runningon a Java 2 Standard Edition host), linkedtogether through a permanent connec-tion. This execution mode (split mode) isparticularly suited for resource-con-strained and wireless devices because theFrontEnd is more lightweight than a com-plete container, the bootstrap phase isfaster, and fewer bytes are transmittedover the wireless link. However, the splitmode doesn’t support agent mobility. Thismeans that if we want to run agents onmobile phones, we have to deploy JADE-
MIDlet
User agent
(3b)Create user agent
(3a)Authentication
acknowledgment
(1)Authentication request
(4)Interaction
(2)Verify user data
Connection agent
Figure 4. MIDlet connection steps. A step-by-step description of the connectionbetween the MIDlet running on themobile device and a connection agentrunning on an SA.
LEAP in the split mode and only exploitagents’ communication features.
Owing to these implementation choices,our system can ignore device coverageproblems because user agents performeven if the user is offline (out of BT-BScommunication range).
A service request involves a user agentand a service agent. The former acts onbehalf of users who need services, and thelatter supplies users with the required ser-vice. In more detail, when a user requiresa service via the MIDlet on a mobiledevice, the user agent on the platformreads the Index.xml file to obtain datarelated to the service required and thename of the agent that can provide theservice. Next, the user agent asks theappropriate service agent for a servicetemplate, which it will use to correctlycompose the service request. In fact, theservice request must make all the relevantservices available within the user’s SA andadhere to the proper service provisionmode. For example, in the Administra-tion SA, students should be able to checktheir curriculum and their fee paymentstatus. In this case, the service must beprovided in a secure mode to protect per-sonal data transmissions, and the requestmust contain all the required fields.
Of course, we set up suitable commu-nication protocols (dealing with hand-shake, authentication, and communica-tion closing), a data packet format, anda template layout to easily code them inXML files.
Case studyWe designed the ANBD system to be
used in several physical environments;in particular, we carried out some exper-iments within our university to test ourdesign choices. The university environ-ment consists of departments, each witha specific scope and services (research,teaching, and secretariat) and a typicalkind of user (professors, students, andemployees).
A possible list of services for usersinclude
• document requests;• exam enrollment;• access to teaching information, such
as course time and exam dates;• requests for teaching aids, either
directly downloaded onto the mobiledevice or sent to an email address; and
• access to location-related information,such as department directories or pro-fessor meeting times.
When users come within a BT-BS’s cov-erage area, the local Bluetooth service dis-covers their devices and pushes theMIDlet onto them (only if the users allowthe MIDlet installation). We accomplishthis with a simple Java application thatloops a Bluetooth device discoverysequence. Once a new device is discov-ered, the application establishes a Blue-tooth connection with it and sends theMIDlet .jar file. Most mobile devices’operating systems receive the file as a mes-sage attachment, and installation auto-matically begins upon user conformation.We used Atinav’s AveLink API (www.avelink.com/Bluetooth) to implement alllow-level interactions between fixed andmobile Bluetooth-enabled devices.
We experienced problems in our testswhile pushing the MIDlet to some phonemodels, most likely due to the differentBluetooth stack implementations. In par-ticular, the Sony-Ericsson Z600 andSiemens S55 don’t support the push modeand reported an “unknown-file-format”when receiving the message. However,most Java-enabled Nokia models allowthis interaction mode.
We implemented a Web-based MIDletdownload mode for devices that don’tsupport this push procedure. In thesecases, users can connect via GeneralPacket Radio Service (GPRS) to a URLthat corresponds to the .jar file. Thedevice then automatically downloads
the MIDlet, but users must start instal-lation manually. We accepted this com-promise solution because users must beaware of the MIDlet download in thisinteraction mode.
A .jad file is generated and attached tothe main .jar MIDlet file both in Blue-tooth push mode and in GPRS OTA pro-visioning. The .jad file describes theMIDlet content, its memory require-ments, and the certification data, whenavailable. The description file is smallerthan the actual MIDlet .jar file (1 to 2Kbytes versus 24 Kbytes). The .jad fileis sent before the .jar file so that themobile phone’s operating system canalert the device’s user, who can acceptor refuse the MIDlet according to theinformation received and the executionenvironment. This reduces the amountof data to transmit and, therefore, thefee users must pay when using the GPRSOTA provisioning mode.
Once installed and started, the MIDletshows a GUI that is dynamically createddepending on the available services.
Figure 5 shows the trial environmentwith four SAs and two RAs successfullyconnected. The logical-areas distributionfits the real environment hierarchy. In thisscenario, a user might enter the librarySA coverage area carrying a smart phone.The MIDlet’s static part will show a GUIwith the connection option list and dialogboxes for login data introduction. Onceauthenticated, the client-side MIDletdownloads the appropriate GUI with a
APRIL–JUNE 2006 PERVASIVEcomputing 59
AdministrationEngineering
Library
University ofPalermo
Service area Resource area
DINFO
D.I.E.
Figure 5. A hierarchical representation of thetrial environment. SAs always link to an RA.
60 PERVASIVEcomputing www.computer.org/pervasive
M O B I L E C O M P U T I N G
list of possible choices and shows it onthe device display. Because related SAs(D.I.E.[Department of Electrical Engi-neering], DINFO, Library) are connectedto the same parent RA (Engineering), thefirst menu lets the user choose servicessupplied by one of the available SAs, evenif he or she is only covered by one ofthem. Users can also access other areas
connected to the network via a higher-level RA.
In a different scenario, another usermight enter the DINFO SA coverage areaand connect a device to the network. Inthis stage of the experiment, we shut offthe Engineering RA platform, simulatinga fault to test the residual system opera-tion capability. The user can still accessservices supplied by the D.I.E., DINFO,Library, and University of Palermo areasbecause the user agent already has allinformation needed to connect to otherSAs. The only users who might experi-ence problems because of the platformfault are those who need to access ser-vices supplied by one of the D.I.E.,DINFO, or Library areas from an exter-nal SA. For instance, users within theAdministration SA can’t access servicessupplied by the DINFO SA during anEngineering RA fault.
User experiencesWe implemented an exam enrollment
service to evaluate the system from theuser’s point of view. Because the serviceis useful for students and professors, wewere able to test reactions from both setsof users.
Because Italian students must fill in aform with name, matriculation roll, andemail address to enroll for exams, we
asked 200 students to enroll for theirexams using their mobile devices. Theyfilled in the form fields with the appro-priate data and sent it back to their useragents, which compiles the XML node.
We received positive feedback fromstudents who found this kind of serviceprovision more familiar than a commonWeb interface, probably because cell
phones are readily accessible and seemto be more familiar than computersamong young people.
Confirming this informal result, wenoted an average of 48 accesses per dayfrom the system log files. The test periodlasted 25 days, and we saw a rapidgrowth from nine accesses the first dayup to a peak of 112 accesses in 90 min-utes on the fourth day. From the third dayon, we had a minimum of 23 accesses perday. These results are impressive whencompared with the number of accesseslogged for our Web site for the same taskin the same period (39 per day average,with a maximum of 91). The activity logfile shows that students repeatedlychecked their subscription status and theexam room and time. We think this is dueto the system’s novelty and because theservice is free of charge.
Our mobile application is as fast asWeb-based access, so we think that stu-dents appreciated the ability to accessservices at any time without having tosearch for Internet points and, above all,pay for Internet access.
From the professor’s point of view, it’sstraightforward to add, modify, or deleteexam information because we defined aservice template layout that involvesonly a few lines of XML code. The sevenprofessors who evaluated our system used
it less than the students, but they found ituseful when they needed to rapidlychange some service-related data. In par-ticular, some professors changed theexam start time just minutes before thescheduled exam time.
It’s worth noting that our test subjectsdidn’t report any errors or failures ontheir mobile devices while executing theMIDlet.
Security issuesThe trial implementation of our sys-
tem didn’t deal explicitly with securityproblems because we were mainly test-ing the system’s operation and useful-ness. Furthermore, the databases we’recurrently using don’t store informationto be secured. However, ANBD usersand programmers are intrinsically pro-vided with suitable security in the threemain categories of security problems—execution-environment security, prob-lems raised by agent protection, andcommunication channels—thanks tothe middleware capabilities. Specifi-cally, the limits of agent execution andresource access are well defined withinJADE containers. Furthermore, fromthe agent’s point of view, the JADE-Sadd-on lets users set up enhancedagent-authentication features using,for instance, user fingerprints.1 Fur-thermore, communications in JADEplatforms use the FIPA-ACL, so it’seasy to encrypt messages exchangedbetween agents.
Concerning robustness, we designedANBD to adapt itself to environmentalchanges and faults, providing users witha reduced set of services, if necessary.
System agents can act autonomously,and we designed them to always be in aconsistent state. The worst case occurswhen a mobile device disconnects dur-ing agent setup or data exchange, forinstance, because of a battery fault. Anagent is only fully set up once the instan-tiation procedure completes. Therefore,
System agents can act autonomously,
and we designed them to always be in a
consistent state.
APRIL–JUNE 2006 PERVASIVEcomputing 61
if the fault occurs before the procedureconcludes, the agent simply doesn’t existand must be reinstantiated. This is a lesscritical situation than an agent left in aninconsistent state. If the fault occurs afterthe procedure is completed, the agent canstart its task and come back to its con-tainer until the client can connect again.
Although our system exploits the basicJADE and Bluetooth security features,we plan to enhance system security in thefuture.
Our future work will seek toimprove security featuresduring login, data access,data transfer, and database
storage. To let users communicate witheach other, we hope to implement a mes-senger feature that, for example, profes-sors might use to contact students withlast-minute messages or students woulduse to contact colleagues.
Furthermore, we’re evaluating thepossibility of letting mobile devices bemore involved in the agent platform. Wethink this could be useful when somelocal execution is needed, given thatnext-generation microprocessors for cellphones and PDAs are capable of high-performance computing. Moreover,we’re experimenting with using smartphones to store user profiles, in hopes ofcomposing intelligent queries accordingto users’ skills and behaviors.
Owing to space limitations, this arti-cle doesn’t provide full implementationdetails on the ANBD system. For furtherinformation, please contact the authorsdirectly.
REFERENCE 1. V. Conti et al., “An Enhanced Authentica-
tion System for the JADE-S Platform,”WSEAS Trans. Information Science andApplications, vol. 1, no. 1, 2004, pp.178–183.
the AUTHORS
Alessandro Genco is an associate professor of computer science in the Departmentof Information Engineering and a coordinator of the PhD School of Computer Engi-neering at the University of Palermo. His research interests include mobile networksand pervasive-system middleware design for augmented reality. He received hisdegree in mathematics from the University of Palermo. Contact him at Dipartimentodi Ingegneria Informatica, Viale delle Scienze, edificio 6, 90128 Palermo, Italy;[email protected].
Salvatore Sorce is an instructor and research collaborator at the University ofPalermo. His research interests are in mobile agents in collaborative augmented-reality environments and in parallel and distributed applications, pervasive com-puting, wireless networks and communications, wearable computers, positioningsystems, and personal-mobile-device programming for pervasive systems. Hereceived his PhD in computer engineering from the University of Palermo. Contacthim at Dipartimento di Ingegneria Informatica, Viale delle Scienze, edificio 6, 90128Palermo, Italy; [email protected].
Giuseppe Reina is a final-year student at the University of Palermo. His current research is in mobile-device programming for remote-service access. He will receive his degree in computer engineeringfrom the University of Palermo this year. Contact him at Dipartimento di Ingegneria Informatica, Vialedelle Scienze, edificio 6, 90128 Palermo, Italy; [email protected].
Giuseppe Santoro is a final-year student at the University of Palermo. His current research is in mobile-device programming for remote-service access. He will receive his degree in computer engineeringfrom the University of Palermo this year. Contact him at Dipartimento di Ingegneria Informatica, Vialedelle Scienze, edificio 6, 90128 Palermo, Italy; [email protected].
IEEE Distributed Systems Online brings youpeer-reviewed articles, detailed tutorials, expert-managedtopic areas, and diverse departments covering the latestnews and developments in this fast-growing field.
