COMPUTING PRACTICES Challenges and Lessons in Developing Middleware on Smart Phones Several research projects pursuing middleware architectures to support pervasive applications on smart phones reveal the importance of careful resource management, lightweight communication protocols, and asynchronous programming. Oriana Riva mart phones are the most promising heralds of future pervasive ETH Zürich computing. With increasingly powerful capabilities in compu- tation, communication, and sensing, these devices have evolved Jaakko Kangasharju from simple communication devices into consumers of various Helsinki University of Technology types of information services as well as sensor hubs for health- Scare monitoring systems, sports trainers, and the like.1 Programming phone applications that can properly perform in this new computing landscape is not easy. Middleware platforms that can, for example, abstract the complexity of network communication, fault toler- ance, and component migration are useful tools to aid the development of distributed applications. However, while middleware traditionally seeks to provide a useful layer of abstraction, an important design principle on phones must also be resource awareness, especially of resources such as energy that are not a primary concern in desktop computing. Middleware for smart phones calls for novel approaches. During the past five years, we have participated in several research proj- ects at the Helsinki Institute for Information Technology (www.hiit.fi) that focus on middleware for pervasive applications. We have explored various topics ranging from XML messaging and synchronization, to event-based communication and service migration, to context monitoring and recon- figuration. We have also built several prototype systems running on modern phone platforms, and we have evaluated their performance in experimental testbeds, in some cases organizing field trials for more extensive evalua- tions. Based on these experiences, we have identified several middleware research challenges along with possible solutions. SMART-PHONE CHARACTERISTICS Smart phones are relatively powerful mobile computing platforms. They offer reasonable data-processing and -storage capabilities, incorporate vari- ous communication technologies, and often include embedded devices such as cameras or sensors. The most useful feature of smart phones as enablers 0018-9162/08/$25.00 © 2008 IEEE Published by the IEEE Computer Society September 2008 77 of pervasive computing is the possibility of installing sion of the Java Platform, Standard Edition (Java SE), new applications, which in many cases anyone, not just that is designed to cope with small devices’ resource con- the manufacturer or operator, can write. straints. Conceptually, Java ME is divided into configu- rations, which provide the requirements on the device Hardware hardware and Java virtual machine (JVM), and pro- Smart-phone CPUs generally use the ARM archi- files, which provide the APIs and libraries available to tecture due to its power efficiency. Clock frequency in the application programmer. On phones, two standard modern models is usually around 200-250 MHz, but configurations are available. recent high-end models exceed 300 MHz. Total RAM The Connected Limited Device Configuration is normally between 64 and 128 Mbytes, but programs is designed for smaller devices. CLDC is a severely can use only a fraction of this, typically 10-20 Mbytes. restricted version of Java, with older versions not pro- External storage is provided by flash memory cards with viding support even for floating-point types. It works in capacity up to 8 Gbytes, but because smart phones’ oper- conjunction with the Mobile Information Device Profile, ating systems do not support virtual memory, this can- a stripped-down version of the Java SE 1.1 library with not automatically be used as an extension to RAM. MIDP-specific user interface and networking libraries. Most smart phones use lithium-ion batteries due to their To save resources and still retain Java’s safety proper- small form factor. Charge ranges between 780 and 1,200 ties, the compiler performs most of the required class file milliamp hours (mAh), which is sufficient for several days verification during the preverification phase. of standby operation or a few hours of phone calls. The Connected Device Configuration is designed for The primary data communica- more-capable devices. CDC pro- tion technology on smart phones The most useful feature of files are arranged in a stack, with is the mobile phone network oper- the Foundation Profile providing ated in packet-switched mode, usu- smart phones as enablers of an almost complete Java SE 1.1 ally either Enhanced Data Rates pervasive computing is the environment enhanced with the for GSM Evolution (EDGE) or the possibility of installing new Collections API. On top of this, the Universal Mobile Telecommunica- Personal Basis Profile and Personal tions System (UMTS), although applications, which in many Profile provide UI libraries. some networks only have the lower- cases anyone can write. Standard practice for software speed General Packet Radio Service development on smart phones is to (GPRS) available. Bluetooth and write the code using a specific tool- infrared technologies are available for short-range com- kit and then test the program on an emulator running on munication, but infrared is rarely useful due to its line- the development machine. Once the application is fully of-sight requirement. Modern business models increas- debugged on the emulator, the developer installs it on the ingly also offer Wi-Fi (IEEE 802.11b/g) connectivity. actual target device and debugs it further there. Usually, A modern smart phone is not only a communica- phone manufacturers provide emulators for their devices tion device but also functions as a media center with to be plugged into the development toolkits to allow more the inclusion of cameras as well as music and video accurate emulation of the actual platform. Sun Microsys- players. Global Positioning System (GPS) receivers are tems’ Java toolkits also provide generic emulators. available as external accessories and are integrated into some recent phone models. Screen size and resolution, MIDDLEWARE RESEARCH PROJECTS keyboard size, and keypad design have also advanced, We carried out our middleware research in the context facilitating applications such as Web browsers, e-mail, of three main projects, whose focus areas are summa- and video players. rized in Figure 1. We did our software development in Java using Nokia Series 60 and Series 80 phones. The Software platform specifics matter little, as the fundamental dis- The most widely used operating system on smart tinctions between phones from different manufacturers phones is Symbian OS, with more than 70 percent of are minor or nonexistent—the lessons we learned should the market share. Symbian is an open platform specifi- be equally applicable to most smart phones. cally designed for resource-constrained mobile devices, with a focus on small memory footprint and low energy Fuego Core consumption. Symbian’s native programming language The Fuego Core (www.hiit.fi/fi/fc) project focused on is a dialect of C++, but it supports Java and other pro- three main topics:2 XML messaging,3 mobile distrib- gramming languages such as Python, Visual Basic, and uted event-based communication, and XML synchro- Perl as well. nization. Its main contribution has been the integration Smart phones use the Java Platform, Micro Edition of current fixed network trends, in particular XML, (http://java.sun.com/javame/technology), a reduced ver- into mobile computing environments. The project has 78 Computer Figure 1. Middleware research projects: research areas, relationships between projects and to external technologies, and examples of applications developed. also contributed to several international standardiza- Contory can achieve reliable and flexible context tion forums, especially the Efficient XML Interchange provisioning by integrating three alternative sources Working Group (www.w3.org/XML/EXI) of the World of context: It can employ local sensors integrated in or Wide Web Consortium, in the area of efficient XML connected to the phone, interact with external context representation. infrastructures using event-based communication and Using the three Fuego Core components, we built Cap- XML messaging from the Fuego Core project, or collect tio, an XML editor that supports concurrent editing of sensor information by migrating from node to node in a XML documents by multiple users working on different mobile ad hoc network of sensing devices. devices. The application either immediately propagates Finally, Contory offers a database abstraction of the changes to an edited XML document as events to the sensor-rich environment through an SQL-like program- other users or synchronizes them later using an XML- ming interface. Using Contory, we built several applica- aware merging algorithm. tions. As Figure 1 shows, WeatherWatcher can retrieve weather-related information in user-specified geographi- DYNAMOS cal regions. The context-aware service recommender5 The DYNAMOS (www.hiit.fi/fi/dynamos) project lets users receive prompt notifications of services avail- focused on context provisioning issues. We developed able in the surrounding environment as well as generate the Contory middleware4 to support mobile applications and share location-specific content. that must be aware of both their local context,