LIGHTWEIGHT MIDDLEWARE ARCHITECTURE FOR MOBILE PHONES · Salminen, T. (2005) Lightweight middleware architecture for mobile phones. University of Oulu, Department of Electrical and

LIGHTWEIGHT MIDDLEWARE ARCHITECTURE FOR MOBILE PHONES

Työn tekijä ___________________________________ Timo Salminen

Työn valvoja ___________________________________

Jukka Riekki Hyväksytty _______/_______2005 Arvosana ___________________________________

Salminen, T. (2005) Lightweight middleware architecture for mobile phones. University of Oulu, Department of Electrical and Information Engineering. Diploma Thesis, 72 p.

ABSTRACT Ubiquitous computing, context-aware applications and mobile services form one of the most promising business opportunities in the near future. Ubiquitous applications, however, introduce great challenges to application developers. The application area includes several demanding characteristics. The applications are mobile and operate in distributed environments. They communicate in wireless fashion using currently available communication interfaces, adapt to the situation at hand, and are aware of their context and any changes in it. To reduce the application developers’ overload and to enable wide-scale application development, the developers need to be provided with a middleware or a platform, which offers the services common to the application area. In order to utilize the architecture in resource-constrained devices, such as in mobile phones, it also has to be lightweight besides being capable of generic use.

In this thesis, a lightweight middleware architecture is implemented to support the development of ubiquitous applications for mobile phones. The work is based on the CAPNET architecture, developed in the CAPNET research program at the University of Oulu. This thesis presents the characteristics of the application area in question and the requirements that the ubiquitous applications set to a middleware architecture. A requirement analysis is carried out by an extensive literature review. The purpose of this work is to refine the architecture to better reach the requirements that are typical to this application area, and to implement the architecture on Symbian operating system. The architecture was validated by developing several application prototypes on top of it and using the applications in a ubiquitous test environment. The validation proved the middleware architecture as functional and verified its applicability to resource-constrained distributed mobile computing environments, since the implemented middleware resulted in an overall size of less than 50 KB. Keywords: ubiquitous computing, component architecture, mobile devices, Symbian operating system

Salminen, T. (2005) Kevytrakenteinen välikerrosohjelmistoarkkitehtuuri matkapuhelimiin. Oulun yliopisto, Sähkö- ja tietotekniikan osasto. Diplomityö, 72 s.

TIIVISTELMÄ Käyttöympäristöstä tietoiset, kaikkialla läsnä olevat sovellukset sekä mobiilipalvelut muodostavat yhden lähitulevaisuuden lupaavimmista uusista liiketoiminta-alueista. Kaikkialla läsnä olevat sovellukset luovat kuitenkin suuria haasteita ohjelmistokehittäjille. Tälle sovellusalueelle on ominaista, että sovellukset ovat liikkuvia ja hajautettuja. Ne kommunikoivat langattomasti kulloinkin saatavilla olevien kommunikointirajapintojen kautta, mukautuvat käyttöympäristöönsä sekä ovat tietoisia käyttöympäristöstään ja siinä tapahtuvista muutoksista. Jotta sovellusaluetta päästäisiin hyödyntämään laajassa mittakaavassa, on sovelluskehittäjille tarjottava välikerrosohjelmisto tai alusta, joka toteuttaa sovellusalueelle luonteenomaiset peruspalvelut. Jotta välikerrosohjelmisto voitaisiin ottaa käyttöön myös resursseiltaan rajoittuneissa mobiililaitteissa kuten matkapuhelimissa, täytyy sen olla yleiskäyttöisyyden lisäksi hyvin pienikokoinen.

Tässä työssä toteutetaan kevytrakenteinen välikerrosohjelmisto, joka on suunniteltu helpottamaan kaikkialla läsnä olevien sovellusten kehitystyötä matkapuhelimiin. Työ perustuu Oulun yliopiston CAPNET-tutkimusohjelmassa kehitettyyn mobiilisovelluksille tarkoitettuun ohjelmistoarkkitehtuuriin. Laajassa kirjallisuuskatsauksessa esitetään sovellusalueelle keskeiset ominaisuudet sekä vaatimukset, jotka sovellusalueelle tarkoitetun yleiskäyttöisen välikerrosohjelmiston tulee toteuttaa. Kirjallisuuskatsauksessa tunnistettujen vaatimusten perusteella olemassa oleva arkkitehtuuri kehitetään paremmin sovellusaluetta vastaavaksi. Tämän lisäksi työssä toteutetaan arkkitehtuurin mukainen välikerrosohjelmisto Symbian-pohjaiselle matkapuhelimelle. Arkkitehtuurin toteutus sekä sen päälle kehitetyt sovellusprototyypit vahvistavat arkkitehtuurin toimivaksi sekä osoittavat välikerrosohjelmiston soveltuvan resursseiltaan rajoitettuihin pienpäätelaitteisiin, sillä sen vaatima tila on alle 50 Kt. Avainsanat: kaikkalla läsnä olevat järjestelmät, komponenttiarkkitehtuuri, mobiililaitteet, Symbian käyttöjärjestelmä

TABLE OF CONTENTS

ABSTRACT TIIVISTELMÄ TABLE OF CONTENTS PREFACE ABBREVIATIONS 1. INTRODUCTION..................................................................................................9

1.1. SCOPE AND OBJECTIVES............................................................................................................. 9 1.2. CONTRIBUTIONS OF THE THESIS .............................................................................................. 10 1.3. STRUCTURE OF THE WORK....................................................................................................... 11

2. UBIQUITOUS ENVIRONMENTS.....................................................................12 2.1. INTRODUCTION OF THE DOMAIN.............................................................................................. 12

2.1.1 Distributed computing................................................................................................ 12 2.1.2 Mobile computing....................................................................................................... 13 2.1.3 Ubiquitous computing ................................................................................................ 13 2.1.4 Context and context awareness.................................................................................. 14 2.1.5 Transparency.............................................................................................................. 15 2.1.6 Middleware................................................................................................................. 16 2.1.7 Software architecture ................................................................................................. 16

2.2. TECHNOLOGIES........................................................................................................................ 17 2.2.1 Common Object Request Broker Architecture .......................................................... 17 2.2.2 Java Remote Method Invocation................................................................................ 18 2.2.3 Distributed Component Object Model....................................................................... 19 2.2.4 Extensible Markup Language .................................................................................... 19 2.2.5 Simple Object Access Protocol .................................................................................. 20 2.2.6 XML-RPC ................................................................................................................... 20 2.2.7 Resource Description Framework ............................................................................. 21 2.2.8 Symbian operating system.......................................................................................... 22

3. UBIQUITOUS MIDDLEWARE .........................................................................24 3.1. REQUIREMENTS FOR UBIQUITOUS MIDDLEWARE..................................................................... 24

3.1.1 Interoperability........................................................................................................... 24 3.1.2 Discoverability ........................................................................................................... 25 3.1.3 Location transparency ............................................................................................... 26 3.1.4 Adaptability ................................................................................................................ 27 3.1.5 Context awareness...................................................................................................... 28 3.1.6 Other requirements .................................................................................................... 28

3.2. UBIQUITOUS SYSTEMS ............................................................................................................. 29 3.2.1 Gaia ............................................................................................................................ 30 3.2.2 One.world ................................................................................................................... 31 3.2.3 Aura ............................................................................................................................ 32 3.2.4 Other systems ............................................................................................................. 33

3.3. STATE OF THE ART SUMMARY ................................................................................................. 34 4. CAPNET ARCHITECTURE ON SYMBIAN PLATFORM ..............................36

4.1. INTRODUCTION TO THE CAPNET ARCHITECTURE.................................................................. 36 4.2. ANALYSIS ON THE CAPNET ARCHITECTURE.......................................................................... 38 4.3. REQUIREMENTS FOR THE NEW ARCHITECTURE ....................................................................... 40 4.4. NEW ARCHITECTURE DESIGN................................................................................................... 40

4.4.1 Component template................................................................................................... 43 4.4.2 Component management............................................................................................ 45 4.4.3 Messaging................................................................................................................... 46 4.4.4 Service discovery........................................................................................................ 49 4.4.5 Context........................................................................................................................ 49

4.4.6 Dynamically reconfigurable stubs ............................................................................. 50 5. IMPLEMENTATION AND FUNCTIONAL TESTING ....................................52

5.1. ARCHITECTURE IMPLEMENTATION.......................................................................................... 52 5.1.1 Component framework............................................................................................... 52 5.1.2 Core components........................................................................................................ 53 5.1.3 XmlRpc-S library........................................................................................................ 54 5.1.4 Testing ........................................................................................................................ 54

5.2. FUNCTIONAL TESTING ............................................................................................................. 55 5.2.1 Prototype applications and services .......................................................................... 55 5.2.2 Test configuration ...................................................................................................... 56 5.2.3 Test scenario............................................................................................................... 58

6. RESULTS AND DISCUSSION ..........................................................................60 6.1. ACHIEVEMENT OF OBJECTIVES ................................................................................................ 60 6.2. ARCHITECTURE EVALUATION.................................................................................................. 61

6.2.1 Architecture design methodology .............................................................................. 61 6.2.2 Scale of the architecture implementation .................................................................. 62 6.2.3 Functional testing results........................................................................................... 62 6.2.4 Shortcomings .............................................................................................................. 64 6.2.5 Strengths ..................................................................................................................... 64

6.3. ARCHITECTURE REVIEW .......................................................................................................... 65 6.4. FUTURE WORK ......................................................................................................................... 66

7. SUMMARY .........................................................................................................68 REFERENCES...........................................................................................................69

PREFACE

This thesis has been done in the MediaTeam research group in the Information Processing Laboratory, University of Oulu in the CAPNET research program. The CAPNET program concentrates on ubiquitous computing, mobile technologies, and context-aware systems. Financiers of the program include Hantro, IBM, Nokia, Serv-It, Tekes (National Technology Agency) and TeliaSonera Finland. The work has been partially done during a researcher visit to the Language and Media Processing Laboratory at the University of Maryland in summer 2004.

Many people have influenced the work that has led to this thesis. First, I would like to thank the MediaTeam personnel for an innovative working environment. Especially people working in the CAPNET program receive my appreciation for the enjoyable cooperation during the past three years. I would also like to acknowledge Dr. David Doermann for the support I received during my researcher visit to the University of Maryland. Mr. Simo Hosio receives my appreciation for his enthusiastic participation in the Symbian development work and test environment creation. I also express my gratitude to my supervisor, Professor Jukka Riekki and the work’s second reviewer, Professor Tapio Seppänen for the comments and guidance during the writing process.

My deepest gratitude falls to my family and to my parents for the support throughout my entire life. Finally, I thank you Seija, for the understanding, inspiration, and unconditional love that you have provided me with during the past years. The endpoint of this path would have been reachable in any case, but together with you, the road was more pleasant, enjoyable and especially more meaningful to walk.

Oulu, May 27, 2005

Timo Salminen

ABBREVIATIONS

3G Third Generation, mobile communication system API Application Programming Interface, interface to existing application CAPNET Context-Aware Pervasive Networking, A project focusing on

context-aware mobile technologies for ubiquitous computing CORBA Common Object Request Broker Architecture, middleware

technology DLL Dynamic Link Library, a software module that can be linked to the

application at runtime FTP File Transfer Protocol, protocol for transferring files between

computers GNU GNU's Not Unix, a project which aims to create a complete

operating system called GNU GPRS General Packet Radio Service, packet-based wireless

communication service over GSM network GSM Global System for Mobile communications, the most widely used

digital mobile phone system and de facto wireless telephone standard in Europe

GUI Graphical User Interface, graphical interface for the user to interact with a computing system

HTTP Hyper Text Transfer Protocol, application layer protocol IDL Interface Definition Language, language for describing software

interfaces LGPL Lesser General Public License, a free software license approved by

free software foundation OS Operating System, software controlling hardware resources in a

computing device PDA Personal Digital Assistant, small portable computer RMI Remote Method Invocation, Java middleware technology RPC Remote Procedure Call, middleware technology for procedural

programming languages SDK Software Development Kit, a toolkit that allows software

development SOAP Simple Object Access Protocol, application layer protocol SSDP Simple Service Discovery Protocol, a service discovery protocol

utilized in UPnP system UI User Interface, interface for the user to interact with a computing

system UML Unified Modeling Language, object-based modeling technology UPnP Universal Plug and Play, a standard that enables simple connectivity

among different devices URI Uniform Resource Identifier, anything that indicates a resource

unequivocally W3C World Wide Web Consortium, standardization organization for web

technologies WWW World Wide Web, a large set of documents on the Internet

connected to each other via links

XML Extensible Markup Language, information representation technology

XML-RPC XML-encoded Remote Procedure Call

1. INTRODUCTION Computing is turning mobile and ubiquitous. We are reaching a situation where an increasing number of applications and services are available for mobile users. People today are accustomed to using mobile phones in everyday life and regularly carry one with them. Mobile phones are no longer mere communication devices, but are used as organizers, data repositories, and containers for users’ applications. Furthermore, mobile phones are utilized in accessing services and information content in the network. Traditionally, mobile phones have been closed platforms without any possibility for application development. However, due to great development in mobile phone industry, mobile phones today provide an open, truly ubiquitous computing platform for the applications. Considering this development and the role of mobile phones in people’s everyday lives, it can be said that mobile phones are becoming fundamental tools in ubiquitous computing in the near future.

Ubiquitous applications introduce great challenges to application developers, especially when resource-limited mobile devices are in question. The application developers’ overload can be considerably reduced by means of middleware, which provides the applications with a level of abstraction from the underlying platform and hides the common functionalities behind generic and simple interfaces. Several ubiquitous middleware architectures and infrastructures have been suggested in the world of academia. Common to the existing systems is, however, that they are deployed on high performance computational devices, such as laptops and PDAs. Furthermore, they utilize technologies that are not supported or cannot be supported by modern mobile phones. Obviously, none of the existing systems and architectures is designed to be used in such resource-constrained devices as mobile phones are.

This work proposes a lightweight middleware architecture to support the development of ubiquitous applications in mobile phones. The architecture is based on CAPNET architecture, developed earlier in the project. Previously, the project has created three architecture versions, each of which have been implemented and tested on a system that consists of PDA devices and network servers. The main purpose of this thesis is to define the requirements for a generic middleware for ubiquitous applications, to refine the existing architecture to serve the application area in question better, and to design and implement the refined architecture on a mobile phone based on the Symbian operating system. The developed architecture is validated by functional testing with several prototype applications built on top of it. Due to the limited execution environment, also the fingerprint of the new architecture has to be small compared to the existing architecture prototypes since the target device is a resource-limited mobile phone.

1.1. Scope and objectives

The work covered in this thesis has several objectives. At first, the goal is to identify the functionality that characterizes the ubiquitous computing in general and to address the requirements for middleware that supports the development of ubiquitous applications. In particular, the goal is to identify the core requirements that are common to the application area. The requirements analysis is carried out by an extensive literature review on the research topic. Several existing solutions and

10

requirement definitions are examined. Moreover, the current state-of-the-art research and technologies are presented and used to identify the requirements.

Secondly, the existing CAPNET architecture is studied and analyzed. The goal is to address the currently supported functionality and to refine the architecture as necessary to support all the core requirements. Special emphasis is put on the designed architecture’s applicability on resource constrained environments, such as mobile phones.

The final objective is to implement the designed architecture on a mobile phone based on the Symbian operating system and validate it as functional. Aside from satisfying the core requirements, an important goal is to come up with lightweight middleware implementation that is applicable in resource-constrained mobile phones. As a complete architecture implementation would introduce a much greater workload than is reasonable for one thesis, the implementation task is limited to the most crucial parts of the architecture that are necessary for proof of concept testing and validation of the overall architecture.

