Developing a Web-Based Service Platform Architecture for Ccontext ...

Paula Perkola
Developing a Web-based Service
Platform Architecture for Context-aware
Mobile Services
School of Electrical Engineering
Thesis submitted for examination for the degree of Master of
Science in Technology.
Espoo 23.5.2011
Thesis supervisor:
Prof. Eero Hyvönen
Thesis instructor:
M.Sc. (Tech.) Renne Tergujeff
A’’
Aalto
University
School of Electrical
Engineering

aalto university
school of electrical engineering
abstract of the
master’s thesis
Author: Paula Perkola
Title: Developing a Web-based Service Platform Architecture for
Context-aware Mobile Services
Date: 23.5.2011 Language: English Number of pages:7+65
Department of Media Technology
Professorship: Media Technology Code: T-75
Supervisor: Prof. Eero Hyvönen
Instructor: M.Sc. (Tech.) Renne Tergujeff
In this thesis, the requirements and specifications for a context- and user-specific
web-based mobile application platform were defined. Based on the accumulated
requirements, a platform architecture was designed and documented and was finally
evaluated by a panel of information system and mobile web application
experts. This Master’s Thesis and the work involved was completed as part of the
HUBI.mobi Project at VTT Technical Research Centre of Finland.
The requirements outlined for a web-based mobile application platform were listed
by their characteristics into functional, non-functional and service-specific requirements.
The functional requirements specified were location-awareness, contextawareness,
data input interfaces, map, user profile and user activity tracking.
The non-functional requirements outlined for the platform were reusability, crossdevice
functionality, scalability and multilingual content support. Lastly, the platform’s
service-specific requirements were identified as Journey Planner, Events and
Recommender.
An architecture for the m.HUBI Platform was designed and documented based on
the specified requirements. The platform consists of both server-side and clientside
components. Communication between the platform’s two sides is handled
via HTTP GET and POST messages that carry data in standard XML format.
The platform’s architecture was evaluated by three expert analysts that utilized
their experience in mobile web application development and information systems
design to assess how well the platform meets its requirements. The architecture
evaluation raised issues and concerns regarding the platform’s context-awareness,
data input interface and scalability requirements. Overall, the expert analysis
proved the m.HUBI Platform to adequately meet the requirements specified for
it.
Keywords: Mobile web application, web service, context-awareness, application
architecture

aalto-yliopisto
sähkötekniikan korkeakoulu
diplomityön
tiivistelmä
Tekijä: Paula Perkola
Työn nimi: Verkkopalvelualustan arkkitehtuurin kehitys kontekstitietoisille
mobiilipalveluille
Päivämäärä: 23.5.2011 Kieli: Englanti Sivumäärä:7+65
Mediatekniikan laitos
Professuuri: Mediatekniikka Koodi: T-75
Valvoja: Prof. Eero Hyvönen
Ohjaaja: DI Renne Tergujeff
Tässä diplomityössä määriteltiin vaatimukset konteksti- ja käyttäjäkohtaiselle
verkkopohjaiselle mobiilisovellusalustalle. Alusta-arkkitehtuuri suunniteltiin ja
dokumentoitiin koottujen vaatimusten perusteella sekä arvioitiin tietojärjestelmäja
mobiiliverkkosovellusasiantuntijoiden toimesta. Tämä diplomityö tehtiin osana
HUBI.mobi projektia Teknologian tutkimuskeskus VTT:llä.
Verkkopohjaisen mobiilisovellusalustan vaatimukset lueteltiin ominaisuuksien
perusteella toiminnallisiin, ei-toiminallisiin ja palvelukohtaisiin vaatimuksiin.
Toiminalliset vaatimukset olivat paikkatietoisuus, kontekstitietoisuus, tiedon
syötön käyttöliittymät, kartta, käyttäjäprofiili ja käyttäjän toimintojen seuranta.
Määritellyt ei-toiminnalliset vaatimukset olivat uudelleenkäytettävyys, laiteriippumattomuus,
skaalautuvuus ja monikielisen sisällön tuki. Viimeiset palvelukohtaiset
vaatimukset olivat matkasuunnittelija, tapahtumat ja suositin.
m.HUBI alustan arkkitehtuuri suunniteltiin ja dokumentoitiin edellä esitettyjen
vaatimusten perusteella. Alusta koostuu sekä serveripuolen että päätelaitepuolen
komponenteista, joiden välinen yhteydenpito hoidetaan HTTP GET ja POST
viesteillä. Viestit välittävät tietoa standardissa XML-muodossa. Kolme
asiantuntijaa hyödynsivät heidän kokemustaan mobiilien verkkosovellusten kehityksestä
ja arvioivat miten hyvin alustan arkkitehtuuri vastasi sille asetettuja
vaatimuksia. Arkkitehtuurianalyysissä nousi esiin puutteita alustan
kontekstitietoisuus-, tiedonsyöttökäyttöliittymä- ja skaalautuvuusvaatimuksissa.
Yleisesti, asiantuntija-analyysi osoitti, että m.HUBI alusta täytti sille asetetut
vaatimukset riittävästi.
Avainsanat: Mobiili verkkosovellus, verkkopalvelu, kontekstitietoisuus, sovellusarkkitehtuuri

iv
Preface
I would like to thank my supervisor Professor Eero Hyvönen and my instructor
Renne Tergujeff for their guidance and help throughout this writing process. I
also owe a big thanks to the HUBI.mobi Project Team and the entire Environment
Information Systems Team at VTT, without whom this thesis would not have been
possible. I also express my sincere appreciation to VTT Technical Research Centre
of Finland and all parties involved in the HUBI.mobi Project for financing my thesis
work and offering me the opportunity to work on and learn from such a challenging
project so early in my career.
Last but not least, I would like to thank my entire family for offering their
advice, support and encouragement throughout my studies and especially during
the completion of my thesis.
Espoo, 23.5.2011
Paula Perkola

v
Contents
Abstract
Abstract (in Finnish)
Preface
Contents
Symbols and abbreviations
ii
iii
iv
v
vii
1 Introduction 1
2 State-of-the-Art In Web, Mobile and Context Systems 3
2.1 Web Applications and Web Services . . . . . . . . . . . . . . . . . . . 3
2.2 Rich Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Context and Context-aware Systems . . . . . . . . . . . . . . . . . . 4
2.4 Context-aware Mobile Applications . . . . . . . . . . . . . . . . . . . 5
2.5 Mobile Positioning Technologies . . . . . . . . . . . . . . . . . . . . . 6
2.6 Mapping Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7 Sample Implementations . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7.1 Mozilla Open Web Applications . . . . . . . . . . . . . . . . . 7
2.7.2 Lively for Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.7.3 xFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Requirements for a Web-based Mobile Service Platform 11
3.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Service-specific Requirements . . . . . . . . . . . . . . . . . . . . . . 17
4 Architecture of the m.HUBI Platform 21
4.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Server Core Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 Database Management . . . . . . . . . . . . . . . . . . . . . . 23
4.2.2 Identity and Authorization Management . . . . . . . . . . . . 23
4.2.3 Recommender Service . . . . . . . . . . . . . . . . . . . . . . 24
4.2.4 Support Functions . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 m.HUBI Platform Service Components . . . . . . . . . . . . . . . . . 24
4.4 Javascript API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.1 Communication Module . . . . . . . . . . . . . . . . . . . . . 33
4.4.2 Foundation Module . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.3 Map Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.4 Positioning Module . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.5 Display Module . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.6 Services Module . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.7 Auxiliary Module . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.5 Content Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 Use-case Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Evaluation of the m.HUBI Platform 48
5.1 Scenario Implementations . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2 Requirement Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3 Critical Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6 Conclusion 53
References 57
Appendix: Comments from Expert Analysis 65
vi

vii
Symbols and abbreviations
Abbreviations
AJAX Asynchronous Javascript and XML
CMS Content Management System
CSS Cascading Style Sheets
DHTML Dynamic Hypertext Markup Language
DOM Document Object Model
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
HVGA Half-size Video Graphics Array
JCAF Java Context Awareness Framework
JSON Javascript Object Notation
JSP JavaServer Pages
nHD Near High-definition
QVGA Quarter Video Graphics Array
RIA Rich Internet Application
RSS Really Simple Syndication
SOAP Simple Object Access Protocol
UDDI Universal Description, Discovery and Integration
VTT VTT Technical Research Centre of Finland
W3C World Wide Web Consortium
WWW World Wide Web
XHTML Extensible Hypertext Markup Language
XML Extensible Markup Language

1 Introduction
The World Wide Web (WWW) as it is known today has come a long way from
the first static web pages created in the early 1990’s [8, 9]. Modern websites can
consist of complex hierarchies of multiple web pages that render dynamically created
contextual content in real-time. Concurrent with the advances in web technologies
has been the evolution and proliferation of hand-held personal mobile devices. An
indication of the prevalence of mobile devices is the surpassing of 5 billion mobile
phone connections in 2010, a third of which included a mobile web browser. [2, 42]
The coincidence of these technologies and events have created a niche for situationspecific,
pertinent, informative, quick and easy-to-use mobile web applications.
As mobile device characteristics and capabilities have evolved, so has the scope
of mobile device content expanded. Previously, mobile phones were restricted by
low-bandwidth communication, inadequate processing power and memory capacity,
and small screen size and screen resolution. [52, 70] Native applications produced for
proprietary operating systems and specific firmware were the only implementation
option for mobile applications at the time. This means that a single native application
needed to be adjusted separately for each mobile phone model or operating
system. [33]
Smartphones are advanced mobile phone devices that are essentially hand-held
computers integrated with mobile telephones. [25] They are subsequently less inhibited
by the drawbacks of conventional mobile phone devices, sometimes called
feature phones, and they can efficiently utilize online web applications as an alternative
to native mobile applications. [33] Web applications, contrary to native mobile
applications, run independent of a mobile phone’s operating system and firmware.
They are launched via an Internet browser, which is designed to provide a common
runtime environment across different mobile, or indeed desktop, platforms. [71]
The growing sophistication and penetration of smartphones in the mobile phone
market combined with the advances in web technologies and standards provided a
fertile foundation for mobile-specific web applications. As these mobile webapps
progressed developers realized there was an untapped resource in the mobile device
itself. The inherent sensing capabilities that modern smartphones provide combined
with the dynamic capabilities of rich web applications and technologies enable the
automatic collection and utilization of tacit situational information from the usage
scenario. [35, 70]
The purpose of this Master’s Thesis is to specify and design a situation-sensitive,
user-specific, feature-rich, highly portable and easily maintainable application platform
that facilitates the rapid development and deployment of mobile web applications.
The motivation behind this thesis work originated from a lack of existing application
or software infrastructure that facilitates mobile application development
with operating system independent web technologies while harnessing contextual
information. At the time of writing, state-of-the-art context-aware mobile web applications
are run either as native applications or on top of middleware applications
in order to gain access to the mobile device’s software and hardware. These existing
solutions provide sufficient access to the mobile device’s software and hardware,

which facilitates the collection and utilization of sensor and context data, but both
solutions are at least partially operating system dependent and require extensive
resources for application development and modification.
The research questions answered in this Master’s Thesis are:
– What are the requirements for an extensible web-based platform architecture
enabling efficient development of context-aware mobile services?
– How well does the designed and documented platform architecture meet
the requirements set out for it?
– Does the designed and documented platform architecture facilitate the
implementation of appropriate platform-based applications in response
to various fictional usage scenarios?
– Are there any critical deficiencies or inadequacies in the designed and
documented platform architecture?
The work documented in this thesis was completed as part of the HUBI.mobi
Project at VTT Technical Research Centre of Finland (VTT). The project, which
ran from 2009 to 2011, was funded by VTT in conjunction with the Finnish Funding
Agency for Technology and Innovation (Tekes) and a number of companies.
The goals of the project included creating the aforementioned m.HUBI Platform—a
web-based mobile accessible application platform—implementing a pilot platform
application and developing novel recommendation mechanisms. The recommendation
algorithms utilize explicit and implicit preference data to produce user-targeted
selections that are solicited from a developmental recommendation service. The
HUBI.mobi project aims at adapting and leveraging experiences and knowledge
gained from previous projects including the design and implementation of a webbased
desktop service platform called the HUBI Platform. The m.HUBI Platform
emphasizes the combination of data such as event and usage information, friend
locations and structured data to provide new content and added-value to users.
Prior to designing a new application platform, the current cutting edge of web
applications, context-aware systems and related technologies is briefly introduced in
section 2. The following section, section 3, represents the design phase by specifying
the requirements and functionalities of a platform that supports and exhibits
the aforementioned properties. The resulting design is then implemented in the
form of a platform architecture and application programming interface (API) that
provides access to the mobile web application platform. The newly specified and
designed platform architecture is documented and presented in section 4. Finally,
the scope and functionality of the architecture and API are objectively evaluated by
several web application specialists, the results of which are condensed and outlined
in section 5.
2

2 State-of-the-Art In Web, Mobile and Context
Systems
The information, services and applications available via the Internet have evolved
beyond recognition within the past decade. The scope of web technologies currently
in active use, not to mention the spread of emerging platforms and tools, is too
wide to discuss comprehensively so this section focuses on covering the most pertinent
topics. This section first introduces the state of modern web applications and
context-aware systems and then reviews several of their practical implementations.
2.1 Web Applications and Web Services
A web service can be generically described as a way to expose the functionality of
an information system and make it available through standard Web technologies,
i.e. HTTP, HTML, Web servers and Web browsers. The use of these technologies
reduces heterogeneity and fosters application and system interoperability. [3, p.
94, 123] A more specific definition is provided by the W3C [80], which states that
“A Web service is a software system designed to support interoperable machineto-machine
interaction over a network. It has an interface described in a machineprocessable
format (specifically WSDL). Other systems interact with the Web service
in a manner prescribed by its description using SOAP-messages, typically conveyed
using HTTP with an XML serialization in conjunction with other Web-related standards.”
Web Services build on top of existing Web protocols using open XML standards
to provide a systematic and extensible framework for application interaction. These
services are characterized by their interoperability and standardized description,
communication and discovery technologies: simple object access protocol (SOAP),
Web Services Description Language (WSDL) and Universal Description Discovery
and Integration (UDDI), respectively. [17]
A web application or webapp, as the term is often abbreviated, is defined by
the W3C as a HTTP-based application whose interactions are machine processable.
Webapps are typically based on existing Web architecture and infrastructure and
they are platform and programming language independent. They also promote application
reuse beyond the browser by enabling interoperability with other Web or
desktop applications. In addition, webapps require the content used to be semantically
unambiguous, which is usually achieved by using XML or JSON data exchange
formats. [74]
Web applications are programs that are accessed over a network. They are
usually coded in a browser-supported language, such as Javascript and HTML, and
they rely on web browsers to execute the application. [85] Webapps are fundamental
to interactive websites because they dynamically build programmatic responses to
incoming HTTP-requests. [22]
A web application server usually consists of a HTTP web server, an application
server and a database or simply an application server and a database. A generic web
server handles the distribution of files across a network by receiving and responding
3

to HTTP requests from other web servers and web browsers. [3, p. 94] However, an
application server enables the distribution of applications and provision of services
over the Internet. [54] Essentially, a web server dispenses only static content whereas
an application server can dispense dynamic content. [13] The database is needed
to provide a data warehouse, transaction processors to add, access and process that
data as well as authorization and identification services to monitor and limit access
to the database. [55]
A web application client contains the front-end portion of a web application. It
constitutes the user interface of the service and is displayed to the end-user via a web
browser. The client contains mechanisms that support and implement application
activity, interaction and communication with the corresponding server.
2.2 Rich Web Applications
Classic web applications can be made more interactive and user-friendly or richer, as
these types of applications are commonly called, by using Asynchronous Javascript
and XML (AJAX). [61] AJAX-based web applications can retrieve Web resources
asynchronously without needing to reload any pages, freeing up the user interface
for other things and improving performance. AJAX incorporates a group of technologies,
which include but are not limited to:
– Extensible Hypertext Markup Language (XHTML),
– Cascading Stylesheets (CSS),
– the Document Object Model (DOM),
– Extensible Markup Language (XML),
– Extensible Stylesheet Language Transformations (XSLT),
– XMLHttpRequest and
– Javascript. [59]
Originally, as the name suggests, the de facto client-side programming language
of AJAX was Javascript and the data encoding format was XML. Despite the naming
convention, programming languages other than Javascript and data encodings
besides XML are used in AJAX applications. In addition, applications do not need
to strictly adhere to the asynchrony to be considered rich web applications. [47, 76]
2.3 Context and Context-aware Systems
Unlike machines, human beings are fairly adept at comprehending implicitly conveyed
information. [21] For example, a person could implicitly assume that if someone
is standing still at a bus stop that the person is waiting for a bus to arrive at
which time they would get on the bus. The ability to translate this kind of tacit
information or context into a machine-accessible format and to further automate
the collection, storage and retrieval of said information has recently become highly
researched. [75]
4

