LIGHTWEIGHT MIDDLEWARE ARCHITECTURE FOR MOBILE .pdf

Document Sample
LIGHTWEIGHT MIDDLEWARE ARCHITECTURE FOR MOBILE .pdf Powered By Docstoc
					        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.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:11/7/2012
language:Finnish
pages:72
tongxiamy tongxiamy http://
About