1.2. Contributions of the thesis The first part of the thesis consists of a literature review of existing ubiquitous systems and architectures. The research characterizes ubiquitous applications and the requirements that the ubiquitous applications need from the underlying platform or infrastructure. In particular, the presented state-of-the-art report identifies the core requirements that are typical to the application area in question. The identified core requirements are used as basis for developing the new architecture.

This thesis contributes to the state of the art regarding middleware architectures that support the development of ubiquitous applications. The developed middleware architecture provides the fundamental services to ubiquitous applications and is able to run on mobile phones. The developed middleware is validated by functional testing. The testing is executed by using the middleware architecture as a platform for several prototype applications, which demonstrates the services it offers. A scientific paper on the developed architecture has been accepted for publication in the proceedings of an international conference [1].

The middleware architecture developed in this work has been successfully utilized in a test environment, which was built for examining how users interact with tangible interfaces in a ubiquitous environment. The work done in this thesis created a basis for the development of the application prototypes that were used in the user tests of the research. The used applications were built on top of the middleware architecture and utilized the services provided by it. The results of the research have been accepted for publication in the proceedings of an international conference on human–computer interaction [2].

Finally, the work done for this thesis includes a native implementation of the XML-RPC communication protocol on the Symbian operating system. Due to great interest in the Symbian discussion forums, the protocol library has been released to the public under GNU lesser general public license (LGPL). The published software library contributes to the free software foundation by introducing the first native XML-RPC protocol implementation for a Symbian platform.

11

1.3. Structure of the work The rest of the thesis is structured as follows. The domain of the work and related

technologies are presented in Chapter 2. Chapter 3 describes requirements for the ubiquitous middleware architecture and existing ubiquitous systems. The CAPNET architecture is introduced in the beginning of Chapter 4. Next, in the same chapter, the existing architecture is analyzed and the design of the new architecture is presented. The middleware based on the defined architecture is implemented in this work. Implementation and functional testing of the middleware are described in Chapter 5. A ubiquitous test environment was built for the functional testing. The author has been involved in the overall design of the test environment and implementation of a few individual services. The test environment and scenarios are described at the end of Chapter 5. In Chapter 6, the architecture is evaluated and the outcome of this work is discussed. Summary of the work is presented in Chapter 7.

12

2. UBIQUITOUS ENVIRONMENTS This chapter defines the basic concepts behind ubiquitous applications, ubiquitous computing, and ubiquitous environments. Moreover, the technologies that are related and commonly used in ubiquitous computing environments are studied and introduced.

2.1. Introduction of the domain The research carried out in this work contains elements from several fields of computing. A number of related technologies are also involved in this study. This chapter provides a short overview of the generic terms and related technologies used in this thesis.

2.1.1 Distributed computing Distributed computing is a computing model, in which the computing is not centralized to a specific device and in which the several computing entities run one or more computational tasks collaboratively. Moreover, in most cases such a system appears as a single computing platform to the user. Distributed and collaborative computing entities constitute a distributed computing system. A number of definitions of distributed computing systems exist in the literature. According to a definition given by Sinha in [3], a distributed computing system is:

“A collection of processors interconnected by a communication network in which each processor has its own local memory and other peripherals, and the communication between any two processors of the system takes place by message passing over the communication network.”

This definition characterizes a distributed computing system from the hardware

point of view. Tanenbaum [4] has a loose and more objective definition that addresses also the software layer and the user of the system as they are an integral part of it. Tanenbaum’s definition is adopted and used in this work as follows:

“A distributed system is a collection of independent computers that appears to its users as a single coherent system.”

A distributed computing system has several characteristics. It encompasses a wide

set of computational devices, communication mechanisms, reliability, scalability, fault tolerance, resource sharing, accessibility of services and more. Thus, a distributed computing environment is complex from the application developers’ point of view. Several industrial solutions exist that aim to support the application development in distributed computing environments. Examples of these technologies are CORBA [5] and Java RMI [6].

One example of distributed computing system is the Internet. As the user reads a web page he/she is actually using the distributed system that comprises the site. As the user browses the web, the web browser communicates with different web servers

13

that provide web pages. Possibly, the browser uses a proxy server to access the web contents stored on web servers faster and more securely. To find these servers, it also uses the domain name system which consists of seven distributed domain name servers in the internet. The web browser communicates with all of these servers via a system of routers which are themselves part of a large distributed routing system. [4]

2.1.2 Mobile computing Mobile computing extends the concept of distributed computing by introducing mobility of participating nodes in the system. Mobility is the ability to move or to be moved freely and easily [7]. Mobile computing, sometimes referred to as nomadic computing, is the use of a portable computer capable of wireless networking [8]. Development of hardware and software technologies has enabled mobile computing to be part of our everyday life. Mobile computing encompasses technologies and devices such as wireless networks, notebook computers, cell- and smart phones, tablet PCs, PDAs and more.

Several properties can be identified that characterize mobile computing. The computing devices are portable and mobile. The users of the devices are mobile. The devices communicate in wireless fashion and are heavily resource-constrained, such as in battery life, processing power and memory. Thus, mobile computing introduces a remarkably unreliable and fault-sensitive computing environment to the applications.

A major challenge in mobile computing is the communication infrastructure, which must support mobility of the participating nodes. A good example of this is a GSM system. As the serving base station changes due to user’s movement, the data is routed to the terminal device without interruptions in traffic. Thus, a GSM infrastructure supports mobility and provides seamless connectivity for mobile terminals.

2.1.3 Ubiquitous computing Ubiquitous computing, also known as pervasive or invisible computing, is a vision by Mark Weiser [9] in which the networked computational devices are embedded all over the user’s environment. In this next-generation computational model, the technology will be more user-oriented and harnessed to support a user’s tasks and activities in all situations. Traditionally, we are used to a computation model in which the applications are tightly coupled into a single or a small number of computational devices with a static interaction method. In this model, for modifying the lecture notes from last week with our favorite text editor, we need physical access to our personal computer where all our personal data resides as well as all of our installed software. In traditional computing models, the applications are associated to the computer, whereas in a ubiquitous model the applications are associated to the user and to the user’s activities. The Oxford English dictionary [7] defines ubiquitous as:

“Present or appearing everywhere, or in all places, at the same time”

14

Furthermore, Mark Weiser [9], one of the pioneers in the ubiquitous computing field, has defined ubiquitous computing as follows:

“Ubiquitous computing enhances the use of computers by making computers

effectively available throughout the physical environment, but making them invisible to the user.”

Thus, ubiquitous computing attempts to break away from the traditional computing

paradigms by making computational services available to the user whenever and wherever desired. Instead of a single screen-based personal computer, users will interact with a number of devices that are distributed and interconnected. Furthermore, ubiquitous applications use resources available in the user’s environment and adapt to the situation at hand. However, ubiquitous computing is not just about technology and the deployment of technology in everyday environments. It also covers the human perception of different technologies and the way of interaction with the technology [10]. The difference to mobile computing is e.g. the user-centric approach employed in ubiquitous computing. In this approach the user does not need to readjust to a new computing environment as the environment changes. Instead, the technology is aware of the user’s living space and adapts to it. Thus, ubiquitous computing enables the system with information about the user’s environment and situation, i.e. user context.

2.1.4 Context and context awareness Context and context awareness is recognized as one of the major characteristics of ubiquitous computing systems. Context is used in these systems to make the application as unobtrusive as possible for the user and to benefit from the added value that can be provided by implicit input of the system according to the user’s context. Various attempts have been made to define the concept of a context. The major problem in most explanations is that they either limit used context elements or that the context usage models are too restricted as they will change from situation to situation. Dey et al. [11] have analyzed various definitions and concluded in the following, relatively loose characterization:

“Context is any information that can be used to characterize the situation of an

entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves.”

A system that utilizes contextual information is considered to be context-aware or context sensitive. Furthermore, context awareness is an application’s or software system’s ability to sense, analyze and employ context from various sources. Context awareness enables a software system to adaptively take different actions in different situations. Dey et al. have defined context awareness as follows [11]:

“A system is context-aware if it uses context to provide relevant information

and/or services to the user, where relevancy depends on the user’s task.”

15

In the ubiquitous computing paradigm, the application environment is highly dynamic and can fluctuate widely across periods of time while the functionality of the application remains the same from the user’s point of view. By acquiring information about the surrounding environment, the system can modify its behavior to provide extensive support to the user’s current task or activity. Furthermore, a context-aware application can offer or highlight the features that are relevant to the user’s current context. This kind of dynamic adaptation model can make a great contribution to human–computer interaction and also serves the fundamental ideas of ubiquitous computing. Context sensing is also remarkably important if the system is to give the user the impression of proactive and spontaneous behavior in all situations.

2.1.5 Transparency

The concept of transparency can be applied to several aspects of distributed computing systems. As mobile and ubiquitous computing environments are also distributed, transparency is involved in them as well. Transparency occurs when the details of the underlying system are hidden from the user and the applications. In a distributed system, for instance, it means that the system is represented as a single and coherent computing platform instead of a large set of heterogeneous computational devices and network connections. Thus, transparency provides an abstraction of the underlying infrastructure to the layer above it. Transparency exists in several forms in distributed systems. Table 1 from [4] describes the transparencies involved in the systems that are distributed by nature.

Table 1. Different forms of transparency

Transparency Description Access Hide differences in data representation and how a resource is

accessed

Location Hide where a resource is located

Migration Hide that a resource may be moved to another location

Relocation Hide that a resource may be moved to another location while in use

Replication Hide that a resource is replicated

Concurrency Hide that a resource may be shared by several competitive users

Failure Hide the failure and recovery of a resource

Persistence Hide whether a (software) resource is in memory or on disk Transparency is a common feature in distributed computing systems. However, in

some cases it can be harmful to hide the distribution aspects from the user. For example, if the load of a local FTP server is at maximum, it is preferable that the user can select another server to download a file. Systems which provide a transparency mechanism to the applications are usually built on top of some enabling technology or an integrating software layer called middleware.

16

2.1.6 Middleware The term middleware has been used in various contexts in the academic world. Thus, no commonly agreed definition of middleware is available that would explain it unambiguously in all areas. Middleware was first introduced in the context of enterprise systems, in which it was used for integrating the disparate and heterogeneous computing systems across multiple company divisions. Later on, it has been used also in contexts of distributed systems, web services, ubiquitous and mobile computing and in embedded systems [12]. Added value in using middleware is that it provides an abstraction of an underlying system and, thus, makes heterogeneous computing platforms transparent to the application layer. In a distributed system, middleware hides the communication mechanisms and locations of interacting entities in the system. In an embedded system, on the other hand, the role of middleware is to provide transparency from heterogeneous hardware platforms and configurations.

Middleware is all about integration. It is a software layer, which resides between applications and operating system and provides the applications a set of generic and commonly used services (Figure 1). In literature, the term middleware is used to define the software layer between the application layer and system layer. The middleware layer, in most cases, is based on one or more well-known middleware technologies. Thus, the term ‘middleware technology’ is used in defining the enabling technologies for the middleware layer. Examples of middleware technologies include CORBA, Java RMI, and DCOM [13].

Figure 1. Middleware in a computing system.

Middleware can be further divided into two layers: middleware services and

middleware technologies. The middleware services layer provides generic services to the applications as well as transparency from different operating systems, terminal devices, networks and communication protocols, hardware platforms, and more. The middleware services layer is built on top of the layer which encapsulates the utilized middleware technologies. Together with the application and system layers, the middleware constitutes the software architecture.

2.1.7 Software architecture Software architecture is an abstract definition of a large software infrastructure or a large system, which is comprised of software entities. The software architecture

17

encompasses a coherent set of patterns that guides the design of each aspect of a software infrastructure. Thus, the software architecture defines the practice of building computer software. A formal definition of software architecture used in this work is adopted from [14] as follows:

“Software architecture of a program or computing system is the structure or

structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.”

A software component can be, for instance, some utilized technology, software

library, codec, communication protocol or any entity that interacts with other components and is required in order to build a system. Externally visible properties refer to the assumptions that other components can make of a component, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. The components have certain relationships to other components in the system. One component may need services from another to provide certain functionality in the system. On the other hand, the functionality may be offered in co-operation between two components, and so on. The intent of the software architecture is that it abstracts away the detailed information of the system and provides enough information for the basis of analysis, decision-making, and hence risk reduction. [14]

2.2. Technologies Several relevant and promising technologies that are close to the domain of this work are presented in this chapter. At first, a few popular middleware technologies are discussed, continuing with technologies for information representation. Finally, some related communication protocols that enable remote procedure calls are presented. The technologies mentioned and presented in this chapter are intended to be illustrative, as also many other technologies exist that are close to the research framework of this thesis.

2.2.1 Common Object Request Broker Architecture Common Object Request Broker Architecture (CORBA) [5] is an open infrastructure for distributed systems that is standardized by the Object Management Group (OMG) [15]. CORBA specifies a system which provides interoperability between objects in a heterogeneous distributed environment. Furthermore, it provides transparency from the network, different operating systems, and different programming languages in a distributed computing environment. CORBA specification does not address the implementation of the components in the system, but their interfaces instead. The interfaces are defined in Interface Definition Language (IDL), which has a programming language independent syntax. CORBA entities can be written and invoked from any programming language that provides mapping from IDL to an implementation language used. The mapping describes how the CORBA data types are to be used in both ends of the interacting parties. IDL mapping is available for the

18

most popular programming languages including C, C++, Java, Python, Ada and COBOL.

The CORBA system is built on top of Object Request Broker, which encompasses the entire communication infrastructure necessary to identify and locate objects, handle connection management, and deliver data. The CORBA ORB architecture with an exemplary function call flow is illustrated in Figure 2 [5].

Figure 2. The CORBA ORB architecture.

The ORB forms the core of the CORBA distributed system. It is responsible for

enabling communication between objects and their clients while hiding issues related to distribution and heterogeneity. The ORB is also responsible for finding the server object, transparently activating it if necessary, delivering the request from the client to the object, and returning a response to the client. The client and the object (also referred to as servant) are connected to the ORB via IDL stub and IDL skeleton. These are generated by IDL compiler from the IDL definition of the object interface.

The CORBA is not designed to be used in wireless environments and mobile, resource-constrained devices. It has been successfully utilized in systems that comprise laptops and PDA devices with wireless network connection. However, current mobile phones do not provide any support for the CORBA technology. Several CORBA libraries exist for Java, for example JacORB [16], but they require Java versions that are not supported by commercial mobile phones. Support can only be found in some new communicators, such as Nokia 9500 Communicator.

2.2.2 Java Remote Method Invocation The Java Remote Method Invocation (RMI) [6] is an object-oriented middleware technology for distributed systems. It allows an object running on one Java Virtual Machine (VM) to invoke methods on an object that is running on another Java VM. The RMI provides transparency from the distribution by enabling the methods of remote objects to be called in the same way that any local method is called. The method call is executed through a reference to a distributed object, which is obtained from the naming service of Java RMI, called RMI Registry. The RMI Registry runs on the server machine and contains information about available server objects. Java RMI relies heavily on Java Object Serialization, which enables programs to read and write Java objects to and from a conventional I/O stream.

Java RMI is not designed for wireless and resource-limited environments. Thus, it is not suited for mobile computing as such. This is mainly because the object serialization produces a large amount of overhead in the invocation and, on the other

19

hand, because of heavy and wasteful usage of TCP connections in RMI. For instance, getting a single reference to a remote object in a GSM data environment takes between 8 and 20 seconds, depending on the version of the Java Virtual Machine [17]. Anyhow, since Java RMI is already a popular middleware technology in distributed systems, some attempts have been made to modify it to mobile computing environments as well [18] [17].