One of the more frequently sited definitions of context, as it pertains to contextawareness
in applications and computing, is the one provided by Dey [21]. Dey
describes context as information that can be used to characterize the situation of an
entity. An entity is further defined as a person, place, or object that is considered
relevant to the interaction between a user and an application, including the user
and the applications themselves. The same author has also outlined a contextaware
system by stating that 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. [21]
In a newly published survey conducted by Truong and Dustdar [75] the scope
of context-aware systems is refined by stating that the system should be otherwise
operable, but the inclusion of contextual information allows the system to operate
better or more appropriately. Additionally, context-awareness enables the system to
give improved responses to its use. These characteristics emphasize the existence of
both functional and non-functional requirements in a modern context-aware system.
[75]
Context-aware systems in that past have largely been either tightly coupled
comprehensive software packages, middleware software geared toward application
integration or framework platforms created for a specific programming language or
type of device. [75] One example of the latter is the ContextPhone software platform
[68], which is a set of open source C++ libraries that run on mobile phones using
the Symbian OS and Nokia S60 platform. Another similarly focused framework is
the Java Context Awareness Framework (JCAF) [6], which has a rigid Java-based
architecture, programming model and infrastructure. Context-aware middleware
has been a popular research topic due to the looser coupling of software components
it provides. [19] It also enables the integration of various external services and
applications, which decreases development time, workload and burden on developers.
[46]
2.4 Context-aware Mobile Applications
During the last decade, mobile phones have become a ubiquitous and natural extension
of personal computing. Faster processors, larger memory, longer-life batteries
and newly emerging input, output and networking technologies help to close the gap
between various mobile devices. [45] These capabilities combined with the ubiquitousness
and proximity of mobile phones and the dynamic nature of users’ lives
has created a need for situation-dependent and context-aware mobile applications.
[11, 44, 62]
The emergence and deployment of Web 2.0 and applications harnessing its advantages
have also contributed to the growing interest in context-aware mobile applications.
[11, 44, 45] Web 2.0 is a concept that consists of wielding the web as
a platform based on user co-development and data creation in which applications
are services as opposed to products. The concept also emphasizes lightweight programming
models in addition to device and platform independence. [44, 59] The
essence of the Web 2.0 concept can be condensed into services that get better the
5

more people use them. [44, 60]
Recently, however, the founder of the term elaborated the definition by stating,
“Web 2.0 is all about harnessing collective intelligence.” He also recognized that
collective intelligence applications rely on real-time understanding, management of
and response to user-generated data. This data is no longer generated exclusively
by manual keyboard input but, as is increasingly often the case, automatically via
hardware and software sensors. [60]
2.5 Mobile Positioning Technologies
Currently, there are various technologies available to calculate the location of mobile
devices. The most prevalent positioning technology is satellite positioning using the
Global Positioning System (GPS) or Assisted GPS (A-GPS). [12, 77] GPS relies on a
system of satellites orbiting the Earth to calculate the position of a mobile device on
the Earth’s surface. Each GPS satellite transmits a low-power, ultra-high-frequency
radio signal which a GPS-enabled device receives and translates into coordinates.
A-GPS decreases the burden of calculating a mobile device’s coordinates by utilizing
the location of cellular base stations to speed up GPS signal acquisition. [12]
Due to the structure of mobile phone networks, a mobile network operator is
constantly aware of or could easily find out the location of a particular mobile phone.
A mobile phone is connected to one or more cell towers when it is operational and as
the locations of these static cell towers are known, the network operator can deduce
the relative location of each mobile phone based on which towers it is connected to.
[12] The various network enabled location technologies include the aforementioned
Cell-ID and Wi-Fi triangulation techniques. [12, 77] Wi-Fi triangulation, which
uses radio waves for high-speed data transfer over short distances [26], exploits
the distance of a mobile device from Wi-Fi access points to calculate the device’s
coordinates.
6
Figure 1: Google Maps, Yahoo! Maps and OpenStreetMap, respectively, are existing web mapping
services. Google and Yahoo represent the commercial sector and OpenStreetMap is an open
source option. These images are screenshots taken from a mobile phone.

2.6 Mapping Services
Geo-mashups, which are applications that combine mapping services with data from
external sources [11, 16], provide a simple, easy and effective way to illustrate and
convey geographically pertinent information. Not surprisingly, the web application
that heralded the consumer web mashup market was one that combined housing
listings with mapping services [67] to provide an interactive map with georeferenced
markers indicating the location of each apartment. [16, 23]
There are currently several freely available consumer mapping services to choose
from, such as Google Maps [34] and Yahoo! Maps [87]. A popular open source
alternative is the OpenStreetMap mapping service combined with OpenLayers user
interface software [57, 58]. These existing mapping services, see Figure 1 for mobile
screenshots of each, provide users with quick and easy access to maps and mapping
interfaces through public web APIs.
2.7 Sample Implementations
This section reviews existing web applications, that embody and utilize the theoretical
topics discussed in the previous section. The examples include a real-world
web application and two research-oriented mobile web applications. At the time
this thesis was written, the applications mentioned in this section exemplify the
state-of-the-art in context-aware and mobile web applications.
2.7.1 Mozilla Open Web Applications
Mozilla Labs has recently released an architecture for what they call Open Web Applications.
[51] Their applications harness standard web technologies and can run
in any modern web browser on either desktop or mobile platforms. The majority of
the Open Web App’s features are enabled by HTML5, which is the latest version of
the core language of the World Wide Web. [81] Web browser provided local storage,
offline access to applications and data, geolocation services and rich graphics capabilities
are just a few of the new properties specified in HTML5 that are employed
in Mozilla’s Open Web Applications. [51]
Open Web Applications augment the features provided by HTML5 with easy
launching, explicit installation flow and proof of purchase authentication. To use
an Open Web Application a user has only to browse an online application store or
directory, select one to install, provide possible payment information and launch the
installed application from a dashboard that holds all his or her applications. An
application dashboard (Figure 2) is an HTML5 enabled rich user interface through
which a user manages, browses and launches his or her installed applications. In
addition to the dashboard, several other components are used in conjunction with
Open Web Applications. Each application must have an application manifest, which
describes the location, requirements and capabilities of that application. A clientside
application repository contains a trusted collection of the manifests from each
of the user’s installed applications. Finally, each Open Web Application needs to
publish a method to install that application into a user’s repository. [51]
7

8
Figure 2: The Mozilla Open Web Application Dashboard provides an interface for users to
manage, browse and launch their installed applications. [51]
Although there are currently no existing context-aware Open Web Applications,
the HTML5 specification [81] combined with the W3C Permissions for Device API
Access working draft [78] provide a suitable basis for such future work and will
undoubtedly facilitate their appearance. [50]
2.7.2 Lively for Qt
Lively for Qt is a Javascript-based application platform for both web-based and
standalone mobile web applications and mashups. [49] A web mashup is a web
application that is created by combining content, presentation or functionality from
existing web sources. Mashups serve a specific and sometimes brief need and they
are usually composed of the latest and most accessible web technologies. [89]
As the name suggests, Lively for Qt runs on top of the cross-platform application
framework Qt. Qt is a mature and well-documented framework that supports a rich
set of APIs, widgets and tools that permit the creation and multi-system deployment
of rich web-enabled applications. Lively for Qt consists of three major components:
a Javascript engine built around the QtScript module, desktop quality graphics
implemented with Qt’s GUI modules, and asynchronous HTTP networking using
the QtNetwork module. [53]
Mikkonen et al. have built a number of web application mashups using the Lively
for Qt platform. Two mashups that utilize the Google Maps API are QtWeather-
Cameras (Figure 3) and QtMapNews (Figure 4). QtWeather Cameras superimposes
live road weather camera information and images over a Google Maps route to supply
the user with real-time road condition data. QtMapNews displays geotagged
news items, natural disasters and national incidents and emergencies compiled from
RSS feeds. An example of a non-map-based application is QtFlickr, an animated
Flickr photo viewer that represents current Twitter trends. The idea behind Qt-
Flickr is to provide a non-textual medium to relate current events and microblog
topics. [49]

9
Figure 3: QtWeatherCameras is a mashup web application built with the Lively for Qt Javascriptbased
platform. The mashup combines Google Maps’ route guide with real-time road condition
data and images. [65]
Figure 4: QtMapNews is a mashup web application built with the Lively for Qt Javascript-based
platform. The mashup combines Google Maps with geotagged RSS news feeds from various sources.
[64]
2.7.3 xFace
xFace is a web application engine developed specifically with lightweight crossplatform
characteristics. It provides programmers with a web runtime environment
that runs on multiple mobile devices and operating systems. xFace also serves as a
lean mobile web browser or mobile desktop environment. The platform emphasizes
the use of open standards and consequently mainly applies W3C approved standards
such as HTML, CSS, AJAX and DOM. xFace is made even lighter by its edited tag
library containing merely 27 tags and its compact code, which takes up only 8MB
on a mobile phone memory card. [43]
xFace enables context-aware applications via a Phone Services API, which provides
access to mobile phone services through Javascript functions and parameters.
The Phone Services API allows web applications to e.g. initiate phone calls, access
contact and calendar information and control multimedia capabilities such as the
camera. [43]
The xFace development team offer three use case scenarios for the platform:
Restaurant Searching, Mobile Stock Client and Mobile Reader, of which only the

former exhibits context awareness. Restaurant Searching (Figure 5) utilizes GPS
information from the user’s mobile device to locate restaurants near the user’s location.
The user may then choose to reserve a table at one of the recommended
restaurants by allowing the application to access the mobile device’s Telephony API.
The Mobile Stock Client and Mobile Reader demonstrate the media capabilities of
the xFace platform by drawing graphics and playing streaming audio online. [43]
10
Figure 5: Restaurant Searching is a prototype application created with the lightweight crossbrowser
web application platform xFace. [43]

3 Requirements for a Web-based Mobile Service
Platform
The design of the m.HUBI Platform begins by defining the functional and nonfunctional
requirements for a mobile web application platform. The specifications
support consequent structural and implementation decisions regarding technology
frameworks, architecture configurations and interface layouts. This section first
outlines the functional requirements of a mobile web application platform, then the
non-functional requirements followed by several service-specific requirements. All of
the requirements explicated in this chapter are labeled for ease of reference.
The functional requirements listed in section 3.1 are specifications for operational
platform characteristics and qualities which are necessary for the usage and
deployment of platform-supported applications. Functional requirements relate to
concerns regarding the literal functionality of software whereas non-functional requirements
are defined as attributes of or constraints on a software system. [15] The
final service-specific requirements in section 3.3 outline several platform applicationspecific
functional requirements, which are more localized requirements than the
platform-wide functional requirements listed in section 3.1. The requirements listed
in this section are determined in part by best practices gathered from literature and
in part by HUBI.mobi Project Management.
3.1 Functional Requirements
The functional requirements specified for a web-based mobile application platform
are listed in Table 1. The requirements itemized in this section were dictated by
the initial platform characteristics specified by the HUBI.mobi Project Management.
The project goals maintained that the mobile application platform needed to
be situation-sensitive, personalized, and able to ingest data from external sources.
The subsequent functional requirements specified for such an application platform
were R1: Location-awareness, R2: Context-awareness, R3: Data Input Interfaces, R4:
Map,R5: User Profile and R6: User Activity Tracking.
R1: Location-awareness
Owing to the non-stationary nature of mobile devices, location of a mobile phone
user can change frequently and is a potentially valuable information source. [38]
Location information can be utilized to show a user his or her location in relation
to the world, as a data source for location-based services such as routing or to find
and indicate relevant or interesting places or things in the user’s vicinity.
Being location-aware is one of the main advantages modern mobile devices have
over desktop and laptop Internet devices. Although coordinates are informative to
a geolocation computer system, they are quite vague to people. In order to translate
geocoordinates into a human-readable form, a street address for example, a process
called reverse geocoding is required. Reverse geocoding transforms a latitude and
longitude coordinate pair into the corresponding street address and city [18].
11

12
Table 1: The functional requirements defined for a web-based mobile service platform are R1:
Location-awareness, R2: Context-awareness, R3: Data Input Interfaces, R4: Map,R5: User Profile
and R6: User Activity Tracking.
No. Requirement Description
Functional Requirements
R1 Location-awareness Ability to ascertain a mobile device’s location in geographic
latitude–longitude coordinate pairs via positioning technologies.
R2 Context-awareness Ability to automatically collect, interpret and utilize situationsensitive
information regarding a usage scenario.
R3 Data Input Interfaces Provision of standards-based mechanisms and uniform access
points to support the ingestion of data from external sources.
R4 Map Ability to provide users with visual information regarding one’s
location and show the locations of other persons or places of
interest.
R5 User Profile Platform supports the creation, preservation and retrieval of individual
user accounts and personal account information. Used
to provide users with subjective service content.
R6 User Activity Tracking Ability to collect and analyze user behavior and actions while
using platform services.
R2: Context-awareness
Gartner [31] stipulates that in the coming years users will increasingly presume that
their information and experiences will follow them around, which mobile technologies
will provide the baseline for. This type of situation-sensitive and unique behavior
is called context-awareness (see section 2.3) and it is especially useful in mobile
scenarios. The organic evolution from mobile applications to context-aware mobile
applications has a basis in the needs and habits a user exhibits while acting in the
mobile environment. [4] For example, mobile phones are almost always switched
on, they follow the user closely throughout the day in multiple situations and at
different times and they are often personalized by their owners in ways that give
insight into the personality of the user. [68]
The inclusion of context-sensitive data into an application provides the user
with added value and an more intuitive user experience. The automatic capture
and application of contextual information eases the burden on users to manually
input information regarding their use case. [44] For instance, a mobile phone user’s
availability status is useful information and, coincidentally, relatively easy to automatically
acquire using the mobile phone’s built-in calendar, assuming that the user
has input his or her appointments. Conversely, this information could be difficult
or at least intrusive to acquire manually from the user.
Contextual information can be used, for example, to provide users with unaided
suggestions and guided interactions. [31] Unaided suggestions rely on previously
gained insight into a user’s preferences and habits based on explicitly given personal
information and implicitly derived personal interests and affinities. Guided interactions
are based more on situational information and probabilities than personalized

data. [30] An example of a guided interaction could be, for instance, when a user
is reading a description of an ongoing event the application might ask the user if
he or she would like routing information to that event or when a user is scrolling
financial news headlines during work hours the news application might provide only
business-related news and filter out entertainment and recreational news headlines.
R3: Data Input Interfaces
The nature of the m.HUBI Platform is to integrate various external data providers’
information in a manner similar to how a mashup service operates. A web mashup is
a web service that integrates existing web applications, websites and web accessible
data sources into a new web service or website. [48] The most effective way to
assimilate data in this way is to provide data input interfaces in the form of a web
API. Data input interfaces are critical to allow external data sources and providers
a uniform access point through which they can upload their data to the platform or
through which the platform can access external data sources. [11]
The implemented interfaces should support at least one standard web data exchange
format, such as XML, JSON, or Really Simple Syndication (RSS) as well as
one or more data exchange protocols such as HTTP and FTP. [11, 86] The supported
data formats should be standardized or at least widely accepted, lightweight and
preferably XML-based. Utilizing standards-based technologies ensures a reasonable
technology life span and thus a more resilient interface. Supporting lightweight data
formats and exchange protocols minimizes the processing load on the platform and
facilitates a lean data structure. The predilection for XML-based formats stems from
the nature of the web and XML’s design goals that reflect simplicity, non-specificity
and web usability [79].
R4: Map
An interactive map is essential in providing the user with visual information regarding
one’s location and showing the locations of other persons or places of interest
(see section 2.6). It is also required in a number of platform services, including the
Journey Planner (see R11: Journey Planner on page 18). Furthermore, as locational
information lays the foundation for the m.HUBI Platform’s context-aware features
(see section R2: Context-awareness) it is necessary to facilitate the visualization
and presentation of this context to the user, for which the logical medium is a map.
R5: User Profile
In addition to anonymous usage without account login, the m.HUBI Platform should
also allow the creation, preservation and retrieval of individual user accounts and
personal account information. A user profile facilitates features and services such
as Bookmarks and Recommendations (see R13: Recommender on page 20). Bookmarks
are places, events, persons, games, etc. that are frequently used or accessed in
m.HUBI Platform supported services. A user’s bookmarks are stored in a database,
13

from which they are retrieved when a user accesses his or her account. Recommendations
are unique and personalized suggestions or data and service filtering
performed to provide a user with subjective service content.
User profile information includes demographic data gained from explicit user input
such as a user’s e-mail address, interests, service settings, etc. as well as implicitly
gained insight into a user’s preferences based on service usage habits (see R6:
User Activity Tracking on page 14) and attention distribution. The information
contained in a user profile combined with locational and contextual data gathered
enable the provision of personalized and situation-specific services. [24] Although
user profiles often enrich, focus and personalize user experience, users can also be
wary of registration unless they are convinced it provides substantial added value
and the collection and use of their personal information is justified and protected.
[28] Offering anonymous access, partial or unlimited, to a website or service can
justify the need for user registration and ensures that users that make the effort to
create an account are committed users. [29]
R6: User Activity Tracking
User activity tracking is the collection and analysis of user behavior and actions on
websites or single web pages. User activity tracking enables the personalization of
the corresponding websites or web pages by adapting its content or services to the
needs of a particular user or type of user. [24] The type of information gathered
includes usage data such as a visitor’s IP address, the time and date of access,
pages and services accessed and the referrer’s URL address. Usage data is the type
of information normally automatically included in a web server’s access log and
subsequently rarely requires extensive development.
User activity tracking data can be applied to various uses such as user profiling,
website usage statistics for marketing or business purposes, usability testing and
website content adaptation. User profiling is the process of applying the gathered
information to create categories of individual or groups of users that share similar
characteristics, behaviors or interests. Usage statistics are strong analytical tools
for supporting marketing or business decisions as they contain objective information
regarding customer needs and habits. Usability testing can greatly benefit from realworld
usage statistics, because they are unobtrusive to collect and can be integrated
at a very early stage in the development cycle. Website content adaptation is the
dynamic modification of a website’s content based on the changing demands and
needs of the user. [5]
The m.HUBI Platform would employ user activity tracking mainly for usage
statistics analysis and user profiling combined with content adaptation in the form of
the Recommendation service (see R13: Recommender on page 20). From a technical
standpoint, the m.HUBI Platform should facilitate the tracking of almost any user
activity including time-sensitive user location information. However, due to privacy
issues, the collection of any personally identifiable information including locationand
time-specific data would need to be anonymized to the extent that individual
users are not identifiable or their movements traceable. The m.HUBI Platform must
14

15
also comply with applicable privacy laws and data protection acts [63].
3.2 Non-Functional Requirements
The non-functional requirements specified for a web-based mobile application platform
are listed in Table 2. The requirements itemized in this section were mainly
gathered from best practices in literature. These requirements describe attributes
of the platform as opposed to the functional requirements specified in the previous
section 3.1, which describe functionalities of the platform. The subsequent
non-functional requirements specified for such an application platform were R7:
Reusability, R8: Cross-device Functionality, R9: Scalability and R10: Multilingual
Content Support.
Table 2: The non-functional requirements defined for a web-based mobile service platform are R7:
Reusability, R8: Cross-device Functionality, R9: Scalability and R10: Multilingual Content
Support.
No. Requirement Description
Non-functional Requirements
R7 Reusability Design architecture is hierarchical and consists of small modular
components. Elements are modular, loosely coupled and
lightweight.
R8 Cross-device Functionality Platform is operating system, device and platform independent
or at least provides mechanisms and processes for decreased
dependence.
R9 Scalability System has the ability to gracefully cope with a growing number
of components or increased workload and is capable of extensibility
and enlargement.
R10 Multilingual Content Support
Platform supplies tools and processes for management and implementation
of multilingual content.
R7: Reusability
The most fundamental and critical non-functional requirement of the mHUBI application
platform is reusability. In order to create a widely applicable and easily
adaptable platform that is conducive to rapid development and deployment, the
architecture should be hierarchical and consist of small modular components. The
more generic and mutually independent architectural components are the easier
they are to integrate and aggregate into other applications or architectures. [69, 88]
Additionally, the initial mHUBI Platform is more likely to evolve organically and
spontaneously when its original design and structure is not a constraint. Thus
interdependence of architectural elements would greatly hinder the probability of
widespread assimilation.
Designing functional components as modular, loosely coupled and lightweight
elements supports their reusability and facilitates the cross-platform nature of the

entire application. [73] Modularity also increases the entire system’s possibility for
extensibility in future. [14]
R8: Cross-device Functionality
Mobile web applications are generally easier and faster to develop and deploy than
native mobile applications. [32, 33, 71] Web technologies are intended and built to
be operating system, device and platform independent. The Web 2.0 tenet goes so
far as to state that the “web is a platform” [59]. This holds true to a certain extent;
web technologies (XML, HTML, CSS, etc.) are structurally identical irrespective
of the device or operating system accessing it. However, web pages still need a
medium to display them to users and when it comes to the medium of choice,
Internet browsers, they unfortunately interpret web pages differently. [71] That is
why cross-browser functionality and uniform presentation is a high priority when
designing and constructing web pages and especially web applications.
The realm of mobile web browsers has even more variation than desktop web
browsers. Currently, there are two types of mobile web browsers available for smartphones:
full browsers, also called direct delivery browsers, and mini browsers, also
called server transcoding browsers. [37, 66] Full browsers have the same functionalities
and execution as desktop web browsers. They download and render web pages
directly from a web server or local file as is. Full browsers facilitate desktop-quality
rendering, at least from a browser standpoint, but they may suffer from memory
constraints resulting from the mobile platform they run on. Mini browsers employ
an intermediate proxy server to request web pages on its behalf. The proxy server
renders and compresses the response and then sends the converted web page to the
mobile client browser. The benefit of mini browsers is their low memory requirement
and the reduced data traffic involved, however, because they do not support clientside
interactivity Javascript is effectively run on the proxy server. [66] These added
constraints of mobile web browsers further emphasize the need for cross-browser
functionality of mobile web applications.
R9: Scalability
Scalability refers to a number of system qualities and characteristics such as the
ability of a system to gracefully cope with a growing number of components or
increased workload and to be capable of extensibility and enlargement. [10] In
web-based systems, scalability and extensibility are often cited as separate system
qualities. In those instances, scalability refers to the system’s capacity to respond
to simultaneous requests and an increased processing workload. [14] Extensibility is
distinguished from scalability as supporting the evolution and change of what was
originally designed. [27] An extensible context-aware system, for instance, facilitates
the addition of new services, new context sensors and context data sources. [14]
The drawbacks of non-scalability include delays or disconnects in response time,
raised data processing demands, space or memory constraints and more expensive
development efforts. Scalability can similarly be inhibited by shortsighted data
16

structure and algorithm design. Extensibility affords the supplementation and replacement
of system requirements in correspondence with user needs. [10]
R10: Multilingual Content Support
Modern websites and web applications need to facilitate global usage and consequently,
offer content in multiple languages. Previously offering web content in
English was seen as catering to an international audience, but with the advancement
of content management systems and other facilitative technologies that is no
longer sufficient [40]. In order to maintain multilingual versions of a single website,
content and structure related issues need to be addressed. Content management
and localization are the most critical factors when dealing with multilingual web
content, but website naming and layout organization are also relevant structural
factors [40].
Management of multilingual content is especially pertinent to the m.HUBI Platform,
but localization issues should also receive due diligence. Proprietary content
and extra-platform components should also be considered future system elements
requiring multilingual support.
3.3 Service-specific Requirements
Service-specific requirements specified for a web-based mobile application platform,
which are listed in Table 3, are HUBI.mobi Project Management dictated functional
specifications for the platform. These requirements describe functionalities of specific
services to be provided by and included in the m.HUBI Platform. The first
requirement is a routing service R11: Journey Planner that offers routing, geolocation
and public transit related functionalities. The second requirement is R12:
Events, a service that offers information on upcoming and ongoing events which
have been collected from external data sources. The third and final service-specific
requirement is R13: Recommender, a service that provides personalized recommendations,
content and services.
Table 3: The service-specific requirements defined for a web-based mobile service platform
are R11: Journey Planner, R12: Events and R13: Recommender.
17
No. Requirement Description
Service-specific Requirements
R11 Journey Planner Provision public transit route options from point to point and
display of route items on a map.
R12 Events Ability to gather and display ongoing and upcoming event data
to user. Events include location information and possible semantic
tags.
R13 Recommender Provide users with personalized recommendations, content and
services based on a user’s explicit and implicit usage preferences.

The requirements defined in this section were chosen in part by research and
project goals dictated by HUBI.mobi Project Management and in part by resources
and knowledge available to the project team at the time this thesis work was completed.
Each service-specific requirement answers a real-life user need identified
by the project management team. For instance, R13: Recommender is included
to integrate concurrent textual data mining algorithm development and to provide
the platform with means to facilitate personalized content. Similarly, R12: Events
serves to provide users with personalized and situation-sensitive content that utilize
individualized recommendations provided by R13: Recommender. Numerous
other service-specific requirements could have been defined, but the ones included
in this section are indicative of the types of services that can be implemented in
platform-based applications.
R11: Journey Planner
A public transport Journey Planner is a service to be implemented as part of the
m.HUBI Platform. The Journey Planner could initially utilize the web service interface
of the Helsinki Regional Transport Authority (HSL) [39] to provide users with
public transport route information in the Helsinki Metropolitan Area. The HSL
interface supports bus, metro, tram, train, ferry and walking transport modes. The
Journey Planner can utilize the user’s current location, which is automatically collected
(see R1: Location-awareness on page 11), as the starting point or destination
for a journey. The user can also choose journey departure or destination points from
a list of bookmarked places (see R5: User Profile on page 13) saved to the user’s
profile and only available if the user has logged in.
Journey Planner
18
8:34
Current location:
Kamppi:
Kimmontie 3, Helsinki
Kampin keskus, Helsinki
Departure
Koskelantie crossing
Koskelantie crossing
Maunula
Maunula
Kamppi
Kamppi
Destination
Show route map
Figure 6: Mockups of the Journey Planner service. Left: Initial Journey Planner screen into which
the user inputs departure, destination and time information. This scenario is a journey from the
user’s current location to a manually input destination at the current time. Middle: Several route
options are displayed for a single journey. Right: Detailed route and transfer information for a
selected route.
R12: Events
A service to provide ongoing and upcoming events in the Helsinki Metropolitan
Area is included in the m.HUBI Platform specification. The service compiles event

data from various sources and lists them based on user prioritization, user profile
settings and user- and group-specific recommendations (see R13: Recommender on
page 20). Events are categorized according to event type such as theater, museum,
sports, music, etc. and optional user preferences regarding each event type are saved
to the user profile. (Figure 7)
19
Events
Starting soon
Events
Near my location
Starting soon
Ending soon
Figure 7: Mockups of the Events service. Left: Initial Events screen showing information of
currently ongoing and upcoming events near the user’s current location in the Helsinki Metropolitan
Area. Middle: Users can sort events based on the event’s location, start time and end time. Right:
Users can save event category related preferences, which are also used to sort events when a user
is logged in.
As mentioned above, Event service data is compiled from various external sources,
which requires an interface for the input of event data. In addition to the generic
data formats described in section R3: Data Input Interfaces, several data models and
formats are available that focus solely on event-related data description. Shaw et al.
[72] conducted a survey of existing event models and compared their event representations.
Of the event models Shaw et al. describe, EventsML-G2 best serves the
purposes of the m.HUBI Platform’s needs. Various qualities encourage the adoption
of the EventsML-G2 standard including its machine-readable XML-based format,
its compliance with the W3Cs Resource Description Framework (RDF) which supports
event-specific semantic annotation and the standard’s extensible nature which
facilitates appending application-specific functionalities. [41]
Pertinent event-related information to be included in event source data include:
– title of event,
– organizer of event,
– start time of event,
– end time of event,
– textual description of event,
– language(s) of event and/or of textual description of event,
– location of event expressed as:
– name of event location,
– address of event location or
– geocoordinates of event location,

20
– link to external information e.g. event website,
– keywords of event and
– semantic mapping of event to an ontology.
R13: Recommender
A Recommender service is required in the m.HUBI Platform to provide users with
personalized recommendations, content and services. The service will, at minimum,
provide user-specific event listings in the Event service (see R12: Events on page 18)
based on a user’s explicit and implicit usage preferences. Explicit user preferences
are gained through user-solicited profile information and implicit user preferences
are acquired with the help of user activity tracking (see R6: User Activity Tracking
on page 14).
Recommendation systems generally fall under one of three categories. Contentbased
recommenders suggest items similar to ones that a user has previously preferred.
Collaborative recommenders rely on the behavior of user groups and suggest
items that other users with similar preferences have liked. The third type of recommendation
system is one that combines content-based and collaborative recommendation
methods. [1]
Disadvantages of purely content-based recommendation systems include limited
content analysis and overspecialization. Limited content analysis is a result of restricted
information regarding users and/or item content. The restrictions may
relate to privacy issues limiting personal information dissemination and item content
may be difficult or expensive to obtain or item quality may be problematic to
machine-detect. Overspecialization follows from the nature of content-based recommendation
systems. Because the system recommends items with similar content,
there is a risk of it failing to recommend items with dissimilar content but which
are still of interest to the user. [20]
Collaborative recommendation systems do not suffer from the same disadvantages
as content-based recommendation systems because they rely on inter-user
similarity rather than inter-item similarity. However, collaborative recommendations
are not without their own limitations. They must tackle new items, rating
sparsity and new users, the latter of which also plagues content-based recommendation
systems. New items pose a problem because they need to be rated by a
sufficient number of users before they can be recommended to other users. Rating
sparsity refers to the critical mass of users per item. In a realistic recommender
system, items with few ratings will rarely be recommended unless there exist other
users with nearly identical preferences. Both collaborative and content-based recommendation
methods have a problem determining the preferences of a new user
because that user has yet to rate any items. Usually explicit user input is needed
to provide a basis for user recommendations prior to uncovering more insights. [1]

21
4 Architecture of the m.HUBI Platform
This section describes the architecture of the m.HUBI Platform. It begins with an
overview of the entire platform and moves on to give more detailed introductions
of server-side components and then client-side elements, respectively. The final
subsection is a use-case scenario starring a fictitious platform-based web application,
which illustrates the usage of the platform architecture and its components from a
more practical perspective. The server-side architecture depicted in this section is
implementation-independent, meaning it makes no assumptions or stipulations on
what technologies are used to implement the platform itself. However, use of the
optional content structure templates described in section 4.5 require the platform
server to run Java programs and support Java Server Pages technology.
4.1 Architecture Overview
The m.HUBI Platform is a web server and web application client framework. The
Platform provides the foundation, structure and means for building, maintaining
and developing context-aware user-specific mobile web applications. The m.HUBI
Platform Server consists of an application server (see section 2.1), one or more
databases, a Recommender Service and several auxiliary components. The m.HUBI
Platform Client embodies a Javascript API as well as content structure and layout
templates.
As the diagram in Figure 8 indicates, the m.HUBI Platform Server has several
subcomponents. Arguably the more important of these components are the
databases and the complementary Database Management module. The databases
store data which is processed, derived from or utilized in m.HUBI Platform Client
applications. Database data ranges from basic user information such as usernames,
email addresses and service profiles to event data provided by or gathered from external
data sources (see section 3.1). The Database Management module ensures
the accessibility, validity and continuity of all data kept in the databases.
A mandatory element to any service that provides registration and user login
is an Identity and Authorization Management module. This module is responsible
for ensuring secure access, transaction consistency and isolation of individual
entries of a database containing username and password information. The Recommender
Service deployed as part of the m.HUBI Platform Server utilizes user
proclivity to produce personally valid content (see section 3.3). The Recommender
harnesses both straightforward input gathered from the users themselves and tacit
user preferences gained from monitoring user behavior and tracking user activity
(see section 3.1). Support functions are used by internal Platform server processes
to perform administrative tasks and maintain log files, for example. These functions
run in the background and are not visible or accessible to platform clients.
Figure 8 contains two external components that are not internal elements of the
m.HUBI Platform, but are essential to its operation. The first such component
represents external web services that the platform queries for information, such
as map images from a mapping service and route options from a public transit

22
Javascript API
m.HUBI PLATFORM
CLIENT-SIDE
PROPRIETARY CLIENT
WEB APPLICATION CLIENT
HTTP
GET / POST
request
HTTP
GET / POST
response
(XML data format)
EXTERNAL
WEB SERVICES
Server
HTTP
GET / POST
(XML
data format)
EXTERNAL
DATA SOURCES
Databases
Figure 8: The m.HUBI Platform is a web application framework complete with server-side and
client-side components. The platform queries external web services for application content such as
map images and other mashup components and receives or retrieves XML formatted data, such as
Events, from external sources. Data is passed between the the server and client sides and between
the server and external services and sources via HTTP GET and POST requests and responses.
The Platform Client is supplemented with proprietary content, layout and Javascript to create
various mobile web applications.
API. The second external component in the figure represents external data sources
which provide source information regarding events or other data utilized by platform
applications. The data received or retrieved from the external source, depending
on whether the data input is initiated by the external source or by the m.HUBI
Platform, respectively, is saved to the platform database.
The m.HUBI Platform Client contains the front-end portion of the mobile web
application. It constitutes the user interface of the service and is displayed to
the end-user via a web browser, more specifically a mobile web browser. The