2.2.3 Distributed Component Object Model The Distributed Component Object Model (DCOM) [13] is an object-based distributed system developed by Microsoft. It provides interoperability and re-usability between distributed objects. The basis of DCOM is formed by Microsoft’s component object technology COM. The goal of COM is to support the development of components that can interact with each other, and to allow binary compatibility between the client and the object written in arbitrary programming language. A component in COM is executable code either contained in a (dynamically linked) library or in the form of an executable program. [4]

DCOM extends COM by adding the possibility for a system to communicate with components that are located on another computer. However, the basic mechanisms to exchange information between components as offered by COM are often exactly the same for DCOM. In other words, DCOM offers transparency of the component distribution to the system. [4]

Similar to CORBA and Java RMI, DCOM is centered on the implementation of interfaces. Thus, a DCOM object implements one or more interfaces, using which the clients can access the services that the component offers. In DCOM, the interfaces are described in Microsoft Interface Definition Language (MIDL), which is equal to IDL in CORBA. [4]

DCOM is Microsoft proprietary solution for distributed systems. Thus, it is best supported on Microsoft Windows platforms. Microsoft provides an operating system for mobile devices, which can be also used in mobile phones. However, similarly to other operating systems for mobile phones, this Windows Mobile platform does not provide any support for DCOM.

2.2.4 Extensible Markup Language Extensible Markup Language (XML) [19] is a simple, very flexible text format that was originally designed to meet the challenges of large-scale electronic publishing. Today, XML is widely used for exchanging information and data on the web and its role and usage is growing all the time. The XML is capable of describing many different kinds of data and it provides a structured format for storing and exchanging information in a self-descriptive way. The advantage with using XML is that it provides a platform-, software- and programming language independent way to describe and exchange the data. Moreover, the XML data is simultaneously in human- and machine-readable format. An example of an XML document is shown in Figure 3.

XML documents are composed of start and end tags, which “mark up” the data in a document. A typical XML document contains a large number of these tags with

20

data contained within the tags. The example shown in Figure 3 contains a message from Julian to George, where she reminds him about some lecture notes. Considering the example, it is easy to recognize the self-descriptive way of presenting information. The tags marked <tag>, are not specified by XML, but instead by the author of the XML document. The example illustrates one advantage with XML, which is its flexibility in representing structural information. XML has, however, several weaknesses as well. The syntax of XML is verbose and partially redundant. It can make XML difficult to apply in situations where bandwidth is limited. This can be a significant challenge especially in multimedia applications running on resource-constrained devices, which use XML to describe images and video.

<message> <to>Julian Smith</to> <from>George Anderson</from> <heading>Reminder</heading> <body>Don't forget the lecture notes!</body> </message>

Figure 3. Message stored in XML format.

2.2.5 Simple Object Access Protocol Simple Object Access Protocol (SOAP) [20] is standard for exchanging XML-based messages in decentralized, distributed computing environments. SOAP is widely used in web services and it uses HTTP as transport protocol. It provides a basic messaging framework by defining the structure of the message and the actions required from the receiving SOAP node. A number of messaging patterns exist that describe how to utilize SOAP. The most popular is Remote Procedure Call pattern, where one node sends a request message to another, which immediately replies to the client with a return message. A disadvantage with SOAP is that the textual data representation generates a significant amount of overhead to the messages. This is considerable especially in case of mobile devices with low bandwidth.

A SOAP message is composed of three parts: SOAP envelope, SOAP header, and SOAP body. The envelope and body are mandatory elements in a SOAP message. The envelope defines an overall framework for expressing what is in the message and how to process it. Moreover, it defines the data types and encoding rules for the data used in the message. SOAP header contains information concerning the message, such as the date on which the message is sent, authentication information, and more. SOAP body comprises the actual SOAP message that is intended for the endpoint of the message. The SOAP header and body are encapsulated inside the SOAP envelope.

2.2.6 XML-RPC XML-RPC is a remote procedure call protocol that is intended to be used in Internet applications. The actual remote procedure call is encoded in XML language and

21

included in the body of the request. A procedure is executed on the server and the value it returns is also formatted in XML. The XML-RPC protocol is lightweight and useful in distributed systems, which do not require complex information to be exchanged between the communicating parties. The protocol, however, limits the parameter types that can be used in remote procedure calls. The protocol supports primitive types, such as Boolean values, integers, doubles, strings, and binaries. Moreover, it also supports arrays and tables that contain the supported types. The XML-RPC call is illustrated in Figure 4 [21].

Figure 4. XML-RPC call.

At first, the function and function parameters are encoded into XML form. The

encoded function call is encapsulated inside HTTP-POST request and transmitted to the receiver. At the other end, the function call and call parameters are decoded from XML data and a corresponding function call is executed. The server returns the function results to the client in similar manner.

2.2.7 Resource Description Framework The Resource Description Framework (RDF) is a language for representing information about resources in the World Wide Web. In particular, it is intended for representing and interchanging metadata about Web resources, such as title, author, date of modification, copyright, and more. It can also be used to represent information about things that can be identified on the Web. [22]

RDF is intended for situations in which the information needs to be processed by applications, rather than only being displayed to people. It provides a common framework for expressing this information so it can be exchanged between applications without loss of meaning. The ability to exchange information between different applications means that the information could be available to applications other than those for which it was originally created. RDF is based on the idea of identifying things using Web identifiers and describing resources in terms of simple properties and property values. The key elements in RDF are resources, properties, and values. A resource is anything that can have URI. A property is a resource that has a name and can be used as a property, for example author or title. The three elements can be utilized in creating RDF statements. A statement consists of the combination of a resource, a property, and a value. These parts are referred to as

22

subject, predicate and object of a statement. A statement associates a subject resource with an object resource or a literal using a predicate resource. A statement can be represented in a graphical form as well. For example the statement “The author of the example is John Smith” would generate a graph as shown in Figure 5. In the graph, the resource has the URI “http://example.rdf”. It has the property “author” with the value “John Smith”.

Figure 5. RDF graph example.

2.2.8 Symbian operating system The Symbian OS is a 32-bit operating system designed for a range of mobile devices from smart phones to PDAs. The system is based on EPOC operating system, which is originally developed by Psion in the 1980s. EPOC was a success due to its good power management, robustness, light and effective applications, and application framework. In addition, Symbian OS provides extensive support for communications and messaging at the application level and thereby is an ideal platform for communicating mobile devices [23]. Symbian Ltd., a joint venture of leading mobile device manufacturers and Psion, was established in 1998 to maintain, license and further develop the core of the Symbian OS.

Symbian Ltd. has released several versions of Symbian OS. EPOC release 5, referred to as Symbian OS 5, was the first operating system by Symbian Ltd. that was used in commercial smart phones and communicators. Symbian OS 6 was released in 2000 and selected as a platform for several products, which reached not only business but also consumer markets, and therefore it received wide publicity. Version 7 of Symbian OS was published in 2002, followed by version 8 in late 2004.

Symbian OS is based on microkernel architecture. The idea behind a microkernel is that the kernel is split up into independent elements, servers, which communicate with applications through a message passing mechanism. The actual kernel does basically nothing, but provides a framework or substrate on which different kinds of services can be built. Servers and applications are running on separate user-level processes, so they are protected from one another’s faults. Misbehavior of one server cannot take down the whole system, and virtually any element in the system can be dynamically replaced at runtime. Client-server design pattern is widely used in Symbian OS. Virtually all asynchronous services in Symbian OS are provided by servers through client-server architecture. Because of the microkernel architecture and system servers, Symbian OS is highly modular, efficient and reconfigurable. By default, the platform offers servers for communication, messaging, multimedia, file system, application framework, telephone, and more. The architecture of Symbian OS v.7.0s is illustrated in Figure 6 [24].

Symbian OS provides fully multitasking and multithreading environment for the applications. Each program runs as a separate process and thus allows multiple

23

applications to run concurrently. This fully multitasking design allows tasks to be run in the background in addition to the application that the user is currently using. The ability to do this has particular benefits especially when running communications applications. Each process in Symbian OS contains one or more threads, and the system scheduler allocates use of the processor to threads by a system of prioritized pre-emptive multitasking. [25]

Figure 6. Symbian OS v.7.0s architecture.

Symbian OS uses an extended subset of the C++ language. Main differences to

standard C++ are implemented to make the usage of C++ more understandable and safer for developers. Also, since the platform is designed for mobile devices, it has to respond more effectively to constraints set by the limited system resources such as processing power, memory and battery life. In addition to C++, Symbian OS delivers also standard C functions. Symbian Ltd. provides complete PersonalJava implementation to the licensees. However, in most cases the commercial products support only a subset of the Java language, provided with extensions, for instance for multimedia, Bluetooth and advanced graphics.

24

3. UBIQUITOUS MIDDLEWARE Requirements for generic use ubiquitous middleware are defined in this chapter. In particular, the emphasis is put on identifying the core requirements that are common to the application area. The identified requirements create a basis for the architecture design which is introduced in Chapter 4. After the requirement specification, existing ubiquitous systems are introduced and analyzed from the viewpoint of the identified requirements.

3.1. Requirements for ubiquitous middleware This chapter gives an overview of the requirements for the middleware that supports the development of ubiquitous applications. The focus is on core requirements that are common to the existing state-of-the-art ubiquitous middleware architectures. In general, the requirements are set by the nature of distributed, mobile and heterogeneous computing environments and, on the other hand, by the characteristics of ubiquity. By examining the existing ubiquitous systems described in [26], [27], [28], [29] and [30], the following five fundamental requirements can be identified:

− interoperability, − discoverability, − location transparency, − adaptability, and − context awareness.

Several additional requirements can be recognized for the architecture as well. In

general, the additional requirements extend the core requirements and need for them to be satisfied first. Additional requirements are discussed briefly at the end of the chapter.

3.1.1 Interoperability Ubiquitous computing environments, quoting Mark Weiser’s definition, consist of various kinds of computational devices, networks and collaborating software and hardware entities. Due to the large number of heterogeneous and cooperating parties, interoperability is required at all levels of ubiquitous computing. IEEE standard glossary of software engineering terminology [31] defines interoperability as:

“Interoperability is the ability of two or more systems or components to exchange

information and to use the information that has been exchanged.” At the application level, the cooperating subsystems need to communicate with

each other and to understand the communicated information. At the system level, the underlying software must be provided with a representation of the data it is able to process. Interoperability is addressed as one key challenge in ubiquitous computing [27], [28], [32], [33]. It is reasonable to provide software components with certain abstractions of the underlying platform, as this allows their use in different

25

environments. Furthermore, abstraction hides the diversity of the underlying system and the functional capabilities behind an integrating architecture or supporting middleware. For instance, it is crucial to a multimedia application to be able to communicate with all output devices in a similar way, whether the device is a monitor, a video projector or something else. In most cases, interoperability in ubiquitous systems is achieved by agreeing on a unique interface for each service or resource type and a standard representation for all data. This is utilized in CORBA-, RMI-, and DCOM-based solutions. A drawback in such systems is that agreement on a single interface for every service type is unlikely to occur for all services, and in case the interface changes the interoperability is lost. Ponnekanti [33] has introduced a solution for application–resource interoperation without standardized service interfaces. The solution utilizes one or more dynamically loadable adapters between incompatible interfaces. Adapters convert information between two predefined interfaces and thus, by chaining a sufficient number of adapters together, the interoperability can be achieved between two non-interoperable functional units. Also frameworks like Semantic Web [34] and Web Services [35] aim to provide application level interoperability between the diverse set of platforms that the Internet is composed of.

3.1.2 Discoverability One of the fundamental challenges of distributed and highly dynamic environments is how the applications can discover the surrounding entities and, conversely, how the applications can be discovered by the other entities in the system. Thus, ubiquitous applications must be provided with a mechanism for locating and addressing the resources and services in the surrounding environment. For example, if the user wants to print a file, a printer service may be a compatible service to support the desired task whereas a display or media player is not. Furthermore, the user may want to discover a printer with certain capabilities such as color and accuracy. On the other hand, if the execution environment of the applications changes due to the user’s mobility, it is crucial for the adaptation process to be able to identify the resources that are available and active in the new environment. Discoverability is a primitive enabler in platforms for distributed and ubiquitous computing [5], [26], [27], [28], [33], [36], [37].

Discoverability can be achieved by several mechanisms. The ubiquitous system may have a centralized service repository, where all the available services and resources of the environment are registered with corresponding service attributes and parameters. The service repository is aware of the services’ and resources’ locations as well. Using a query mechanism provided by the repository, the entities in the system can locate all available resources. This model is utilized for instance in Jini [37] and CORBA frameworks. In Jini, the applications use a dedicated lookup server for monitoring available resources in the local environment and for querying available services with the desired attributes. Discoverability in CORBA is handled by using a trading service, respectively. A drawback in the centralized model is that it requires infrastructure as well as configuration, management and administration.

In another service discovery model, all the devices in the system have their own service repositories. The service repository includes the services provided by the device. This mechanism is utilized by the Bluetooth [38] protocol. The Bluetooth

26

discovery process requires two steps. First, the devices are discovered. As soon as a device is found, the services provided by the located device can be discovered.

Simple service discovery protocol (SSDP) [39] is a discovery protocol utilized in UPnP. In SSDP protocol, the services are discovered by sending multicast requests to the network. If the SSDP service receives a discovery request that matches the service it offers, it will respond to the request. Similarly to Bluetooth service discovery protocol, SSDP does not require additional infrastructure. However, SSDP requires multicast support from the utilized network layer, which is not provided for example in GPRS network.

3.1.3 Location transparency

In a ubiquitous system, the execution environment of applications can be logically considered a single container including all applications, other components, and resources. Moreover, the idea in distributed environments is that the resources can be accessed without any knowledge of where the resources or the user are physically located. Whether a file is located in the mobile terminal’s local file system or in a network server, the user accesses it in the same way. This is called location transparency; the locations of the system components are transparent to the other components, the programmer, and the user.

Many modern distributed systems and platforms illustrate location transparency [5], [6], [13]. Location transparency is usually achieved by remote procedure calls (RPCs), which establish a client–server relationship between the interacting parties, eliminating the need for each party to be aware of the other’s location. The remote procedure call system consists of five elements: client, client-stub, server, server-skeleton and RPC runtime. When the client makes a procedure call for a procedure that exists on a remote machine, it invokes the appropriate method in client-stub. To the client, this resembles a normal local procedure call. The client-stub then assembles data packets, which include the target procedure identifier and the required values. These packets are then passed to the local RPC runtime, which transmits them to the remote runtime. On receipt, these packages are passed to the server-skeleton where they are unpacked and passed to the target procedure in the server. Once this procedure has been executed, any results are packaged up and the process is repeated in reverse. RPC is synchronous by nature, so while the server procedure is being executed, the client is suspended, awaiting the result. An RPC framework is presented in Figure 7.

Figure 7. Remote procedure call.

27

In addition to remote procedure calls, location transparency can be achieved by

suppliers that provide information to the system. The information is used by consumers that do not need to know where the information source is physically located. Such an asynchronous and location-transparent communication mechanism can be found for example in JavaSpace [40]. These kinds of systems are typically data- or document-oriented, while RPC systems are procedure- or object-oriented.

Location transparency provides the system with great scalability. If some component in the system is overloaded, the system can add new components to form a cluster of components. The system can then route clients to the appropriate component. Location transparency also offers fault tolerance. If a particular component fails, its clients can be referred to a different component without the client even realizing it.

3.1.4 Adaptability Adaptability is the ability of a software entity to adapt to the changing environment. Moreover, adaptation is necessary when there is a significant mismatch between the supply and demand of a resource [41]. Adaptability is regarded as one of the most important functionalities in ubiquitous computing [26], [32], [36], [42], [43]. For example, some resources or services in the environment may be vital to the application. As the application’s execution environment changes due to the user’s mobility, the vital resources need to be substituted by corresponding resources in the new environment in order to ensure continuous operation. The requirement for adaptation is present on many different layers of a computing system. The user’s new environment may offer several network connections, which are better qualified due to the user’s preferences. Thus, an adaptation may be required at the network layer as well. Because of the many different system levels where the adaptation and adaptability is required, many definitions are also available for adaptation. The definitions of adaptation and adaptability used in this work are as defined in the Oxford English dictionary [7]:

Adaptation: “The action or process of adapting or being adapted.” Adaptability: “Ability to adapt oneself to new conditions.” Several strategies and approaches can be taken to provide adaptation in a

ubiquitous environment. Satyanarayanan [42] has divided the strategies into three categories (Figure 8). In the laissez-faire approach, the responsibility of the adaptation is legislated to the individual applications. This approach, however, lacks a central arbitrator to resolve possible incompatible resource demands of different applications and to enforce limits on resource usage [42]. Also, since each application needs to implement its own adaptation functionality, the size and complexity of the applications highly increases. Adaptation, as a very common

28

requirement in a ubiquitous system, can also be delegated to the underlying operating system, platform or middleware. This application-transparent approach hides the adaptation mechanism from the application layer, reducing the application developer’s workload and simplifying the development process. Several other models have also been introduced that fall between these two extremes. These intermediate forms are collectively referred to as application-aware adaptation. The motivation for these models is to allow applications to determine the best adaptation behavior for the situation, but preserve the ability of the system to monitor resources and enforce allocation decisions [42].

Figure 8. Range of adaptation strategies.

3.1.5 Context awareness One principal goal in ubiquitous computing is to make the actual computing and the enabling technologies essentially transparent. In an extreme situation, the applications are totally isolated from the execution environment. However, this makes laissez-faire and application-aware adaptations impossible. More generally, it prevents the applications from being context-aware, i.e. from using context to provide relevant information and services to the user [11]. Thus, ubiquitous applications must be provided with knowledge about the local environment and changes in it, i.e. the applications need to be aware of the user’s context.

When considering context-aware systems in general, some common functionalities can be identified that are present in almost every system: context sensing and processing, context information representation, and the applications that utilize the context information. In general, the context information can be divided into low- and high-level context information. Low-level context information can be collected using sensors in the system. Low-level context information sources can be combined or processed further to higher level context information. For example, if a person is at his/her workplace and it is late evening, it can be deduced that the person is working overtime. In order for the context information to be utilized, it needs to be represented in a way in which it can be understood. Finally, there is no use for context without context-aware applications.

3.1.6 Other requirements

A number of other requirements can be identified for the ubiquitous application middleware. These, however, are mostly extensions of the core requirements and need for the core requirements to be satisfied first. Several requirements may also be

29

set by application-specific issues, but they can be difficult to generalize to cover the whole application area. The additional requirements include, but are not limited to:

− migration, − relocation, − security and privacy, and − failure transparency.

Migration happens when the software component is physically moved to another location in a way that allows it to continue the task which was interrupted by the reassignment. The main challenge in migration is how to store the state and point of execution of the running component, and how to continue the execution after migration. Relocation is related to migration. Relocation means that the resource can be moved to another location while it is in use. If client uses a resource that is relocated, the client’s handle to the resource must be reconfigured due to new location of the resource. Thus, relocation includes migration and requires support from the client of the resource or service as well.

Ubiquitous computing is highly user-oriented and the focus is on invisible interaction between the technology and humans. As in any system where human beings are involved, security and privacy are very important factors. The users need to be authenticated, privacy of the user must be secured, and the user’s personal data must not be accessible to others. As in any distributed system, failure transparency is needed in the ubiquitous system as well. Failure transparency signifies that failures and recovery mechanisms are the responsibility of the middleware, not the application.

3.2. Ubiquitous systems Several ubiquitous middleware architectures and infrastructures have been introduced in the academic world. In this chapter, the current state-of-the-art architectures are analyzed and examined from the viewpoint of the core requirements identified to the application area. Moreover, this chapter provides an insight to the existing solutions and an overview of the state-of-the-art research on the topic.

The current systems treat ubiquity from slightly different perspectives. Gaia [27] is a metaoperating system that extends the reach of traditional operating systems to manage ubiquitous computing habitats and living spaces as integrated programmable environments. One.world [29] provides an architecture for building pervasive applications, and Aura [28] aims to provide the users with a distraction-free computing environment and to minimize the system’s intrusion to their lives.

The architectures and systems are discussed in this chapter in detail. In particular, special attention is paid to how the architectures satisfy the core requirements, as introduced in the previous chapter. Also applicability of the architectures on mobile phones is discussed.

30

3.2.1 Gaia Gaia is a metaoperating system [27], which is designed to support the development of portable applications for active spaces. Active spaces are programmable ubiquitous computing environments in which the users interact with several devices and services simultaneously. The services provided by Gaia are similar to the services provided by traditional operating systems. They include program execution, I/O operations, file system manipulation, communications, error detection and resource allocation. By extending the concepts of traditional operating systems to ubiquitous computing spaces, Gaia simplifies space management and application development for active spaces and provides a single programmable entity instead of scattered resources.

Gaia architecture is composed of three layers: the kernel, the application framework, and the applications in active space. The kernel is composed of five basic services and a central control unit called component management core (CMC). Kernel services include space repository, event manager, context file system, presence service, and context service. These primary services are available for Gaia applications, which are tied to the component-based application framework. The Gaia architecture is illustrated in Figure 9 below [27].

Figure 9. Gaia architecture.

The Gaia application framework provides applications with tools for adapting to

the changing environment, interoperating with a heterogeneous collection of individual devices, discovering resources and services in the surrounding smart space, migrating applications, and acquiring contextual information. Adaptability is a fundamental service to the applications built on Gaia. When a user enters a new environment, the user’s sessions can be dynamically mapped to the new resources in the active space. Gaia uses a special mapping mechanism for adapting the applications. Each application has an XML-based description, listing the application components and component requirements as well as initialization parameters. All the available resources and services in the current environment are discovered using a space repository, found in every active space. Space repository contains XML-based descriptions of all available resources and provides mechanisms for querying them, respectively. When the application moves from one active space to another, these

31

descriptions are dynamically mapped together for finding required services and adapting the application to a new environment. Gaia supports application migration. Component management core is responsible for loading, unloading, transferring, creating and destroying all Gaia components and applications. Thus, CMC enables applications to be physically transferred to another location, where the execution can continue after an adaptation process. Gaia relies heavily on CORBA, which provides interoperability and location transparency to the system. Also the space repository of active spaces in the Gaia system is based on CORBA technology.

Utilization of the CORBA technology prevents the use of Gaia in resource-limited mobile terminals. Gaia also uses the high-level scripting language LuaOrb [44], which is not supported by mobile phones and, furthermore, stresses a resource-limited device by an additional interpreter.

3.2.2 One.world One.world [29] provides an integrated, comprehensive framework for building pervasive applications. It targets applications that automatically adapt to highly dynamic computing environments. The architecture includes services that make it easier for developers to manage constant change. Figure 10 presents the one.world architecture [29].

Figure 10. One.world architecture.

One.world system provides the applications with four foundation services: virtual

machine, tuples, asynchronous events and environments. A virtual machine provides a common execution environment across all devices and hardware platforms. Tuples define a common data model for all applications and thus make it easy to share data. Tuples are records with named and optionally typed fields. Moreover, each tuple is self-describing so an application can dynamically inspect its structure and contents. All communication in one.world is managed through asynchronous events. Applications are composed from components that exchange events through imported and exported event handlers. Events make change explicit to applications, with the goal that applications adapt to change instead of forcing users to manually

32

reconfigure their devices and applications. Finally, environments are the central mechanism for structuring and composing applications in one.world. They serve as containers for stored tuples, application components and other environments, and form a hierarchy with a single root per device. Each application consists of at least one environment, in which it runs and stores its persistent data.

One.world provides several system services, which are built on the foundation services. System services include for example discovery, adaptation, context, and application migration. Furthermore, tuples and event-based communication provides the one.world system with interoperability and location transparency. One.world relies on the Java virtual machine, which hinders its utilization in resource-constrained devices. In particular, Java’s object serialization, which is utilized by one.world, is not supported by J2ME version of Java, available in most mobile phones.

3.2.3 Aura In Aura system [28], the functionality is based on user’s tasks, which are supported by abstract services in the user’s environment. The user’s tasks are defined in XML-based description language. Also services are described in an abstract way, and as the user’s environment changes, tasks are remapped in corresponding services by the system. Thus, Aura is not a middleware but instead a framework, which enables applications to be assigned to the user in a manner of ubiquitous computing. For instance, user’s task ‘edit text’ could be assigned to Microsoft Word in Windows environment, whereas in UNIX environment the Emacs editor would be offered to the user. Aura architecture is illustrated in Figure 11 [28].

Figure 11. Aura architecture.

The Aura architecture is divided into several layers. The lowest layer, intelligent

networking, provides support for network weather monitoring and network proactivity. The intelligent networking layer consists of two monitoring components

33

that periodically gather information from wireless access points and prediction components that utilize the data when examining the network state. Over the Linux based OS layer, Aura has the Coda file system, which provides nomadic, disconnectable file access and Odyssey for supporting application-aware adaptation and resource monitoring. The next layer comprises other Aura runtime support and Spectra, which provides a remote execution mechanism to the Aura system. Moreover, Spectra utilizes context information in deciding how to best execute the remote call. Aura applications are built on top of this layer. In a major departure from existing systems, Aura introduces a task layer called Prism, which resides on top of the application layer. Prism supports user task monitoring, user intent monitoring and high-level proactivity. The key ingredients of the Prism architecture are explicit representations of user tasks as coalitions of abstract services and context observation and environment management infrastructure that assists with resource monitoring and adaptation.

Aura emphasizes three fundamental requirements of ubiquitous middleware: adaptability, discoverability and context awareness. Aura is highly user- and task-oriented and provides a framework for ubiquity. It is, however, only deployed on high-performance Linux and Windows platforms. Even though Aura is intended for pervasive computing environments involving wireless communication, wearable or handheld computers, and smart spaces, it is not reported to run on any mobile device.

3.2.4 Other systems The HOMEROS is a component-based middleware architecture for ubiquitous computing environments [26]. The system architecture consists of three layers. The lowest layer provides the basic component handling logic. Extended component service layer contains a repository for storing information about the available components and resources. Furthermore, it provides a decoupled communication mechanism that is based on events, suppliers and consumers. The topmost layer in HOMEROS, the system support layer, includes context manager, configuration manager, QoS adaptation module, resource manager and security manager. HOMEROS supports the applications by satisfying all core requirements identified in Chapter 3.1. Moreover, it provides additional services, such as security. The deficiency in HOMEROS is that it is targeted mainly to PDA devices, and it utilizes CORBA, which makes it impossible to run HOMEROS on the current mobile phones.

MediaBroker [30] is a distributed framework designed to support streaming media in pervasive computing applications. The architecture divides the system into media sources and sinks, which are connected by the MediaBroker engine. The engine comprises a set of data brokers, which transports data from one media source to one or more media sinks where the MediaBroker clients are connected. MediaBroker satisfies a number of core requirements for ubiquitous applications. However, it provides no other than streaming media services to the application layer and lacks support for context awareness.

34

3.3. State of the art summary Due to the development of hardware and software technologies, computing is coming closer to the users. Distributed computing allows users to interact with diverse computing devices as a single system. Mobile computing extends distributed computing by allowing users to interact with the system regardless of their location. Furthermore, mobile computing introduces a challenging execution environment for the applications as well as demands for wireless networking. Ubiquitous computing serves the user by providing implicit functionality, such as adaptation according to the user’s context and extends mobile computing by a more user-centric approach. The evolution of the computing models described and some of their characteristics are illustrated in Figure 12 (based on [41]).

Figure 12. Evolution of ubiquitous computing.

Development of ubiquitous applications is a very challenging task. The application

development work can be reduced considerably by middleware, which provides the basic functionality that is common to the application area. The core services that the middleware must provide to the applications are interoperability, discoverability, location transparency, context-awareness and adaptability. These elements characterize ubiquitous computing in general and provide the functionality that is required in any ubiquitous computing system. Lots of research has been done in the field of ubiquitous computing and several ubiquitous computing systems exist which satisfy all the core requirements. As a summary, the existing systems and the services they provide are presented in Figure 13.

Figure 13. Requirements fulfilled by the existing systems.

35

Mobile phones provide a truly ubiquitous computing platform by nature. Common to the existing systems is that none of them is designed for resource-constrained devices, such as mobile phones. The existing ubiquitous middleware architectures also utilize technologies that are not supported or cannot be supported by modern mobile phones. In most cases, they utilize middleware technologies like CORBA that is simply too heavy for a resource-constrained mobile device.

36

4. CAPNET ARCHITECTURE ON SYMBIAN PLATFORM Three versions of the CAPNET architecture exist. This chapter introduces the CAPNET architecture in general. After the introduction, the utilized architecture development process and different versions of the architecture are analyzed. In the analysis, special attention is paid to how the current architecture version satisfies the core requirements introduced in Chapter 3.1. The analysis is an input to the requirement specification for the new architecture. Requirement specification is a driver for a new architecture design which is described at the end of this chapter.

4.1. Introduction to the CAPNET architecture The CAPNET is a middleware architecture for supporting the development of ubiquitous and context-aware applications. Thus, the middleware provides applications with services that are common to the areas of ubiquitous and context-aware applications. The architecture divides functionality into atomic entities called components, each of which is specialized in some task or domain area and provides corresponding functionality to the other entities in the system. Moreover, a component can use services of other domain areas to fulfill their responsibilities. A component can be specialized for instance in discovering the services and the resources in the environment. At the user level, on the other hand, a component can represent a service in the environment, such as a printer or a projector. This also provides an analogy between the digital and physical worlds.

Each component has a well-defined interface and a description that defines the properties of the component. The components form a context-aware and pervasive middleware layer that offers a set of generic services to the applications. On a general level, the CAPNET architecture constitutes an abstraction layer between the applications and the underlying platform and infrastructure. In line with Bernstein’s [45] definition of middleware, this CAPNET middleware masks the complexity of networks, system distribution and underlying platforms and thereby allows developers to focus on application-specific issues. Furthermore, it factors out the commonly used functions into independent components, so that they can be shared across platforms and software environments. Components are the smallest building blocks, which constitute the whole system. The component framework of the CAPNET architecture is illustrated in Figure 14.

The CAPNET components live inside a container called an engine. Every device in the CAPNET universe comprises one engine. As a minimal functionality, the engine has capabilities for managing components, communicating with other engines in the system, and discovering available resources in the environment. These primitive domain areas constitute the core of an engine. Figure 15 illustrates a system that consists of a mobile phone and two network servers, each of which contains one CAPNET engine. The application, running on the mobile phone, utilizes keyboard and projector services, represented by corresponding components in the CAPNET environment.

37

Figure 14. CAPNET component framework.

The functionality of an engine can be extended by starting additional components

into the engine or utilizing the components that are already running in other engines. The main controlling component in the engine is called Component Management. Each component in an engine is controlled independently by the Component Management. Therefore, misbehavior of one component cannot affect the others. Components are depicted by metadata called component description. Component description defines the component by its name and interface, a contact where it is accessible, requirements for execution, and so on. Moreover, every component instance in the CAPNET universe is identified by an individual ID number, which is unique over space and time. Therefore, each functional subunit of the system can be uniquely addressed.