Javascript API contains documented and preprogrammed Javascript functions that
support and implement application activity, interaction and communication with
the m.HUBI Platform Server. The Platform Client also includes templates for the
application client’s structure and layout, but these are optional and their inclusion in
a final web application is completely voluntary. The templates are primarily meant
as a starting point for new application design and provide cohesive layouts for any
m.HUBI Platform implementations.
4.2 Server Core Functions
The m.HUBI Platform Server’s Core functions consist of the Database Management
module, the Identity and Authorization Management module, the Recommender
Service and various inconspicuous support functions. The first two modules are
comprehensive monitoring and maintenance tools, which are critical to any web
application that handles database or user account transactions. The Recommender
Service facilitates the provision of intuitive and situationally relevant web services
to mobile users. Lastly, support functions play the indispensable role of workhorse
ensuring basic server operation and maintenance.
4.2.1 Database Management
The Database Management module is charged with monitoring and controlling access
to the servers database(s), ensuring that any and all transactions are processed
reliably and securely and multiple simultaneous transactions are effectively queued.
A database transaction is a short sequence of database interactions which represent
one meaningful activity in the user’s environment. The transaction processing module
takes care that all transactions are executed indivisibly, meaning that either all
of the actions are completed successfully or none of them are. [36] Persistence maintenance
is particularly important in web applications because the applications allow
data to be created, transferred and stored in different types of software components
such as Internet browsers, relational databases and web servers. This architecture
complicates the flow of data through the various pieces of software and emphasizes
the need for persistent data. Data persistence refers to having the same data available
in the same form throughout and between user sessions. [56] In simplified terms,
the Persistence module enables session data to outlive the session it was created in
and facilitates the reinstatement of that data when the session is ‘resumed’.
4.2.2 Identity and Authorization Management
The Identity and Authorization Management module is responsible for ensuring secure
access, transaction consistency and isolation of individual entries of a database
containing username and password information. Additionally, the Identity and Authorization
Management module encrypts the passwords before they are stored to
the database so that they are not saved in plain text format. This ensures an further
layer of protection in user registration because even if the encrypted passwords were
to fall into the wrong hands, they would be essentially useless. The Identity and
23

Authorization Management module can also be tasked with providing secure connections
between the web application client and server. Such connections are Secure
Sockets Layer (SSL) connections, for instance, that use bilateral keys to encrypt and
decrypt transmitted messages. SSL transactions are illegible to anyone other than
its participants unless a third party attains both parties’ keys. [82]
4.2.3 Recommender Service
The Recommender Service (see section 3.3) disseminates user-specific and contextsensitive
content to m.HUBI Platform Clients. Each registered platform user has
an individual user interest profile associated with their account that is built and
refined each time the user interacts with a platform service. The Recommender
operates by gathering service content, e.g. event data from external sources, from
the corresponding database. The externally sourced data may contain semantically
relevant category tags indicating what topic group it belongs to e.g. sports, theater,
music or the grouping is programmatically deduced from the data’s description
text. The Recommender Service uses a novel keyword extraction algorithm that was
developed as part of the HUBI.mobi Project along side the m.HUBI Platform. The
algorithm specializes in extracting keywords and phrases from short text documents,
such as event descriptions or user created content. The extraction approach is based
on three-level word analysis and clustering and aims to provide informative terms
for data categorization and user modeling. The Recommender Service checks the
user’s profile for their content preferences and sorts the list in descending order of
preference.
4.2.4 Support Functions
The Support functions component is the grease that makes the gears of the m.HUBI
Platform turn smoothly. It is responsible for managing and maintaining auxiliary
processes of the platform. The elements of the support functions module manage
session cookie generation and validation, external web service connection initiation,
preservation and suspension, and log file creation, population and maintenance.
Platform web application client cookies and external web service connections are
processed on behalf of service components (see section 4.3). Log files keep a record
of all the actions performed in the server and provide written documentation in the
event of an error or undesired action.
4.3 m.HUBI Platform Service Components
The m.HUBI Platform Server employs service components to provide m.HUBI Platform
Clients with dynamic content and programmatic processing for database query
responses. The Platform services are divided into thirteen separate components:
Login, Logout, Location, Map, MyPlaces, POI, Track, Localization, Bookmark,
Friends, User Management, Journey Planner and Feedback. The following sections
describe each aforementioned component in greater detail. Unless otherwise indi-
24

cated, the input and output of the service components are HTTP GET request and
response messages, respectively.
Login
The m.HUBI Platform Login service component grants m.HUBI Platform users access
to their user account and corresponding profile data. The component receives
data in the form of a HTTP POST request (Figure 9). The input request is checked
for a textual username and password, which a user has input into the m.HUBI Platform
Client browser. The Login component then checks the registered user database
for a corresponding username and password. If such a user exists and that user’s
account has the password provided in the request message, the service component
indicates the user is online and creates a timestamped user-specific cookie, which
is subsequently used to automatically identify the user for the cookie’s period of
validity—the default duration is 12 hours. The Login component then creates an
XML document containing the login cookie and returns the document as an HTTP
POST response to the requesting client application.
25
m.HUBI PLATFORM
SERVER-SIDE
HTTP GET request
Figure 9: The m.HUBI Platform Server includes Service components such as the Login and
Logout components. Both components receive HTTP requests from platform client applications
and communicate with the server’s registered user database to complete user authorization. A web
cookie is returned to the requesting application when necessary processing is complete.
Logout
The m.HUBI Platform Logout service component changes the status of a registered
platform user to offline in the client application he or she is currently logged into.
The Logout component receives a request containing a platform issued cookie, which

corresponds to a single registered user (Figure 9). The component checks and validates
the contents of that cookie and logs the matching user out of the requesting
m.HUBI Platform Client. Finally, the service component creates an empty cookie,
appends it to the response message and returns the it to the requesting m.HUBI
Platform Client application.
Location
The m.HUBI Platform Location service component saves and retrieves database
data disclosing the location of registered platform users. Additionally, the component
delivers street addresses by reverse geocoding them (see section 3.1) from
satellite coordinates. The component receives a request message containing a platform
issued cookie and the requesting user’s location as latitude and longitude coordinates
(Figure 10). First, the component checks and validates the contents of
the request cookie. Then, it saves the user’s current location to the user database.
Lastly, the service component completes reverse geocoding on the user’s location
coordinates and returns the result as an HTML document. The reverse geocoding is
actually outsourced to an external web service, so in effect, the service component
calls that external service with the input GPS coordinates and receives a response
indicating the corresponding street address. The HTML document is returned to
the requesting platform client application as a response.
26
m.HUBI PLATFORM
SERVER-SIDE
Figure 10: The m.HUBI Platform Server includes Service components such as the Location and
Map components. Both components receive request messages from platform client applications and
communicate with external web services to complete their tasks. The Location component returns
a reverse geocoded street address and the Map service returns a map image to the requesting
applications.

27
Map
The Map service component creates and supplies map images to display on m.HUBI
Platform Clients. The component receives a request (Figure 10) containing various
input parameters including user location and map center coordinates, desired image
size and type of map e.g. Journey Planner route map (see section 3.3) or POI map
(see section 3.3). First, the Map component uses the input coordinate parameters
to calculate the needed image tiles and retrieves them from an external mapping
service (see section 3.1). To decrease the time required for image retrieval from
external services, the m.HUBI Platform also employs an image cache where it stores
frequently used map tiles. Next, depending on the map type indicated in the input
parameters, the component will draw on top of the map image. For instance, in
the case of a POI map, the service component will draw an icon for the POI in its
corresponding coordinates. Finally, the Map component returns the resulting map
image to the requesting platform client as a response message.
MyPlaces
The MyPlaces service component handles requests pertaining to user-specific and
user-created locations and POIs. POIs saved as MyPlaces indicate frequently visited
or important places to the user such as Home, Work, Mom and Dad’s, etc. The
component receives a request containing a m.HUBI Platform issued cookie and various
input parameters depending on what kind of action is desired (Figure 11). The
MyPlaces service component executes addition, update, deletion, moving and listing
of user-created POIs. MyPlaces POIs are stored, visible and usable only to a single
registered user via that user’s platform account. A request asking the component for
a listing of a user’s POIs returns an XML document containing that information as a
HTTP GET response. Other requests contain input parameters indicating a POI to
add, delete, update or move upward or downward in the POI listing. The MyPlaces
component completes the requested action and returns a response message with a
textual indication of the success or failure of that action.
POI
The POI service component executes requests regarding location annotated data
such as event happenings that have been integrated into the m.HUBI Platform from
external data sources (see section 3.3). The component receives a request message
(Figure 11) containing parameters indicating what kind of POI data is required,
how that data should be sorted and whether or not the action should be tracked
(see section 3.1). If the request also contains a platform issued login cookie, the POI
component checks the validity of that cookie and utilizes user profile information to
supply focused listings (see section 3.3). The POI service component communicates
with the user and external input databases as well as the Recommender Service to
compile a return POI list. The list compilation is gathered as an XML document
and returned to the message originating m.HUBI Platform Client application as a
response.

28
m.HUBI PLATFORM
SERVER-SIDE
Figure 11: The m.HUBI Platform Server includes Service components such as the MyPlaces and
POI service components. Both components receive HTTP requests from platform client applications
and communicate with other server components to complete their tasks. The MyPlaces
component contacts an external web service for geocoding assistance as well as the MyPlaces
database to append, update or retrieve POIs. The POI component communicates with the user,
user profile and POI databases as well as the Recommender Service. The MyPlaces service component
returns either a success or failure indicator or an XML document, depending on the input
parameters. The POI service component always returns an XML document.
Track
The Track service component handles the logging of usage tracking and communicates
with the Recommender Service regarding those actions (see section 3.1). The
component receives a request containing a platform issued login cookie and parameters
indicating what action is being tracked (Figure 12). Tracking service usage is
used to compile platform usage statistics and improve personal user recommendations
and user experience in general. For example, each time a user views a list item
in a client application’s service, that viewing triggers a tracking event which in turn
triggers modifications in the lists provided to a particular user by the Recommender
Service. The Track service component returns a response indicating if the requested
tracking action was successfully carried out.
Localization
The Localization service component serves language-specific text and content to
client applications if multilingual options are available. Different language options
are handled in the platform by a separate language cookie, which has a validity
period just as the login cookie does. Various services that offer multilingual content
use the language cookie to determine what content to provide. The Localization
component receives a request containing a platform issued language cookie (Fig-

29
m.HUBI PLATFORM
SERVER-SIDE
Figure 12: The m.HUBI Platform Server includes Service components such as the Track and Localization
service components. Both components receive requests from platform client applications
and communicate with other server components to complete their tasks. The Track component
returns a success or failure indicator regarding the status of the task it was asked to perform. The
Localization service component returns a platform issued language cookie as a response message.
ure 12). If the request also contains parameters indicating the client that issued
the request wishes to change the language settings, the component checks the existence
and validity of the input language cookie and saves the language setting to
that user’s profile. The Localization service component then appends the indicated
language as a parameter of the language cookie and returns the amended cookie as
a response to the m.HUBI Platform Client application it emanated from.
Bookmark
The Bookmark service component handles user bookmark related tasks. Bookmarks
on the m.HUBI Platform are similar to web bookmarks, in that a user can bookmark
a personally significant event, POI, place, etc. and save that item to their platform
profile. The Bookmarks are stored in a database and associated with the user
account that created them. The Bookmark component receives a request (Figure 13)
containing a platform issued cookie and input parameters indicating whether the
user wants to add or delete a single bookmark or alternatively list all the user’s stored
bookmarks. The service component communicates with the platform user database
to execute the requested task and returns a response to the m.HUBI Platform Client
application the original request emanated from. Addition and deletion of bookmarks
results in a simple success or failure response and a bookmark list request results in
an XML document containing a list of the requesting user’s stored bookmarks.

30
m.HUBI PLATFORM
SERVER-SIDE
Figure 13: The m.HUBI Platform Server includes Service components such as the Bookmark and
Friends service components. Both components receive requests from platform client applications
and communicate with the User and User Profile Databases to complete their tasks. The Bookmark
and Friends components each return a success or failure indicator regarding the status of the task
it was asked to perform. If the requested action was to list a user’s bookmarks or friends, the
corresponding service component returns the list as an XML document.
Friends
The Friends service component executes requests related to user friends. Similarly
to social networks such as Facebook or Twitter, registered users of m.HUBI Platform
can indicate that other registered users are their friends. The Friends component
receives a request message (Figure 13) containing a platform issued cookie and input
parameters indicating if the user wishes to add or remove a friend, decline a friend
request or simply list that user’s friends. The service component communicates
with the platform user database, which holds a record of individual user’s friends,
to execute the requested task. The result is a simple success or failure indication
in the cases of friend addition and removal and friend request refusal. When the
m.HUBI Platform Client application has requested a list of user friends, the result
is an XML document listing those friends. The Friends component returns the task
result as a response to the platform client application the original request emanated
from.
User Management
The User Management service component oversees actions concerning user accounts
and related data. Tasks the User Management component executes include saving
settings to and retrieving data from a user account as well as creating and deleting
m.HUBI Platform user accounts. The service component receives a request that,
barring the creation of a new registered user account, contains a platform issued

31
m.HUBI PLATFORM
SERVER-SIDE
Figure 14: The m.HUBI Platform Server includes Service components such as the User Management
and Journey Planner service components. Both components receive requests from platform
client applications and communicate with the User Database and External Web Service, respectively,
to complete their tasks. The User Management service component returns a success or
failure indicator or an XML document depending on the requested action. The Journey Planner
service component returns an XML document containing route information.
cookie (Figure 14). The request also contains parameters indicating what duties
the service component should perform. The User Management component communicates
with the platform user database to retrieve or save data and returns any
response data as an XML document in a response. If no data is being returned to
the requesting m.HUBI Platform Client application, the response simply indicates
the success or failure of the requested task.
Journey Planner
The Journey Planner service component handles communication between m.HUBI
Platform Client applications and the external Journey Planner service (see section
3.3), which is currently implemented by the Helsinki Regional Transit Authority
(HSL). The component receives a request message containing departure and
destination addresses and a departure or arrival time (Figure 14). The Journey
Planner component sends a message to the HSL Journey Planner web service that
contains the service component input parameters. The HSL web service produces
a response containing three complete route options from the given departure point
to the provided destination. The service component parses the HSL web service
response message into an XML document and returns it as a response to the client
application that originally made the service component request.

32
Feedback
The Feedback service component delivers user feedback to the m.HUBI Platform
administrators. The component receives user feedback in the form of a HTTP
POST request containing the input entered by the user into the client application
feedback form (Figure 15). The Feedback component checks for a platform issued
cookie and if such a valid cookie is found, indicates that the feedback is from a
registered user. The component then forwards the user input as an email to the
platform administrators and returns an empty HTTP POST response to the client
indicating whether the feedback was successfully processed.
m.HUBI PLATFORM
SERVER-SIDE
Service Components
Figure 15: The m.HUBI Platform Server includes Service components such as the Feedback and
User Management service components. The Feedback component receives HTTP POST requests
containing textual user feedback from platform client applications. The User Management component
returns a success or failure indicator indicating if the feedback was forwarded by email to
platform administrators.
4.4 Javascript API
This section presents the contents and operations of the m.HUBI Platform Javascript
API. The API consists of seven modules divided according to their functionality. The
following descriptions are not intended as a manual or user guide to web developers
utilizing the m.HUBI Platform for application creation or for other technical purposes.
This section merely introduces the functions included in the m.HUBI API
and a provides a general overview of their capabilities.