Figure 15. CAPNET engines and services.

Applications in the engine are CAPNET components as well. Thus, the

architecture introduces an application framework and the applications are influenced by the same rules as any other components. The components are distributed in the

38

CAPNET environment inside packages, which contain component code and component description. The component packages can be downloaded to the system and started dynamically at runtime.

4.2. Analysis on the CAPNET architecture

The first CAPNET architecture was released in December 2002. An iterative development process was selected for the architectural design in the early phases of the project. The iterative development process is cyclic by nature. It consists of three tasks:

1. Creation of application scenarios. 2. Specifying the architecture. 3. Designing and implementing the architecture and the application

prototypes.

Application prototypes are defined by the selected application scenarios. Requirements for the architecture design (task 2) are set by the application scenarios (task 1) and the feedback from the implementation task (task 3). Thus, the architectural design is driven by the ubiquitous application scenarios and the prototyping work. The requirements for the architecture are refined in every iteration cycle. So far, the architecture has been refined twice after the first developed architecture version. The latest version, version three, was introduced in the beginning of 2004.

The first version of the CAPNET architecture was based on “Know Your Whereabouts” application scenario, which was strongly focused on utilizing user’s context. The scenario, in short, included the following use cases:

− the user can set the profile on his/her mobile device, − the system is capable of positioning and learning the users’ habits and

routines, − the system is capable of changing the user’s profile according to his/her

habits and routines, such as when entering a meeting room, − the user has a calendar where he/she can write notes, for example where

the meeting is, − the system reminds the user about upcoming events, such as a meeting,

and − the user can add notes in certain places and contexts.

The first architecture version was designed to satisfy the requirements of the

selected application scenario and the overall requirements of the application area in question. The selected scenario introduced a requirement for context awareness. Other requirements included interoperability and dynamic application partitioning, i.e. the system is capable of adding and removing parts of the application at runtime. Interoperability was identified due to the distributed nature of the system to be developed. The architecture also provided a mechanism for service discovery and location transparency to the applications and components. The architecture was developed with several prototype applications, which implemented the described functionality.

39

Version 2 of the architecture was refined from the first architecture according to “Business Meeting Scenario” and experiments from the previous architecture version. The application scenario included the following use cases:

− the user has a calendar where he/she can make notes, for example where

the meeting is, − the user is able to attach a document to a calendar event, − when the user is walking inside the office building, he/she can see a

dynamically updated list of services available nearby, − the system is capable of changing the user’s profile according to his/her

context, such as when he/she enters the meeting room, and − the system offers files to the user according to his/her context.

The second selected application scenario did not address any further requirements

to the overall architecture. The contribution of the new release was increased context elements and extensive utilization of context, a common data model, and extended functionality due to new components, services, and applications. Nevertheless, as the functionality increased, no new domain areas or components were introduced. This influenced the architecture by requiring more complex logic in each domain. The third architecture introduced a new model for layering the components and stated that the components should be structured according to component dependencies. It also focused on separating the advanced logic from the core functionality to the layer above it. Moreover, it separated the platform-dependent components into an additional layer below. Equally to the second version, no fundamental requirements were introduced that would have affected the primitive functionality of the architecture. The third architecture is described in more detail in [46] and [47].

The third version of the architecture satisfies the same requirements as the first developed architecture, even though the functionality has significantly increased due to the new application scenarios. By this statement, it can be concluded that the iterative development process has not influenced the architectural development in a desired way, since no new requirements to the architecture were introduced during the two iteration cycles, even though the functionality increased at the application level.

The core requirements satisfied by the current architecture are:

− interoperability, − discoverability, − context awareness, and − location transparency.

The architecture also includes limited support for adaptability. Laissez-faire

adaptability is covered in some individual domain areas, such as a user interface component, which provides the applications with an abstract method to build user interfaces. The User Interface component is able to adapt due to the properties of the display currently available. Similarly, the Connectivity Management component is able to adapt to the best available network connection. For a user of these components, this provides application-transparent adaptation since they are unaware of the ongoing adaptation process. However, no generic, component-level application-transparent adaptation mechanism is provided by the current architecture.

40

For instance, if the user interface component suddenly becomes unavailable due to the user’s mobility, it needs to be replaced by a corresponding component that is available. This requires support from the overall architecture in order to adapt the applications and components transparently to the changing environment at the component level. Support for a full and generic adaptability mechanism is thus required from the refined version of the architecture, which is introduced in this thesis.

4.3. Requirements for the new architecture

The research done in this thesis contributes the core requirements for a generic ubiquitous middleware architecture. The identified requirements are utilized as a driver for the new architecture design instead of refining the architecture against the new application scenarios. The development process based on requirements provides a solid ground for future development as the understanding of the application area increases and new higher-level requirements can be identified to the system. Moreover, the architecture based on application scenarios may lead to an application-specific architecture, which is not a goal of this work. Instead, the goal is to develop a generic and widely utilizable architecture solution that serves a wide set of application scenarios.

The design of the new architecture has three requirements:

− the architecture must interoperate with the existing architecture (version three),

− the core requirements introduced in Chapter 3.1 must be fulfilled, and − the architecture must be operable on the Symbian operating system.

These requirements derive to the design and implementation in several forms. The

design of the new architecture is discussed in the next chapter.

4.4. New architecture design The basis for the new architectural design is adopted from the first and the third architecture versions, since they are focused on stable domain areas. In the second version, due to extended functionality in some domain areas, some component interfaces are changed and thus are conflicting with the other versions. The work done in this thesis includes the design of new layering and composition for the components. Especially the core layer is being influenced dramatically by the new design. Component Management and stub objects are refined in this work, and a complete XML-RPC protocol library is developed as well. The Messaging component is revised due to the developed protocol library. The design of Service Discovery and Context components are adopted from the previous architecture versions as well as the component lifecycle model.

Due to the requirement-driven design approach, the layering introduced in architecture version three is refined. Motivation for the new layering is that the core of the new architecture must satisfy all the identified core requirements. In architecture version three, the support for context awareness is missing in the core

41

module. Context awareness is needed in order to enable generic application-transparent adaptation support, which is missing in the current architecture as well. The core module of architecture version three contains support for a distributed file system, which is removed in the new architecture.

The new core forms the lowest layer of the architecture and provides the core functionality to the upper layers. The selected design approach does not affect the interoperability with architecture version three, since both versions share the same component interfaces. Other layers include additional components layer and application layer. Additional components layer is comprised of value-adding components and can be layered further as necessary. An example of a value-adding component is the User Interface component. It provides an abstract method to the developer to describe the user interface of an application in XML-based language. The user interface is then built by the User Interface component according to the description using the GUI libraries of the underlying platform. This enables applications to be built without any dependencies to the underlying UI libraries. Connectivity Management component is used for managing the available network interfaces, such as Bluetooth, GPRS and 3G. This thesis concentrates on the overall architecture and the core layer, so the layer of additional components is not covered further. The new architecture is illustrated in Figure 16.

Figure 16. Overview of the new CAPNET architecture.

The core layer is composed of four components:

− component management, − messaging component, − service discovery component, and − context component.

Messaging component provides synchronous and asynchronous communication

mechanisms to the other components and allows them to share information and data with each other. All communication between the components in different engines flows through the Messaging component. Messaging delivers remote procedure calls (RPCs) to the destination and processes the incoming calls from the other

42

components. Thus, interoperability is provided by the Messaging component along with the distribution mechanism. The Service Discovery component satisfies the discoverability requirement by providing a mechanism for discovering and locating services, resources, and other components in the environment. Context component offer operations to the system for obtaining contextual information and provide the system with context awareness. Context is provided, both synchronously and asynchronously, as context events. Context component, in turn, utilize the available sensors for acquiring contextual data from the environment.

The main controlling unit of an engine is called Component Management. It controls all components by loading them into the system, initializing, starting, and terminating them. It also processes the requests concerning component access from the other components. Component Management also introduces stub objects, which are not components but act as glue between the components. When an application requests a component, Component Management returns a stub object, which represents the requested component. Thus, the applications never have a direct handle to the components they use. A stub implements the same interface with the requested component and mediates the component calls to the target component which they represent. If the requested component is located outside the local engine, the stub utilizes Messaging to redirect component calls to the target component in a remote engine. In this way the calling component has no knowledge of where the actual component is located. Thus, stubs are involved in providing a location transparency mechanism to the system. The role of the stub objects is illustrated in Figure 17.

Figure 17. Stub objects in the CAPNET system.

As analyzed in Chapter 4.2, the architecture version three lacks support for generic

application-transparent adaptation. Thus, the existing architecture requires minor modifications to the stub objects and to the Component Management component:

− stub objects must be dynamically reconfigurable at runtime, and − stub objects are owned by Component Management instead of the stub

user.

The new Component Management owns all stub objects inside an engine. If a component is requested by another component or application, a reference to the stub object is returned. If the execution environment of an application changes due to the user’s mobility, Component Management can reconfigure the stubs and associate them with the corresponding services in the new environment. Thus, reconfigurable

43

stubs enable an application-transparent adaptation mechanism. An application-transparent adaptation mechanism is provided together with reconfigurable stub objects, Context component, Service Discovery component, and Component Management. As a summary, Table 2 illustrates the requirements fulfilled by the services in the designed architecture.

Table 2. Requirements fulfilled by CAPNET services

Application requirement CAPNET service(s) Interoperability Messaging

Discoverability Service discovery

Location transparency Dynamically reconfigurable stub objects, messaging

Adaptability Component management, context, dynamically reconfigurable stub objects, service discovery

Context awareness Context The interoperability requirement with the existing architecture version influences

the overall architecture in several ways:

− the architecture must be component-based, − component interfaces must be compatible, − component descriptions must be compatible, − communication and data representation must be compatible, and − the components must be wrapped into individual, downloadable packages.

The interoperability requirement with the existing architecture also derives to the

implementation level. First, the components must be described in RDF language as it is selected to be utilized in architecture version three. Second, the communication must use XML-RPC protocol as XML-RPC is utilized by the Messaging component in all versions of the CAPNET architecture.

The rest of this chapter presents a detailed design of the core components in the system. At first, the Component Template is defined, since every component in the system is derived from it. The Component Management and Messaging components are discussed next and followed with the design of the XML-RPC protocol library. At the end of the chapter, the Service Discovery and Context components are presented, as well as the dynamically reconfigurable stub objects.

4.4.1 Component template All CAPNET components are derived from the Component Template class. Component Template implements Manageable Component interface, which contains the operations that are necessary for managing the component: initialize, start, uninitialize and stop. The Manageable Component interface defines a state machine, which expresses the state of the component during the component’s lifecycle. It also provides functions for inquiring the current state, user, and ID number of the component. The lifecycle of the components is illustrated in Figure 18. The error

44

state can be reached from any other state and it is entered if error occurs during the component execution.

Figure 18. Component lifecycle.

Component Template is a template class for all CAPNET components. It

implements the Manageable Component interface and RPC Executable Interface, which is required for executing remote procedure calls by the Messaging component. Component Template specification is illustrated in Figure 19.

Figure 19. Component Template specification.

Component Template has a reference to the Component Management and

Messaging components, which are the basic services provided to every component by default. Other components can be requested from Component Management as necessary. Component Template also includes attributes that define the user of the component as well as component ID, which identify it uniquely in the CAPNET environment.

45

The CAPNET components can be created in two ways. They can be made by extending the Component Template class and implementing the component-specific interface. Another option is that the component implements Manageable Component, RPC Executable Interface, and component-specific interfaces. This, however, is not recommended since Component Template includes implementations of all necessary functions, which must then be implemented by the component itself.

4.4.2 Component management

Component Management is the main controlling unit in the engine. It processes the requests from the components to get access to the other components. It handles loading, initializing, starting, uninitializing, and stopping the components as requested. It also provides a mechanism to shut down a local engine.

Component Management owns all components in the engine. The stub objects, which are utilized in component requests, are controlled and owned by Component Management as well. Components and stubs are wrapped in Component Containers and stored to Component Repository, used by Component Management. Component Management derives from the Component Template class and implements the Component Management interface, which the other components use to access the Component Management services. Component Management specification is illustrated in Figure 20.

Figure 20. Component Management specification.

The components in the CAPNET system are delivered in downloadable packages.

Component Management is capable of loading the components in the system at runtime. Thus, if the requested component is not locally available, it can be downloaded from the network server indicated in the component request. If the requested component is already running in the engine, Component Management

46

initializes and returns a stub object, which is associated to the local component. If the component is already running but located in another engine, Component Management initializes and returns a stub object that is associated to the component in the remote engine. Component Management can also utilize the Service Discovery component in locating the requested resources. The component request activity diagram is illustrated in Figure 21.

Figure 21. Component request activity diagram.

Each component has a component description that defines the component. It

contains a unique component identification number, initialization parameters used in start-up, component name and interface, running-url, storage-url and more. Running-url defines the location where the component is running, if it is already started somewhere in the CAPNET environment. Storage-url describes the location where the component packages can be downloaded.

4.4.3 Messaging

The Messaging component provides synchronous and asynchronous communication mechanisms to the other components and allows them to share information and data with each other. All communication between the components in different engines flows through the messaging component. Messaging delivers remote procedure calls

47

to their destination and processes the incoming calls from the other components. The CAPNET messaging is based on the XML-RPC protocol, which, in turn, provides interoperability between different platforms and system architectures. To employ the modularity in the system, the XML-RPC protocol is designed as an external library, which is utilized by the Messaging component. Furthermore, this approach enables the protocol layer to be easily extended or replaced with another communication protocol as needed.

The Messaging component is managed and owned by Component Management. When a new component is initialized and started in the engine, Component Management provides the Messaging component with a reference to the new component. Messaging then enables the component to be invoked through RPC calls. When an incoming RPC request is received, Messaging mediates the call to the corresponding component where the RPC request is processed. Messaging component specification is shown in Figure 22.

Figure 22. Messaging specification.

The XML-RPC library is decomposed into two modules: client and server. The

server is responsible for mediating the incoming XML-RPC calls to the component that provides the requested service. The client is used in invoking XML-RPC requests over the network.

The XML-RPC library forms a layer between the application and communication layers, and is controlled by the Messaging component. When Component Management provides Messaging with a new component started in the engine, the Messaging registers it to the XML-RPC server. After registration, the XML-RPC server is capable of invoking the incoming method calls to the corresponding component. The XML-RPC library is illustrated in Figure 23.

XML-RPC server introduces two interfaces. RpcServerInterface is utilized by the underlying communication layer for passing incoming RPC calls to the XML-RPC server. RpcExecutable Interface is implemented by the component that offers RPC service. It is utilized by the XML-RPC server for invoking the XML-RPC calls to the components. XML-RPC server specification is introduced in Figure 24.

48

Figure 23. XML-RPC library.

XML-RPC client provides the client-side functionality and is utilized by the

Messaging component and stub objects. Similarly to the XML-RPC server, it introduces two interfaces. XmlRpcClientInterface is used by the applications for invoking the XML-RPC calls. At initialization, the XML-RPC client is attached to the target object and provided with a reference to RpcInvocationInterface, which is an interface to the communication layer. Furthermore, the communication layer interface can be changed at runtime as well. XML-RPC client specification is illustrated in Figure 25.

Figure 24. XML-RPC server specification.

All data between the XML-RPC service and the applications are encapsulated

inside the XmlRpcValue object. Function call parameters are provided to the service as an array of XmlRpcValue objects, and the call result is returned as a single XmlRpcValue object.

49

Figure 25. XmlRpc client specification.