33
m.HUBI Javascript API
Figure 16: The m.HUBI Platform Client includes a Javascript API containing functions and
classes utilized in platform client applications. The API is divided into seven modules according
to function relativity. The modules are Communication, Foundation, Map, Positioning, Display,
Services and Auxiliary.
4.4.1 Communication Module
The Communication module contains functions that handle communication between
platform clients and the platform server. It is an integral part of the API and ensures
that client applications serve users with up-to-date and valid data. The module
also handles the forwarding of server responses to the correct handler or callback
functions.
The first of the two Communication module functions is xhr, which sends request
messages to the m.HUBI Platform Service Components (see section 4.3). The
function creates an XMLHttpRequest and sends it to the URL indicated in url. The
callback parameter indicates the function that will handle the processing of the
returned XMLHttpRequest. The postData parameter contains optional textual data
to send to the server if requestType is POST instead of the default GET.
The second function, parseXMLListener, is a catch-all callback function for
various xhr function server calls. ParseXMLListener interprets and converts XML
documents into Javascript Objects and forwards them to user-defined Javascript
functions for display to the user. The function receiving the forwarded Javascript
Object is determined based on the content of the XML document and type of the
subsequent Javascript Object.
parseXMLListener ( resp )
xhr ( requestType, url, callback, postData )
4.4.2 Foundation Module
The Foundation module contains functions that are generally relevant to the m.HUBI
Platform and Javascript API. The functions carry out fundamental processes such
as login and logout of registered users, saving and updating user settings to the
platform server as well as displaying and concealing pages on the web application
client. User action tracking (see section 3.1) on platform clients is facilitated in the
Foundation module. The trackAction function can be called to register the usage

of a service or viewing of an item e.g. POI, Route, etc. API functions that take a
track parameter call trackAction internally.
autoLogin()
back()
clearFeedback()
create ( key, value, expireDays )
deleteUser()
destroy ( key )
displayXML ( objArray )
getUserSettings()
hide ( elementId )
login()
loginListener ( resp )
logout()
logoutListener ( resp )
retrieve ( key )
saveProfile()
saveSettings()
sendFeedback()
setDate ( item, addHours, addMinutes )
setHeader ( title, icon )
show ( elementId, type )
showPage ( pageId, title, icon, backPg )
trackAction ( trackable )
34
Foundation Module
autoLogin *
displayXML
logoutListener
setHeader
back
getUserSettings *
retrieve
show
parseXMLListener
clearFeedback
create
hide
login *
saveProfile *
saveSettings *
showPage
trackAction *
xhr
deleteUser *
loginListener
sendFeedback *
destroy
logout *
setDate
Figure 17: The m.HUBI API Foundation module contains functions that are generally relevant to
the platform. The functions carry out fundamental processes such as login and logout of registered
users, saving and updating user settings to the platform server and displaying and concealing pages
on the web application client. Functions with an asterisk (*) after their names make a call to the
Communication module’s xhr function.

35
4.4.3 Map Module
The Map module contains functions relevant to the m.HUBI Platform Map service.
The map is used as a visual medium to show users their own location, locations
of POIs, MyPlaces or Journey Planner Routes, RouteLegs or RoutePoints (see section
4.4.6). Map module functions retrieve, display and adjust map images. The
Map module also contains the Javascript class Point, which is used to define single
map points with explicit geo- and screen coordinates. Point instances are used to
precisely indicate e.g. user, POI and Buddy positions on map images.
initializeIphoneMap()
initializeWidgetMap()
mapReset()
panMap ( direction )
panReset()
setMapImage()
setMapImageUrl ( url )
showPoisOnMap ( poiList )
showUserOnMap()
zoomIn()
zoomOut()
zoomReset()
Point(x, y) {
getLat() setLat ( lat )
getLon() setLon ( lon )
getX() setX ( x )
getY() setY ( y )
}
Map Module
initializeIphoneMap
setMapImageUrl
initializeWidgetMap
showPoisOnMap *
mapReset
panMap
showUserOnMap
zoomIn
xhr
panReset
zoomOut
setMapImage
zoomReset
Figure 18: The m.HUBI API Map module contains functions relevant to platform Map service.
Maps are used as visual media to show users the location of themselves, user friends, POIs,
MyPlaces, etc. In addition to the functions depicted in the figure, the Map module includes a
Javascript Class declaration for Point objects. Functions with an asterisk (*) after their names
make a call to the Communication module’s xhr function.

36
4.4.4 Positioning Module
The Positioning module contains functions that are relevant to positioning and geolocation
processes of the m.HUBI Platform. The functions handle acquisition and
evaluation of GPS, Geolocation or widget geocoordinate information, depending on
the capabilities of the mobile device and web browser being used. The module also
handles the dissemination and retrieval of that location information to and from the
platform server. Positioning is executed repeatedly at an interval that is set by the
updateTimeout function.
getPositioningStatus()
initializeGPS()
sendLocation()
startPositioning()
stopLocationShare()
stopPositioning()
updateGpsServer()
updateLocation ( mode )
updateTimeout()
Positioning Module
getPositioningStatus
updateGpsServer *
initializeGPS
updateLocation *
sendLocation *
startPositioning
updateTimeout
xhr
stopLocationShare
stopPositioning
Figure 19: The m.HUBI API Positioning module contains functions relevant to positioning
processes of the platform. The functions handle acquisition and evaluation of GPS, Geolocation
or widget geocoordinate information, depending on the capabilities of the mobile device and web
browser being used. The module also handles the dissemination and retrieval of that location
information to and from the platform server. Functions with an asterisk (*) after their names
make a call to the Communication module’s xhr function.
4.4.5 Display Module
The Display module contains functions that detect the screen proportions and characteristics
of the device being used to view a m.HUBI Platform Client application.
Based on the information gleaned from the device, the module activates the appropriate
CSS file or files. The Display module, if utilized without modifications or
additions, should only be used in conjunction with platform layout templates (see
section 4.5) as it utilizes and refers to them in the function evaluation.

37
detectResolution()
loadCss ( file, title )
replaceImages()
setActiveStyleSheet ( title )
windowResized()
Display Module
detectResolution
setActiveStyleSheet
loadCss
windowResized
replaceImages
Figure 20: The m.HUBI API Display module contains functions that detect the screen proportions
and characteristics of the device being used to view a platform client application. Based on
the information gleaned from the device, the module activates the appropriate CSS file or files.
4.4.6 Services Module
The Services module contains functions that pertain to various services of the
m.HUBI Platform, such as Events and Journey Planner (see sections 3.3 and 3.3).
For ease of use and clarity, the functions have been divided into service-specific
submodules named after the service they relate to.
Bookmarks
All functions of this module relate to Bookmarks. Registered platform users can
bookmark certain items that are relevant, interesting or useful to them in client
applications. Those bookmarks are saved to the user’s profile and can be retrieved,
modified and utilized when that user is logged in. Generally bookmarks are POI
objects, but other objects such as Journey Planner Routes can also be bookmarked.
Friends
addBookmark ( item )
deleteBookmark ( item )
displayBookmarks ( bookmarkArray )
getBookmarks ( track )
showBookmark ( item )
The functions of this module relate to the platform’s Friends service. The Friends
service allows users to create social networks by indicating their relationships with
each other. Friends may view each other’s locations when location sharing is enabled,

which is the default setting. The Friends module also contains the Buddy Javascript
Class, which represent user friends as they are depicted in the m.HUBI Platform.
acceptBuddyRequest ( friendName )
addBuddy ( friendName )
declineBuddyRequest ( friendName )
displayBuddies ( buddyArray )
getBuddies ( track )
getBuddyInfo ( friendName )
removeBuddy ( friendName )
Buddy {
getAvatar() setAvatar ( avatar )
getDistance() setDistance ( distance )
getLocDate() setLocDate ( locDate )
getName() setName ( name )
getPhone() setPhone ( phone )
getStatus() setStatus ( status )
}
38
Service Module
Bookmarks
Journey Planner
addBookmark *
getBookmarks *
displayRoute
showRoute
deleteBookmark *
showBookmark
getRoute *
updateRoute
displayBookmarks
getRouteToPoi
updateRoutePage
Friends
MyPlaces
parseXMLListener
acceptBuddyRequest
getBuddies *
addMyPlace *
getMyPlaces *
xhr
addBuddy
getBuddyInfo
deleteMyPlace *
moveMyPlace *
declineBuddyRequest
removeBuddy
displayMyPlaces
updateMyPlace *
displayBuddies
POI
displayEvents
showPoi
getPois *
showPoiDescription
Figure 21: The m.HUBI API Services module contains functions that pertain to various services
of the m.HUBI Platform. The services and corresponding function submodules are Bookmarks,
Friends, Journey Planner, MyPlaces and POI. The Friends, Journey Planner and POI submodules
also include Javascript classes, which are not depicted in the figure. Functions with an asterisk (*)
after their names make a call to the Communication module’s xhr function.

39
Journey Planner
The functions of this module relate to the m.HUBI Platform service Journey Planner
(see section 3.3). The Journey Planner provides public transport route options from
a given departure point to a given destination at a given time. The route options
are requested from the platform server Journey Planner service component by the
getRoute function and the response is displayed by the displayRoute function.
The Journey Planner module also includes the Route Javascript class and Route-
Leg and RoutePoint Javascript subclasses. A Route object represents a single Journey
Planner route, which is retrieved from an external public transit web service. A
RouteLeg object represents a subcomponent of a Route object. It is used to define
a route section completed on e.g. a single bus or on foot from one point to another.
Transfers, for instance, separate two RouteLeg objects from each other. A Route-
Point object represents a subcomponent of a RouteLeg object. It is used to define
a single point along a journey, such as the start or end point of a RouteLeg.
displayRoute ( routeArray )
getRoute ( from, to, depTime, arrTime, altDate, track )
getRouteToPoi ( poi )
showRoute ( route, legNo )
updateRoute ( updateElId, updateElVal )
updateRoutePage()
Route() {
getEnd() setEnd ( end )
getLegs() setLegs ( legs )
getStart() setStart ( start )
getStartDate() setStartDate ( startDate )
}
RouteLeg() {
getColor() setColor ( color )
getEnd() setEnd ( end )
getLength() setLength ( length )
getLine() setLine ( line )
getPoints() setPoints ( points )
getStart() setStart ( start )
getTransitType() setTransitType ( transitType )
}
RoutePoint() {
getLat() setLat ( lat )
getLon() setLon ( lon )
getName() setName ( name )
}

40
MyPlaces
The functions of this module relate to the m.HUBI Platform service MyPlaces.
MyPlaces are user-defined POIs that represent significant or frequently visited places
for the user, for instance Home, Work, Mom and Dad’s, and so on. The moveMyPlace
function is used to rearrange the MyPlaces list by moving a single MyPlace up or
down in the list.
POI
addMyPlace()
deleteMyPlace ( poi )
displayMyPlaces ( myPlacesArray )
getMyPlaces ( track )
moveMyPlace ( poi, moveDir )
updateMyPlace ( poi, updateData )
All functions of this module relate to Places Of Interest (POI) and other location
annotated data such as event happenings that have been integrated into the m.HUBI
Platform from external data sources (see section 3.3). The module also includes the
Javascript class POI, which is used as a placeholder for POI objects received from
the platform server and displayed on the web application client. The POI object
methods getType and setType relate to the type or genre of each POI. The types
of POI available depend on the kind of data accessible to platform clients. Example
POI types can include theater, music, gallery, sports, education and so on.
displayEvents ( poiArray )
getPois ( track, sort )
showPoi ( item )
showPoiDescription ( item )
Poi() {
getAddress() setAddress ( address )
getDataProvider() setDataProvider ( dataProvider )
getDesc() setDesc ( desc )
getDist() setDist ( dist )
getEndDate() setEndDate ( endDate )
getId() setId ( id )
getIsHome() setIsHome ( isHome )
getLat() setLat ( lat )
getLon() setLon ( lon )
getName() setName ( name )
getPlace() setPlace ( place )
getStartDate() setStartDate ( startDate )
getType() setType ( type )
getUrl() setUrl ( url )
}

41
4.4.7 Auxiliary Module
The Auxiliary module contains functions that execute frequently required actions
for various other m.HUBI API or proprietary Javascript functions. The module’s
functions handle retrieval and setting of HTML element values, computation of
mathematical calculations and performance of other menial tasks. This module is
not essential for the use of the m.HUBI Platform, but it facilitates speedier processing
times and decreases code repetition.
appendUrlAttribute ( url, attribute, value )
changeUrlAttribute ( url, attribute, value )
createMenu()
distanceBetween ( latA, lonA, latB, lonB )
getCheckedValue ( radioObj )
getSelectedValue ( selectObj )
hasUrlAttribute ( url, attribute )
latLngToPixel ( lat, lon, zoom )
pixelToLatLng ( x, y, zoom )
setCheckedValue ( radioObj, setValue )
setSelectedValue( selectObj, setValue )
Auxiliary Module
appendUrlAttribute
changeUrlAttribute
createMenu
hasUrlAttribute
latLngToPixel
pixelToLatLng
distanceBetween
getCheckedValue
setCheckedValue
setSelectedValue
getSelectedValue
Figure 22: The m.HUBI API Auxiliary module contains functions that execute frequently required
actions on behalf of other Javascript functions. The module’s functions handle retrieval
and setting of HTML element values, computation of mathematical calculations and performance
of other menial tasks.
4.5 Content Templates
The m.HUBI Platform offers content templates which may be used and filled in to
create functional client applications (Figure 23). The integration of the structure
and layout templates is discretionary, but they are provided to facilitate and ease the
development of new client applications. The two types of content templates, structure
and layout, address different aspects of mobile web application client interfaces
and they can be utilized either together or separately, should they be utilized at all.

The structure template is constructed mainly in HTML but it is actually a
JavaServer Page (JSP). JSP is a server-side technology that facilitates the creation
and distribution of dynamic web pages. Standard HTML pages are static and require
other technologies or mechanisms, such as Javascript, PHP and Perl, to dynamically
alter their content. JSP pages consist of a combination of regular HTML tags and
JSP elements. When a JSP page is requested from a web server, the server first
executes the JSP elements, then merges the results with the static HTML and
finally sends the outcome to the requester. [7] The template can also be modified
or edited to better suit the purposes of the application being created.
42
Figure 23: The m.HUBI Platform Server includes content templates to facilitate and ease development
of new client applications. Structure and layout templates can be used together, separately
or not at all.
The layout templates are simple CSS files that adapt and conform the web application
content to various mobile devices, screen sizes and orientations. The layout
templates can be used in conjunction with or independent of the platform content
templates. The example client application shown in Figure 23 is constructed by using
the complete content templates as they are provided, without any modifications.
The default client language is English, but other languages can be offered and their
text substituted using JSP variables and language files.
The layout templates provided address three mobile device screen resolutions,
namely Quarter Video Graphics Array (QVGA), Half-size Video Graphics Array
(HVGA) [83] and Near High-definition (nHD) [84]. The respective pixel ratios in
portrait orientation, meaning the screen width is smaller than the screen height, are
240 x 320, 320 x 480 and 360 x 640 pixels. Each screen resolution size has two corresponding
layout templates, one for portrait orientation and the other for landscape
orientation. Additionally, a default layout template is provided for use when the
device screen resolution is undefined and a browser-specific template is provided for
use with Opera mobile browsers. A comprehensive list of all the stylesheets included
in the m.HUBI Platform Client Layout Templates is supplied in Table 4.

43
Table 4: List of all the CSS files included as the m.HUBI Platform Client Layout Templates. The
stylesheets address various device screen resolutions and orientations.
Name of template Screen resolution Browser type
[W x H]
qvga-portrait 240 x 320 Non-IE
qvga-landscape 320 x 240 Non-IE
hvga-portrait 320 x 480 Non-IE
hvga-landscape 480 x 320 Non-IE
nhd-portrait 360 x 640 Non-IE
nhd-landscape 640 x 360 Non-IE
opera 360 x 640 Opera
default 320 x 480 Non-IE
4.6 Use-case Scenario
This section introduces a fictional m.HUBI Platform web application called My-
Conf. The mock application is used to depict an end-user scenario that delineates
the characteristics of the m.HUBI Platform and exhibits their functionality through
potential real-life situations and usage contexts. The scenario depicted in the following
text begins with a registered user logging into the fabricated MyConf application.
The user then views application-specific event data that has been expressly input
into the platform database for MyConf usage. Next, the pseudo user clicks on a
single event item, which displays detailed information regarding the event including
a textual description of the event. Lastly, the user retrieves public transit route
options using the MyConf Journey Planner in which the previously viewed event
venue is the route’s destination.
MyConf is a context-sensitive mobile web application created for use by participants
of a scientific conference and workshop. The application contains a Journey
Planner, a conference event calendar, a directory of conference participants and organizers
and a taxi-share service for persons wanting to share taxi rides between
different conference venues and hotels. MyConf was made using the structure and
layout templates and Javascript API that are available with the m.HUBI Platform.
The application also includes proprietary Javascript functions, HTML and
CSS content to focus and specify the application scope. The developers of MyConf
have added conference events such as presentations, workshops and networking opportunities
to the platform’s event database. A mock-up image of the application’s
homepage is shown in Figure 24.
Mr. Jones is a first-time conference participant and has not previously visited the
conference venue. After checking into his hotel, Mr. Jones navigates to the MyConf
homepage on his iPhone. As a registered conference participant, Mr. Jones received
a username and password for his MyConf account and proceeds to the login page of