4.4.4 Service discovery Service Discovery component is responsible for locating the components, resources and services in the CAPNET environment. Furthermore, Service Discovery provides the system with mechanisms to publish them. Services can be discovered by providing Service Discovery with an XML-based service query. The query consists of a set of parameters and rules that indicate the desired service. According to the given query and preferences of the user, Service Discovery returns a list of matched services. A specification of Service Discovery is illustrated in Figure 26.

Figure 26. Service Discovery specification.

For discovering components, services and resources, Service Discovery is

provided with a service query that defines a set of attributes and rules that a discovered service has to match. The discovery process returns a query result, which contains a list of services matching the given query.

4.4.5 Context Context component delivers the context information to the system. Applications can gather the context information in synchronous method calls or subscribe the context events based on some set of criteria. As the user’s context changes, the Context component compares it to the subscriptions and triggers context events to the components as necessary. The context component acts as a mediator between the

50

context sources (sensors) and the other components in the system. Context component specification is shown in Figure 27.

Figure 27. Context specification.

4.4.6 Dynamically reconfigurable stubs

Dynamically reconfigurable stubs are managed and owned by Component Management. They derive from the stub template class and implement the same interface with the component they represent. Thus, every component in the system has an individual stub object. When a component is requested, Component Management initializes the stub object of the requested component and returns a reference of it to the application. If the stub represents a component in the local engine, the stub is provided with a reference to it i.e. XML-RPC needs not to be used between local components. If the stub represents a component outside the local engine, the stub is initialized to use the messaging to redirect component calls to the target component in a remote engine.

The stub objects provide mechanisms for controlling and configuring them at runtime. If the execution environment of an application changes due to the user’s mobility, Component Management can reconfigure the stubs and associate them with corresponding services in the new environment. Thus, reconfigurable stubs enable the system with an application-transparent adaptation mechanism. Since the actual locations of the components are hidden behind the stub objects, all interactions at the application level are done location-transparently. If the application, for some reason, needs to know the location of the component, it can find it out by using the Service Discovery component.

Stub specification of the User Interface component is illustrated in Figure 28. The User Interface Stub implements the same interface as the component it represents and, thus, the requesting component can use it as the original component. Similarly to the CAPNET components, the stub objects can be dynamically loaded to the system at runtime. Furthermore, the stub objects are delivered in individual packages and can thus be downloaded into the system from the network as necessary.

51

Figure 28. User Interface stub specification.

52

5. IMPLEMENTATION AND FUNCTIONAL TESTING This chapter presents the implementation of the designed architecture on a mobile phone based on the Symbian operating system. The goal in the architecture implementation is to provide a middleware layer that can be used in proof of concept testing and in the evaluation of the overall architecture. Several prototype applications are implemented on top of the middleware. The prototype applications are used in functional testing and in validation of the architecture and services which it provides to the application layer. At first, the architecture is described. The rest of the chapter describes the functional tests that were carried out for validation of the architecture.

5.1. Architecture implementation As the implementation of a complete architecture would have required a much greater contribution of labor than is reasonable within the scope of one thesis, all core components are not fully implemented in this work. However, the implemented functionality is sufficient for proof of concept testing and for demonstrating the services that the middleware architecture offers to the applications. The architecture was implemented in native C++ language, using Series 60 SDK version 2.0. Only the Symbian standard libraries were used in the implementation, so the architecture can be compiled and operated on any Symbian platform, not only on devices based on Series 60. Since the architecture was implemented in C++ language and because the target device was a resource-constrained mobile phone, extra attention was paid to memory leaks in out-of-memory situations. Furthermore, as the implemented core services provide the most important functionality in the architecture and introduces a basis for future development, a great emphasis was put on robustness and reliability of the middleware. Robustness and reliability was ensured by extensive software testing.

One of the biggest challenges in the implementation task was that the standard Symbian OS libraries provide only the most basic services for the application developers. For instance, Symbian OS does not provide an XML parser, which is one fundamental utility in the CAPNET system. Also lack of 3rd party software components for Symbian OS increased the implementation work dramatically. The only 3rd party software library used in the implementation was EAXP XML parser [48]. The biggest drawback in the implementation work was that no native XML-RPC protocol library was available for Symbian OS and it needed to be implemented as well.

5.1.1 Component framework

The component framework of the architecture was implemented by utilizing polymorphic dynamic link libraries (DLL), also referred to as polymorphic interface DLLs. Standard DLL is a software library, which is loaded to the system automatically whenever a software module that utilizes the DLL is started. Thus, the library is dynamically linked to its user at runtime. Polymorphic DLLs are libraries which export one method. The method returns an instance of an object, which

53

implements some publicly known interface. Several polymorphic DLLs can implement an object of the same interface. Although the objects share the same interface, the implementation and functionality of the object instances may vary a lot. The difference to standard DLL is that polymorphic DLL must be loaded to the system explicitly by the application that uses it. Polymorphic DLLs are typically used for providing plug-in facilities to the applications. For example, every Symbian OS application is a polymorphic DLL since they share the same interface that is used by the Symbian OS application framework for starting the application.

The motivation in using polymorphic DLLs was the requirement that the middleware platform must be able to load and run the components at runtime. Thus, the system must be able to load the components explicitly as needed. Symbian OS does not provide any other way to extend the application dynamically at runtime in the described way. An advantage with polymorphic DLLs is also that they can be distributed as single packages and thus downloaded into the system from the network, which, in turn, was one requirement for the middleware implementation as well. All components in the CAPNET universe implement the Component Interface, which is naturally used as the object type returned from the CAPNET component libraries. As the stub objects are loaded into the system alongside with the components, they are implemented as polymorphic DLLs as well. All stub objects derive from the same stub interface, which is used as a return type from the stub libraries.

5.1.2 Core components

Components in the middleware are delivered as polymorphic DLLs. When a new component is requested, the Component Management loads the corresponding DLL into the system and instantiates the requested component. After successful component loading, the Component Management loads a stub object of the component in a similar fashion. Component Management includes internal component repository, where the components and stubs are stored alongside with the loaded component and stub libraries. When the component is unloaded from the system, the component library is also closed and all system resources it uses are relieved. The described functionality requires certain dynamics from the system, which cannot be achieved by any other way than using polymorphic DLLs.

The lowest layer of the architecture, the core, is a constant part of the CAPNET engine which is always present. Moreover, the core components are key resources that are always available to the applications. Therefore, the reason why polymorphic DLL approach is used in the component framework does not apply to the core components since there is no need to load and unload them explicitly to and from the system. Utilizing the client-server architecture of the Symbian OS was considered as one approach in implementation of the core components. However, there are certain limits which prevented utilization of the client-server framework.

Firstly, the framework does not provide a mechanism to exchange object references which is required by Component Management for distributing references to the stub objects. Secondly, the system servers in Symbian OS are loaded only when they are needed, and it would thus prevent an unoccupied engine from being run on the device alone with no other than the core components.

54

For these reasons, all core components excluding Component Management are implemented as polymorphic DLLs, although they need not to be loaded and unloaded explicitly to the system. Component Management benefits this approach as well, since all components in the system can be managed in a similar way regardless of whether they are core components, components in the upper layers, or application components. Component Management is implemented as an executable target type as it is not a Symbian application. An executable target type in Symbian is for executables that have no graphical user interface and are thus not tied to the Symbian application framework. Starting the engine in a mobile phone requires Component Management to be started explicitly by some dedicated application. Another option is to configure Component Management to be started automatically on device start-up.

5.1.3 XmlRpc-S library

The CAPNET Messaging component utilizes XML-RPC protocol. The protocol, however, was developed outside of the Messaging component. The motivation for separating the communication protocol from the Messaging component was to decrease the dependencies in the system and, on the other hand, to increase the scalability of the Messaging component by allowing the protocol to be exchanged in future releases of the Messaging as necessary. The XML-RPC protocol was implemented as a standard dynamic link library, which is utilized by the Messaging component. Interoperability of the protocol library was tested with an official XML-RPC validator, available in [21].

What was remarkable in the development of the protocol library was that it is the first reported native XML-RPC library for the Symbian operating system. Due to great interest and several requests in the Internet discussion forums of the topic, the library was released to the public under an LGPL license. Thus, one of the contributions in this thesis is XmlRpc-S [49], the first publicly available XML-RPC library for the Symbian operating system.

5.1.4 Testing

Testing of the architecture elements was carried out in several phases alongside the overall development process. The tests were executed on an EPOC emulator that is included in the SDK, and on a real device (Nokia 6600) to validate the test results also in target device. Extra attention was paid to memory leaks in out-of-memory situations. Every software component was first tested individually against memory leaks using white-box testing approach. The tests were executed at every block of code that allocated memory, and they were thus able to cause a memory leak if the allocation failed for some reason. A possible memory leak was tested by causing an out-of-memory situation explicitly by hand and examining the result. Memory leak tests were executed only on the emulator.

After the memory leak tests, every utility and software module in the system was unit tested using black-box testing approach. Tests were carried out by utilizing SymbianOSUnit [50], a unit testing framework for Symbian operating system, and by implementing a test suite for every software module in the system. When the tests

55

were successfully passed and all faults were corrected, the work continued in the implementation of the next software module.

The components in the CAPNET architecture were built up using the developed and tested utilities and software modules. Each CAPNET component was unit tested using the black-box approach. After unit tests, the components were integrated to an engine, which was unit tested in black-box manner, respectively. An integration test suite was developed and executed to validate the interoperation of the components and to secure the robust and reliable functionality of the entire CAPNET engine.

The communication protocol is typically one of the most important, but the least visible segment in any distributed system. Thus, the implemented XML-RPC library was required to be ultimately robust and reliable. To ensure this, the extensive test suite was implemented for the XmlRpc-S library. Both client and server side modules and utilities were tested individually in the same manner than other software components in the architecture. After the successful tests, client and server modules were integrated and tested together. To avoid the challenges of mobile networking, the communication layer was replaced by a utility that connected the two parties together locally. This allowed the tests to be run on the same device and without latencies and possible errors caused by the real communication layer. After the successful integration tests, the XmlRpc-S library was tested for interoperability with the official XML-RPC validator available in [21]. Special application was developed for interoperability testing, which included a proper communication layer. The protocol library was validated both on the emulator and on the target device. On the emulator, the test application was connected to the validator via Ethernet, and GPRS connection was used on the target device. All validator tests were successfully passed and thus, the protocol library was officially validated.

5.2. Functional testing The architecture was validated through functional testing. Functional testing was carried out by implementing several applications on top of the developed middleware and using them in a ubiquitous environment, which included a number of services available to the user. The purpose was to demonstrate the services that the architecture offers to the applications and thus to validate the implemented middleware as functional. This chapter describes the prototype applications, the services used, the test environment configuration, and the test scenario. The prototype applications are based on the ‘ubiquitous office’ scenario. The scenario is created for experimenting the usage of visual tags as tangible interfaces in a ubiquitous computing environment. The experiments and utilization of the middleware architecture in the scenarios are described in more detail in [2] and [1].

5.2.1 Prototype applications and services

Three prototype applications were implemented on top of the architecture. The applications were used in demonstrating the services that the middleware offers for the ubiquitous application developers. The applications were used in a ubiquitous test environment, which contained a number of services. The prototype applications were

56

able to use the services according to the user’s requests. The test environment included the following services:

− keyboard service, − display service, − printer service, and − SMS service.

Keyboard service offers fully featured keyboard capabilities. It allows a standard

keyboard to be used as an input for the CAPNET engine on a mobile phone. Display service offers a public display facility to the CAPNET components. Printer service offers printing capabilities and SMS service provides an easy mechanism to write short messages. It combines keyboard and display services into one whole so the user does not need to use them both separately.

The three prototype applications developed are SMS application, map application, and calendar application. Two versions of the SMS application exist. The first version was developed in the early phases of the architecture implementation for demonstration purposes. The first SMS application version is able to utilize the display service. Normally, the user interface of the SMS application is shown on the mobile phone’s screen. When the application starts using the display service, its user interface is transferred to the bigger and more fully-featured display. Furthermore, the keyboard service allows the input mechanism of the system to be extended. Normally, the user can type the SMS messages by the keypad of mobile phone. When the keyboard service is utilized, the user can write messages with a standard keyboard.

The second SMS application version uses an SMS service, which combined the display and keyboard into one whole. The user interface is transferred and the input mechanism extended by the same service. The second version of the SMS application is used in the test scenario. The map application is able to gather context information and use the printer service for printing the map currently open. The calendar application utilizes context information for viewing calendar information of the users in the system.

Since there is no generic User Interface component implemented on Symbian yet, the applications are tied to native UI libraries on the mobile phone side. Applications are, however, provided with abstract UI descriptions, which enable them to use any external UI component in the environment.

5.2.2 Test configuration

A test environment was created for testing the prototype applications in practice. Prototype applications were deployed on the user’s mobile phone whereas the services were running on the network servers. Services in the network were implemented on top of the previous architecture version, which is implemented in Java language. Communication between the mobile phone and the network servers was handled over GPRS.

Service Discovery and Context components were missing from the engine running on the mobile phone. The two components, however, were compensated for by an RFID infrastructure, which was attached to the CAPNET system on the mobile

57

phone side. The RFID infrastructure used is composed of RFID tags attached to the services in the environment as well as an external RFID reader module which communicates with the RFID reader software in the mobile phone via Bluetooth connection. The RFID reader software offers RFID events to the CAPNET system via Context component. With the RFID system, the user can physically discover and request services in the environment by touching them with the RFID reader. This enables the system with user-initiated service requests. In addition to requesting services, the RFID system can be used to recognize the user’s context. This is because touching an RFID tag sets heavy constraints to the situation. For instance, if the user touches a tag in a meeting room, the system can recognize that the user has entered a meeting room.

The physical test environment consisted of a mobile phone equipped with an external RFID reader, and services in the environment that were tagged with RFID tags. The RFID reader provided RFID events to the CAPNET system as RFID tags were touched. The events contained data that was stored into the tag. The RFID tags contained all the information that was needed by Component Management to access the corresponding component when an RFID tag was touched. Thus, no additional service discovery mechanism was required for the application scenarios. The test environment is illustrated in Figure 29.

Figure 29. Physical test environment.

Physical services, printer, keyboard etc. were represented by corresponding

components in the CAPNET system. As the service, labeled with an RFID tag, was touched, the RFID system generated a corresponding event to the application. The applications were able to recognize the requested service. If the application was able to use the service, it requested the service component from Component Management, using the service parameters delivered by the event. After receiving a stub object of the service component, the application could start utilizing the requested service. For instance, if the printer service was touched, the map application used it to print a map. The software configuration of the test environment is illustrated in Figure 30.

58

5.2.3 Test scenario

The developed prototype applications were tested in the following scenario: Kari is a new employee in a company, which utilizes the CAPNET system in their office space. All services in the workplace are tagged with RFID tags, and they can be used by touching them with a mobile phone. Services include office equipment (printers etc.) but they can be also fully virtual. The map service, for instance, offers a map of the floor where the user is.

Figure 30. Software configuration in functional test.

The scenario starts when Kari enters his new workplace. At first, he has a meeting

with his manager Janne. However, Kari finds out that Janne is not in his office at the appointed time. Kari has been told that the building is equipped with services, which can be accessed by touching them with a mobile phone. Services are indicated with tags that can be easily recognized from the environment. Moreover, the visual appearance of each tag suggests in an intuitive fashion the service offered by it. Kari notices some tags next to the door of Janne’s office, and one of them looks like a calendar. Intuitively, Kari associates the calendar tag to Janne’s schedule and touches it with his phone. This action opens a calendar application with Janne’s calendar appointments on Kari’s phone’s display. It appears that Janne has scheduled the meeting to a meeting room instead of his office.