44
MyConf
Calendar
Taxi-share
Directory
Figure 24: A homepage mock-up of the fictional MyConf web application client. The webapp
includes a Journey Planner, a conference calendar, a conference participant and organizer directory
and a taxi-share service for sharing taxi rides between different conference venues and hotels.
the webapp. By inputting his account information and pressing the Login-button,
Mr. Jones initiates an asynchronous AJAX dialogue between the MyConf webapp
client and the m.HUBI Platform Server running MyConf. This dialogue, which is
outlined below, is depicted in Figure 25.
Use-case scenario: Login user
function loginListener() {
...
}
function create() {
...
}
7
Javascript
m.HUBI PLATFORM
CLIENT-SIDE
HTTP
GET / POST
request
WEB APPLICATION CLIENT
HTTP
GET / POST
response
(XML data format)
PROPRIETARY CLIENT
1
3

The MyConf proprietary HTML contains the login page’s Login-button element.
When that button is pressed its onclick attribute calls the m.HUBI API login
function. The login function collects the username and password values Mr. Jones
input into the login form and calls the platform’s Javascript API xhr function with
the parameters (’POST’, ’login’, loginListener, ’username: password’). The
xhr function creates an HTTP POST request containing the login information and
sends it to the Login service component (see Figure 9) at the MyConf server via a
secure SSL connection.
The Login service component receives the POST request and asks the server’s
User Database if the user data is valid. The User Database responds to the Login
service component that the information is indeed correct. Next, the Login service
component requests that the platform server’s cookie generator create a session login
cookie with Mr. Jones’ account information. Finally, the service component creates
a HTTP POST response containing the newly generated session login cookie and
returns it to the MyConf webapp client. When the response message reaches the
client, it is handed to the platform Javascript API loginListener function for
parsing. The loginListener function utilizes another API function, create, to
save Mr. Jones’ authentication information as a browser cookie with default validity
of one year. Now, Mr. Jones is shown to his fellow MyConf users as logged in and if
he has allowed the sharing of his location to friends or other conference participators,
they will also see his location.
Use-case scenario: Open event calendar
45
function parseXMLListener() {
...
}
function displayEvents() {
...
} 8
Javascript
User Database:
5
Is session cookie
valid?
HTTP GET
Server
User Profile Database
& POI Database:
List Mr. Jones'
6 calendar events
Databases
Figure 26: The sequence of events illustrates the component workflow when Mr. Jones views his
event calendar on the MyConf web application client. Because Mr. Jones has already logged into
the application, his registered event listing can be retrieved from the platform server databases.

Next, Mr. Jones checks out his conference itinerary from MyConf’s Calendar service
(see Figure 26). When he presses the Calendar button on the MyConf homepage
that button’s onclick attribute indicates that the proprietary openCalendar
function is called. The openCalendar function calls the platform’s Javascript API
function xhr with the parameters (’GET’, ’poi’, parseXMLListener, null). The
xhr function sends the POI service component a message containing the session login
cookie and parameters indicating that the webapp client would like a response message
containing calendar events. The POI service component (see Figure 11) first
checks the validity of the session login cookie by communicating with the server’s
User Database, then it contacts the User Profile and POI databases to gather all
of Mr. Jones’ calendar events i.e. conference events he has indicated that he will
be attending. The POI service component then returns the collected events to the
webapp client as an XML document.
When the return message reaches the MyConf webapp, its handling is turned over
to the platform’s parseXMLListener callback function, as indicated in the original
xhr function call. The parseXMLListener dissembles the response XML document
into Javascript POI Objects and calls the follow-up function displayEvents to
handle the population and display of the actual Calendar page.
Use-case scenario: View event details
46
1

updateRoutePage and getRoute API functions to complete the route options retrieval.
The updateRoutePage function fills in the event POI address and time as
described above and the getRoute function calls the xhr function with the parameters
(’GET’, ’journeyPlanner’, parseXMLListener, null).
47
Use-case scenario: Get route to event
function parseXMLListener() {
...
}
function displayRoute() {
...
}
6
Javascript
m.HUBI PLATFORM
CLIENT-SIDE
HTTP
GET / POST
request
WEB APPLICATION CLIENT
HTTP
GET / POST
response
(XML data format)
PROPRIETARY CLIENT
1
HTTP GET
REQUEST
HTTP
GET / POST
request
EXTERNAL
WEB SERVICES
4
< XML >
HTTP GET
RESPONSE
HTTP GET
HTTP
GET / POST
response
Figure 28: After viewing details of a conference event Mr. Jones clicks the Journey Planner icon
of the MyConf web application to retrieve public transit route options from his hotel to the event’s
venue. The route options are queried from an external web service and returned to the webapp
client in XML form.
The Journey Planner service component receives a HTTP GET request from
the MyConf webapp client (see Figure 14). The service component reconstructs
the incoming message into an outgoing message that it sends to an external web
service that provides route information and journey planning for public transit. The
web service returns its response as an XML document, which is then restructured
and returned to the MyConf webapp. At the client end, the parseXMLListener
function handles the response message and saves the route information as Javascript
Route Objects. The parseXMLListener calls the displayRoute follow-up function
to display and format the parsed route options to the MyConf webapp.

48
5 Evaluation of the m.HUBI Platform
The m.HUBI Platform architecture defined, designed and documented in sections 3
through 4 was analyzed and evaluated by three mobile web application and information
systems experts. Two of the three expert analysts, Experts A and B, were
previously familiar with the VTT project, HUBI.mobi, into which this thesis work
was incorporated. They were asked to only evaluate the architecture and documentation
provided and to disregard any prior knowledge they may have had regarding
the platform.
The expert analysts were first presented with two scenarios (see Table 5) in which
a m.HUBI Platform mobile web application might be useful. They were asked to
familiarize themselves with the platform requirements, design, architecture and, in
particular, the Developer’s Javascript API. The experts were then asked to rate the
platform according to how well the requirements defined in section 3 were met in the
architecture (see Table 6). Finally, the experts commented generally on the design
and documentation of the m.HUBI Platform architecture (see section A1).
5.1 Scenario Implementations
The three expert analysts that evaluated the m.HUBI Platform architecture design
and documentation were provided with two fictional usage scenarios in which a
platform-based mobile application might be useful (see Table 5). They were asked
to indicate whether they could implement an appropriate platform application for
each scenario. If they found that such an application could not be implemented, the
experts were asked to describe why that was and what components were lacking or
insufficient. Similarly, if they found the development of a relevant platform application
plausible, the experts were asked to describe which components they would use
for the implementation. Expert C was unable to contribute to the scenario analysis,
as such the corresponding column is missing from Table 5.
The first scenario is one of a housewife who is taking her two children to Helsinki
for a day trip. The trip will include going to Korkeasaari zoo and then having
dinner with their father in downtown Helsinki. The housewife needs public transport
routing information from her home to the zoo and also needs to reserve a table at
a family-friendly downtown restaurant. Experts A and B both indicated that an
application for this scenario was plausible, but only partially implementable due to
an inadequacy in the retrieval of a particular POI type. The experts indicated that
the public transport route option retrieval was straightforward, but the filtering of
family-style restaurants from the POI list was an unavailable function. As indicated
in item 14 of Table A1, this issue was subsequently resolved by supplying a type
parameter for POI retrieval.
The second m.HUBI Platform usage scenario is one of a young urbanite who
suddenly has an hour to spend in downtown Helsinki. The mock user is a frequenter
of local art galleries and exhibits and would prefer not to view an exhibit he has
already seen. Expert A determined that with the amendment of a type filter for
POI retrieval, which was already mentioned in relation to Scenario 1, and sorting

those POIs according to the exhibits’ starting date the scenario was implementable.
Expert B concluded that a platform application to fit the scenario was implementable
by utilizing the user’s profile and preferences to retrieve POIs to meet his interests
and using the Friends service to view nearby Friends. However, Expert B stipulated
that the implementation is conditional upon the retrieval, review and updating of
the user’s profile preference information.
Table 5: As part of an objective platform evaluation, three expert analysts were presented with
scenarios in which a m.HUBI Platform mobile web application might be useful. The analysts were
asked to evaluate if they would be able to develop a platform-based application to be used in the
example scenarios.
49
No. Scenario Expert A Expert B
1 Laura is a thirtyish housewife who lives in
Riihimäki, Finland with her husband Pekka,
their two children, Onni 2-years-old and Essi
5-years-old, and the family dog Peppi. Laura
is taking the kids on a day trip into Helsinki
to do some shopping, visit Korkeasaari zoo and
meet Pekka for a family dinner in the evening.
Laura would usually drive the car the 70 km
to Helsinki, but Pekka has taken it. As an unaccustomed
public transit user, Laura is aware
that there is a train station in Riihimäki, but
doesn’t know the schedules for Helsinki-bound
trains. Also, since Laura had planned on using
her car’s onboard GPS navigation system
to drive directly to the zoo, she doesn’t know
how to get from the Helsinki train station to
the Korkeasaari zoo.
When Laura and the kids meet Pekka for dinner
in Helsinki, which is something that the
family does every few months, Pekka usually
leaves the choice of restaurant and making of
reservation up to Laura. Laura hasn’t been
able to reserve a table at any of the family’s
regular restaurants and she usually likes
to make sure the restaurant they dine at offers
a children’s menu and is generally familyfriendly.
2 Mikko is a twenty-five year-old graphic design
student who lives in Kallio, Helsinki. Mikko
is meant to be meeting his mother for coffee
in downtown Helsinki, but his mother sends
him a text message saying that the meeting she
is currently in will run late and suggests they
can meet an hour later for dinner instead. As
Mikko is already downtown he doesn’t see any
point in going home to Kallio in the meantime,
so he now has an hour to spend in the Helsinki
city center.
As a graphic design student, Mikko has visited
most of Helsinki’s art museums and galleries
many times, but he isn’t sure if some of the
exhibits have recently changed. Mikko is not
generally a solitary art-lover and usually takes
a friend to galleries with him.
Plausible / partially
implementable.
Use getRouteToPoi,
displayRoute and
getPois Javascript
API functions. Would
require a method for
retrieving particular
POI types e.g. restaurants,
family-friendly
restaurants (see item
14 in Table A1).
Plausible / partially
implementable. Use
displayBuddies and
getPois. Would require
only museum or
gallery POIs i.e. type
parameter for getPois
function (see item
14 in Table A1) and
sorted according to the
most recent exhibit.
Plausible / partially
implementable. Use
the Journey Planner
service and map to
retrieve and display
route from Riihimäki
to Korkeasaari zoo.
Would require a type
parameter for getPois
function to specify
the type of POI to
return (see item 14 in
Table A1).
Implementable. Use
user profile preferences
and getPois function
to retrieve nearby
POIs and Friend service
to view nearby
friends. Would require
user profile retrieval
and updating.

5.2 Requirement Fulfillment
The second part of the m.HUBI Platform analysis comprised of rating the architecture
in regards to how well the requirements specified in section 3 were met. The
experts were asked to mark each requirement with a rating from 0 to 5, whereby a
score of 0 indicates that the requirement is not met at all and a rating of 5 denotes
that the requirement is met perfectly. The experts were also permitted to comment
on their ratings, especially if there was a particular deficiency that contributed to
their rating. The expert analysis requirement rating results are presented in Table 6.
Some ratings were left blank by the experts and they are indicated by n/a. The last
column of the table is the average rating for each requirement, which was calculated
in relation to the total amount of ratings given for that requirement.
In terms of overall rating for the platform architecture reaching the platform
requirements, the expert analysis result is mediocre. The average rating for all the
requirement groups, functional, non-functional and service-specific, is just above 3.
This indicates that the architecture has adequately achieved the goals specified, but
there is also room for improvement.
The functional requirements R1–R6 were rated an average of 3.2, which was the
highest average score out of the three requirement groups. Additionally, having
earned a rating ratio of 5 ratings to 1 n/a, received the highest number of ratings
out of the three requirement groups. The R4: Map requirement earned the highest
average rating out of the functional requirements with a score of 4.0. Expert B
justified his rating of 4 by stating that it was unclear whether the implemented map is
interactive, as was specified in the original requirement on page 13. The lowest scorer
of the functional requirements was R3: Data Input Interfaces, which only received
a single rating of 1. The lone rating came from Expert B, who noted that there was
an absence of input interfaces in the architecture description of section 4. The lack
of data interface in the architecture documentation may explain why Experts A and
C did not evaluate R3 at all. Requirements R1–R2 and R5–R6 received an overall
average rating of 2.6–3.6.
The non-functional requirements R7–R10 received an average rating of 3.1 and
a rating ratio of 7 ratings to 12 n/a’s. 3.2 received the highest relative rating, with
an average of 3.5. Expert A noted that his rating was based on the support for
various mobile device screen sizes and resolutions provided by the content templates
described in section 4.5. Potentially this rating could have been higher, if more
device characteristics besides screen size and resolution were taken into account,
such as device platform or browser. 3.2 received the lowest rating out of the nonfunctional
requirements with an average of 2.6. Expert A commented that there
were no explicit figures or descriptions regarding the performance scalability of the
platform and Expert C stated the lack of physical deployment information for his
mark. The scalability issue is further discussed in section 5.3.
The third and final requirement group of service-specific requirements R11–R13
earned an average rating of 3.0, although the statistics are skewed due to the rating
ratio of 1 rating to every 2 n/a’s. The only analyst to rate this group of requirements
was Expert B, who found some deficiencies with the enabling of the R12: Events
50

service and the documentation of the R13: Recommender service. Expert B commented
that there were fields specified in the Events requirement on page 20 which
were not included in the Javascript Class POI (see section 4.4.6, such as organizer
and language. He also stated that the documentation regarding the Recommender
Service (see section 4.2.3) was lacking. The latter issue is discussed in more detail
in section 5.3.
Table 6: As part of an objective platform evaluation, two expert analysts were asked to rate the
m.HUBI Platform in regards to how well the requirements defined in section 3 are met.
51
No. Requirement Expert A Expert B Expert C ¯X
Functional Requirements 3.2
R1 Location-awareness 3 3 5 3.6
R2 Context-awareness 1 3 4 2.6
R3 Data Input Interfaces n/a 1 n/a 1.0
R4 Map 3 4 5 4.0
R5 User Profile 3 2 5 3.3
R6 User Activity Tracking 3 3 n/a 3.0
Non-functional Requirements 3.1
R7 Reusability n/a 4 n/a 4.0
R8 Cross-device Functionality 3 4 n/a 3.5
R9 Scalability 1 4 3 2.6
R10 Multilingual Content Support n/a 3 n/a 3.0
Service-specific Requirements 3.0
R11 Journey Planner n/a 4 n/a 4.0
R12 Events n/a 3 n/a 3.0
R13 Recommender n/a 2 n/a 2.0
5.3 Critical Issues
As the final part of the expert analysis of the m.HUBI Platform architecture design
and documentation, the three experts were asked to comment freely and mention
any inadequacy, discrepancy or inconsistency they found. The full list of comments
is listed in Table A1 of Appendix 6. The more prominent and significant issues
raised are discussed at length in this section.
A distinct inadequacy in R2: Context-awareness of the functional requirements
(see section 3.1), was noted by two of the three experts. The comments concerned
the lack of a concise description of what the term context inferred in the scope of the
m.HUBI Platform. Expert A was concerned that the only contextual information
to be collected and utilized by the platform is locational, whereas Expert B also
mentioned the Friends service. The root of the issue lies in the original requirement
wording and ambiguous nature of the term context itself. In relation to the platform,
the context-awareness requirement actually stands for providing mechanisms to add
new contextual sensor input data to the platform architecture. Such data could be
future mobile device sensor gathered information including acceleration, tempera-

ture, audio and video data. The requirement does not make any assumptions on
how the contextual input is used, but should require the platform to facilitate the
collection, storage and dissemination of the data.
A number of comments were made on the platform architecture documentation
provided in section 4. The issues raised were concerned with the nonexistent data
input interfaces (see requirement R3: Data Input Interfaces), the scalability characteristics
of the architecture specified in R9: Scalability and the operations of the
Recommender Service defined in R13: Recommender. The comments made on R3:
Data Input Interfaces and R13: Recommender were deemed so severe by the writer,
that the architecture description in section 4 was modified accordingly. An external
data input interface was appended to Figure 8 and the corresponding text and the
description of the Recommender Service in section 4.2.3 was revised and expanded
to better explain the inner processes of the Recommender Service component.
The remarks made regarding the scalability of the platform architecture, as mentioned
also in section 5.2, were that there was no reference, explicit or implicit, of any
kind of scalability parameters or statistics. Performance, distribution and physical
deployment metrics of the platform and its components would have provided a practical
view of the platform’s response to its scalability requirement (see section R9:
Scalability).
52

53
6 Conclusion
Websites of the 21st century are hardly recognizable as the ancestors of the first
static web pages implemented almost 20 years ago. Not only has the complexity of
the pages themselves increased, but the technologies and software platforms used to
serve the pages facilitate a multitude of dynamic content creation. Mobile phones
have undergone a similar and simultaneous evolution that has transformed them
from simple telephony and messaging instruments to portable personal computers
complete with high-resolution full-color screens, web access and synchronized applications.
Through the confluence of these services and devices a need has emerged
for context-sensitive, personal, feature-rich, quickly and easily accessible mobile web
applications.
Web services and rich web applications utilize technologies that allow desktopquality
application functionalities and content to be disseminated over the Internet
via a web browser interface. Modern web applications harness the modularity and
distributed nature the web and promote the Web 2.0 tenets of utilizing the web itself
as a platform and implementing lightweight and interactive architecture components
that yield services instead of products. Rich web applications (RIAs) enable webbased
applications to act and look more like desktop applications. They facilitate
asynchronous data retrieval and server interactions, so the user is saved from having
to communicate on the application’s terms and can instead focus on the activity
they want to complete. Web services and RIAs also facilitate the population and
delivery of personal content that is produced on-demand as the information or service
is requested. This mode of production allows for situationally relevant and highly
personalized content to be automatically injected into the application.
Smartphones, which are essentially hand-held mobile phone computers, have
completely revolutionized the field of mobile applications. In addition to native applications,
which are created specifically for a particular mobile operating system
or device firmware, and cross-platform applications, which use application middleware
to provide a uniform runtime environment for various systems and platforms,
smartphones are equipped with desktop-quality web browsers that can gracefully
execute web applications. Web application development consumes less time and
resources than native or cross-platform application development, because all web
browsers are designed to correctly interpret and execute the same code regardless
of the environment they are deployed in. In other words, where native applications
require program code to be tailored separately for each operating system or mobile
phone model and cross-platform applications require underlying operating system
dependent middleware to be installed, merely a single program version of a web
application needs to be written.
The growing sophistication and penetration of smartphones in the mobile phone
market combined with the advances in web technologies and standards has provided
a fertile foundation for mobile-specific web applications. As these mobile webapps
progressed, developers realized there was an untapped resource in the mobile device
itself. The inherent sensing capabilities that modern smartphones provide combined
with the dynamic capabilities and technologies of rich web applications enable the

automatic collection and utilization of tacit situational information from the usage
scenario.
Interpretation of tacit information is a notoriously difficult task for machine
processing to accomplish. Tacit or implicit information is knowledge that is not
obvious, but can be inferred from a situation or the context of a situation. For
instance, if a man is standing at a street corner with a map in his hands and is
looking at the street signs around him it could be deduced that he is lost. Similarly,
if the man is looking at his map and suddenly starts walking determinedly down
the street one could assume that he has located where he is on the map and is now
moving towards his destination. These details are relatively easy for a human being
to conclude if they were observing the situation, but a machine would not easily
make the correlation. The ability to automatically collect, interpret and store this
kind of implicit data in a machine-accessible format is paramount to context-aware
system design.
The reason context and situational information is viewed as a valuable addition
to mobile applications is the facilitation of better and more appropriate operations
and content. Situational information affords a system to provide more relevant
services and information to the user’s particular scenario. Additionally, if the data
can be automatically gathered and processed it relieves the user of the strain of
manually inputing that information. At the moment, mobile web applications suffer
from the limitation of a difficulties in accessing mobile device’s other applications or
content. Native applications do not have this dilemma, because they are executed by
the device’s operating system in a platform-compatible programming language and
are subsequently able to communicate with other applications or device hardware
directly. An enhancement in this field would be the acceptance and implementation
of the W3C Permissions for Device API Access working draft [78] that suggests
the provision of a uniform interface for web applications to access mobile device
hardware and software elements.
In this thesis, the requirements and specifications for a web-based mobile application
platform were defined. Based on the accumulated requirements, a platform
architecture was designed and documented and was finally evaluated by a panel of
experts. This Master’s dissertation and the work involved was completed as part of
the HUBI.mobi Project, which ran from 2009 to 2011, in the employ of VTT Technical
Research Centre of Finland (VTT). The initial thesis specification was to design
the architecture for a situation-sensitive, user-specific, feature-rich, highly portable
and easily maintainable application platform with which the rapid development and
deployment of mobile web applications would be possible. The resulting requirements
were gathered in part from literature and in part dictated by the HUBI.mobi
Project Management.
The requirements outlined in this thesis for a web-based mobile application platform
were listed by their characteristics into functional, non-functional and servicespecific
requirements (see section 3). The functional requirements specified were R1:
Location-awareness, R2: Context-awareness, R3: Data Input Interfaces, R4: Map, R5:
User Profile and R6: User Activity Tracking. The non-functional requirements outlined
for the platform were R7: Reusability, R8: Cross-device Functionality, R9:
54

Scalability and R10: Multilingual Content Support. Finally, the platform’s servicespecific
requirements were identified as R11: Journey Planner, R12: Events and R13:
Recommender.
Based on the requirements specified the architecture for the m.HUBI Platform
was designed and its documentation presented (see section 4). The platform consists
of server-side and client-side components. The client-side includes a Javascript API
and optional layout and structure content templates. Implemented platform-based
client applications may also include proprietary Javascript and content. The platform’s
server-side consists of Service Components, a Database Management module,
an Identity and Authorization Management module, a Recommender Service and a
Support Function component. The Service Components module is comprised of several
functionally independent subcomponents. Each subcomponent communicates
with and executes processes between a corresponding component in the client-side
Javascript API and the server-side Database Management module. Communication
between the platform’s client-side and its server-side is handled via HTTP GET and
POST messages that carry data in standard XML format.
Following the design and documentation of the architecture of the m.HUBI Platform,
it was evaluated by three expert analysts. The experts utilized their experience
in mobile web application development and information systems design to assess the
m.HUBI Platform in regards to how well it meets the requirements set for it and
how exhaustive and relevant its documentation is. The analysis consisted of three
segments; a user scenario, an architecture rating and an open comment segment.
The first segment consisted of two fictional usage scenarios in which a platformbased
webapp might be useful. The experts were asked to indicate whether they
believed they would be able to implement an appropriate m.HUBI Platform webapp
for each scenario. The second evaluation segment was a straightforward rating
task, in which the experts indicated how well they felt each architecture requirement
(see section 3) was met with a rating of 0 through 5. The third segment allowed
the expert analysts an open forum to comment on any deficiencies, superfluities or
discrepancies they found in either the architecture or its documentation.
The results of the first segment of the expert evaluation are subject to scrutiny
due to the small number of analysts that provided their estimations. Although the
two experts to complete the evaluation viewed the fictional usage scenarios presented
to be at least partially implementable with only minor changes enabling full implementation,
the judgments were purely theoretical and based on the architecture
documentation provided. A larger set of appraisers or more varied usage scenarios
would result in a more credible evaluation outcome and provide a more objective
result. The second evaluation segment, which entailed numerical rating of each architecture
requirement in relation to its fulfillment in the designed and documented
architecture, also suffers from similar credibility issues although all three experts
submitted their appraisals. Despite the statistical disputability of the second evaluation
segment, the platform requirements received an acceptable average rating of
3.1, which is just above the scale median of 3.
The expert evaluation, although limited in scope, revealed a number of relevant
functional and superficial issues. An inadequacy brought up by several analysts was
55

the ambiguous definition of context in regards to the platform architecture requirement
R2: Context-awareness. The concern was that the architecture design did not
incorporate enough variety in contextual data integration. The experts felt that
the only context available to the platform was locational information regarding the
users and their service-using friends. Another critical issue raised was the lack of
focus on requirement R9: Scalability in terms of the platform system’s performance,
distribution and physical deployment. These metrics are left unaddressed, but they
would provide valuable insight into the handling capabilities and system characteristics
of the platform scalability. A number of remarks were made regarding the
documentation of the architecture that primarily pertained to vague or ambiguous
descriptions and specific functionalities of the Javascript API.
In relation to existing comparable context-aware mobile application research
frameworks and platforms, the m.HUBI Platform is distinct in its solely web environment.
Other frameworks such and the JCAF [6], xFace [43] and Lively for
Qt [49] rely on middleware programs to provide runtime environments for their contextual
applications. Although, at present, m.HUBI Platform has limited access to
mobile device hardware or software which creates difficulty in accessing contextual
data, the problem will be significantly mitigated if not overcome with the adoption of
standardized Device APIs [78]. The m.HUBI Platform resembles its framework and
platform counterparts by emphasizing the attributes of lightweightness, extensibility
and platform independence. Although it also shares an open standards philosophy
with the xFace web application engine, the m.HUBI Platform is entirely based on
W3C endorsed technologies whereas the xFace platform also utilizes standards published
by other organizations.
A comprehensive evaluation of the m.HUBI Platform architecture and documentation
is difficult to execute thoroughly without an appraisable working implementation.
A portion of any potential architectural deficiencies are such, that they do
not manifest or are at least highly challenging to detect until a working version of
the platform has been constructed. However, the existing architecture design and
documentation was perceived as adequate in regards to the requirements laid out
for it and acceptable as a mobile web application development platform.
Potential improvement areas and considerations for future work are contextrelated
platform component specification, context input identification and collection
implementation, scalability testing, and capability verification. The author views
context input identification and the implementation of contextual data collection
as a particularly crucial issue and potential pitfall for the architecture and platform
as a whole. A central focus for future work regarding the m.HUBI Platform
is pilot application implementation by both existing project members, whom are
already familiar with the architecture, and external parties, that have no previous
knowledge of the architecture and could provide valuable insight into the quality
and suitability of the platform. Following application implementation, a pertinent
parallel research avenue would be the comparison of various context-aware mobile
applications created with frameworks and platforms similar to and including the
m.HUBI Platform.
56

57
References
[1] Adomavicius, G. and Tuzhilin, A. Toward the Next Generation of Recommender
Systems: A Survey of the State-of-the-Art and Possible Extensions.
IEEE Transactions on Knowledge and Data Engineering, 2005. Vol. 17. pp.
734–749. ISSN 1041-4347.
[2] Allied Business Intelligence, Inc. More than 60% of Handsets Will Have Mobile
Browsers in 2015. URL: http://www.abiresearch.com/press/1705-More+
than+60+of+Handsets+Will+Have+Mobile+Browsers+in+2015. August 3,
2010. [Accessed January 12, 2011].
[3] Alonso, G., Casati, F., Kuno, H. and Machiraju, V. Web Services: Concepts,
Architectures and Applications. Heidelberg, Germany, Springer-Verlag, 2004. p.
354. ISBN 3-540-44008-9.
[4] Anagnostopoulos, C. B., Tsounis, A. and Hadjiefthymiades, S. Context Awareness
in Mobile Computing Environments. Wireless Personal Communications:
An International Journal, 2007. Vol. 42:3. pp. 445–464. ISSN 0929-6212.
[5] Atterer, R., Wnuk, M. and Schmidt, A. Knowing the User’s Every Move—User
Activity Tracking for Website Usability Evaluation and Implicit Interaction.
Proceedings of the 15th International Conference on World Wide Web. Edinburgh,
Scotland, May 22–26, 2006. New York, New York, ACM, 2006. pp.
203–212. ISBN 1-59593-323-9.
[6] Bardram, J. E. The Java Context Awareness Framework (JCAF) - A Service
Infrastructure and Programming Framework for Context-Aware Applications.
In: Gellersen, H. W., Want, R. and Schmidt, A. (Eds.) Pervasive Computing,
Lecture Notes in Computer Science. Vol. 3468. 2005. pp. 98–115. DOI:
10.1007/11428572 7.
[7] Bergsten, H. JavaServer Pages TM . California, United States, O’Reilly, 2002. p.
684. ISBN 0-596-00317-X.
[8] Berners-Lee, T. Design Issues. URL: http://www.w3.org/History/
19921103-hypertext/hypertext/WWW/DesignIssues/Overview.html. 1992.
[Accessed January 12, 2011].
[9] Berners-Lee, T. ECHT90. URL: http://www.w3.org/History/
19921103-hypertext/hypertext/Conferences/ECHT90/Introduction.
html. 1992. [Accessed January 12, 2011].
[10] Bondi, A. Characteristics of Scalability and Their Impact on Performance. Proceedings
of the Second International Workshop on Software and Performance.
Ottawa, Ontario, Canada, September 17–20, 2000. New York, New York, ACM,
2000. pp. 195–203. ISBN 1-58113-195-X.

[11] Brodt, A., Nicklas, D., Sathish, S. and Mitschang, B. Context-Aware Mashups
for Mobile Devices. In: Bailey, J., Maier, D., Schewe, K., Thalheim, B. and
Wang, X. S. (Eds.) Proceedings of the Ninth International Conference on Web
Information Systems Engineering. Auckland, New Zealand, September 1–3,
2008. Berlin, Springer-Verlag, 2008. pp. 280–291.
[12] Carr, E. Location Technologies Primer. TechCrunch, 2008. URL: http:
//techcrunch.com/2008/06/04/location-technologies-primer/. June 4,
2008. [Accessed January 19, 2011].
[13] Cecchet, E., Chanda, A., Elnikety, S., Marguerite, J. and Zwaenepoel, W. Performance
comparison of middleware architectures for generating dynamic web
content. Proceedings of the ACM/IFIP/USENIX 2003 International Conference
on Middleware. Rio de Janeiro, Brazil, June 16–20, 2003. New York, NY,
Springer-Verlag, 2003. pp. 242–261. ISBN 3-540-40317-5.
[14] Choi, J. Software Architecture for Extensible Context-aware Systems. International
Conference on Convergence and Hybrid Information Technology,
Daejeon, South Korea, August 28–30, 2008. pp. 811–816. DOI:
10.1109/ICHIT.2008.236
[15] Chung, L. and do Prado Leite, J. On Non-Functional Requirements In Software
Engineering. In: Borgida, A., Chaudhri, V, Giorgini, P. and Yu E. (Eds.) Conceptual
Modeling: Foundations and Applications. Vol. 5600. Springer Berlin,
2009. pp. 363–379. (Lecture Notes in Computer Science).
[16] Clarkin, L. and Holmes, J. Enterprise Mashups. The Architecture Journal, 2007.
Vol. 13. URL: http://msdn.microsoft.com/en-us/architecture/bb906060
[Accessed January 18, 2011].
[17] Curbera, F., Duftler, M., Khalaf, R., Nagy, W., Mukhi, N. and Weerawarana,
S. Unraveling the Web Services Web: An Introduction to SOAP, WSDL and
UDDI. IEEE Internet Computing, 2002. Vol. 6:2. pp. 86–93. ISSN 1089-7801.
[18] Dao, D., Rizos, C. and Wang, J. Location-based services: technical and business
issues. GPS Solutions, 2002. Vol. 6:3. Heidelberg, Germany, Springer. pp. 169–
178. ISSN 1080-5370.
[19] Davidyuk, O., Riekki, J., Rautio, V-M. and Sun, J. Context-Aware Middleware
for Mobile Multimedia Applications. Proceedings of the 3rd International Conference
on Mobile and Ubiquitous Multimedia, College Park, Maryland, October
27–29, 2004. New York, New York, ACM. pp. 213–220.
[20] Desrosiers, C. and Karypis, A. A comprehensive Survey of Neighborhood-based
Recommendation Methods. In: Ricci, F., Rokach, L., Shapira, B. and Kantor,
P. B. (Eds.) Handbook on Recommender Systems. Springer New York, 2009. pp.
107–144. ISBN 978-0-387-85819-7.
58

[21] Dey, A. Understanding and Using Context. Personal Ubiquitous Computing,
2001. Vol. 5:1. pp. 4–7. ISSN 1617-4909.
[22] DocForge Web Application. URL: http://docforge.com/wiki/Web_
application [Accessed December 22, 2010].
[23] DuVander, A. 5 Years Ago Today the Web Mashup Was Born. Programmable
Web Blog, 2010. URL: http://blog.programmableweb.com/2010/04/08/
the-fifth-anniversary-of-map-mashups-on-the-web/ [Accessed January
18, 2011].
[24] Eirinaki, M. and Vazirgiannis, M. Web Mining for Web Personalization. Journal
of ACM Transactions on Internet Technology, 2003. Vol. 3:1. New York, New
York, ACM. pp. 1–27. ISSN 1533-5399.
[25] Encyclopædia Britannica. Smartphone. URL: http://www.britannica.com/
EBchecked/topic/1498102/smartphone. [Accessed January 13, 2011].
[26] Encyclopædia Britannica. Wi-Fi. URL: http://www.britannica.com/
EBchecked/topic/1473553/Wi-Fi. [Accessed January 18, 2011].
[27] Fielding, R. T. Principled Design of the Modern Web Architecture. Journal
of ACM Transactions on Internet Technology, 2002. Vol. 2:2. New York, New
York, ACM. pp. 115–150. ISSN 1533-5399.
[28] Fisher, M. B. Why require registration? Part 1. URL: http:
//completeusability.com/why-require-registration-part-1/. May
5, 2009. [Accessed January 27, 2011].
[29] Fisher, M. B. Why require registration? Part 2. URL: http://
completeusability.com/why-require-registration-part-2/. August 17,
2009. [Accessed January 27, 2011].
[30] Gartner, Inc. Clark, W. Fundamentals of Context Delivery Architecture: Provisioning
Context-Enriched Services, 2010 Update. URL: http://www.gartner.
com/DisplayDocument?id=1372919. May 20, 2010. [Accessed January 20,
2011].
[31] Gartner, Inc. Clark, W. Key Issues for Context-Aware Computing, 2010. URL:
http://www.gartner.com/DisplayDocument?id=1354514. April 16, 2010.
[Accessed January 4, 2011].
[32] Gartner, Inc. Jones, N. Cross-Platform Mobile Application Development Tools:
Interest and Capability Expected to Grow. URL: http://www.gartner.com/
DisplayDocument?id=1293616. February 2, 2010. [Accessed January 4, 2011].
[33] Global Intelligence Alliance. Native or Web Application? How Best to Deliver
Content and Services to Your Audiences over the Mobile Phone. URL:
http://www.globalintelligence.com/insights-analysis/white-papers/
59

native-or-web-application-how-best-to-deliver-cont/. April 2010.
[Accessed January 13, 2011].
[34] Google. Google Maps API Family. URL: http://code.google.com/apis/
maps/. [Accessed December 22, 2010].
[35] Griswold, W. G. Five Enablers for Mobile 2.0. Computer, 2007. Vol. 40:10. pp.
96–98. ISSN 0018-9162.
[36] Haerder, T. and Reuter, A. Principles of transaction-oriented database recovery.
ACM Computing Surveys, 1983. Vol. 15:4. pp. 287–317. ISSN 0360-0300.
[37] Hernandez, E. A. War of the Mobile Browsers. IEEE Pervasive Computing,
2009. Vol. 8:1. pp. 82–85. ISSN 1536-1268.
[38] Hinz, M. and Fiala, Z. Context Modeling for Device- and Location-Aware Mobile
Web Applications. Workshop of the Third International Conference on
Pervasive Computing, Munich, Germany, May 8–13, 2005.
[39] HSL: Helsinki Regional Transport Authority. Reittiopas API Developer’s
Guide. URL: http://developer.reittiopas.fi/pages/en/home.php. [Accessed
January 24, 2011].
[40] Huang, S. and Tilley, S. Issues of content and structure for a multilingual web
site. Proceedings of The 19th Annual International Conference on Computer
Documentation, Sante Fe, New Mexico, USA, 2001. New York, New York,
ACM. pp. 103–110. ISBN 1-58113-295-6.
[41] International Press Telecommunications Council. IPTC Standards.
URL: http://www.iptc.org/std/NAR/1.5/documentation/
IPTC-G2-Implementation-Guide_2.zip. 2009. [Accessed January 27,
2011].
[42] International Telecommunication Union. The World in 2010: ICT
Facts and Figures. URL: http://www.itu.int/ITU-D/ict/material/
FactsFigures2010.pdf. 2010. [Accessed January 12, 2011].
[43] Jiang, F., Feng, Z. and Luo, L. xFace - A Lightweight Web Application Engine
on Multiple Mobile Platforms. The Tenth IEEE International Conference on
Computer and Information Technology, Bradford, West Yorkshire, UK, June
29–July 1, 2010. pp. 2055–2060.
[44] Koskela, T., Kostamo N., Kassinen O., Ohtonen J. and Ylianttila M. Towards
Context-Aware Mobile Web 2.0 Service Architecture. International Conference
on Mobile Ubiquitous Computing, Systems, Services and Technologies, Papeete,
November 4–9, 2007. pp. 41–48.
[45] Li, D and Chandra, U. Building Web-Based Collaboration Services on Mobile
Phones. The 2008 International Symposium on Collaborative Technologies and
Systems, Irvine, California, May 19–23, 2008. pp. 295–304.
60