While figuring out the way to the meeting room, Kari notices a map tag next to the calendar tag. As Kari touches it with his phone, the phone opens an application which shows a route to the meeting room and indicates that Janne is in the meeting room. There is one more tag next to Janne’s office labeled as a general tag. It would have caused a list of all available actions to be shown on the screen of Kari’s phone. Kari could have accessed Janne’s calendar and location from that menu as well.

As Kari starts walking towards the meeting room, he notices a printer in the corridor. Kari finds out that the printer is labeled with two tags; the first one looks exactly the same as the one by Janne’s door. Kari associates the second tag to a printing action and touches it with his phone. Since the map application is on top on the phone’s display, the map is printed. As a curiosity, Kari also touches the first tag. This causes a list of available services to be shown on his phone: Print, Info and Call maintenance. Thus, Kari finds out that, with a general tag, he can access all the available services related to the printer. Finally, Kari finds the meeting room. When

59

he is about to enter the room, he discovers some tags next to the door of the meeting room. He associates one tag with the meeting profile and touches it with his phone. As a consequence, the phone changes the profile into the meeting mode, and no phone calls disturb him during the meeting.

When the meeting is over, Kari needs to make a reservation for a cocktail party for the evening. He finds some tags from the brochure of the company organizing the party. One tag is next to a contact number. Kari associates this tag with a phone call and touches it. As a consequence, a phone call is initialized, and Kari makes the reservation. Finally, before going back home, Kari finds out that he has to enroll on a weekend course. While he is writing an SMS to the course assistant, he notices a computer with a tag attached on it. Touching the tag enhances the mobile phone with advanced input and output capabilities: the display of the SMS application is transferred to the computer’s larger screen, and the text can be typed using the computer’s keyboard.

The scenario was repeated five times with groups of two people. The prototype applications worked as expected without major problems. The minor drawbacks were related to the GPRS connection which was used in communication with the server side components. The connection was relatively slow and introduced latency, which was easy to notice especially with the keyboard service. However, the perceived problems were negligible and did not affect the proof of concept testing.

Some stages of the experiments are illustrated in Figure 31. In the pictures, the user is holding the tag reader that communicates via Bluetooth with the mobile phone. In the situation shown on the left, the printer service is used. Next, the user locates another employee in the building. In the third situation, the user is at the office doorway and uses the services he has found. In the situation shown on the right, the user interface of the SMS application has been transferred onto the computer’s screen.

Figure 31. Experiments.

60

6. RESULTS AND DISCUSSION Generic requirements for the ubiquitous application middleware were introduced in Chapter 3. Chapter 4 presented the middleware architecture design, and its implementation was described in Chapter 5 together with functional testing. This chapter discusses the work presented in this thesis and evaluates the achieved results. At first, the achievement of the objectives set to the work is discussed. Then the developed architecture is evaluated together with the implemented middleware. After the complete evaluation, a comparison to existing systems is provided. Finally, future development and work is contemplated.

6.1. Achievement of objectives

This chapter discusses how the objectives set for the work in Chapter 1.1 have been reached. The first objective was to address the functionality that characterizes ubiquitous computing in general and to identify the core requirements for middleware that supports the development of ubiquitous applications.

The objective was successfully reached via the wide literature review presented. Several requirements were addressed to the ubiquitous application area by analyzing existing systems and requirement definitions. The task was concluded as five core requirements for a generic use ubiquitous middleware: interoperability, discoverability, location transparency, adaptability and context awareness. The identified core requirements were noticed to derive from the distributed nature of the ubiquitous systems and, on the other hand, from the characteristics of ubiquitous computing. Instead of a literature review, the same result would probably have been achieved by defining a great number of ubiquitous application scenarios and analyzing their common requirements for the supporting middleware. This, however, may lead to application-specific requirements, and the purpose of this thesis was to come up with requirements for a generic use middleware architecture. The identified requirements provided a basis for the design of a new architecture. They also provided the research group with better understanding of the application area. Moreover, the addressed core requirements serve the research on ubiquitous systems and middleware architectures since they describe the primary functionality that needs to be provided first in order to develop a generic and widely utilizable system. The core requirements for ubiquitous middleware will be reported together with reference architecture design in a scientific publication in [1].

The second objective was to analyze the existing CAPNET architecture from the viewpoint of core requirements identified for the application area. The goal was to address the supported functionality and to refine the architecture as necessary to support the identified core requirements. An extensive analysis was done on the previous architectures, which showed that support for generic, component-level adaptation was missing. The weakness was corrected in the new architecture design. Moreover, the analysis on previous architectures provided the research group with better understanding of the overall architecture. Together with the identified requirements, the architecture analysis provided objectives to the research group for future architecture development work.

The final objective was to implement the designed architecture on the Symbian operating system and validate it as functional. The implementation proved to be a

61

very time-consuming task, since the availability of 3rd party libraries and software components for the Symbian operating system was very poor. For instance, it was required to implement an XML-RPC protocol library as no such module was publicly available. The developed protocol library contributed to the Symbian developer community since it was released to public as the first native XML-RPC protocol implementation for the Symbian operating system. The middleware was validated by several prototype applications built on top of it, and by using them in a ubiquitous test environment. The validation proved the architecture as functional. The middleware implementation also proved that the architecture is operable on very resource-constrained mobile devices, as the overall size of the implementation was less than 50 KB. The lightweight size of the middleware implementation was one of the main goals in the work as well, and it was successfully reached. A detailed evaluation of the architecture is presented in following chapter.

6.2. Architecture evaluation The middleware architecture has been implemented on a Symbian OS mobile phone. Several application prototypes are built on top of the middleware. The middleware implementation was made to validate the architecture as functional. The validation was done through functional testing by implementing several applications on top of it and using them in a ubiquitous test environment. The services provided by the architecture were demonstrated by executing a wide set of use cases related to ubiquitous computing. This chapter evaluates the work done in this thesis starting with the architectural design methodology and scale of the architecture implementation. The results of functional tests are evaluated and, finally, the shortcomings and strengths of the architecture are discussed.

6.2.1 Architecture design methodology The basis for the architecture development was created in a literature review on related research in which the requirements for ubiquitous application middleware were defined. In particular, the focus was on identifying the core requirements that are typical to the application area. An existing architecture version was adopted as a model for the design, since one requirement for the new architecture was interoperability with the previous one. The development process of the previous architectures had utilized an iterative development process for defining the objectives to the next architecture version. In the iterative model, the objectives were generated by application scenarios and by experiences gained from the previous architecture implementation work.

The development process in this work utilized an approach based on requirements instead of the iterative model. Motivation for the new approach was that requirement specification based on application scenarios may lead to application-specific middleware. Other than that, the purpose of this thesis was to come up with a generic and widely utilizable middleware architecture, which would provide a stable basis for future development. The approach used can be said to have been a success, since one core requirement was identified which was missing in the existing architecture. Furthermore, no new fundamental requirements were introduced during the two

62

iteration cycles that were carried out from the first architecture version by the iterative model.

The design approach based on requirements remarkably affected the composition of the architecture. Core modules in the previous architecture were rearranged to better meet the identified core requirements. This harmonized the core layer of the architecture and provided a solid basis for future development, since the fundamental services are now always present in the engine. Interfaces of the components, however, remained the same, which is a requirement for maintaining the interoperability between the architectures.

6.2.2 Scale of the architecture implementation

As the implementation of a complete architecture would have required a much greater contribution of labor than is reasonable within the scope of one thesis, all core components are not fully implemented. However, after this first development cycle, a number of features can be demonstrated, even though complete implementation would have allowed making more wide-scale experiments.

The implemented architecture includes complete versions of the Component Management and Messaging components. Service Discovery and Context components were not implemented in this development cycle. However, all the functionality is implemented that is required for testing the services offered by the architecture. Service Discovery and Context components are compensated for by an RFID infrastructure that is being utilized in the test scenarios and in the environment where the application prototypes were tested. The Service Discovery functionality was demonstrated as user-initiated service requests, which provided the system with context information as well. The scale of the middleware implementation was rich enough for proof of concept testing and for successfully validating the required functionality of the developed architecture. Fully functional Service Discovery and Context components would, however, equip the system with more extensive discovery mechanisms and context utilization.

In summary it can be said that, regarding the wide scope of the work, the middleware implementation was properly scaled and successfully served its purpose in proof of concept testing and validating the architecture as functional.

6.2.3 Functional testing results The functional tests demonstrated the use of the implemented middleware architecture and the services it provides. Three main objectives, set to the architecture in Chapter 4.3 are discussed in detail in this chapter. First, we discuss the interoperability requirement with the existing architecture and its applicability on a mobile phone based on the Symbian operating system. The constructed test environment utilized the previous CAPNET architecture version on the server side, where several service components were running. Service components were used by the prototype applications, which validated the interoperability requirement with the existing CAPNET architecture. Second, the middleware and prototype applications were running on the mobile phone side which, in turn, validated the requirement of the architecture to be applicable on the Symbian operating system.

63

The most crucial requirement for the architecture was to fulfill the core requirements introduced in Chapter 3.1. The architecture was validated against the core requirements by several application prototypes.

Application-transparent adaptation was demonstrated with a keyboard service. Normally, the user can send a message by typing it in the SMS application using the mobile phone’s keypad. The user can, however, enhance the input mechanism of the system by a keyboard service, which is accessed by touching a keyboard with the RFID reader. This adapts the system input according to the user’s request. As a consequence, the keyboard is used as an input instead of the keypad on the mobile phone, and the user can type the messages with a fully-featured keyboard. This adaptation is handled automatically by the system. Thus, the application itself has no knowledge about the adapted input method.

A display service was used to demonstrate the application-aware adaptation. When the user touches a display, the SMS application transfers its user interface onto the larger and better-featured screen. First, the application receives an event about the display service, as requested by the user. Utilizing the data received within the event, the application asks Component Management to get the display service and starts using it instead of the screen of the mobile phone. In this scenario, the adaptation was initiated by the application itself due to the user’s request, but it can be affected by the middleware as well. Component Management could prevent the usage of the requested service due to user-level access restrictions or suggest another corresponding service be used instead. However, access restriction facilities are not implemented in Component Management in this stage of the development cycle.

Laissez-faire adaptation is dependent on the application and every application must implement its own adaptation strategies. The architecture supports the laissez-faire adaptation by offering context information to the applications and the other components. Laissez-faire adaptation was not demonstrated in practice, but obviously the services needed in this adaptation scenario are offered to the applications by the architecture.

Location transparency was illustrated by the SMS application as well. When the SMS application starts using a display service, it is provided with a stub object. Thus, it uses the service as any other local resource, in a location-transparent manner, even though the service is physically located in a network server.

The map application is able to use a printer component, which provides printing capabilities to the system with a printer it represents. Moreover, the map application is able to receive notifications when the user touches a printer tag. When the map application receives a printer event, it recognizes the user’s action “print” and the user’s context, which is “next to the printer”. As a reaction, the map application asks component management to get the printer component described by the received RFID event. When a stub to the printer component is returned to the map application, it is used for printing the map shown on the mobile phone’s screen. This demonstrates the use of the user’s context and, again, the location transparency provided by the middleware since the application knows only the description of the requested printer service. Utilization of context is demonstrated also by the calendar application. Touching a tag next to the office provides calendar information of the owner of the office, which is indicated by the received RFID event.

Since the prototype is deployed on several different computational devices, the interoperability requirement is covered in all scenarios. The discoverability requirement was demonstrated using the RFID infrastructure. Touching an RFID tag

64

provided the applications with a description, using which they could request a corresponding service component from Component Management. These user initiated service requests can be considered as any service discovery mechanism. However, publishing the service is more troublesome using the RFID system, since the services must be published using pre-programmed RFID tags.

6.2.4 Shortcomings The main shortcoming of the developed middleware was that it provided only the most primitive functionality of the core layer in the architecture. Full core implementation would have allowed more extensive and wide-scale experiments to be conducted. Also additional components would have made the architecture more valuable to the applications. For example, the missing User Interface component dramatically affected the development of prototype applications, since they needed to be linked to the GUI libraries of Symbian OS.

One fundamental shortcoming of the architecture is that it does not cover such issues as access restrictions, privacy and security. This is a very essential question especially for the user’s context information, which is heavily personal and one fundamental part in ubiquitous computing. In any system where the user’s personal information and data is involved, the security needs to be taken into account. Thus, also access to context information should be restricted only to authorized users.

The architecture provides support for adaptation. However, as the users of the ubiquitous system are humans, the adaptation strategies should also be individual to the users. One might prefer an adaptation strategy which may be undesirable to the other. Profiling is one solution for offering personalized services to the users. Utilizing the user’s profile, the system could decide the preferable adaptation mechanism individually. In any case, no profiling or personalization has been taken into account in the adaptation mechanisms provided by the architecture at the moment.

6.2.5 Strengths Even though the architecture is not fully implemented, the implementation was rich enough for proof of concept testing against the set requirements. Also the implemented middleware was functioning as it was expected. This is definitely a strength, since it provides the research group with a constant and validated base for future development as the work continues. This enables also industrial partners of the CAPNET program to start experimenting with the ubiquitous applications on mobile phones and to develop the architecture further as needed.

Another strength of the implemented middleware is that, for not being an industrial product, its operation was very stable and robust and no problems were met during the prototype application tests. However, it was an expected result since a lot of effort was put on testing the software modules in the system. This is an important aspect for the future as well, since the robust and reliable core functionality created a stable basis for the development of the architecture towards a more advanced functionality.

65

The application prototypes illustrated the services that the architecture offers. Considering that the applications were operating in a truly ubiquitous environment, the amount of code when making the applications was very little. Moreover, no effort was needed in implementing the functionality related to ubiquity as it was provided by the architecture. The provided middleware significantly decreased the workload required for developing the ubiquitous applications.

A clear strength of the work is the lightweight fingerprint of the implemented middleware. The target platform of the middleware was a resource-constrained mobile phone where the size of the middleware was less than 50 kilobytes. Thus, the middleware implementation can be utilized in resource-limited devices, such as mobile phones.

The architecture allows functionality to be extended dynamically by loading components into the system as needed. Moreover, the architecture can utilize the resources running in other devices in the CAPNET system. Thus, the architecture is highly scalable and modular, which gives additional value to the system. The architecture is not based on any existing middleware technology, which would hinder its usage in resource-limited environments. This is a great strength as the middleware based on the architecture is able to operate also on mobile phones, which provide a truly ubiquitous computing environment by nature. Moreover, to the author’s best knowledge, the architecture is the first publicly reported, ubiquitous application development supporting middleware, which is able to operate on mobile phones and implemented in native programming language.

6.3. Architecture review

Chapter 3 presented three state-of-the-art architectures and systems from the field of ubiquitous computing: Gaia, Aura and one.world. Although each of the systems presented treats ubiquitous computing from a slightly different point of view, there are certain similarities between the three and the architecture presented in this thesis. Moreover, the existing systems have several characteristics that could bring additional value to the CAPNET architecture.

The Gaia metaoperating system provides the applications with similar services as the middleware architecture described in this work. Also the one.world system is functionally equal to the CAPNET architecture. However, at the implementation level the one.world and the CAPNET are significantly dissimilar.

The Aura architecture comprises several levels in the system; from hardware, through the operating system, to applications and the users, which is a considerably different approach than the other systems manifest. However, Aura lacks some fundamental services, such as interoperability and location transparency. The Aura system, on the other hand, applies proactivity as an additional concept. Proactivity has been a research topic in the CAPNET program as well [51], but it has not been considered in the CAPNET architecture development. Thus, the CAPNET architecture does not provide a generic support for proactivity.

The services provided by the Gaia kernel modules are close to the services provided by the components in the CAPNET core layer. Gaia Space repository and Presence Service provides equal services to the CAPNET Service Discovery. Gaia Context service and Event Manager are relatives to the Context and Messaging

66

components in the CAPNET architecture. Furthermore, both systems include Component Management as a main controlling unit of the architecture.

Gaia Event Manager uses event channels to deliver information. Event channels forward suppliers’ events to the consumers registered with the channel. The event manager has a single entry point and one or more event channel factories. The applications can also define their own event channels for application state changes. This is similar to communication in the one.world system. In one.world, the communication is done through asynchronous events, which are implemented using tuples. Tuples provide the system with location transparency as well. The same kind of service is worth considering also in CAPNET, since it would provide abstraction to the services provided to the application layer. Currently, the application must be aware of the component that provides the service it needs. In an event-based model, the application could subscribe the events without a need to worry about the actual service provider. [27]

Gaia and Aura systems provide file system facilities to the applications. Aura provides applications with a nomadic file access, which is based on Coda [52] file system. It offers the applications continuous access to data even in the presence of server and network failures. The Gaia Context File System provides a mechanism for the applications to distinguish meaningful information from irrelevant information, based on contextual data. A similar kind of file system was developed previously in the CAPNET program [53]. However, this Context Based Storage of the CAPNET system resides above the core layer and is thus not covered in this work. Similarly to the Coda file system, the idea in the original CAPNET file system was to provide continuous access to the data. Continuous data access has not been developed as such in the previous architecture versions, and it is certainly one service that would bring added value to the CAPNET system in the future.

6.4. Future work

The work described in this thesis provided well-grounded design and implementation of a generic use middleware architecture for ubiquitous applications. Furthermore, the implemented middleware architecture provides the research group with stable and validated core functionality for future development. Implementation of the architecture covered the most fundamental parts of the architecture core which was proof of concept tested and validated as functional. However, there is lots of work to be done for achieving a fully featured and widely utilizable ubiquitous middleware architecture for mobile phones, which was one of the far-reaching visions at the beginning of this work. The work presented in this thesis will continue in several forms in the future including three main topics: architecture development, middleware implementation, and test environment creation.

Architecture development work includes several subtopics. First, a lot of research needs to be done on how to improve the current functionality and how the additional requirements described in Chapter 3.1 can be fulfilled. Adaptation, for example, is a well-addressed research topic in the academic world, and there are several research projects working with different kind of adaptability scenarios and models. Security and privacy can also be categorized as an important research topic in ubiquitous systems. As stable core functionality is provided by this work, more services can be considered to be added to the architecture, such as migration, relocation and more.

67

Also profiling needs to be considered as advanced adaptability mechanisms are developed for the middleware.

Using mobile phones as a ubiquitous application platform is one fundamental research topic that is very close to the work done in this thesis. The developed middleware and applications built on top of it have already been utilized in experimenting with the topic [2]. More extensive and wide-scale experiments can be made as the functionality of the architecture increases. Thus, the middleware implementation work will continue aggressively in the near future towards a full core functionality with the implementation of Context and Service Discovery components. One of the biggest drawbacks in the current middleware implementation is the lack of a User Interface component. In addition to missing core components, the UI component implementation will also be included in the next development cycle of the middleware. Support for additional communication interfaces, such as Bluetooth, and seamless integration of them will also be considered.

The test environment development aims at a real ubiquitous test environment with a large number of available services. The test environment is used in experimenting with the ubiquitous applications. Since the middleware is applicable on mobile phones, which are widely used and already carried by people, more wide-scale experiments can also be made.

As a conclusion it can be said that a lot has been achieved in this thesis for providing a lightweight middleware for ubiquitous applications on mobile phones. However, even more work is still to be done for reaching that goal comprehensively and in experimenting with this wide-ranging research topic.

68

7. SUMMARY The main topics covered in this thesis included distributed computing, mobile computing, ubiquitous computing, ubiquitous applications, and ubiquitous middleware architectures. Each of these is wide enough for a doctoral thesis. Thus, this study covered only the most fundamental and primitive issues related to the topics.

The main focus of this work was to develop a generic and widely utilizable middleware architecture for ubiquitous applications. The architecture had to be as lightweight as possible so that it could be employed on resource-constrained devices, such as mobile phones. The architecture is based on the CAPNET architecture, developed earlier in the project and implemented on PDA devices. The previous architecture version was refined to better support the application area in question. A wide literature review was introduced, addressing the core requirements for generic ubiquitous middleware and creating a basis for the development of a new architecture. The motivation for the literature review was to map and characterize the application area and especially the requirements set to the underlying platform. Based on the literature review, some weaknesses were identified from the existing architecture. The deficiencies were corrected in the refined architecture. Furthermore, a new design approach was taken for the new architecture development, which dramatically affected the composition of the architecture components and harmonized the overall architecture.

This thesis presented a novel middleware architecture, which was implemented on a mobile phone based on the Symbian operating system. The architecture was validated as functional by implementing several prototype applications on top of it. The prototype applications were used in demonstrating the fundamental services offered by the architecture. Due to the wide scope of the thesis, only the core services of the middleware were implemented. Thus, all possibilities of how the architecture could be utilized in ubiquitous computing could not be demonstrated with the application suite developed. As the functionality of the architecture increases in the future, the architecture is expected to serve the application area in a much greater extent than current applications can demonstrate. This, however, requires more wide-scale experiments to be made also at the application level with new and more fully-featured application prototypes. After all, no matter how superior or overwhelming a middleware architecture might be, it is only as useful as the best application built on top of it.

69

REFERENCES [1] Salminen, T. & Riekki, J. (2005) Lightweight Middleware Architecture for

Mobile Phones. To appear in: International Conference on Pervasive Systems and Computing (PSC’05), June 27-30, Las Vegas, Nevada, USA.

[2] Riekki, J., Salminen, T., Hosio, S. & Alakärppä, I. (2005) Requesting Services by Touching Objects in the Environment. To appear in: International Conference on Human Computer Interaction (HCII-2005), July 27-30, Las Vegas, Nevada, USA.

[3] Sinha, P., K. (1996) Distributed Operating Systems Concepts and Design. Wiley-IEEE Press, 764 p. ISBN 0-7803-1119-1.

[4] Tanenbaum, A.S. (2002) Distributed Systems Principles and Paradigms. Prentice Hall Press, New Jersey, 803 p. ISBN 0-13-121786-0.

[5] Object Management Group, Inc. (16.5.2005) Common Object Request Broker Architecture. URL: http://www.corba.org.

[6] Sun Microsystems, Inc. (11.3.2005) Java Remote Method Invocation. URL: http://java.sun.com/products/jdk/rmi.

[7] Oxford English Dictionary. (16.5.2005) Home page. URL: http://www.oed.com.

[8] Forman, G.H. & Zahorjan, J. (1994) The Challenges of Mobile Computing. IEEE Computer, vol. 27, April, pp. 38-47.

[9] Weiser, M. (1993) Some Computer Science Issues in Ubiquitous Computing. Communications of the ACM, vol. 36, July, pp. 75-84.

[10] Schmidt, A. (2002) Ubiquitous Computing – Computing in Context. Ph.D. Thesis, Computing Department, Lancaster University, England, U.K., 294 p.

[11] Dey, A.K. & Abowd, G.D. (1999) Towards a Better Understanding of Context and Context-Awareness. In: Proceedings of Computer-Human Interaction 2000 (CHI 2000), Workshop on The What, Who, Where, When and How of Context-Awareness, Hague, Netherlands, 12 p.

[12] Vinoski, S. (2002) Where is Middleware? IEEE Internet Computing, vol. 6, issue 2, March-April, pp. 83-85.

[13] Microsoft Corporation. (11.3.2005) Component Object Model Technologies. URL: http://www.microsoft.com/com.

[14] Bass, L., Clements, P. & Kazman, R. (1998) Software Architecture in Practise. Addison-Wesley Longman Inc., Massachusetts, 452 p. ISBN 0-201-19930-0.

[15] Object Management Group, Inc. (16.5.2005) Home Page. URL: http://www.omg.org.

70

[16] JacORB. (16.5.2005) Home Page. URL: http://www.jacorb.org.

[17] Campadello, S. (2003) Middleware Infrastructure for Distributed Mobile Applicadtions. Ph.D. Thesis, Department of Computer Science, University of Helsinki, Finland, 155 p. ISBN 952-10-0975-6

[18] Wall, T. & Cahill, V. (2001) Mobile RMI: supporting remote access to Java server objects on mobile hosts. In: 3rd IEEE International Symposium on Distributed Objects and Applications, September 17-20, Rome, Italy, pp. 41-51.

[19] World Wide Web Consortium. (16.5.2005) Extensible Markup Language. URL: http://www.w3.org/XML.

[20] World Wide Web Consortium. (10.5.2005) Simple Object Access Protocol. URL: http://www.w3.org/TR/SOAP.

[21] Userland Software. (16.5.2005) XML-RPC Home Page. URL: http://www.xmlrpc.com.

[22] World Wide Web Consortium. (16.5.2005) Resource Description Framework. URL: http://www.w3.org/RDF.

[23] Symbian technical documents. (16.5.2005) Symbian OS: supporting packet-switched networks. URL: http://www.symbian.com/technology/packet-switch.html.

[24] Symbian technical documents (16.5.2005) Symbian OS Version 7.0 functional description. URL: http://www.symbian.com/technology/symbos-v7x-det.html.

[25] Symbian technical documents. (16.5.2005) Symbian OS for Palm developers. URL: http://www.symbian.com/developer/techlib/papers/SymbianOS_for_Palm/ Symbian_OS_for_Palm_Developers.html.

[26] Han, S., Bong, Y. & Youn, H. (2004) A New Middleware Architecture for Ubiquitous Computing Environment. In: Proceedings of the Second IEEE Workshop on Software Technologies for Future Embedded and Ubiquitous Systems (WSTFEUS’04), May 11-12, Vienna, Austria, pp. 117-121.

[27] Roman, M., Hess, C., Cerquiera, R., Renganathan, A., Campess, R. H. & Nahrstedt K. (2002) A Middleware Infrastructure for Active Spaces. IEEE Pervasive Computing, vol. 1, pp. 74-83.

[28] Garlan, D., Siewiorek, D. P., Smailagic, A. & Steenkiste, P. (2002) Project Aura: Towards Distraction-Free Pervasive Computing. IEEE Pervasive Computing, vol. 1, pp. 22-31.

[29] Grimm, R. (2004) One.World: Experiences with a Pervasive Computing Architecture. IEEE Pervasive Computing, vol. 3, pp. 22-30.

71

[30] Modahl, M., Bahrak, I., Wolenetz, M., Hutto, P. & Ramachandran, U. (2004) MediaBroker: An Architecture for Ubiquitous Computing Environment. In: Proceedings of the Second IEEE Workshop on Software Technologies for Future Embedded and Ubiquitous Systems (WSTFEUS’04), May 11-12, Vienna, Austria, pp. 253-262.

[31] IEEE Std 610.12-1990 IEEE standard glossary of software engineering terminology.

[32] Tokunaga, E., Zee, A., Kurahashi, M., Nemoto, M. & Nakajima, N. (2004) A Middleware Infrastructure for Building Mixed Reality Applications in Ubiquitous Computing Environments. In: Proceedings of the First Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous’04), August 22-25, Boston, Massachusetts, USA, pp. 382-392.

[33] Ponnekanti, S. (2003) Application-Service Interoperation without Standardized Service Interfaces. In: Proceedings of the First IEEE International Conference on Pervasive Computing and Communications (PerCom03), March 23-26, Dallas, Texas, USA, pp. 30-37.

[34] World Wide Web Consortium. (16.5.2005) Semantic Web. URL: http://www.w3.org/2001/sw.

[35] World Wide Web Consortium. (11.3.2005) Web Services. URL: http://www.w3.org/2002/ws.

[36] Ranganathan, A., Chetan, S. & Campbell, R. (2004) Mobile Polymorphic Applications in Ubiquitous Computing Environments. In: Proceedings of the First Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous’04), August 22-25, Boston, Massachusetts, USA, pp. 402-412.

[37] Arnold, K., O’Sullivan, O., Scheifler, R., Waldo, J. & Wollrath, A. (1999) The Jini Specification, Addison-Wesley Longman Ltd., Boston, 385 p. ISBN 0-2016-1634-3.

[38] The Bluetooth Special Interest Group, Inc. (11.3.2005) The Official Bluetooth Website. URL: http://www.bluetooth.com.

[39] Internet Engineering Task Force. (16.5.2005) Simple Service Discovery Protocol. URL: http://www.upnp.org/download/draft_cai_ssdp_v1_03.txt.

[40] Freeman, E., Hupfer, S. & Arnold, K. (1999) JavaSpaces Principles, Patterns, and Practice, Addison-Wesley Longman Ltd., Essex, UK, 368 p. ISBN 0-2013-0955-6.

[41] Satyanarayanan, M. (2001) Pervasive Computing: Vision and Challenges. IEEE Personal Communications, vol. 8, pp. 10-17.

72

[42] Satyanarayanan, M. (1996) Fundamental Challenges in Mobile Computing. In: Proceedings of the 15th Annual ACM Symposium on Principles of Distributed Computing, May, Philadelphia, Pennsylvania, USA, pp. 1-7.

[43] Raatikainen, K., Christensen, H. & Nakajima, T. (2002) Application Requirements for Middleware for Mobile and Pervasive Systems. ACM SIGMOBILE Mobile Computing and Communications Review, vol. 6, issue 4, pp. 16-24.

[44] LuaOrb. (16.5.2005) Home Page. URL: http://www.tecgraf.puc-rio.br/ ~rcerq/luaorb.

[45] Bernstein, P.A. (1996) Middleware: a model for distributed system services. Communications of the ACM. vol. 39, issue 2. pp. 86-98.

[46] Davidyuk, O. (2004) Component Architecture for Context-Aware Applications, Diploma thesis. Lappeenranta University of Technology, Department of Information Technology, Lappeenranta, Finland, 65p.

[47] Davidyuk, O., Riekki, J., Rautio, V-M. & Sun, J. (2004) Context-Aware Middleware for Mobile Multimedia Applications. In: Proceedings of the 3th International Conference on Mobile and Ubiquitous Multimedia (MUM2004), October 27-29, College Park, Maryland, USA, pp. 213-220.

[48] EAXP Parser. (16.5.2005) EAXP Parser Home Page. URL: http://irssibot.777-team.org/eaxp.

[49] XmlRpc-S. (16.5.2005) XmlRpc-S Home Page. URL: http://www.ee.oulu.fi/ ~tisalmin/xmlrpc-s.

[50] SymbianOsUnit. (16.5.2005) Symbian OS Unit – Unit Test Framework Home Page. URL: http://www.symbianosunit.co.uk.

[51] Pirttikangas, S. (2004) Routine Learning: From Reactive to Proactive Environments. Ph.D. thesis, Department of Electrical and Information engineering, University of Oulu, Finland, 73 p. ISBN 951-42-7565-9.

[52] Satyanarayanan, M., Kistler, J. J., Kumar, P., Okasaki, M. E., Siegel, E. G. & Steere, D. C. (1990) Coda: A Highly Available File System for a Distributed Workstation Environment. IEEE Transactions on Computers, vol. 39, issue 4, pp. 447-459.

[53] Khungar, S. & Riekki, J. (2004) A Context Based Storage for Ubiquitous Computing Applications. In: 2nd European Symposium on Ambient Intelligence, November 8-10, Eindhoven, Netherlands, pp. 55-58.