[46] Martin, S., Castro, M., Talevski, A. and Potdar, V. A Middleware for Mobile
and Ubiquitous Learning Ecosystems based on a Reconfigurable Plug-and-Play
Architecture: Application to Mashups. 24th IEEE International Conference on
Advanced Information Networking and Applications Workshops, Perth, Australia,
April 20–23, 2010. pp. 1–6.
[47] Mazzetti, P., Nativi, X., Sacco, A. and Bigagli, L. Integration of REST style and
AJAX technologies to build Web applications. Third International Conference
on Information and Communication Technologies: From Theory to Applications,
Damascus, Syria, April, 7–11, 2008. pp. 1–6.
[48] Miah, S. J. and Gammack, J. A Mashup Architecture for Web End-user Applicaiton
Designs. 2nd IEEE International Conference on Digital Ecosystems and
Technologies, Phitsanulok, Thailand, February 26–29, 2008. pp. 532–537.
[49] Mikkonen, T., Taivalsaari, A. and Terho, M. Lively for Qt: A Platform for Mobile
Web Applications. Proceedings of the 6th international Conference on Mobile
Technology, Application and Systems, Nice, France, September 2–4, 2009.
New York, New York, ACM. pp. 1–8.
[50] MozillaWiki. Open Web Apps Wiki - Manifest. URL: https://wiki.mozilla.
org/Labs/Apps/Manifest. October 20, 2010. [Accessed December 28, 2010].
[51] Mozilla Labs. Open Web Apps Technical Overview. URL: https://apps.
mozillalabs.com/oneFile.html. October 18, 2010. [Accessed November 2,
2010].
[52] Murugesan, S. and Venkatakrishnan, B. A. Addressing the Challenges of Web
Applications on Mobile Handheld Devices. International Conference on Mobile
Business, Sydney, Australia, July 11–13, 2005. pp. 199–205.
[53] Nokia Corporation. Qt - A cross-platform application and UI framework. URL:
http://qt.nokia.com/ [Accessed December 28, 2010].
[54] Oracle, Inc. GlassFish Wiki. What is an Application Server?. URL: http:
//wikis.sun.com/display/GlassFish/FaqWhatIsAppServer. June 2, 2010.
[Accessed February 10, 2011].
[55] Oracle, Inc. MySQL 5.0 Reference Manual. URL: http://downloads.mysql.
com/docs/refman-5.0-en.a4.pdf. 2011. [Accessed February 10, 2011].
[56] Offutt, J. Quality attributes of Web software applications. IEEE Software, 2002.
Vol. 19:2. pp. 25–32. ISSN 0740-7459.
[57] OpenStreetMap Wiki. OpenLayers. URL: http://wiki.openstreetmap.org/
wiki/OpenLayers. November 30, 2010. [Accessed December 20, 2010].
[58] OpenLayers. OpenLayers: Free Maps for the Web. URL: http://www.
openlayers.org/. [Accessed December 20, 2010].
61

[59] O’Reilly, T. What is Web 2.0. URL: http://oreilly.com/pub/a/web2/
archive/what-is-web-20.html. September 30, 2005. [Accessed December 27,
2010].
[60] O’Reilly, T. and Battelle, J. Web Squared: Web 2.0 Five Years
On. Web 2.0 Summit Conference, San Francisco, California, October
20–22, 2009. URL: http://assets.en.oreilly.com/1/event/28/web2009_
websquared-whitepaper.pdf [Accessed December 27, 2010].
[61] Paulson, L. D. Building Rich Web Applications with Ajax. Computer, 2005.
Vol. 38:10. pp. 14–17. ISSN 0018-9162.
[62] Pokraev, S., Koolwaaij, J., van Setten, M., Broens, T., Dockhorn Costa, P.,
Wibbels, M., Ebben, P. and Strating, P. Service Platform for Rapid Development
and Deployment of Context-Aware, Mobile Applications. IEEE International
Conference on Web Services, Orlando, Florida, July 11–15, 2005. pp.
639–646.
[63] Privacy Laws and Business. Data Protection and Privacy Law Links URL:
http://www.privacylaws.com/templates/Links.aspx?id=404#411. 2011.
[Accessed January 27, 2011].
[64] QtMapNews. URL: http://wn.com/qtmapnews [Accessed December 28, 2010].
[65] QtWeatherCameras. URL: http://wn.com/QtWeatherCameras [Accessed December
28, 2010].
[66] Quirksmode. Mobile Browsers URL: http://www.quirksmode.org/mobile/
browsers.html [Accessed January 24, 2011].
[67] Rademacher, P. HousingMaps.com. URL: http://www.housingmaps.com/.
2005. [Accessed January 18, 2011].
[68] Raento, M., Oulasvirta, A., Petit, R. and Toivonen, H. ContextPhone: A Prototyping
Platform for Context-Aware Mobile Applications. IEEE Pervasive Computing,
2005. Vol. 4:2. pp. 51–59. ISSN 1536-1268.
[69] Raman, T. V. Toward 2W, Beyond Web 2.0. Communications of the ACM,
2009. Vol. 52:2. pp. 52–59. ISSN 0001-0782.
[70] Reynolds, F. Web 2.0 – In Your Hand. IEEE Pervasive Computing, 2009. Vol.
8:1. pp. 86–88. ISSN 1536-1268.
[71] Rogers, R. Developing Portable Mobile Web Applications. Linux Journal, 2010.
Vol. 2010:197. pp. 3. ISSN 1075-3583.
[72] Shaw, R., Troncy, R, and Hardman, L. LODE: Linking Open Descriptions
of Events. In: Gómez-Pérez, A., Yu, Y. and Ding, Y. (Eds.) The Semantic
Web, Lecture Notes in Computer Science. Vol. 5926. 2009. pp. 153–167. DOI:
10.1007/978-3-642-10871-6 11.
62

[73] Siyu, M., Qiu, Z. and Luo, L. Research on Mobile Web Applications End to End
Technology. 10th IEEE International Conference on Computer and Information
Technology, Bradford, UK, June 29–July 1, 2010. pp. 2061–2065.
[74] Sun Microsystems, Inc. Hadley, M. Web Application Description Language.
URL: http://www.w3.org/Submission/2009/SUBM-wadl-20090831/. August
31, 2009. [Accessed December 14, 2010].
[75] Truong, H-L. and Dustdar, S. A Survey on Context-aware Web Service Systems.
International Journal of Web Information Systems, 2009. Vol. 5:1. pp. 5–31.
ISSN 1744-0084.
[76] Ullman, C. What is Ajax?. URL: http://www.wrox.com/WileyCDA/Section/
What-is-Ajax-.id-303217.html. 2007. [Accessed December 27, 2010].
[77] Vaughan-Nichols, S. J. Will Mobile Computing’s Future Be Location, Location,
Location?. Computer, 2009. Vol. 42:2. pp. 14–17. ISSN 0018-9162.
[78] W3C: World Wide Web Consortium. Byers, P. (Aplix), Hirsch, F. (Nokia)
and Hazaël-Massieux, D. (W3C). (Eds.) Permissions for Device API Access.
URL: http://www.w3.org/TR/2010/WD-api-perms-20101005/. October
5, 2010. [Accessed December 28, 2010].
[79] W3C: World Wide Web Consortium. Bray, T. (Textuality and Netscape),
Paoli, J. (Microsoft), Sperberg-McQueen, C. M. (W3C), Maler, E. (Sun Microsystems,
Inc.) and Yergeau, F. (Eds.) Extensible Markup Language (XML)
1.0. URL: http://www.w3.org/TR/REC-xml/#sec-origin-goals. November
26, 2008. [Accessed December 22, 2010].
[80] W3C: World Wide Web Consortium. Haas, H. (W3C) and Brown, A. (Microsoft,
Inc.). (Eds.) Web Services Glossary. URL: http://www.w3.org/TR/
2004/NOTE-ws-gloss-20040211/. February 11, 2004. [Accessed December 14,
2010].
[81] W3C: World Wide Web Consortium. Hickson, I. (Google, Inc.). (Eds.) HTML5:
A vocabulary and associated APIs for HTML and XHTML. URL: http://www.
w3.org/TR/2010/WD-html5-20101019/. October 19, 2010. [Accessed December
28, 2010].
[82] Weaver, A. C. Secure Sockets Layer. Computer, 2006. Vol. 39:4. pp. 88–90. ISSN
0018-9162.
[83] Wikipedia Graphic Display Resolutions. URL: http://en.wikipedia.org/w/
index.php?oldid=417030472 [Accessed March 7, 2011].
[84] Wikipedia List of common resolutions. URL: http://en.wikipedia.org/w/
index.php?oldid=417556789 [Accessed March 7, 2011].
63

[85] Wikipedia Web Application. URL: https://secure.wikimedia.org/
wikipedia/en/wiki/Web_application [Accessed December 22, 2010].
[86] Xu, K., Zhang, X., Song, M. and Song, J. Mobile Mashup: Architecture, Challenges
and Suggestions. International Conference on Management and Service
Science, Wuhan, China, September 20–22, 2009. pp. 1–4.
[87] Yahoo! Inc. Yahoo! Maps Web Services. URL: http://developer.yahoo.
com/maps/. [Accessed December 22, 2010].
[88] Ye, W., Hu, W., Zhao, W., Gao, X., Zhang, S. and Wang, L. Towards
Lightweight Application Integration Based on Mashup. World Conference on
Services - I, Los Angeles, California, July 6–10, 2009. pp. 500–506.
[89] Yu, J., Bentallah, B., Saint-Paul, R., Casati, F. and Daniel, F. Understanding
Mashup Development. IEEE Internet Computing, 2009. Vol. 12:5. pp. 44–52.
ISSN 1089-7801.
64

65
Appendix: Comments from Expert Analysis
Table A1: The results of the expert analysis discussed in section 5 and the possible actions taken
in response are listed here.
No. Issue
=⇒ Action taken
Requirements
1 Requirement sections 3.1–3.3 are not concise enough
=⇒ Added summary tables 2–3 to section 3
2 No sources listed for the requirements in section 3. What are they based on?
3 What is ‘context’ in the scope of the m.HUBI Platform architecture?
4 Do mini browsers and full browsers (see section R8: Cross-device Functionality) both support platform
applications to the same extent?
5 Does multilingual content management (see section 3.2) consider language-specific layout issues such
as width of textual elements?
6 Service-specific requirements in section 3.3 are too product-specific. Requirements should be specified
from a higher level e.g section R11: Journey Planner could be Routing.
Architecture Documentation
7 Architecture is missing a viewpoint definition. What is the meaning of the different colored boxes in
Figure 8?
8 External data sources and input interfaces not mentioned in platform architecture.
=⇒ Added external data input interfaces to architecture description in section 4.
9 Map interactivity: Are the maps served by the Map Service Component (see Figure 10) interactive
as indicated in the requirement R4: Map?
10 What relationship do the architecture’s client-side proprietary elements have with the client-side
platform elements?
11 What is the physical deployment of the platform especially in terms of scalability (see section R9:
Scalability)?
12 How does the Recommender Service (see section R13: Recommender) create the recommendations?
=⇒ Added subsection 4.2.3 to architecture description.
13 How is user activity tracking (see section R6: User Activity Tracking) handled for actions that do
not require server communication?
Javascript API
14 Analysis scenarios: Unable to sort POIs by type.
15 No explicit function for immediate location retrieval e.g. getLocation.
16 No functions for explicit geocoding or reverse geocoding e.g. geocodeLocation( locString ) and
reverseGeocodeCoordinate( lat, lon ).
17 No corresponding start function for stopLocationShare in API Positioning Module.
18 No functions for viewing, updating or managing user profile in API Foundation Module.
19 No function for creating a new user account in API Foundation Module.
20 No function to change application language.
21 Is the positioning technology used relevant to the platform e.g. updateLocation( mode ) in API Positioning
Module?
22 Inefficient use of multiple functions for similar execution i.e. initializeIphoneMap and
initializeWidgetMap and showUserOnMap and showPoisOnMap in API Map Module.
23 All Event fields from R12: Events not represented in Javascript Object Class POI in API module POI.
24 Amount of function-specific information in section 4.4 insufficient. Either add more detailed information
i.e. return values and function descriptions or move function lists to appendix.