Developing a Web-Based Service Platform Architecture for Ccontext ...
Developing a Web-Based Service Platform Architecture for Ccontext ...
Developing a Web-Based Service Platform Architecture for Ccontext ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Paula Perkola<br />
<strong>Developing</strong> a <strong>Web</strong>-based <strong>Service</strong><br />
<strong>Plat<strong>for</strong>m</strong> <strong>Architecture</strong> <strong>for</strong> Context-aware<br />
Mobile <strong>Service</strong>s<br />
School of Electrical Engineering<br />
Thesis submitted <strong>for</strong> examination <strong>for</strong> the degree of Master of<br />
Science in Technology.<br />
Espoo 23.5.2011<br />
Thesis supervisor:<br />
Prof. Eero Hyvönen<br />
Thesis instructor:<br />
M.Sc. (Tech.) Renne Tergujeff<br />
A’’<br />
Aalto<br />
University<br />
School of Electrical<br />
Engineering
aalto university<br />
school of electrical engineering<br />
abstract of the<br />
master’s thesis<br />
Author: Paula Perkola<br />
Title: <strong>Developing</strong> a <strong>Web</strong>-based <strong>Service</strong> <strong>Plat<strong>for</strong>m</strong> <strong>Architecture</strong> <strong>for</strong><br />
Context-aware Mobile <strong>Service</strong>s<br />
Date: 23.5.2011 Language: English Number of pages:7+65<br />
Department of Media Technology<br />
Professorship: Media Technology Code: T-75<br />
Supervisor: Prof. Eero Hyvönen<br />
Instructor: M.Sc. (Tech.) Renne Tergujeff<br />
In this thesis, the requirements and specifications <strong>for</strong> a context- and user-specific<br />
web-based mobile application plat<strong>for</strong>m were defined. <strong>Based</strong> on the accumulated<br />
requirements, a plat<strong>for</strong>m architecture was designed and documented and was finally<br />
evaluated by a panel of in<strong>for</strong>mation system and mobile web application<br />
experts. This Master’s Thesis and the work involved was completed as part of the<br />
HUBI.mobi Project at VTT Technical Research Centre of Finland.<br />
The requirements outlined <strong>for</strong> a web-based mobile application plat<strong>for</strong>m were listed<br />
by their characteristics into functional, non-functional and service-specific requirements.<br />
The functional requirements specified were location-awareness, contextawareness,<br />
data input interfaces, map, user profile and user activity tracking.<br />
The non-functional requirements outlined <strong>for</strong> the plat<strong>for</strong>m were reusability, crossdevice<br />
functionality, scalability and multilingual content support. Lastly, the plat<strong>for</strong>m’s<br />
service-specific requirements were identified as Journey Planner, Events and<br />
Recommender.<br />
An architecture <strong>for</strong> the m.HUBI <strong>Plat<strong>for</strong>m</strong> was designed and documented based on<br />
the specified requirements. The plat<strong>for</strong>m consists of both server-side and clientside<br />
components. Communication between the plat<strong>for</strong>m’s two sides is handled<br />
via HTTP GET and POST messages that carry data in standard XML <strong>for</strong>mat.<br />
The plat<strong>for</strong>m’s architecture was evaluated by three expert analysts that utilized<br />
their experience in mobile web application development and in<strong>for</strong>mation systems<br />
design to assess how well the plat<strong>for</strong>m meets its requirements. The architecture<br />
evaluation raised issues and concerns regarding the plat<strong>for</strong>m’s context-awareness,<br />
data input interface and scalability requirements. Overall, the expert analysis<br />
proved the m.HUBI <strong>Plat<strong>for</strong>m</strong> to adequately meet the requirements specified <strong>for</strong><br />
it.<br />
Keywords: Mobile web application, web service, context-awareness, application<br />
architecture
aalto-yliopisto<br />
sähkötekniikan korkeakoulu<br />
diplomityön<br />
tiivistelmä<br />
Tekijä: Paula Perkola<br />
Työn nimi: Verkkopalvelualustan arkkitehtuurin kehitys kontekstitietoisille<br />
mobiilipalveluille<br />
Päivämäärä: 23.5.2011 Kieli: Englanti Sivumäärä:7+65<br />
Mediatekniikan laitos<br />
Professuuri: Mediatekniikka Koodi: T-75<br />
Valvoja: Prof. Eero Hyvönen<br />
Ohjaaja: DI Renne Tergujeff<br />
Tässä diplomityössä määriteltiin vaatimukset konteksti- ja käyttäjäkohtaiselle<br />
verkkopohjaiselle mobiilisovellusalustalle. Alusta-arkkitehtuuri suunniteltiin ja<br />
dokumentoitiin koottujen vaatimusten perusteella sekä arvioitiin tietojärjestelmäja<br />
mobiiliverkkosovellusasiantuntijoiden toimesta. Tämä diplomityö tehtiin osana<br />
HUBI.mobi projektia Teknologian tutkimuskeskus VTT:llä.<br />
Verkkopohjaisen mobiilisovellusalustan vaatimukset lueteltiin ominaisuuksien<br />
perusteella toiminnallisiin, ei-toiminallisiin ja palvelukohtaisiin vaatimuksiin.<br />
Toiminalliset vaatimukset olivat paikkatietoisuus, kontekstitietoisuus, tiedon<br />
syötön käyttöliittymät, kartta, käyttäjäprofiili ja käyttäjän toimintojen seuranta.<br />
Määritellyt ei-toiminnalliset vaatimukset olivat uudelleenkäytettävyys, laiteriippumattomuus,<br />
skaalautuvuus ja monikielisen sisällön tuki. Viimeiset palvelukohtaiset<br />
vaatimukset olivat matkasuunnittelija, tapahtumat ja suositin.<br />
m.HUBI alustan arkkitehtuuri suunniteltiin ja dokumentoitiin edellä esitettyjen<br />
vaatimusten perusteella. Alusta koostuu sekä serveripuolen että päätelaitepuolen<br />
komponenteista, joiden välinen yhteydenpito hoidetaan HTTP GET ja POST<br />
viesteillä. Viestit välittävät tietoa standardissa XML-muodossa. Kolme<br />
asiantuntijaa hyödynsivät heidän kokemustaan mobiilien verkkosovellusten kehityksestä<br />
ja arvioivat miten hyvin alustan arkkitehtuuri vastasi sille asetettuja<br />
vaatimuksia. Arkkitehtuurianalyysissä nousi esiin puutteita alustan<br />
kontekstitietoisuus-, tiedonsyöttökäyttöliittymä- ja skaalautuvuusvaatimuksissa.<br />
Yleisesti, asiantuntija-analyysi osoitti, että m.HUBI alusta täytti sille asetetut<br />
vaatimukset riittävästi.<br />
Avainsanat: Mobiili verkkosovellus, verkkopalvelu, kontekstitietoisuus, sovellusarkkitehtuuri
iv<br />
Preface<br />
I would like to thank my supervisor Professor Eero Hyvönen and my instructor<br />
Renne Tergujeff <strong>for</strong> their guidance and help throughout this writing process. I<br />
also owe a big thanks to the HUBI.mobi Project Team and the entire Environment<br />
In<strong>for</strong>mation Systems Team at VTT, without whom this thesis would not have been<br />
possible. I also express my sincere appreciation to VTT Technical Research Centre<br />
of Finland and all parties involved in the HUBI.mobi Project <strong>for</strong> financing my thesis<br />
work and offering me the opportunity to work on and learn from such a challenging<br />
project so early in my career.<br />
Last but not least, I would like to thank my entire family <strong>for</strong> offering their<br />
advice, support and encouragement throughout my studies and especially during<br />
the completion of my thesis.<br />
Espoo, 23.5.2011<br />
Paula Perkola
v<br />
Contents<br />
Abstract<br />
Abstract (in Finnish)<br />
Preface<br />
Contents<br />
Symbols and abbreviations<br />
ii<br />
iii<br />
iv<br />
v<br />
vii<br />
1 Introduction 1<br />
2 State-of-the-Art In <strong>Web</strong>, Mobile and Context Systems 3<br />
2.1 <strong>Web</strong> Applications and <strong>Web</strong> <strong>Service</strong>s . . . . . . . . . . . . . . . . . . . 3<br />
2.2 Rich <strong>Web</strong> Applications . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
2.3 Context and Context-aware Systems . . . . . . . . . . . . . . . . . . 4<br />
2.4 Context-aware Mobile Applications . . . . . . . . . . . . . . . . . . . 5<br />
2.5 Mobile Positioning Technologies . . . . . . . . . . . . . . . . . . . . . 6<br />
2.6 Mapping <strong>Service</strong>s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
2.7 Sample Implementations . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
2.7.1 Mozilla Open <strong>Web</strong> Applications . . . . . . . . . . . . . . . . . 7<br />
2.7.2 Lively <strong>for</strong> Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
2.7.3 xFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
3 Requirements <strong>for</strong> a <strong>Web</strong>-based Mobile <strong>Service</strong> <strong>Plat<strong>for</strong>m</strong> 11<br />
3.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
3.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 15<br />
3.3 <strong>Service</strong>-specific Requirements . . . . . . . . . . . . . . . . . . . . . . 17<br />
4 <strong>Architecture</strong> of the m.HUBI <strong>Plat<strong>for</strong>m</strong> 21<br />
4.1 <strong>Architecture</strong> Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
4.2 Server Core Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
4.2.1 Database Management . . . . . . . . . . . . . . . . . . . . . . 23<br />
4.2.2 Identity and Authorization Management . . . . . . . . . . . . 23<br />
4.2.3 Recommender <strong>Service</strong> . . . . . . . . . . . . . . . . . . . . . . 24<br />
4.2.4 Support Functions . . . . . . . . . . . . . . . . . . . . . . . . 24<br />
4.3 m.HUBI <strong>Plat<strong>for</strong>m</strong> <strong>Service</strong> Components . . . . . . . . . . . . . . . . . 24<br />
4.4 Javascript API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32<br />
4.4.1 Communication Module . . . . . . . . . . . . . . . . . . . . . 33<br />
4.4.2 Foundation Module . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
4.4.3 Map Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
4.4.4 Positioning Module . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
4.4.5 Display Module . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
4.4.6 <strong>Service</strong>s Module . . . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
4.4.7 Auxiliary Module . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 Content Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
4.6 Use-case Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
5 Evaluation of the m.HUBI <strong>Plat<strong>for</strong>m</strong> 48<br />
5.1 Scenario Implementations . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
5.2 Requirement Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . 50<br />
5.3 Critical Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
6 Conclusion 53<br />
References 57<br />
Appendix: Comments from Expert Analysis 65<br />
vi
vii<br />
Symbols and abbreviations<br />
Abbreviations<br />
AJAX Asynchronous Javascript and XML<br />
CMS Content Management System<br />
CSS Cascading Style Sheets<br />
DHTML Dynamic Hypertext Markup Language<br />
DOM Document Object Model<br />
HTML Hypertext Markup Language<br />
HTTP Hypertext Transfer Protocol<br />
HVGA Half-size Video Graphics Array<br />
JCAF Java Context Awareness Framework<br />
JSON Javascript Object Notation<br />
JSP JavaServer Pages<br />
nHD Near High-definition<br />
QVGA Quarter Video Graphics Array<br />
RIA Rich Internet Application<br />
RSS Really Simple Syndication<br />
SOAP Simple Object Access Protocol<br />
UDDI Universal Description, Discovery and Integration<br />
VTT VTT Technical Research Centre of Finland<br />
W3C World Wide <strong>Web</strong> Consortium<br />
WWW World Wide <strong>Web</strong><br />
XHTML Extensible Hypertext Markup Language<br />
XML Extensible Markup Language
1 Introduction<br />
The World Wide <strong>Web</strong> (WWW) as it is known today has come a long way from<br />
the first static web pages created in the early 1990’s [8, 9]. Modern websites can<br />
consist of complex hierarchies of multiple web pages that render dynamically created<br />
contextual content in real-time. Concurrent with the advances in web technologies<br />
has been the evolution and proliferation of hand-held personal mobile devices. An<br />
indication of the prevalence of mobile devices is the surpassing of 5 billion mobile<br />
phone connections in 2010, a third of which included a mobile web browser. [2, 42]<br />
The coincidence of these technologies and events have created a niche <strong>for</strong> situationspecific,<br />
pertinent, in<strong>for</strong>mative, quick and easy-to-use mobile web applications.<br />
As mobile device characteristics and capabilities have evolved, so has the scope<br />
of mobile device content expanded. Previously, mobile phones were restricted by<br />
low-bandwidth communication, inadequate processing power and memory capacity,<br />
and small screen size and screen resolution. [52, 70] Native applications produced <strong>for</strong><br />
proprietary operating systems and specific firmware were the only implementation<br />
option <strong>for</strong> mobile applications at the time. This means that a single native application<br />
needed to be adjusted separately <strong>for</strong> each mobile phone model or operating<br />
system. [33]<br />
Smartphones are advanced mobile phone devices that are essentially hand-held<br />
computers integrated with mobile telephones. [25] They are subsequently less inhibited<br />
by the drawbacks of conventional mobile phone devices, sometimes called<br />
feature phones, and they can efficiently utilize online web applications as an alternative<br />
to native mobile applications. [33] <strong>Web</strong> applications, contrary to native mobile<br />
applications, run independent of a mobile phone’s operating system and firmware.<br />
They are launched via an Internet browser, which is designed to provide a common<br />
runtime environment across different mobile, or indeed desktop, plat<strong>for</strong>ms. [71]<br />
The growing sophistication and penetration of smartphones in the mobile phone<br />
market combined with the advances in web technologies and standards provided a<br />
fertile foundation <strong>for</strong> mobile-specific web applications. As these mobile webapps<br />
progressed developers realized there was an untapped resource in the mobile device<br />
itself. The inherent sensing capabilities that modern smartphones provide combined<br />
with the dynamic capabilities of rich web applications and technologies enable the<br />
automatic collection and utilization of tacit situational in<strong>for</strong>mation from the usage<br />
scenario. [35, 70]<br />
The purpose of this Master’s Thesis is to specify and design a situation-sensitive,<br />
user-specific, feature-rich, highly portable and easily maintainable application plat<strong>for</strong>m<br />
that facilitates the rapid development and deployment of mobile web applications.<br />
The motivation behind this thesis work originated from a lack of existing application<br />
or software infrastructure that facilitates mobile application development<br />
with operating system independent web technologies while harnessing contextual<br />
in<strong>for</strong>mation. At the time of writing, state-of-the-art context-aware mobile web applications<br />
are run either as native applications or on top of middleware applications<br />
in order to gain access to the mobile device’s software and hardware. These existing<br />
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<br />
solutions are at least partially operating system dependent and require extensive<br />
resources <strong>for</strong> application development and modification.<br />
The research questions answered in this Master’s Thesis are:<br />
– What are the requirements <strong>for</strong> an extensible web-based plat<strong>for</strong>m architecture<br />
enabling efficient development of context-aware mobile services?<br />
– How well does the designed and documented plat<strong>for</strong>m architecture meet<br />
the requirements set out <strong>for</strong> it?<br />
– Does the designed and documented plat<strong>for</strong>m architecture facilitate the<br />
implementation of appropriate plat<strong>for</strong>m-based applications in response<br />
to various fictional usage scenarios?<br />
– Are there any critical deficiencies or inadequacies in the designed and<br />
documented plat<strong>for</strong>m architecture?<br />
The work documented in this thesis was completed as part of the HUBI.mobi<br />
Project at VTT Technical Research Centre of Finland (VTT). The project, which<br />
ran from 2009 to 2011, was funded by VTT in conjunction with the Finnish Funding<br />
Agency <strong>for</strong> Technology and Innovation (Tekes) and a number of companies.<br />
The goals of the project included creating the a<strong>for</strong>ementioned m.HUBI <strong>Plat<strong>for</strong>m</strong>—a<br />
web-based mobile accessible application plat<strong>for</strong>m—implementing a pilot plat<strong>for</strong>m<br />
application and developing novel recommendation mechanisms. The recommendation<br />
algorithms utilize explicit and implicit preference data to produce user-targeted<br />
selections that are solicited from a developmental recommendation service. The<br />
HUBI.mobi project aims at adapting and leveraging experiences and knowledge<br />
gained from previous projects including the design and implementation of a webbased<br />
desktop service plat<strong>for</strong>m called the HUBI <strong>Plat<strong>for</strong>m</strong>. The m.HUBI <strong>Plat<strong>for</strong>m</strong><br />
emphasizes the combination of data such as event and usage in<strong>for</strong>mation, friend<br />
locations and structured data to provide new content and added-value to users.<br />
Prior to designing a new application plat<strong>for</strong>m, the current cutting edge of web<br />
applications, context-aware systems and related technologies is briefly introduced in<br />
section 2. The following section, section 3, represents the design phase by specifying<br />
the requirements and functionalities of a plat<strong>for</strong>m that supports and exhibits<br />
the a<strong>for</strong>ementioned properties. The resulting design is then implemented in the<br />
<strong>for</strong>m of a plat<strong>for</strong>m architecture and application programming interface (API) that<br />
provides access to the mobile web application plat<strong>for</strong>m. The newly specified and<br />
designed plat<strong>for</strong>m architecture is documented and presented in section 4. Finally,<br />
the scope and functionality of the architecture and API are objectively evaluated by<br />
several web application specialists, the results of which are condensed and outlined<br />
in section 5.<br />
2
2 State-of-the-Art In <strong>Web</strong>, Mobile and Context<br />
Systems<br />
The in<strong>for</strong>mation, services and applications available via the Internet have evolved<br />
beyond recognition within the past decade. The scope of web technologies currently<br />
in active use, not to mention the spread of emerging plat<strong>for</strong>ms and tools, is too<br />
wide to discuss comprehensively so this section focuses on covering the most pertinent<br />
topics. This section first introduces the state of modern web applications and<br />
context-aware systems and then reviews several of their practical implementations.<br />
2.1 <strong>Web</strong> Applications and <strong>Web</strong> <strong>Service</strong>s<br />
A web service can be generically described as a way to expose the functionality of<br />
an in<strong>for</strong>mation system and make it available through standard <strong>Web</strong> technologies,<br />
i.e. HTTP, HTML, <strong>Web</strong> servers and <strong>Web</strong> browsers. The use of these technologies<br />
reduces heterogeneity and fosters application and system interoperability. [3, p.<br />
94, 123] A more specific definition is provided by the W3C [80], which states that<br />
“A <strong>Web</strong> service is a software system designed to support interoperable machineto-machine<br />
interaction over a network. It has an interface described in a machineprocessable<br />
<strong>for</strong>mat (specifically WSDL). Other systems interact with the <strong>Web</strong> service<br />
in a manner prescribed by its description using SOAP-messages, typically conveyed<br />
using HTTP with an XML serialization in conjunction with other <strong>Web</strong>-related standards.”<br />
<strong>Web</strong> <strong>Service</strong>s build on top of existing <strong>Web</strong> protocols using open XML standards<br />
to provide a systematic and extensible framework <strong>for</strong> application interaction. These<br />
services are characterized by their interoperability and standardized description,<br />
communication and discovery technologies: simple object access protocol (SOAP),<br />
<strong>Web</strong> <strong>Service</strong>s Description Language (WSDL) and Universal Description Discovery<br />
and Integration (UDDI), respectively. [17]<br />
A web application or webapp, as the term is often abbreviated, is defined by<br />
the W3C as a HTTP-based application whose interactions are machine processable.<br />
<strong>Web</strong>apps are typically based on existing <strong>Web</strong> architecture and infrastructure and<br />
they are plat<strong>for</strong>m and programming language independent. They also promote application<br />
reuse beyond the browser by enabling interoperability with other <strong>Web</strong> or<br />
desktop applications. In addition, webapps require the content used to be semantically<br />
unambiguous, which is usually achieved by using XML or JSON data exchange<br />
<strong>for</strong>mats. [74]<br />
<strong>Web</strong> applications are programs that are accessed over a network. They are<br />
usually coded in a browser-supported language, such as Javascript and HTML, and<br />
they rely on web browsers to execute the application. [85] <strong>Web</strong>apps are fundamental<br />
to interactive websites because they dynamically build programmatic responses to<br />
incoming HTTP-requests. [22]<br />
A web application server usually consists of a HTTP web server, an application<br />
server and a database or simply an application server and a database. A generic web<br />
server handles the distribution of files across a network by receiving and responding<br />
3
to HTTP requests from other web servers and web browsers. [3, p. 94] However, an<br />
application server enables the distribution of applications and provision of services<br />
over the Internet. [54] Essentially, a web server dispenses only static content whereas<br />
an application server can dispense dynamic content. [13] The database is needed<br />
to provide a data warehouse, transaction processors to add, access and process that<br />
data as well as authorization and identification services to monitor and limit access<br />
to the database. [55]<br />
A web application client contains the front-end portion of a web application. It<br />
constitutes the user interface of the service and is displayed to the end-user via a web<br />
browser. The client contains mechanisms that support and implement application<br />
activity, interaction and communication with the corresponding server.<br />
2.2 Rich <strong>Web</strong> Applications<br />
Classic web applications can be made more interactive and user-friendly or richer, as<br />
these types of applications are commonly called, by using Asynchronous Javascript<br />
and XML (AJAX). [61] AJAX-based web applications can retrieve <strong>Web</strong> resources<br />
asynchronously without needing to reload any pages, freeing up the user interface<br />
<strong>for</strong> other things and improving per<strong>for</strong>mance. AJAX incorporates a group of technologies,<br />
which include but are not limited to:<br />
– Extensible Hypertext Markup Language (XHTML),<br />
– Cascading Stylesheets (CSS),<br />
– the Document Object Model (DOM),<br />
– Extensible Markup Language (XML),<br />
– Extensible Stylesheet Language Trans<strong>for</strong>mations (XSLT),<br />
– XMLHttpRequest and<br />
– Javascript. [59]<br />
Originally, as the name suggests, the de facto client-side programming language<br />
of AJAX was Javascript and the data encoding <strong>for</strong>mat was XML. Despite the naming<br />
convention, programming languages other than Javascript and data encodings<br />
besides XML are used in AJAX applications. In addition, applications do not need<br />
to strictly adhere to the asynchrony to be considered rich web applications. [47, 76]<br />
2.3 Context and Context-aware Systems<br />
Unlike machines, human beings are fairly adept at comprehending implicitly conveyed<br />
in<strong>for</strong>mation. [21] For example, a person could implicitly assume that if someone<br />
is standing still at a bus stop that the person is waiting <strong>for</strong> a bus to arrive at<br />
which time they would get on the bus. The ability to translate this kind of tacit<br />
in<strong>for</strong>mation or context into a machine-accessible <strong>for</strong>mat and to further automate<br />
the collection, storage and retrieval of said in<strong>for</strong>mation has recently become highly<br />
researched. [75]<br />
4
One of the more frequently sited definitions of context, as it pertains to contextawareness<br />
in applications and computing, is the one provided by Dey [21]. Dey<br />
describes context as in<strong>for</strong>mation that can be used to characterize the situation of an<br />
entity. An entity is further defined as a person, place, or object that is considered<br />
relevant to the interaction between a user and an application, including the user<br />
and the applications themselves. The same author has also outlined a contextaware<br />
system by stating that a system is context-aware if it uses context to provide<br />
relevant in<strong>for</strong>mation and/or services to the user, where relevancy depends on the<br />
user’s task. [21]<br />
In a newly published survey conducted by Truong and Dustdar [75] the scope<br />
of context-aware systems is refined by stating that the system should be otherwise<br />
operable, but the inclusion of contextual in<strong>for</strong>mation allows the system to operate<br />
better or more appropriately. Additionally, context-awareness enables the system to<br />
give improved responses to its use. These characteristics emphasize the existence of<br />
both functional and non-functional requirements in a modern context-aware system.<br />
[75]<br />
Context-aware systems in that past have largely been either tightly coupled<br />
comprehensive software packages, middleware software geared toward application<br />
integration or framework plat<strong>for</strong>ms created <strong>for</strong> a specific programming language or<br />
type of device. [75] One example of the latter is the ContextPhone software plat<strong>for</strong>m<br />
[68], which is a set of open source C++ libraries that run on mobile phones using<br />
the Symbian OS and Nokia S60 plat<strong>for</strong>m. Another similarly focused framework is<br />
the Java Context Awareness Framework (JCAF) [6], which has a rigid Java-based<br />
architecture, programming model and infrastructure. Context-aware middleware<br />
has been a popular research topic due to the looser coupling of software components<br />
it provides. [19] It also enables the integration of various external services and<br />
applications, which decreases development time, workload and burden on developers.<br />
[46]<br />
2.4 Context-aware Mobile Applications<br />
During the last decade, mobile phones have become a ubiquitous and natural extension<br />
of personal computing. Faster processors, larger memory, longer-life batteries<br />
and newly emerging input, output and networking technologies help to close the gap<br />
between various mobile devices. [45] These capabilities combined with the ubiquitousness<br />
and proximity of mobile phones and the dynamic nature of users’ lives<br />
has created a need <strong>for</strong> situation-dependent and context-aware mobile applications.<br />
[11, 44, 62]<br />
The emergence and deployment of <strong>Web</strong> 2.0 and applications harnessing its advantages<br />
have also contributed to the growing interest in context-aware mobile applications.<br />
[11, 44, 45] <strong>Web</strong> 2.0 is a concept that consists of wielding the web as<br />
a plat<strong>for</strong>m based on user co-development and data creation in which applications<br />
are services as opposed to products. The concept also emphasizes lightweight programming<br />
models in addition to device and plat<strong>for</strong>m independence. [44, 59] The<br />
essence of the <strong>Web</strong> 2.0 concept can be condensed into services that get better the<br />
5
more people use them. [44, 60]<br />
Recently, however, the founder of the term elaborated the definition by stating,<br />
“<strong>Web</strong> 2.0 is all about harnessing collective intelligence.” He also recognized that<br />
collective intelligence applications rely on real-time understanding, management of<br />
and response to user-generated data. This data is no longer generated exclusively<br />
by manual keyboard input but, as is increasingly often the case, automatically via<br />
hardware and software sensors. [60]<br />
2.5 Mobile Positioning Technologies<br />
Currently, there are various technologies available to calculate the location of mobile<br />
devices. The most prevalent positioning technology is satellite positioning using the<br />
Global Positioning System (GPS) or Assisted GPS (A-GPS). [12, 77] GPS relies on a<br />
system of satellites orbiting the Earth to calculate the position of a mobile device on<br />
the Earth’s surface. Each GPS satellite transmits a low-power, ultra-high-frequency<br />
radio signal which a GPS-enabled device receives and translates into coordinates.<br />
A-GPS decreases the burden of calculating a mobile device’s coordinates by utilizing<br />
the location of cellular base stations to speed up GPS signal acquisition. [12]<br />
Due to the structure of mobile phone networks, a mobile network operator is<br />
constantly aware of or could easily find out the location of a particular mobile phone.<br />
A mobile phone is connected to one or more cell towers when it is operational and as<br />
the locations of these static cell towers are known, the network operator can deduce<br />
the relative location of each mobile phone based on which towers it is connected to.<br />
[12] The various network enabled location technologies include the a<strong>for</strong>ementioned<br />
Cell-ID and Wi-Fi triangulation techniques. [12, 77] Wi-Fi triangulation, which<br />
uses radio waves <strong>for</strong> high-speed data transfer over short distances [26], exploits<br />
the distance of a mobile device from Wi-Fi access points to calculate the device’s<br />
coordinates.<br />
6<br />
Figure 1: Google Maps, Yahoo! Maps and OpenStreetMap, respectively, are existing web mapping<br />
services. Google and Yahoo represent the commercial sector and OpenStreetMap is an open<br />
source option. These images are screenshots taken from a mobile phone.
2.6 Mapping <strong>Service</strong>s<br />
Geo-mashups, which are applications that combine mapping services with data from<br />
external sources [11, 16], provide a simple, easy and effective way to illustrate and<br />
convey geographically pertinent in<strong>for</strong>mation. Not surprisingly, the web application<br />
that heralded the consumer web mashup market was one that combined housing<br />
listings with mapping services [67] to provide an interactive map with georeferenced<br />
markers indicating the location of each apartment. [16, 23]<br />
There are currently several freely available consumer mapping services to choose<br />
from, such as Google Maps [34] and Yahoo! Maps [87]. A popular open source<br />
alternative is the OpenStreetMap mapping service combined with OpenLayers user<br />
interface software [57, 58]. These existing mapping services, see Figure 1 <strong>for</strong> mobile<br />
screenshots of each, provide users with quick and easy access to maps and mapping<br />
interfaces through public web APIs.<br />
2.7 Sample Implementations<br />
This section reviews existing web applications, that embody and utilize the theoretical<br />
topics discussed in the previous section. The examples include a real-world<br />
web application and two research-oriented mobile web applications. At the time<br />
this thesis was written, the applications mentioned in this section exemplify the<br />
state-of-the-art in context-aware and mobile web applications.<br />
2.7.1 Mozilla Open <strong>Web</strong> Applications<br />
Mozilla Labs has recently released an architecture <strong>for</strong> what they call Open <strong>Web</strong> Applications.<br />
[51] Their applications harness standard web technologies and can run<br />
in any modern web browser on either desktop or mobile plat<strong>for</strong>ms. The majority of<br />
the Open <strong>Web</strong> App’s features are enabled by HTML5, which is the latest version of<br />
the core language of the World Wide <strong>Web</strong>. [81] <strong>Web</strong> browser provided local storage,<br />
offline access to applications and data, geolocation services and rich graphics capabilities<br />
are just a few of the new properties specified in HTML5 that are employed<br />
in Mozilla’s Open <strong>Web</strong> Applications. [51]<br />
Open <strong>Web</strong> Applications augment the features provided by HTML5 with easy<br />
launching, explicit installation flow and proof of purchase authentication. To use<br />
an Open <strong>Web</strong> Application a user has only to browse an online application store or<br />
directory, select one to install, provide possible payment in<strong>for</strong>mation and launch the<br />
installed application from a dashboard that holds all his or her applications. An<br />
application dashboard (Figure 2) is an HTML5 enabled rich user interface through<br />
which a user manages, browses and launches his or her installed applications. In<br />
addition to the dashboard, several other components are used in conjunction with<br />
Open <strong>Web</strong> Applications. Each application must have an application manifest, which<br />
describes the location, requirements and capabilities of that application. A clientside<br />
application repository contains a trusted collection of the manifests from each<br />
of the user’s installed applications. Finally, each Open <strong>Web</strong> Application needs to<br />
publish a method to install that application into a user’s repository. [51]<br />
7
8<br />
Figure 2: The Mozilla Open <strong>Web</strong> Application Dashboard provides an interface <strong>for</strong> users to<br />
manage, browse and launch their installed applications. [51]<br />
Although there are currently no existing context-aware Open <strong>Web</strong> Applications,<br />
the HTML5 specification [81] combined with the W3C Permissions <strong>for</strong> Device API<br />
Access working draft [78] provide a suitable basis <strong>for</strong> such future work and will<br />
undoubtedly facilitate their appearance. [50]<br />
2.7.2 Lively <strong>for</strong> Qt<br />
Lively <strong>for</strong> Qt is a Javascript-based application plat<strong>for</strong>m <strong>for</strong> both web-based and<br />
standalone mobile web applications and mashups. [49] A web mashup is a web<br />
application that is created by combining content, presentation or functionality from<br />
existing web sources. Mashups serve a specific and sometimes brief need and they<br />
are usually composed of the latest and most accessible web technologies. [89]<br />
As the name suggests, Lively <strong>for</strong> Qt runs on top of the cross-plat<strong>for</strong>m application<br />
framework Qt. Qt is a mature and well-documented framework that supports a rich<br />
set of APIs, widgets and tools that permit the creation and multi-system deployment<br />
of rich web-enabled applications. Lively <strong>for</strong> Qt consists of three major components:<br />
a Javascript engine built around the QtScript module, desktop quality graphics<br />
implemented with Qt’s GUI modules, and asynchronous HTTP networking using<br />
the QtNetwork module. [53]<br />
Mikkonen et al. have built a number of web application mashups using the Lively<br />
<strong>for</strong> Qt plat<strong>for</strong>m. Two mashups that utilize the Google Maps API are QtWeather-<br />
Cameras (Figure 3) and QtMapNews (Figure 4). QtWeather Cameras superimposes<br />
live road weather camera in<strong>for</strong>mation and images over a Google Maps route to supply<br />
the user with real-time road condition data. QtMapNews displays geotagged<br />
news items, natural disasters and national incidents and emergencies compiled from<br />
RSS feeds. An example of a non-map-based application is QtFlickr, an animated<br />
Flickr photo viewer that represents current Twitter trends. The idea behind Qt-<br />
Flickr is to provide a non-textual medium to relate current events and microblog<br />
topics. [49]
9<br />
Figure 3: QtWeatherCameras is a mashup web application built with the Lively <strong>for</strong> Qt Javascriptbased<br />
plat<strong>for</strong>m. The mashup combines Google Maps’ route guide with real-time road condition<br />
data and images. [65]<br />
Figure 4: QtMapNews is a mashup web application built with the Lively <strong>for</strong> Qt Javascript-based<br />
plat<strong>for</strong>m. The mashup combines Google Maps with geotagged RSS news feeds from various sources.<br />
[64]<br />
2.7.3 xFace<br />
xFace is a web application engine developed specifically with lightweight crossplat<strong>for</strong>m<br />
characteristics. It provides programmers with a web runtime environment<br />
that runs on multiple mobile devices and operating systems. xFace also serves as a<br />
lean mobile web browser or mobile desktop environment. The plat<strong>for</strong>m emphasizes<br />
the use of open standards and consequently mainly applies W3C approved standards<br />
such as HTML, CSS, AJAX and DOM. xFace is made even lighter by its edited tag<br />
library containing merely 27 tags and its compact code, which takes up only 8MB<br />
on a mobile phone memory card. [43]<br />
xFace enables context-aware applications via a Phone <strong>Service</strong>s API, which provides<br />
access to mobile phone services through Javascript functions and parameters.<br />
The Phone <strong>Service</strong>s API allows web applications to e.g. initiate phone calls, access<br />
contact and calendar in<strong>for</strong>mation and control multimedia capabilities such as the<br />
camera. [43]<br />
The xFace development team offer three use case scenarios <strong>for</strong> the plat<strong>for</strong>m:<br />
Restaurant Searching, Mobile Stock Client and Mobile Reader, of which only the
<strong>for</strong>mer exhibits context awareness. Restaurant Searching (Figure 5) utilizes GPS<br />
in<strong>for</strong>mation from the user’s mobile device to locate restaurants near the user’s location.<br />
The user may then choose to reserve a table at one of the recommended<br />
restaurants by allowing the application to access the mobile device’s Telephony API.<br />
The Mobile Stock Client and Mobile Reader demonstrate the media capabilities of<br />
the xFace plat<strong>for</strong>m by drawing graphics and playing streaming audio online. [43]<br />
10<br />
Figure 5: Restaurant Searching is a prototype application created with the lightweight crossbrowser<br />
web application plat<strong>for</strong>m xFace. [43]
3 Requirements <strong>for</strong> a <strong>Web</strong>-based Mobile <strong>Service</strong><br />
<strong>Plat<strong>for</strong>m</strong><br />
The design of the m.HUBI <strong>Plat<strong>for</strong>m</strong> begins by defining the functional and nonfunctional<br />
requirements <strong>for</strong> a mobile web application plat<strong>for</strong>m. The specifications<br />
support consequent structural and implementation decisions regarding technology<br />
frameworks, architecture configurations and interface layouts. This section first<br />
outlines the functional requirements of a mobile web application plat<strong>for</strong>m, then the<br />
non-functional requirements followed by several service-specific requirements. All of<br />
the requirements explicated in this chapter are labeled <strong>for</strong> ease of reference.<br />
The functional requirements listed in section 3.1 are specifications <strong>for</strong> operational<br />
plat<strong>for</strong>m characteristics and qualities which are necessary <strong>for</strong> the usage and<br />
deployment of plat<strong>for</strong>m-supported applications. Functional requirements relate to<br />
concerns regarding the literal functionality of software whereas non-functional requirements<br />
are defined as attributes of or constraints on a software system. [15] The<br />
final service-specific requirements in section 3.3 outline several plat<strong>for</strong>m applicationspecific<br />
functional requirements, which are more localized requirements than the<br />
plat<strong>for</strong>m-wide functional requirements listed in section 3.1. The requirements listed<br />
in this section are determined in part by best practices gathered from literature and<br />
in part by HUBI.mobi Project Management.<br />
3.1 Functional Requirements<br />
The functional requirements specified <strong>for</strong> a web-based mobile application plat<strong>for</strong>m<br />
are listed in Table 1. The requirements itemized in this section were dictated by<br />
the initial plat<strong>for</strong>m characteristics specified by the HUBI.mobi Project Management.<br />
The project goals maintained that the mobile application plat<strong>for</strong>m needed to<br />
be situation-sensitive, personalized, and able to ingest data from external sources.<br />
The subsequent functional requirements specified <strong>for</strong> such an application plat<strong>for</strong>m<br />
were R1: Location-awareness, R2: Context-awareness, R3: Data Input Interfaces, R4:<br />
Map,R5: User Profile and R6: User Activity Tracking.<br />
R1: Location-awareness<br />
Owing to the non-stationary nature of mobile devices, location of a mobile phone<br />
user can change frequently and is a potentially valuable in<strong>for</strong>mation source. [38]<br />
Location in<strong>for</strong>mation can be utilized to show a user his or her location in relation<br />
to the world, as a data source <strong>for</strong> location-based services such as routing or to find<br />
and indicate relevant or interesting places or things in the user’s vicinity.<br />
Being location-aware is one of the main advantages modern mobile devices have<br />
over desktop and laptop Internet devices. Although coordinates are in<strong>for</strong>mative to<br />
a geolocation computer system, they are quite vague to people. In order to translate<br />
geocoordinates into a human-readable <strong>for</strong>m, a street address <strong>for</strong> example, a process<br />
called reverse geocoding is required. Reverse geocoding trans<strong>for</strong>ms a latitude and<br />
longitude coordinate pair into the corresponding street address and city [18].<br />
11
12<br />
Table 1: The functional requirements defined <strong>for</strong> a web-based mobile service plat<strong>for</strong>m are R1:<br />
Location-awareness, R2: Context-awareness, R3: Data Input Interfaces, R4: Map,R5: User Profile<br />
and R6: User Activity Tracking.<br />
No. Requirement Description<br />
Functional Requirements<br />
R1 Location-awareness Ability to ascertain a mobile device’s location in geographic<br />
latitude–longitude coordinate pairs via positioning technologies.<br />
R2 Context-awareness Ability to automatically collect, interpret and utilize situationsensitive<br />
in<strong>for</strong>mation regarding a usage scenario.<br />
R3 Data Input Interfaces Provision of standards-based mechanisms and uni<strong>for</strong>m access<br />
points to support the ingestion of data from external sources.<br />
R4 Map Ability to provide users with visual in<strong>for</strong>mation regarding one’s<br />
location and show the locations of other persons or places of<br />
interest.<br />
R5 User Profile <strong>Plat<strong>for</strong>m</strong> supports the creation, preservation and retrieval of individual<br />
user accounts and personal account in<strong>for</strong>mation. Used<br />
to provide users with subjective service content.<br />
R6 User Activity Tracking Ability to collect and analyze user behavior and actions while<br />
using plat<strong>for</strong>m services.<br />
R2: Context-awareness<br />
Gartner [31] stipulates that in the coming years users will increasingly presume that<br />
their in<strong>for</strong>mation and experiences will follow them around, which mobile technologies<br />
will provide the baseline <strong>for</strong>. This type of situation-sensitive and unique behavior<br />
is called context-awareness (see section 2.3) and it is especially useful in mobile<br />
scenarios. The organic evolution from mobile applications to context-aware mobile<br />
applications has a basis in the needs and habits a user exhibits while acting in the<br />
mobile environment. [4] For example, mobile phones are almost always switched<br />
on, they follow the user closely throughout the day in multiple situations and at<br />
different times and they are often personalized by their owners in ways that give<br />
insight into the personality of the user. [68]<br />
The inclusion of context-sensitive data into an application provides the user<br />
with added value and an more intuitive user experience. The automatic capture<br />
and application of contextual in<strong>for</strong>mation eases the burden on users to manually<br />
input in<strong>for</strong>mation regarding their use case. [44] For instance, a mobile phone user’s<br />
availability status is useful in<strong>for</strong>mation and, coincidentally, relatively easy to automatically<br />
acquire using the mobile phone’s built-in calendar, assuming that the user<br />
has input his or her appointments. Conversely, this in<strong>for</strong>mation could be difficult<br />
or at least intrusive to acquire manually from the user.<br />
Contextual in<strong>for</strong>mation can be used, <strong>for</strong> example, to provide users with unaided<br />
suggestions and guided interactions. [31] Unaided suggestions rely on previously<br />
gained insight into a user’s preferences and habits based on explicitly given personal<br />
in<strong>for</strong>mation and implicitly derived personal interests and affinities. Guided interactions<br />
are based more on situational in<strong>for</strong>mation and probabilities than personalized
data. [30] An example of a guided interaction could be, <strong>for</strong> instance, when a user<br />
is reading a description of an ongoing event the application might ask the user if<br />
he or she would like routing in<strong>for</strong>mation to that event or when a user is scrolling<br />
financial news headlines during work hours the news application might provide only<br />
business-related news and filter out entertainment and recreational news headlines.<br />
R3: Data Input Interfaces<br />
The nature of the m.HUBI <strong>Plat<strong>for</strong>m</strong> is to integrate various external data providers’<br />
in<strong>for</strong>mation in a manner similar to how a mashup service operates. A web mashup is<br />
a web service that integrates existing web applications, websites and web accessible<br />
data sources into a new web service or website. [48] The most effective way to<br />
assimilate data in this way is to provide data input interfaces in the <strong>for</strong>m of a web<br />
API. Data input interfaces are critical to allow external data sources and providers<br />
a uni<strong>for</strong>m access point through which they can upload their data to the plat<strong>for</strong>m or<br />
through which the plat<strong>for</strong>m can access external data sources. [11]<br />
The implemented interfaces should support at least one standard web data exchange<br />
<strong>for</strong>mat, such as XML, JSON, or Really Simple Syndication (RSS) as well as<br />
one or more data exchange protocols such as HTTP and FTP. [11, 86] The supported<br />
data <strong>for</strong>mats should be standardized or at least widely accepted, lightweight and<br />
preferably XML-based. Utilizing standards-based technologies ensures a reasonable<br />
technology life span and thus a more resilient interface. Supporting lightweight data<br />
<strong>for</strong>mats and exchange protocols minimizes the processing load on the plat<strong>for</strong>m and<br />
facilitates a lean data structure. The predilection <strong>for</strong> XML-based <strong>for</strong>mats stems from<br />
the nature of the web and XML’s design goals that reflect simplicity, non-specificity<br />
and web usability [79].<br />
R4: Map<br />
An interactive map is essential in providing the user with visual in<strong>for</strong>mation regarding<br />
one’s location and showing the locations of other persons or places of interest<br />
(see section 2.6). It is also required in a number of plat<strong>for</strong>m services, including the<br />
Journey Planner (see R11: Journey Planner on page 18). Furthermore, as locational<br />
in<strong>for</strong>mation lays the foundation <strong>for</strong> the m.HUBI <strong>Plat<strong>for</strong>m</strong>’s context-aware features<br />
(see section R2: Context-awareness) it is necessary to facilitate the visualization<br />
and presentation of this context to the user, <strong>for</strong> which the logical medium is a map.<br />
R5: User Profile<br />
In addition to anonymous usage without account login, the m.HUBI <strong>Plat<strong>for</strong>m</strong> should<br />
also allow the creation, preservation and retrieval of individual user accounts and<br />
personal account in<strong>for</strong>mation. A user profile facilitates features and services such<br />
as Bookmarks and Recommendations (see R13: Recommender on page 20). Bookmarks<br />
are places, events, persons, games, etc. that are frequently used or accessed in<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong> supported services. A user’s bookmarks are stored in a database,<br />
13
from which they are retrieved when a user accesses his or her account. Recommendations<br />
are unique and personalized suggestions or data and service filtering<br />
per<strong>for</strong>med to provide a user with subjective service content.<br />
User profile in<strong>for</strong>mation includes demographic data gained from explicit user input<br />
such as a user’s e-mail address, interests, service settings, etc. as well as implicitly<br />
gained insight into a user’s preferences based on service usage habits (see R6:<br />
User Activity Tracking on page 14) and attention distribution. The in<strong>for</strong>mation<br />
contained in a user profile combined with locational and contextual data gathered<br />
enable the provision of personalized and situation-specific services. [24] Although<br />
user profiles often enrich, focus and personalize user experience, users can also be<br />
wary of registration unless they are convinced it provides substantial added value<br />
and the collection and use of their personal in<strong>for</strong>mation is justified and protected.<br />
[28] Offering anonymous access, partial or unlimited, to a website or service can<br />
justify the need <strong>for</strong> user registration and ensures that users that make the ef<strong>for</strong>t to<br />
create an account are committed users. [29]<br />
R6: User Activity Tracking<br />
User activity tracking is the collection and analysis of user behavior and actions on<br />
websites or single web pages. User activity tracking enables the personalization of<br />
the corresponding websites or web pages by adapting its content or services to the<br />
needs of a particular user or type of user. [24] The type of in<strong>for</strong>mation gathered<br />
includes usage data such as a visitor’s IP address, the time and date of access,<br />
pages and services accessed and the referrer’s URL address. Usage data is the type<br />
of in<strong>for</strong>mation normally automatically included in a web server’s access log and<br />
subsequently rarely requires extensive development.<br />
User activity tracking data can be applied to various uses such as user profiling,<br />
website usage statistics <strong>for</strong> marketing or business purposes, usability testing and<br />
website content adaptation. User profiling is the process of applying the gathered<br />
in<strong>for</strong>mation to create categories of individual or groups of users that share similar<br />
characteristics, behaviors or interests. Usage statistics are strong analytical tools<br />
<strong>for</strong> supporting marketing or business decisions as they contain objective in<strong>for</strong>mation<br />
regarding customer needs and habits. Usability testing can greatly benefit from realworld<br />
usage statistics, because they are unobtrusive to collect and can be integrated<br />
at a very early stage in the development cycle. <strong>Web</strong>site content adaptation is the<br />
dynamic modification of a website’s content based on the changing demands and<br />
needs of the user. [5]<br />
The m.HUBI <strong>Plat<strong>for</strong>m</strong> would employ user activity tracking mainly <strong>for</strong> usage<br />
statistics analysis and user profiling combined with content adaptation in the <strong>for</strong>m of<br />
the Recommendation service (see R13: Recommender on page 20). From a technical<br />
standpoint, the m.HUBI <strong>Plat<strong>for</strong>m</strong> should facilitate the tracking of almost any user<br />
activity including time-sensitive user location in<strong>for</strong>mation. However, due to privacy<br />
issues, the collection of any personally identifiable in<strong>for</strong>mation including locationand<br />
time-specific data would need to be anonymized to the extent that individual<br />
users are not identifiable or their movements traceable. The m.HUBI <strong>Plat<strong>for</strong>m</strong> must<br />
14
15<br />
also comply with applicable privacy laws and data protection acts [63].<br />
3.2 Non-Functional Requirements<br />
The non-functional requirements specified <strong>for</strong> a web-based mobile application plat<strong>for</strong>m<br />
are listed in Table 2. The requirements itemized in this section were mainly<br />
gathered from best practices in literature. These requirements describe attributes<br />
of the plat<strong>for</strong>m as opposed to the functional requirements specified in the previous<br />
section 3.1, which describe functionalities of the plat<strong>for</strong>m. The subsequent<br />
non-functional requirements specified <strong>for</strong> such an application plat<strong>for</strong>m were R7:<br />
Reusability, R8: Cross-device Functionality, R9: Scalability and R10: Multilingual<br />
Content Support.<br />
Table 2: The non-functional requirements defined <strong>for</strong> a web-based mobile service plat<strong>for</strong>m are R7:<br />
Reusability, R8: Cross-device Functionality, R9: Scalability and R10: Multilingual Content<br />
Support.<br />
No. Requirement Description<br />
Non-functional Requirements<br />
R7 Reusability Design architecture is hierarchical and consists of small modular<br />
components. Elements are modular, loosely coupled and<br />
lightweight.<br />
R8 Cross-device Functionality <strong>Plat<strong>for</strong>m</strong> is operating system, device and plat<strong>for</strong>m independent<br />
or at least provides mechanisms and processes <strong>for</strong> decreased<br />
dependence.<br />
R9 Scalability System has the ability to gracefully cope with a growing number<br />
of components or increased workload and is capable of extensibility<br />
and enlargement.<br />
R10 Multilingual Content Support<br />
<strong>Plat<strong>for</strong>m</strong> supplies tools and processes <strong>for</strong> management and implementation<br />
of multilingual content.<br />
R7: Reusability<br />
The most fundamental and critical non-functional requirement of the mHUBI application<br />
plat<strong>for</strong>m is reusability. In order to create a widely applicable and easily<br />
adaptable plat<strong>for</strong>m that is conducive to rapid development and deployment, the<br />
architecture should be hierarchical and consist of small modular components. The<br />
more generic and mutually independent architectural components are the easier<br />
they are to integrate and aggregate into other applications or architectures. [69, 88]<br />
Additionally, the initial mHUBI <strong>Plat<strong>for</strong>m</strong> is more likely to evolve organically and<br />
spontaneously when its original design and structure is not a constraint. Thus<br />
interdependence of architectural elements would greatly hinder the probability of<br />
widespread assimilation.<br />
Designing functional components as modular, loosely coupled and lightweight<br />
elements supports their reusability and facilitates the cross-plat<strong>for</strong>m nature of the
entire application. [73] Modularity also increases the entire system’s possibility <strong>for</strong><br />
extensibility in future. [14]<br />
R8: Cross-device Functionality<br />
Mobile web applications are generally easier and faster to develop and deploy than<br />
native mobile applications. [32, 33, 71] <strong>Web</strong> technologies are intended and built to<br />
be operating system, device and plat<strong>for</strong>m independent. The <strong>Web</strong> 2.0 tenet goes so<br />
far as to state that the “web is a plat<strong>for</strong>m” [59]. This holds true to a certain extent;<br />
web technologies (XML, HTML, CSS, etc.) are structurally identical irrespective<br />
of the device or operating system accessing it. However, web pages still need a<br />
medium to display them to users and when it comes to the medium of choice,<br />
Internet browsers, they un<strong>for</strong>tunately interpret web pages differently. [71] That is<br />
why cross-browser functionality and uni<strong>for</strong>m presentation is a high priority when<br />
designing and constructing web pages and especially web applications.<br />
The realm of mobile web browsers has even more variation than desktop web<br />
browsers. Currently, there are two types of mobile web browsers available <strong>for</strong> smartphones:<br />
full browsers, also called direct delivery browsers, and mini browsers, also<br />
called server transcoding browsers. [37, 66] Full browsers have the same functionalities<br />
and execution as desktop web browsers. They download and render web pages<br />
directly from a web server or local file as is. Full browsers facilitate desktop-quality<br />
rendering, at least from a browser standpoint, but they may suffer from memory<br />
constraints resulting from the mobile plat<strong>for</strong>m they run on. Mini browsers employ<br />
an intermediate proxy server to request web pages on its behalf. The proxy server<br />
renders and compresses the response and then sends the converted web page to the<br />
mobile client browser. The benefit of mini browsers is their low memory requirement<br />
and the reduced data traffic involved, however, because they do not support clientside<br />
interactivity Javascript is effectively run on the proxy server. [66] These added<br />
constraints of mobile web browsers further emphasize the need <strong>for</strong> cross-browser<br />
functionality of mobile web applications.<br />
R9: Scalability<br />
Scalability refers to a number of system qualities and characteristics such as the<br />
ability of a system to gracefully cope with a growing number of components or<br />
increased workload and to be capable of extensibility and enlargement. [10] In<br />
web-based systems, scalability and extensibility are often cited as separate system<br />
qualities. In those instances, scalability refers to the system’s capacity to respond<br />
to simultaneous requests and an increased processing workload. [14] Extensibility is<br />
distinguished from scalability as supporting the evolution and change of what was<br />
originally designed. [27] An extensible context-aware system, <strong>for</strong> instance, facilitates<br />
the addition of new services, new context sensors and context data sources. [14]<br />
The drawbacks of non-scalability include delays or disconnects in response time,<br />
raised data processing demands, space or memory constraints and more expensive<br />
development ef<strong>for</strong>ts. Scalability can similarly be inhibited by shortsighted data<br />
16
structure and algorithm design. Extensibility af<strong>for</strong>ds the supplementation and replacement<br />
of system requirements in correspondence with user needs. [10]<br />
R10: Multilingual Content Support<br />
Modern websites and web applications need to facilitate global usage and consequently,<br />
offer content in multiple languages. Previously offering web content in<br />
English was seen as catering to an international audience, but with the advancement<br />
of content management systems and other facilitative technologies that is no<br />
longer sufficient [40]. In order to maintain multilingual versions of a single website,<br />
content and structure related issues need to be addressed. Content management<br />
and localization are the most critical factors when dealing with multilingual web<br />
content, but website naming and layout organization are also relevant structural<br />
factors [40].<br />
Management of multilingual content is especially pertinent to the m.HUBI <strong>Plat<strong>for</strong>m</strong>,<br />
but localization issues should also receive due diligence. Proprietary content<br />
and extra-plat<strong>for</strong>m components should also be considered future system elements<br />
requiring multilingual support.<br />
3.3 <strong>Service</strong>-specific Requirements<br />
<strong>Service</strong>-specific requirements specified <strong>for</strong> a web-based mobile application plat<strong>for</strong>m,<br />
which are listed in Table 3, are HUBI.mobi Project Management dictated functional<br />
specifications <strong>for</strong> the plat<strong>for</strong>m. These requirements describe functionalities of specific<br />
services to be provided by and included in the m.HUBI <strong>Plat<strong>for</strong>m</strong>. The first<br />
requirement is a routing service R11: Journey Planner that offers routing, geolocation<br />
and public transit related functionalities. The second requirement is R12:<br />
Events, a service that offers in<strong>for</strong>mation on upcoming and ongoing events which<br />
have been collected from external data sources. The third and final service-specific<br />
requirement is R13: Recommender, a service that provides personalized recommendations,<br />
content and services.<br />
Table 3: The service-specific requirements defined <strong>for</strong> a web-based mobile service plat<strong>for</strong>m<br />
are R11: Journey Planner, R12: Events and R13: Recommender.<br />
17<br />
No. Requirement Description<br />
<strong>Service</strong>-specific Requirements<br />
R11 Journey Planner Provision public transit route options from point to point and<br />
display of route items on a map.<br />
R12 Events Ability to gather and display ongoing and upcoming event data<br />
to user. Events include location in<strong>for</strong>mation and possible semantic<br />
tags.<br />
R13 Recommender Provide users with personalized recommendations, content and<br />
services based on a user’s explicit and implicit usage preferences.
The requirements defined in this section were chosen in part by research and<br />
project goals dictated by HUBI.mobi Project Management and in part by resources<br />
and knowledge available to the project team at the time this thesis work was completed.<br />
Each service-specific requirement answers a real-life user need identified<br />
by the project management team. For instance, R13: Recommender is included<br />
to integrate concurrent textual data mining algorithm development and to provide<br />
the plat<strong>for</strong>m with means to facilitate personalized content. Similarly, R12: Events<br />
serves to provide users with personalized and situation-sensitive content that utilize<br />
individualized recommendations provided by R13: Recommender. Numerous<br />
other service-specific requirements could have been defined, but the ones included<br />
in this section are indicative of the types of services that can be implemented in<br />
plat<strong>for</strong>m-based applications.<br />
R11: Journey Planner<br />
A public transport Journey Planner is a service to be implemented as part of the<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong>. The Journey Planner could initially utilize the web service interface<br />
of the Helsinki Regional Transport Authority (HSL) [39] to provide users with<br />
public transport route in<strong>for</strong>mation in the Helsinki Metropolitan Area. The HSL<br />
interface supports bus, metro, tram, train, ferry and walking transport modes. The<br />
Journey Planner can utilize the user’s current location, which is automatically collected<br />
(see R1: Location-awareness on page 11), as the starting point or destination<br />
<strong>for</strong> a journey. The user can also choose journey departure or destination points from<br />
a list of bookmarked places (see R5: User Profile on page 13) saved to the user’s<br />
profile and only available if the user has logged in.<br />
Journey Planner<br />
18<br />
8:34<br />
Current location:<br />
Kamppi:<br />
Kimmontie 3, Helsinki<br />
Kampin keskus, Helsinki<br />
Departure<br />
Koskelantie crossing<br />
Koskelantie crossing<br />
Maunula<br />
Maunula<br />
Kamppi<br />
Kamppi<br />
Destination<br />
Show route map<br />
Figure 6: Mockups of the Journey Planner service. Left: Initial Journey Planner screen into which<br />
the user inputs departure, destination and time in<strong>for</strong>mation. This scenario is a journey from the<br />
user’s current location to a manually input destination at the current time. Middle: Several route<br />
options are displayed <strong>for</strong> a single journey. Right: Detailed route and transfer in<strong>for</strong>mation <strong>for</strong> a<br />
selected route.<br />
R12: Events<br />
A service to provide ongoing and upcoming events in the Helsinki Metropolitan<br />
Area is included in the m.HUBI <strong>Plat<strong>for</strong>m</strong> specification. The service compiles event
data from various sources and lists them based on user prioritization, user profile<br />
settings and user- and group-specific recommendations (see R13: Recommender on<br />
page 20). Events are categorized according to event type such as theater, museum,<br />
sports, music, etc. and optional user preferences regarding each event type are saved<br />
to the user profile. (Figure 7)<br />
19<br />
Events<br />
Starting soon<br />
Events<br />
Near my location<br />
Starting soon<br />
Ending soon<br />
Figure 7: Mockups of the Events service. Left: Initial Events screen showing in<strong>for</strong>mation of<br />
currently ongoing and upcoming events near the user’s current location in the Helsinki Metropolitan<br />
Area. Middle: Users can sort events based on the event’s location, start time and end time. Right:<br />
Users can save event category related preferences, which are also used to sort events when a user<br />
is logged in.<br />
As mentioned above, Event service data is compiled from various external sources,<br />
which requires an interface <strong>for</strong> the input of event data. In addition to the generic<br />
data <strong>for</strong>mats described in section R3: Data Input Interfaces, several data models and<br />
<strong>for</strong>mats are available that focus solely on event-related data description. Shaw et al.<br />
[72] conducted a survey of existing event models and compared their event representations.<br />
Of the event models Shaw et al. describe, EventsML-G2 best serves the<br />
purposes of the m.HUBI <strong>Plat<strong>for</strong>m</strong>’s needs. Various qualities encourage the adoption<br />
of the EventsML-G2 standard including its machine-readable XML-based <strong>for</strong>mat,<br />
its compliance with the W3Cs Resource Description Framework (RDF) which supports<br />
event-specific semantic annotation and the standard’s extensible nature which<br />
facilitates appending application-specific functionalities. [41]<br />
Pertinent event-related in<strong>for</strong>mation to be included in event source data include:<br />
– title of event,<br />
– organizer of event,<br />
– start time of event,<br />
– end time of event,<br />
– textual description of event,<br />
– language(s) of event and/or of textual description of event,<br />
– location of event expressed as:<br />
– name of event location,<br />
– address of event location or<br />
– geocoordinates of event location,
20<br />
– link to external in<strong>for</strong>mation e.g. event website,<br />
– keywords of event and<br />
– semantic mapping of event to an ontology.<br />
R13: Recommender<br />
A Recommender service is required in the m.HUBI <strong>Plat<strong>for</strong>m</strong> to provide users with<br />
personalized recommendations, content and services. The service will, at minimum,<br />
provide user-specific event listings in the Event service (see R12: Events on page 18)<br />
based on a user’s explicit and implicit usage preferences. Explicit user preferences<br />
are gained through user-solicited profile in<strong>for</strong>mation and implicit user preferences<br />
are acquired with the help of user activity tracking (see R6: User Activity Tracking<br />
on page 14).<br />
Recommendation systems generally fall under one of three categories. Contentbased<br />
recommenders suggest items similar to ones that a user has previously preferred.<br />
Collaborative recommenders rely on the behavior of user groups and suggest<br />
items that other users with similar preferences have liked. The third type of recommendation<br />
system is one that combines content-based and collaborative recommendation<br />
methods. [1]<br />
Disadvantages of purely content-based recommendation systems include limited<br />
content analysis and overspecialization. Limited content analysis is a result of restricted<br />
in<strong>for</strong>mation regarding users and/or item content. The restrictions may<br />
relate to privacy issues limiting personal in<strong>for</strong>mation dissemination and item content<br />
may be difficult or expensive to obtain or item quality may be problematic to<br />
machine-detect. Overspecialization follows from the nature of content-based recommendation<br />
systems. Because the system recommends items with similar content,<br />
there is a risk of it failing to recommend items with dissimilar content but which<br />
are still of interest to the user. [20]<br />
Collaborative recommendation systems do not suffer from the same disadvantages<br />
as content-based recommendation systems because they rely on inter-user<br />
similarity rather than inter-item similarity. However, collaborative recommendations<br />
are not without their own limitations. They must tackle new items, rating<br />
sparsity and new users, the latter of which also plagues content-based recommendation<br />
systems. New items pose a problem because they need to be rated by a<br />
sufficient number of users be<strong>for</strong>e they can be recommended to other users. Rating<br />
sparsity refers to the critical mass of users per item. In a realistic recommender<br />
system, items with few ratings will rarely be recommended unless there exist other<br />
users with nearly identical preferences. Both collaborative and content-based recommendation<br />
methods have a problem determining the preferences of a new user<br />
because that user has yet to rate any items. Usually explicit user input is needed<br />
to provide a basis <strong>for</strong> user recommendations prior to uncovering more insights. [1]
21<br />
4 <strong>Architecture</strong> of the m.HUBI <strong>Plat<strong>for</strong>m</strong><br />
This section describes the architecture of the m.HUBI <strong>Plat<strong>for</strong>m</strong>. It begins with an<br />
overview of the entire plat<strong>for</strong>m and moves on to give more detailed introductions<br />
of server-side components and then client-side elements, respectively. The final<br />
subsection is a use-case scenario starring a fictitious plat<strong>for</strong>m-based web application,<br />
which illustrates the usage of the plat<strong>for</strong>m architecture and its components from a<br />
more practical perspective. The server-side architecture depicted in this section is<br />
implementation-independent, meaning it makes no assumptions or stipulations on<br />
what technologies are used to implement the plat<strong>for</strong>m itself. However, use of the<br />
optional content structure templates described in section 4.5 require the plat<strong>for</strong>m<br />
server to run Java programs and support Java Server Pages technology.<br />
4.1 <strong>Architecture</strong> Overview<br />
The m.HUBI <strong>Plat<strong>for</strong>m</strong> is a web server and web application client framework. The<br />
<strong>Plat<strong>for</strong>m</strong> provides the foundation, structure and means <strong>for</strong> building, maintaining<br />
and developing context-aware user-specific mobile web applications. The m.HUBI<br />
<strong>Plat<strong>for</strong>m</strong> Server consists of an application server (see section 2.1), one or more<br />
databases, a Recommender <strong>Service</strong> and several auxiliary components. The m.HUBI<br />
<strong>Plat<strong>for</strong>m</strong> Client embodies a Javascript API as well as content structure and layout<br />
templates.<br />
As the diagram in Figure 8 indicates, the m.HUBI <strong>Plat<strong>for</strong>m</strong> Server has several<br />
subcomponents. Arguably the more important of these components are the<br />
databases and the complementary Database Management module. The databases<br />
store data which is processed, derived from or utilized in m.HUBI <strong>Plat<strong>for</strong>m</strong> Client<br />
applications. Database data ranges from basic user in<strong>for</strong>mation such as usernames,<br />
email addresses and service profiles to event data provided by or gathered from external<br />
data sources (see section 3.1). The Database Management module ensures<br />
the accessibility, validity and continuity of all data kept in the databases.<br />
A mandatory element to any service that provides registration and user login<br />
is an Identity and Authorization Management module. This module is responsible<br />
<strong>for</strong> ensuring secure access, transaction consistency and isolation of individual<br />
entries of a database containing username and password in<strong>for</strong>mation. The Recommender<br />
<strong>Service</strong> deployed as part of the m.HUBI <strong>Plat<strong>for</strong>m</strong> Server utilizes user<br />
proclivity to produce personally valid content (see section 3.3). The Recommender<br />
harnesses both straight<strong>for</strong>ward input gathered from the users themselves and tacit<br />
user preferences gained from monitoring user behavior and tracking user activity<br />
(see section 3.1). Support functions are used by internal <strong>Plat<strong>for</strong>m</strong> server processes<br />
to per<strong>for</strong>m administrative tasks and maintain log files, <strong>for</strong> example. These functions<br />
run in the background and are not visible or accessible to plat<strong>for</strong>m clients.<br />
Figure 8 contains two external components that are not internal elements of the<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong>, but are essential to its operation. The first such component<br />
represents external web services that the plat<strong>for</strong>m queries <strong>for</strong> in<strong>for</strong>mation, such<br />
as map images from a mapping service and route options from a public transit
22<br />
Javascript API<br />
m.HUBI PLATFORM<br />
CLIENT-SIDE<br />
PROPRIETARY CLIENT<br />
WEB APPLICATION CLIENT<br />
HTTP<br />
GET / POST<br />
request<br />
HTTP<br />
GET / POST<br />
response<br />
(XML data <strong>for</strong>mat)<br />
EXTERNAL<br />
WEB SERVICES<br />
Server<br />
HTTP<br />
GET / POST<br />
(XML<br />
data <strong>for</strong>mat)<br />
EXTERNAL<br />
DATA SOURCES<br />
Databases<br />
Figure 8: The m.HUBI <strong>Plat<strong>for</strong>m</strong> is a web application framework complete with server-side and<br />
client-side components. The plat<strong>for</strong>m queries external web services <strong>for</strong> application content such as<br />
map images and other mashup components and receives or retrieves XML <strong>for</strong>matted data, such as<br />
Events, from external sources. Data is passed between the the server and client sides and between<br />
the server and external services and sources via HTTP GET and POST requests and responses.<br />
The <strong>Plat<strong>for</strong>m</strong> Client is supplemented with proprietary content, layout and Javascript to create<br />
various mobile web applications.<br />
API. The second external component in the figure represents external data sources<br />
which provide source in<strong>for</strong>mation regarding events or other data utilized by plat<strong>for</strong>m<br />
applications. The data received or retrieved from the external source, depending<br />
on whether the data input is initiated by the external source or by the m.HUBI<br />
<strong>Plat<strong>for</strong>m</strong>, respectively, is saved to the plat<strong>for</strong>m database.<br />
The m.HUBI <strong>Plat<strong>for</strong>m</strong> Client contains the front-end portion of the mobile web<br />
application. It constitutes the user interface of the service and is displayed to<br />
the end-user via a web browser, more specifically a mobile web browser. The
Javascript API contains documented and preprogrammed Javascript functions that<br />
support and implement application activity, interaction and communication with<br />
the m.HUBI <strong>Plat<strong>for</strong>m</strong> Server. The <strong>Plat<strong>for</strong>m</strong> Client also includes templates <strong>for</strong> the<br />
application client’s structure and layout, but these are optional and their inclusion in<br />
a final web application is completely voluntary. The templates are primarily meant<br />
as a starting point <strong>for</strong> new application design and provide cohesive layouts <strong>for</strong> any<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong> implementations.<br />
4.2 Server Core Functions<br />
The m.HUBI <strong>Plat<strong>for</strong>m</strong> Server’s Core functions consist of the Database Management<br />
module, the Identity and Authorization Management module, the Recommender<br />
<strong>Service</strong> and various inconspicuous support functions. The first two modules are<br />
comprehensive monitoring and maintenance tools, which are critical to any web<br />
application that handles database or user account transactions. The Recommender<br />
<strong>Service</strong> facilitates the provision of intuitive and situationally relevant web services<br />
to mobile users. Lastly, support functions play the indispensable role of workhorse<br />
ensuring basic server operation and maintenance.<br />
4.2.1 Database Management<br />
The Database Management module is charged with monitoring and controlling access<br />
to the servers database(s), ensuring that any and all transactions are processed<br />
reliably and securely and multiple simultaneous transactions are effectively queued.<br />
A database transaction is a short sequence of database interactions which represent<br />
one meaningful activity in the user’s environment. The transaction processing module<br />
takes care that all transactions are executed indivisibly, meaning that either all<br />
of the actions are completed successfully or none of them are. [36] Persistence maintenance<br />
is particularly important in web applications because the applications allow<br />
data to be created, transferred and stored in different types of software components<br />
such as Internet browsers, relational databases and web servers. This architecture<br />
complicates the flow of data through the various pieces of software and emphasizes<br />
the need <strong>for</strong> persistent data. Data persistence refers to having the same data available<br />
in the same <strong>for</strong>m throughout and between user sessions. [56] In simplified terms,<br />
the Persistence module enables session data to outlive the session it was created in<br />
and facilitates the reinstatement of that data when the session is ‘resumed’.<br />
4.2.2 Identity and Authorization Management<br />
The Identity and Authorization Management module is responsible <strong>for</strong> ensuring secure<br />
access, transaction consistency and isolation of individual entries of a database<br />
containing username and password in<strong>for</strong>mation. Additionally, the Identity and Authorization<br />
Management module encrypts the passwords be<strong>for</strong>e they are stored to<br />
the database so that they are not saved in plain text <strong>for</strong>mat. This ensures an further<br />
layer of protection in user registration because even if the encrypted passwords were<br />
to fall into the wrong hands, they would be essentially useless. The Identity and<br />
23
Authorization Management module can also be tasked with providing secure connections<br />
between the web application client and server. Such connections are Secure<br />
Sockets Layer (SSL) connections, <strong>for</strong> instance, that use bilateral keys to encrypt and<br />
decrypt transmitted messages. SSL transactions are illegible to anyone other than<br />
its participants unless a third party attains both parties’ keys. [82]<br />
4.2.3 Recommender <strong>Service</strong><br />
The Recommender <strong>Service</strong> (see section 3.3) disseminates user-specific and contextsensitive<br />
content to m.HUBI <strong>Plat<strong>for</strong>m</strong> Clients. Each registered plat<strong>for</strong>m user has<br />
an individual user interest profile associated with their account that is built and<br />
refined each time the user interacts with a plat<strong>for</strong>m service. The Recommender<br />
operates by gathering service content, e.g. event data from external sources, from<br />
the corresponding database. The externally sourced data may contain semantically<br />
relevant category tags indicating what topic group it belongs to e.g. sports, theater,<br />
music or the grouping is programmatically deduced from the data’s description<br />
text. The Recommender <strong>Service</strong> uses a novel keyword extraction algorithm that was<br />
developed as part of the HUBI.mobi Project along side the m.HUBI <strong>Plat<strong>for</strong>m</strong>. The<br />
algorithm specializes in extracting keywords and phrases from short text documents,<br />
such as event descriptions or user created content. The extraction approach is based<br />
on three-level word analysis and clustering and aims to provide in<strong>for</strong>mative terms<br />
<strong>for</strong> data categorization and user modeling. The Recommender <strong>Service</strong> checks the<br />
user’s profile <strong>for</strong> their content preferences and sorts the list in descending order of<br />
preference.<br />
4.2.4 Support Functions<br />
The Support functions component is the grease that makes the gears of the m.HUBI<br />
<strong>Plat<strong>for</strong>m</strong> turn smoothly. It is responsible <strong>for</strong> managing and maintaining auxiliary<br />
processes of the plat<strong>for</strong>m. The elements of the support functions module manage<br />
session cookie generation and validation, external web service connection initiation,<br />
preservation and suspension, and log file creation, population and maintenance.<br />
<strong>Plat<strong>for</strong>m</strong> web application client cookies and external web service connections are<br />
processed on behalf of service components (see section 4.3). Log files keep a record<br />
of all the actions per<strong>for</strong>med in the server and provide written documentation in the<br />
event of an error or undesired action.<br />
4.3 m.HUBI <strong>Plat<strong>for</strong>m</strong> <strong>Service</strong> Components<br />
The m.HUBI <strong>Plat<strong>for</strong>m</strong> Server employs service components to provide m.HUBI <strong>Plat<strong>for</strong>m</strong><br />
Clients with dynamic content and programmatic processing <strong>for</strong> database query<br />
responses. The <strong>Plat<strong>for</strong>m</strong> services are divided into thirteen separate components:<br />
Login, Logout, Location, Map, MyPlaces, POI, Track, Localization, Bookmark,<br />
Friends, User Management, Journey Planner and Feedback. The following sections<br />
describe each a<strong>for</strong>ementioned component in greater detail. Unless otherwise indi-<br />
24
cated, the input and output of the service components are HTTP GET request and<br />
response messages, respectively.<br />
Login<br />
The m.HUBI <strong>Plat<strong>for</strong>m</strong> Login service component grants m.HUBI <strong>Plat<strong>for</strong>m</strong> users access<br />
to their user account and corresponding profile data. The component receives<br />
data in the <strong>for</strong>m of a HTTP POST request (Figure 9). The input request is checked<br />
<strong>for</strong> a textual username and password, which a user has input into the m.HUBI <strong>Plat<strong>for</strong>m</strong><br />
Client browser. The Login component then checks the registered user database<br />
<strong>for</strong> a corresponding username and password. If such a user exists and that user’s<br />
account has the password provided in the request message, the service component<br />
indicates the user is online and creates a timestamped user-specific cookie, which<br />
is subsequently used to automatically identify the user <strong>for</strong> the cookie’s period of<br />
validity—the default duration is 12 hours. The Login component then creates an<br />
XML document containing the login cookie and returns the document as an HTTP<br />
POST response to the requesting client application.<br />
25<br />
m.HUBI PLATFORM<br />
SERVER-SIDE<br />
HTTP GET request<br />
Figure 9: The m.HUBI <strong>Plat<strong>for</strong>m</strong> Server includes <strong>Service</strong> components such as the Login and<br />
Logout components. Both components receive HTTP requests from plat<strong>for</strong>m client applications<br />
and communicate with the server’s registered user database to complete user authorization. A web<br />
cookie is returned to the requesting application when necessary processing is complete.<br />
Logout<br />
The m.HUBI <strong>Plat<strong>for</strong>m</strong> Logout service component changes the status of a registered<br />
plat<strong>for</strong>m user to offline in the client application he or she is currently logged into.<br />
The Logout component receives a request containing a plat<strong>for</strong>m issued cookie, which
corresponds to a single registered user (Figure 9). The component checks and validates<br />
the contents of that cookie and logs the matching user out of the requesting<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong> Client. Finally, the service component creates an empty cookie,<br />
appends it to the response message and returns the it to the requesting m.HUBI<br />
<strong>Plat<strong>for</strong>m</strong> Client application.<br />
Location<br />
The m.HUBI <strong>Plat<strong>for</strong>m</strong> Location service component saves and retrieves database<br />
data disclosing the location of registered plat<strong>for</strong>m users. Additionally, the component<br />
delivers street addresses by reverse geocoding them (see section 3.1) from<br />
satellite coordinates. The component receives a request message containing a plat<strong>for</strong>m<br />
issued cookie and the requesting user’s location as latitude and longitude coordinates<br />
(Figure 10). First, the component checks and validates the contents of<br />
the request cookie. Then, it saves the user’s current location to the user database.<br />
Lastly, the service component completes reverse geocoding on the user’s location<br />
coordinates and returns the result as an HTML document. The reverse geocoding is<br />
actually outsourced to an external web service, so in effect, the service component<br />
calls that external service with the input GPS coordinates and receives a response<br />
indicating the corresponding street address. The HTML document is returned to<br />
the requesting plat<strong>for</strong>m client application as a response.<br />
26<br />
m.HUBI PLATFORM<br />
SERVER-SIDE<br />
Figure 10: The m.HUBI <strong>Plat<strong>for</strong>m</strong> Server includes <strong>Service</strong> components such as the Location and<br />
Map components. Both components receive request messages from plat<strong>for</strong>m client applications and<br />
communicate with external web services to complete their tasks. The Location component returns<br />
a reverse geocoded street address and the Map service returns a map image to the requesting<br />
applications.
27<br />
Map<br />
The Map service component creates and supplies map images to display on m.HUBI<br />
<strong>Plat<strong>for</strong>m</strong> Clients. The component receives a request (Figure 10) containing various<br />
input parameters including user location and map center coordinates, desired image<br />
size and type of map e.g. Journey Planner route map (see section 3.3) or POI map<br />
(see section 3.3). First, the Map component uses the input coordinate parameters<br />
to calculate the needed image tiles and retrieves them from an external mapping<br />
service (see section 3.1). To decrease the time required <strong>for</strong> image retrieval from<br />
external services, the m.HUBI <strong>Plat<strong>for</strong>m</strong> also employs an image cache where it stores<br />
frequently used map tiles. Next, depending on the map type indicated in the input<br />
parameters, the component will draw on top of the map image. For instance, in<br />
the case of a POI map, the service component will draw an icon <strong>for</strong> the POI in its<br />
corresponding coordinates. Finally, the Map component returns the resulting map<br />
image to the requesting plat<strong>for</strong>m client as a response message.<br />
MyPlaces<br />
The MyPlaces service component handles requests pertaining to user-specific and<br />
user-created locations and POIs. POIs saved as MyPlaces indicate frequently visited<br />
or important places to the user such as Home, Work, Mom and Dad’s, etc. The<br />
component receives a request containing a m.HUBI <strong>Plat<strong>for</strong>m</strong> issued cookie and various<br />
input parameters depending on what kind of action is desired (Figure 11). The<br />
MyPlaces service component executes addition, update, deletion, moving and listing<br />
of user-created POIs. MyPlaces POIs are stored, visible and usable only to a single<br />
registered user via that user’s plat<strong>for</strong>m account. A request asking the component <strong>for</strong><br />
a listing of a user’s POIs returns an XML document containing that in<strong>for</strong>mation as a<br />
HTTP GET response. Other requests contain input parameters indicating a POI to<br />
add, delete, update or move upward or downward in the POI listing. The MyPlaces<br />
component completes the requested action and returns a response message with a<br />
textual indication of the success or failure of that action.<br />
POI<br />
The POI service component executes requests regarding location annotated data<br />
such as event happenings that have been integrated into the m.HUBI <strong>Plat<strong>for</strong>m</strong> from<br />
external data sources (see section 3.3). The component receives a request message<br />
(Figure 11) containing parameters indicating what kind of POI data is required,<br />
how that data should be sorted and whether or not the action should be tracked<br />
(see section 3.1). If the request also contains a plat<strong>for</strong>m issued login cookie, the POI<br />
component checks the validity of that cookie and utilizes user profile in<strong>for</strong>mation to<br />
supply focused listings (see section 3.3). The POI service component communicates<br />
with the user and external input databases as well as the Recommender <strong>Service</strong> to<br />
compile a return POI list. The list compilation is gathered as an XML document<br />
and returned to the message originating m.HUBI <strong>Plat<strong>for</strong>m</strong> Client application as a<br />
response.
28<br />
m.HUBI PLATFORM<br />
SERVER-SIDE<br />
Figure 11: The m.HUBI <strong>Plat<strong>for</strong>m</strong> Server includes <strong>Service</strong> components such as the MyPlaces and<br />
POI service components. Both components receive HTTP requests from plat<strong>for</strong>m client applications<br />
and communicate with other server components to complete their tasks. The MyPlaces<br />
component contacts an external web service <strong>for</strong> geocoding assistance as well as the MyPlaces<br />
database to append, update or retrieve POIs. The POI component communicates with the user,<br />
user profile and POI databases as well as the Recommender <strong>Service</strong>. The MyPlaces service component<br />
returns either a success or failure indicator or an XML document, depending on the input<br />
parameters. The POI service component always returns an XML document.<br />
Track<br />
The Track service component handles the logging of usage tracking and communicates<br />
with the Recommender <strong>Service</strong> regarding those actions (see section 3.1). The<br />
component receives a request containing a plat<strong>for</strong>m issued login cookie and parameters<br />
indicating what action is being tracked (Figure 12). Tracking service usage is<br />
used to compile plat<strong>for</strong>m usage statistics and improve personal user recommendations<br />
and user experience in general. For example, each time a user views a list item<br />
in a client application’s service, that viewing triggers a tracking event which in turn<br />
triggers modifications in the lists provided to a particular user by the Recommender<br />
<strong>Service</strong>. The Track service component returns a response indicating if the requested<br />
tracking action was successfully carried out.<br />
Localization<br />
The Localization service component serves language-specific text and content to<br />
client applications if multilingual options are available. Different language options<br />
are handled in the plat<strong>for</strong>m by a separate language cookie, which has a validity<br />
period just as the login cookie does. Various services that offer multilingual content<br />
use the language cookie to determine what content to provide. The Localization<br />
component receives a request containing a plat<strong>for</strong>m issued language cookie (Fig-
29<br />
m.HUBI PLATFORM<br />
SERVER-SIDE<br />
Figure 12: The m.HUBI <strong>Plat<strong>for</strong>m</strong> Server includes <strong>Service</strong> components such as the Track and Localization<br />
service components. Both components receive requests from plat<strong>for</strong>m client applications<br />
and communicate with other server components to complete their tasks. The Track component<br />
returns a success or failure indicator regarding the status of the task it was asked to per<strong>for</strong>m. The<br />
Localization service component returns a plat<strong>for</strong>m issued language cookie as a response message.<br />
ure 12). If the request also contains parameters indicating the client that issued<br />
the request wishes to change the language settings, the component checks the existence<br />
and validity of the input language cookie and saves the language setting to<br />
that user’s profile. The Localization service component then appends the indicated<br />
language as a parameter of the language cookie and returns the amended cookie as<br />
a response to the m.HUBI <strong>Plat<strong>for</strong>m</strong> Client application it emanated from.<br />
Bookmark<br />
The Bookmark service component handles user bookmark related tasks. Bookmarks<br />
on the m.HUBI <strong>Plat<strong>for</strong>m</strong> are similar to web bookmarks, in that a user can bookmark<br />
a personally significant event, POI, place, etc. and save that item to their plat<strong>for</strong>m<br />
profile. The Bookmarks are stored in a database and associated with the user<br />
account that created them. The Bookmark component receives a request (Figure 13)<br />
containing a plat<strong>for</strong>m issued cookie and input parameters indicating whether the<br />
user wants to add or delete a single bookmark or alternatively list all the user’s stored<br />
bookmarks. The service component communicates with the plat<strong>for</strong>m user database<br />
to execute the requested task and returns a response to the m.HUBI <strong>Plat<strong>for</strong>m</strong> Client<br />
application the original request emanated from. Addition and deletion of bookmarks<br />
results in a simple success or failure response and a bookmark list request results in<br />
an XML document containing a list of the requesting user’s stored bookmarks.
30<br />
m.HUBI PLATFORM<br />
SERVER-SIDE<br />
Figure 13: The m.HUBI <strong>Plat<strong>for</strong>m</strong> Server includes <strong>Service</strong> components such as the Bookmark and<br />
Friends service components. Both components receive requests from plat<strong>for</strong>m client applications<br />
and communicate with the User and User Profile Databases to complete their tasks. The Bookmark<br />
and Friends components each return a success or failure indicator regarding the status of the task<br />
it was asked to per<strong>for</strong>m. If the requested action was to list a user’s bookmarks or friends, the<br />
corresponding service component returns the list as an XML document.<br />
Friends<br />
The Friends service component executes requests related to user friends. Similarly<br />
to social networks such as Facebook or Twitter, registered users of m.HUBI <strong>Plat<strong>for</strong>m</strong><br />
can indicate that other registered users are their friends. The Friends component<br />
receives a request message (Figure 13) containing a plat<strong>for</strong>m issued cookie and input<br />
parameters indicating if the user wishes to add or remove a friend, decline a friend<br />
request or simply list that user’s friends. The service component communicates<br />
with the plat<strong>for</strong>m user database, which holds a record of individual user’s friends,<br />
to execute the requested task. The result is a simple success or failure indication<br />
in the cases of friend addition and removal and friend request refusal. When the<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong> Client application has requested a list of user friends, the result<br />
is an XML document listing those friends. The Friends component returns the task<br />
result as a response to the plat<strong>for</strong>m client application the original request emanated<br />
from.<br />
User Management<br />
The User Management service component oversees actions concerning user accounts<br />
and related data. Tasks the User Management component executes include saving<br />
settings to and retrieving data from a user account as well as creating and deleting<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong> user accounts. The service component receives a request that,<br />
barring the creation of a new registered user account, contains a plat<strong>for</strong>m issued
31<br />
m.HUBI PLATFORM<br />
SERVER-SIDE<br />
Figure 14: The m.HUBI <strong>Plat<strong>for</strong>m</strong> Server includes <strong>Service</strong> components such as the User Management<br />
and Journey Planner service components. Both components receive requests from plat<strong>for</strong>m<br />
client applications and communicate with the User Database and External <strong>Web</strong> <strong>Service</strong>, respectively,<br />
to complete their tasks. The User Management service component returns a success or<br />
failure indicator or an XML document depending on the requested action. The Journey Planner<br />
service component returns an XML document containing route in<strong>for</strong>mation.<br />
cookie (Figure 14). The request also contains parameters indicating what duties<br />
the service component should per<strong>for</strong>m. The User Management component communicates<br />
with the plat<strong>for</strong>m user database to retrieve or save data and returns any<br />
response data as an XML document in a response. If no data is being returned to<br />
the requesting m.HUBI <strong>Plat<strong>for</strong>m</strong> Client application, the response simply indicates<br />
the success or failure of the requested task.<br />
Journey Planner<br />
The Journey Planner service component handles communication between m.HUBI<br />
<strong>Plat<strong>for</strong>m</strong> Client applications and the external Journey Planner service (see section<br />
3.3), which is currently implemented by the Helsinki Regional Transit Authority<br />
(HSL). The component receives a request message containing departure and<br />
destination addresses and a departure or arrival time (Figure 14). The Journey<br />
Planner component sends a message to the HSL Journey Planner web service that<br />
contains the service component input parameters. The HSL web service produces<br />
a response containing three complete route options from the given departure point<br />
to the provided destination. The service component parses the HSL web service<br />
response message into an XML document and returns it as a response to the client<br />
application that originally made the service component request.
32<br />
Feedback<br />
The Feedback service component delivers user feedback to the m.HUBI <strong>Plat<strong>for</strong>m</strong><br />
administrators. The component receives user feedback in the <strong>for</strong>m of a HTTP<br />
POST request containing the input entered by the user into the client application<br />
feedback <strong>for</strong>m (Figure 15). The Feedback component checks <strong>for</strong> a plat<strong>for</strong>m issued<br />
cookie and if such a valid cookie is found, indicates that the feedback is from a<br />
registered user. The component then <strong>for</strong>wards the user input as an email to the<br />
plat<strong>for</strong>m administrators and returns an empty HTTP POST response to the client<br />
indicating whether the feedback was successfully processed.<br />
m.HUBI PLATFORM<br />
SERVER-SIDE<br />
<strong>Service</strong> Components<br />
Figure 15: The m.HUBI <strong>Plat<strong>for</strong>m</strong> Server includes <strong>Service</strong> components such as the Feedback and<br />
User Management service components. The Feedback component receives HTTP POST requests<br />
containing textual user feedback from plat<strong>for</strong>m client applications. The User Management component<br />
returns a success or failure indicator indicating if the feedback was <strong>for</strong>warded by email to<br />
plat<strong>for</strong>m administrators.<br />
4.4 Javascript API<br />
This section presents the contents and operations of the m.HUBI <strong>Plat<strong>for</strong>m</strong> Javascript<br />
API. The API consists of seven modules divided according to their functionality. The<br />
following descriptions are not intended as a manual or user guide to web developers<br />
utilizing the m.HUBI <strong>Plat<strong>for</strong>m</strong> <strong>for</strong> application creation or <strong>for</strong> other technical purposes.<br />
This section merely introduces the functions included in the m.HUBI API<br />
and a provides a general overview of their capabilities.
33<br />
m.HUBI Javascript API<br />
Figure 16: The m.HUBI <strong>Plat<strong>for</strong>m</strong> Client includes a Javascript API containing functions and<br />
classes utilized in plat<strong>for</strong>m client applications. The API is divided into seven modules according<br />
to function relativity. The modules are Communication, Foundation, Map, Positioning, Display,<br />
<strong>Service</strong>s and Auxiliary.<br />
4.4.1 Communication Module<br />
The Communication module contains functions that handle communication between<br />
plat<strong>for</strong>m clients and the plat<strong>for</strong>m server. It is an integral part of the API and ensures<br />
that client applications serve users with up-to-date and valid data. The module<br />
also handles the <strong>for</strong>warding of server responses to the correct handler or callback<br />
functions.<br />
The first of the two Communication module functions is xhr, which sends request<br />
messages to the m.HUBI <strong>Plat<strong>for</strong>m</strong> <strong>Service</strong> Components (see section 4.3). The<br />
function creates an XMLHttpRequest and sends it to the URL indicated in url. The<br />
callback parameter indicates the function that will handle the processing of the<br />
returned XMLHttpRequest. The postData parameter contains optional textual data<br />
to send to the server if requestType is POST instead of the default GET.<br />
The second function, parseXMLListener, is a catch-all callback function <strong>for</strong><br />
various xhr function server calls. ParseXMLListener interprets and converts XML<br />
documents into Javascript Objects and <strong>for</strong>wards them to user-defined Javascript<br />
functions <strong>for</strong> display to the user. The function receiving the <strong>for</strong>warded Javascript<br />
Object is determined based on the content of the XML document and type of the<br />
subsequent Javascript Object.<br />
parseXMLListener ( resp )<br />
xhr ( requestType, url, callback, postData )<br />
4.4.2 Foundation Module<br />
The Foundation module contains functions that are generally relevant to the m.HUBI<br />
<strong>Plat<strong>for</strong>m</strong> and Javascript API. The functions carry out fundamental processes such<br />
as login and logout of registered users, saving and updating user settings to the<br />
plat<strong>for</strong>m server as well as displaying and concealing pages on the web application<br />
client. User action tracking (see section 3.1) on plat<strong>for</strong>m clients is facilitated in the<br />
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<br />
track parameter call trackAction internally.<br />
autoLogin()<br />
back()<br />
clearFeedback()<br />
create ( key, value, expireDays )<br />
deleteUser()<br />
destroy ( key )<br />
displayXML ( objArray )<br />
getUserSettings()<br />
hide ( elementId )<br />
login()<br />
loginListener ( resp )<br />
logout()<br />
logoutListener ( resp )<br />
retrieve ( key )<br />
saveProfile()<br />
saveSettings()<br />
sendFeedback()<br />
setDate ( item, addHours, addMinutes )<br />
setHeader ( title, icon )<br />
show ( elementId, type )<br />
showPage ( pageId, title, icon, backPg )<br />
trackAction ( trackable )<br />
34<br />
Foundation Module<br />
autoLogin *<br />
displayXML<br />
logoutListener<br />
setHeader<br />
back<br />
getUserSettings *<br />
retrieve<br />
show<br />
parseXMLListener<br />
clearFeedback<br />
create<br />
hide<br />
login *<br />
saveProfile *<br />
saveSettings *<br />
showPage<br />
trackAction *<br />
xhr<br />
deleteUser *<br />
loginListener<br />
sendFeedback *<br />
destroy<br />
logout *<br />
setDate<br />
Figure 17: The m.HUBI API Foundation module contains functions that are generally relevant to<br />
the plat<strong>for</strong>m. The functions carry out fundamental processes such as login and logout of registered<br />
users, saving and updating user settings to the plat<strong>for</strong>m server and displaying and concealing pages<br />
on the web application client. Functions with an asterisk (*) after their names make a call to the<br />
Communication module’s xhr function.
35<br />
4.4.3 Map Module<br />
The Map module contains functions relevant to the m.HUBI <strong>Plat<strong>for</strong>m</strong> Map service.<br />
The map is used as a visual medium to show users their own location, locations<br />
of POIs, MyPlaces or Journey Planner Routes, RouteLegs or RoutePoints (see section<br />
4.4.6). Map module functions retrieve, display and adjust map images. The<br />
Map module also contains the Javascript class Point, which is used to define single<br />
map points with explicit geo- and screen coordinates. Point instances are used to<br />
precisely indicate e.g. user, POI and Buddy positions on map images.<br />
initializeIphoneMap()<br />
initializeWidgetMap()<br />
mapReset()<br />
panMap ( direction )<br />
panReset()<br />
setMapImage()<br />
setMapImageUrl ( url )<br />
showPoisOnMap ( poiList )<br />
showUserOnMap()<br />
zoomIn()<br />
zoomOut()<br />
zoomReset()<br />
Point(x, y) {<br />
getLat() setLat ( lat )<br />
getLon() setLon ( lon )<br />
getX() setX ( x )<br />
getY() setY ( y )<br />
}<br />
Map Module<br />
initializeIphoneMap<br />
setMapImageUrl<br />
initializeWidgetMap<br />
showPoisOnMap *<br />
mapReset<br />
panMap<br />
showUserOnMap<br />
zoomIn<br />
xhr<br />
panReset<br />
zoomOut<br />
setMapImage<br />
zoomReset<br />
Figure 18: The m.HUBI API Map module contains functions relevant to plat<strong>for</strong>m Map service.<br />
Maps are used as visual media to show users the location of themselves, user friends, POIs,<br />
MyPlaces, etc. In addition to the functions depicted in the figure, the Map module includes a<br />
Javascript Class declaration <strong>for</strong> Point objects. Functions with an asterisk (*) after their names<br />
make a call to the Communication module’s xhr function.
36<br />
4.4.4 Positioning Module<br />
The Positioning module contains functions that are relevant to positioning and geolocation<br />
processes of the m.HUBI <strong>Plat<strong>for</strong>m</strong>. The functions handle acquisition and<br />
evaluation of GPS, Geolocation or widget geocoordinate in<strong>for</strong>mation, depending on<br />
the capabilities of the mobile device and web browser being used. The module also<br />
handles the dissemination and retrieval of that location in<strong>for</strong>mation to and from the<br />
plat<strong>for</strong>m server. Positioning is executed repeatedly at an interval that is set by the<br />
updateTimeout function.<br />
getPositioningStatus()<br />
initializeGPS()<br />
sendLocation()<br />
startPositioning()<br />
stopLocationShare()<br />
stopPositioning()<br />
updateGpsServer()<br />
updateLocation ( mode )<br />
updateTimeout()<br />
Positioning Module<br />
getPositioningStatus<br />
updateGpsServer *<br />
initializeGPS<br />
updateLocation *<br />
sendLocation *<br />
startPositioning<br />
updateTimeout<br />
xhr<br />
stopLocationShare<br />
stopPositioning<br />
Figure 19: The m.HUBI API Positioning module contains functions relevant to positioning<br />
processes of the plat<strong>for</strong>m. The functions handle acquisition and evaluation of GPS, Geolocation<br />
or widget geocoordinate in<strong>for</strong>mation, depending on the capabilities of the mobile device and web<br />
browser being used. The module also handles the dissemination and retrieval of that location<br />
in<strong>for</strong>mation to and from the plat<strong>for</strong>m server. Functions with an asterisk (*) after their names<br />
make a call to the Communication module’s xhr function.<br />
4.4.5 Display Module<br />
The Display module contains functions that detect the screen proportions and characteristics<br />
of the device being used to view a m.HUBI <strong>Plat<strong>for</strong>m</strong> Client application.<br />
<strong>Based</strong> on the in<strong>for</strong>mation gleaned from the device, the module activates the appropriate<br />
CSS file or files. The Display module, if utilized without modifications or<br />
additions, should only be used in conjunction with plat<strong>for</strong>m layout templates (see<br />
section 4.5) as it utilizes and refers to them in the function evaluation.
37<br />
detectResolution()<br />
loadCss ( file, title )<br />
replaceImages()<br />
setActiveStyleSheet ( title )<br />
windowResized()<br />
Display Module<br />
detectResolution<br />
setActiveStyleSheet<br />
loadCss<br />
windowResized<br />
replaceImages<br />
Figure 20: The m.HUBI API Display module contains functions that detect the screen proportions<br />
and characteristics of the device being used to view a plat<strong>for</strong>m client application. <strong>Based</strong> on<br />
the in<strong>for</strong>mation gleaned from the device, the module activates the appropriate CSS file or files.<br />
4.4.6 <strong>Service</strong>s Module<br />
The <strong>Service</strong>s module contains functions that pertain to various services of the<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong>, such as Events and Journey Planner (see sections 3.3 and 3.3).<br />
For ease of use and clarity, the functions have been divided into service-specific<br />
submodules named after the service they relate to.<br />
Bookmarks<br />
All functions of this module relate to Bookmarks. Registered plat<strong>for</strong>m users can<br />
bookmark certain items that are relevant, interesting or useful to them in client<br />
applications. Those bookmarks are saved to the user’s profile and can be retrieved,<br />
modified and utilized when that user is logged in. Generally bookmarks are POI<br />
objects, but other objects such as Journey Planner Routes can also be bookmarked.<br />
Friends<br />
addBookmark ( item )<br />
deleteBookmark ( item )<br />
displayBookmarks ( bookmarkArray )<br />
getBookmarks ( track )<br />
showBookmark ( item )<br />
The functions of this module relate to the plat<strong>for</strong>m’s Friends service. The Friends<br />
service allows users to create social networks by indicating their relationships with<br />
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<br />
Class, which represent user friends as they are depicted in the m.HUBI <strong>Plat<strong>for</strong>m</strong>.<br />
acceptBuddyRequest ( friendName )<br />
addBuddy ( friendName )<br />
declineBuddyRequest ( friendName )<br />
displayBuddies ( buddyArray )<br />
getBuddies ( track )<br />
getBuddyInfo ( friendName )<br />
removeBuddy ( friendName )<br />
Buddy {<br />
getAvatar() setAvatar ( avatar )<br />
getDistance() setDistance ( distance )<br />
getLocDate() setLocDate ( locDate )<br />
getName() setName ( name )<br />
getPhone() setPhone ( phone )<br />
getStatus() setStatus ( status )<br />
}<br />
38<br />
<strong>Service</strong> Module<br />
Bookmarks<br />
Journey Planner<br />
addBookmark *<br />
getBookmarks *<br />
displayRoute<br />
showRoute<br />
deleteBookmark *<br />
showBookmark<br />
getRoute *<br />
updateRoute<br />
displayBookmarks<br />
getRouteToPoi<br />
updateRoutePage<br />
Friends<br />
MyPlaces<br />
parseXMLListener<br />
acceptBuddyRequest<br />
getBuddies *<br />
addMyPlace *<br />
getMyPlaces *<br />
xhr<br />
addBuddy<br />
getBuddyInfo<br />
deleteMyPlace *<br />
moveMyPlace *<br />
declineBuddyRequest<br />
removeBuddy<br />
displayMyPlaces<br />
updateMyPlace *<br />
displayBuddies<br />
POI<br />
displayEvents<br />
showPoi<br />
getPois *<br />
showPoiDescription<br />
Figure 21: The m.HUBI API <strong>Service</strong>s module contains functions that pertain to various services<br />
of the m.HUBI <strong>Plat<strong>for</strong>m</strong>. The services and corresponding function submodules are Bookmarks,<br />
Friends, Journey Planner, MyPlaces and POI. The Friends, Journey Planner and POI submodules<br />
also include Javascript classes, which are not depicted in the figure. Functions with an asterisk (*)<br />
after their names make a call to the Communication module’s xhr function.
39<br />
Journey Planner<br />
The functions of this module relate to the m.HUBI <strong>Plat<strong>for</strong>m</strong> service Journey Planner<br />
(see section 3.3). The Journey Planner provides public transport route options from<br />
a given departure point to a given destination at a given time. The route options<br />
are requested from the plat<strong>for</strong>m server Journey Planner service component by the<br />
getRoute function and the response is displayed by the displayRoute function.<br />
The Journey Planner module also includes the Route Javascript class and Route-<br />
Leg and RoutePoint Javascript subclasses. A Route object represents a single Journey<br />
Planner route, which is retrieved from an external public transit web service. A<br />
RouteLeg object represents a subcomponent of a Route object. It is used to define<br />
a route section completed on e.g. a single bus or on foot from one point to another.<br />
Transfers, <strong>for</strong> instance, separate two RouteLeg objects from each other. A Route-<br />
Point object represents a subcomponent of a RouteLeg object. It is used to define<br />
a single point along a journey, such as the start or end point of a RouteLeg.<br />
displayRoute ( routeArray )<br />
getRoute ( from, to, depTime, arrTime, altDate, track )<br />
getRouteToPoi ( poi )<br />
showRoute ( route, legNo )<br />
updateRoute ( updateElId, updateElVal )<br />
updateRoutePage()<br />
Route() {<br />
getEnd() setEnd ( end )<br />
getLegs() setLegs ( legs )<br />
getStart() setStart ( start )<br />
getStartDate() setStartDate ( startDate )<br />
}<br />
RouteLeg() {<br />
getColor() setColor ( color )<br />
getEnd() setEnd ( end )<br />
getLength() setLength ( length )<br />
getLine() setLine ( line )<br />
getPoints() setPoints ( points )<br />
getStart() setStart ( start )<br />
getTransitType() setTransitType ( transitType )<br />
}<br />
RoutePoint() {<br />
getLat() setLat ( lat )<br />
getLon() setLon ( lon )<br />
getName() setName ( name )<br />
}
40<br />
MyPlaces<br />
The functions of this module relate to the m.HUBI <strong>Plat<strong>for</strong>m</strong> service MyPlaces.<br />
MyPlaces are user-defined POIs that represent significant or frequently visited places<br />
<strong>for</strong> the user, <strong>for</strong> instance Home, Work, Mom and Dad’s, and so on. The moveMyPlace<br />
function is used to rearrange the MyPlaces list by moving a single MyPlace up or<br />
down in the list.<br />
POI<br />
addMyPlace()<br />
deleteMyPlace ( poi )<br />
displayMyPlaces ( myPlacesArray )<br />
getMyPlaces ( track )<br />
moveMyPlace ( poi, moveDir )<br />
updateMyPlace ( poi, updateData )<br />
All functions of this module relate to Places Of Interest (POI) and other location<br />
annotated data such as event happenings that have been integrated into the m.HUBI<br />
<strong>Plat<strong>for</strong>m</strong> from external data sources (see section 3.3). The module also includes the<br />
Javascript class POI, which is used as a placeholder <strong>for</strong> POI objects received from<br />
the plat<strong>for</strong>m server and displayed on the web application client. The POI object<br />
methods getType and setType relate to the type or genre of each POI. The types<br />
of POI available depend on the kind of data accessible to plat<strong>for</strong>m clients. Example<br />
POI types can include theater, music, gallery, sports, education and so on.<br />
displayEvents ( poiArray )<br />
getPois ( track, sort )<br />
showPoi ( item )<br />
showPoiDescription ( item )<br />
Poi() {<br />
getAddress() setAddress ( address )<br />
getDataProvider() setDataProvider ( dataProvider )<br />
getDesc() setDesc ( desc )<br />
getDist() setDist ( dist )<br />
getEndDate() setEndDate ( endDate )<br />
getId() setId ( id )<br />
getIsHome() setIsHome ( isHome )<br />
getLat() setLat ( lat )<br />
getLon() setLon ( lon )<br />
getName() setName ( name )<br />
getPlace() setPlace ( place )<br />
getStartDate() setStartDate ( startDate )<br />
getType() setType ( type )<br />
getUrl() setUrl ( url )<br />
}
41<br />
4.4.7 Auxiliary Module<br />
The Auxiliary module contains functions that execute frequently required actions<br />
<strong>for</strong> various other m.HUBI API or proprietary Javascript functions. The module’s<br />
functions handle retrieval and setting of HTML element values, computation of<br />
mathematical calculations and per<strong>for</strong>mance of other menial tasks. This module is<br />
not essential <strong>for</strong> the use of the m.HUBI <strong>Plat<strong>for</strong>m</strong>, but it facilitates speedier processing<br />
times and decreases code repetition.<br />
appendUrlAttribute ( url, attribute, value )<br />
changeUrlAttribute ( url, attribute, value )<br />
createMenu()<br />
distanceBetween ( latA, lonA, latB, lonB )<br />
getCheckedValue ( radioObj )<br />
getSelectedValue ( selectObj )<br />
hasUrlAttribute ( url, attribute )<br />
latLngToPixel ( lat, lon, zoom )<br />
pixelToLatLng ( x, y, zoom )<br />
setCheckedValue ( radioObj, setValue )<br />
setSelectedValue( selectObj, setValue )<br />
Auxiliary Module<br />
appendUrlAttribute<br />
changeUrlAttribute<br />
createMenu<br />
hasUrlAttribute<br />
latLngToPixel<br />
pixelToLatLng<br />
distanceBetween<br />
getCheckedValue<br />
setCheckedValue<br />
setSelectedValue<br />
getSelectedValue<br />
Figure 22: The m.HUBI API Auxiliary module contains functions that execute frequently required<br />
actions on behalf of other Javascript functions. The module’s functions handle retrieval<br />
and setting of HTML element values, computation of mathematical calculations and per<strong>for</strong>mance<br />
of other menial tasks.<br />
4.5 Content Templates<br />
The m.HUBI <strong>Plat<strong>for</strong>m</strong> offers content templates which may be used and filled in to<br />
create functional client applications (Figure 23). The integration of the structure<br />
and layout templates is discretionary, but they are provided to facilitate and ease the<br />
development of new client applications. The two types of content templates, structure<br />
and layout, address different aspects of mobile web application client interfaces<br />
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<br />
JavaServer Page (JSP). JSP is a server-side technology that facilitates the creation<br />
and distribution of dynamic web pages. Standard HTML pages are static and require<br />
other technologies or mechanisms, such as Javascript, PHP and Perl, to dynamically<br />
alter their content. JSP pages consist of a combination of regular HTML tags and<br />
JSP elements. When a JSP page is requested from a web server, the server first<br />
executes the JSP elements, then merges the results with the static HTML and<br />
finally sends the outcome to the requester. [7] The template can also be modified<br />
or edited to better suit the purposes of the application being created.<br />
42<br />
Figure 23: The m.HUBI <strong>Plat<strong>for</strong>m</strong> Server includes content templates to facilitate and ease development<br />
of new client applications. Structure and layout templates can be used together, separately<br />
or not at all.<br />
The layout templates are simple CSS files that adapt and con<strong>for</strong>m the web application<br />
content to various mobile devices, screen sizes and orientations. The layout<br />
templates can be used in conjunction with or independent of the plat<strong>for</strong>m content<br />
templates. The example client application shown in Figure 23 is constructed by using<br />
the complete content templates as they are provided, without any modifications.<br />
The default client language is English, but other languages can be offered and their<br />
text substituted using JSP variables and language files.<br />
The layout templates provided address three mobile device screen resolutions,<br />
namely Quarter Video Graphics Array (QVGA), Half-size Video Graphics Array<br />
(HVGA) [83] and Near High-definition (nHD) [84]. The respective pixel ratios in<br />
portrait orientation, meaning the screen width is smaller than the screen height, are<br />
240 x 320, 320 x 480 and 360 x 640 pixels. Each screen resolution size has two corresponding<br />
layout templates, one <strong>for</strong> portrait orientation and the other <strong>for</strong> landscape<br />
orientation. Additionally, a default layout template is provided <strong>for</strong> use when the<br />
device screen resolution is undefined and a browser-specific template is provided <strong>for</strong><br />
use with Opera mobile browsers. A comprehensive list of all the stylesheets included<br />
in the m.HUBI <strong>Plat<strong>for</strong>m</strong> Client Layout Templates is supplied in Table 4.
43<br />
Table 4: List of all the CSS files included as the m.HUBI <strong>Plat<strong>for</strong>m</strong> Client Layout Templates. The<br />
stylesheets address various device screen resolutions and orientations.<br />
Name of template Screen resolution Browser type<br />
[W x H]<br />
qvga-portrait 240 x 320 Non-IE<br />
qvga-landscape 320 x 240 Non-IE<br />
hvga-portrait 320 x 480 Non-IE<br />
hvga-landscape 480 x 320 Non-IE<br />
nhd-portrait 360 x 640 Non-IE<br />
nhd-landscape 640 x 360 Non-IE<br />
opera 360 x 640 Opera<br />
default 320 x 480 Non-IE<br />
4.6 Use-case Scenario<br />
This section introduces a fictional m.HUBI <strong>Plat<strong>for</strong>m</strong> web application called My-<br />
Conf. The mock application is used to depict an end-user scenario that delineates<br />
the characteristics of the m.HUBI <strong>Plat<strong>for</strong>m</strong> and exhibits their functionality through<br />
potential real-life situations and usage contexts. The scenario depicted in the following<br />
text begins with a registered user logging into the fabricated MyConf application.<br />
The user then views application-specific event data that has been expressly input<br />
into the plat<strong>for</strong>m database <strong>for</strong> MyConf usage. Next, the pseudo user clicks on a<br />
single event item, which displays detailed in<strong>for</strong>mation regarding the event including<br />
a textual description of the event. Lastly, the user retrieves public transit route<br />
options using the MyConf Journey Planner in which the previously viewed event<br />
venue is the route’s destination.<br />
MyConf is a context-sensitive mobile web application created <strong>for</strong> use by participants<br />
of a scientific conference and workshop. The application contains a Journey<br />
Planner, a conference event calendar, a directory of conference participants and organizers<br />
and a taxi-share service <strong>for</strong> persons wanting to share taxi rides between<br />
different conference venues and hotels. MyConf was made using the structure and<br />
layout templates and Javascript API that are available with the m.HUBI <strong>Plat<strong>for</strong>m</strong>.<br />
The application also includes proprietary Javascript functions, HTML and<br />
CSS content to focus and specify the application scope. The developers of MyConf<br />
have added conference events such as presentations, workshops and networking opportunities<br />
to the plat<strong>for</strong>m’s event database. A mock-up image of the application’s<br />
homepage is shown in Figure 24.<br />
Mr. Jones is a first-time conference participant and has not previously visited the<br />
conference venue. After checking into his hotel, Mr. Jones navigates to the MyConf<br />
homepage on his iPhone. As a registered conference participant, Mr. Jones received<br />
a username and password <strong>for</strong> his MyConf account and proceeds to the login page of
44<br />
MyConf<br />
Calendar<br />
Taxi-share<br />
Directory<br />
Figure 24: A homepage mock-up of the fictional MyConf web application client. The webapp<br />
includes a Journey Planner, a conference calendar, a conference participant and organizer directory<br />
and a taxi-share service <strong>for</strong> sharing taxi rides between different conference venues and hotels.<br />
the webapp. By inputting his account in<strong>for</strong>mation and pressing the Login-button,<br />
Mr. Jones initiates an asynchronous AJAX dialogue between the MyConf webapp<br />
client and the m.HUBI <strong>Plat<strong>for</strong>m</strong> Server running MyConf. This dialogue, which is<br />
outlined below, is depicted in Figure 25.<br />
Use-case scenario: Login user<br />
function loginListener() {<br />
...<br />
}<br />
function create() {<br />
...<br />
}<br />
7<br />
Javascript<br />
m.HUBI PLATFORM<br />
CLIENT-SIDE<br />
HTTP<br />
GET / POST<br />
request<br />
WEB APPLICATION CLIENT<br />
HTTP<br />
GET / POST<br />
response<br />
(XML data <strong>for</strong>mat)<br />
PROPRIETARY CLIENT<br />
1<br />
3<br />
The MyConf proprietary HTML contains the login page’s Login-button element.<br />
When that button is pressed its onclick attribute calls the m.HUBI API login<br />
function. The login function collects the username and password values Mr. Jones<br />
input into the login <strong>for</strong>m and calls the plat<strong>for</strong>m’s Javascript API xhr function with<br />
the parameters (’POST’, ’login’, loginListener, ’username: password’). The<br />
xhr function creates an HTTP POST request containing the login in<strong>for</strong>mation and<br />
sends it to the Login service component (see Figure 9) at the MyConf server via a<br />
secure SSL connection.<br />
The Login service component receives the POST request and asks the server’s<br />
User Database if the user data is valid. The User Database responds to the Login<br />
service component that the in<strong>for</strong>mation is indeed correct. Next, the Login service<br />
component requests that the plat<strong>for</strong>m server’s cookie generator create a session login<br />
cookie with Mr. Jones’ account in<strong>for</strong>mation. Finally, the service component creates<br />
a HTTP POST response containing the newly generated session login cookie and<br />
returns it to the MyConf webapp client. When the response message reaches the<br />
client, it is handed to the plat<strong>for</strong>m Javascript API loginListener function <strong>for</strong><br />
parsing. The loginListener function utilizes another API function, create, to<br />
save Mr. Jones’ authentication in<strong>for</strong>mation as a browser cookie with default validity<br />
of one year. Now, Mr. Jones is shown to his fellow MyConf users as logged in and if<br />
he has allowed the sharing of his location to friends or other conference participators,<br />
they will also see his location.<br />
Use-case scenario: Open event calendar<br />
45<br />
function parseXMLListener() {<br />
...<br />
}<br />
function displayEvents() {<br />
...<br />
} 8<br />
Javascript<br />
<br />
User Database:<br />
5<br />
Is session cookie<br />
valid?<br />
HTTP GET<br />
Server<br />
User Profile Database<br />
& POI Database:<br />
List Mr. Jones'<br />
6 calendar events<br />
Databases<br />
Figure 26: The sequence of events illustrates the component workflow when Mr. Jones views his<br />
event calendar on the MyConf web application client. Because Mr. Jones has already logged into<br />
the application, his registered event listing can be retrieved from the plat<strong>for</strong>m server databases.
Next, Mr. Jones checks out his conference itinerary from MyConf’s Calendar service<br />
(see Figure 26). When he presses the Calendar button on the MyConf homepage<br />
that button’s onclick attribute indicates that the proprietary openCalendar<br />
function is called. The openCalendar function calls the plat<strong>for</strong>m’s Javascript API<br />
function xhr with the parameters (’GET’, ’poi’, parseXMLListener, null). The<br />
xhr function sends the POI service component a message containing the session login<br />
cookie and parameters indicating that the webapp client would like a response message<br />
containing calendar events. The POI service component (see Figure 11) first<br />
checks the validity of the session login cookie by communicating with the server’s<br />
User Database, then it contacts the User Profile and POI databases to gather all<br />
of Mr. Jones’ calendar events i.e. conference events he has indicated that he will<br />
be attending. The POI service component then returns the collected events to the<br />
webapp client as an XML document.<br />
When the return message reaches the MyConf webapp, its handling is turned over<br />
to the plat<strong>for</strong>m’s parseXMLListener callback function, as indicated in the original<br />
xhr function call. The parseXMLListener dissembles the response XML document<br />
into Javascript POI Objects and calls the follow-up function displayEvents to<br />
handle the population and display of the actual Calendar page.<br />
Use-case scenario: View event details<br />
46<br />
1<br />
updateRoutePage and getRoute API functions to complete the route options retrieval.<br />
The updateRoutePage function fills in the event POI address and time as<br />
described above and the getRoute function calls the xhr function with the parameters<br />
(’GET’, ’journeyPlanner’, parseXMLListener, null).<br />
47<br />
Use-case scenario: Get route to event<br />
function parseXMLListener() {<br />
...<br />
}<br />
function displayRoute() {<br />
...<br />
}<br />
6<br />
Javascript<br />
m.HUBI PLATFORM<br />
CLIENT-SIDE<br />
HTTP<br />
GET / POST<br />
request<br />
WEB APPLICATION CLIENT<br />
HTTP<br />
GET / POST<br />
response<br />
(XML data <strong>for</strong>mat)<br />
PROPRIETARY CLIENT<br />
1<br />
HTTP GET<br />
REQUEST<br />
<br />
HTTP<br />
GET / POST<br />
request<br />
EXTERNAL<br />
WEB SERVICES<br />
4<br />
< XML ><br />
HTTP GET<br />
RESPONSE<br />
HTTP GET<br />
HTTP<br />
GET / POST<br />
response<br />
Figure 28: After viewing details of a conference event Mr. Jones clicks the Journey Planner icon<br />
of the MyConf web application to retrieve public transit route options from his hotel to the event’s<br />
venue. The route options are queried from an external web service and returned to the webapp<br />
client in XML <strong>for</strong>m.<br />
The Journey Planner service component receives a HTTP GET request from<br />
the MyConf webapp client (see Figure 14). The service component reconstructs<br />
the incoming message into an outgoing message that it sends to an external web<br />
service that provides route in<strong>for</strong>mation and journey planning <strong>for</strong> public transit. The<br />
web service returns its response as an XML document, which is then restructured<br />
and returned to the MyConf webapp. At the client end, the parseXMLListener<br />
function handles the response message and saves the route in<strong>for</strong>mation as Javascript<br />
Route Objects. The parseXMLListener calls the displayRoute follow-up function<br />
to display and <strong>for</strong>mat the parsed route options to the MyConf webapp.
48<br />
5 Evaluation of the m.HUBI <strong>Plat<strong>for</strong>m</strong><br />
The m.HUBI <strong>Plat<strong>for</strong>m</strong> architecture defined, designed and documented in sections 3<br />
through 4 was analyzed and evaluated by three mobile web application and in<strong>for</strong>mation<br />
systems experts. Two of the three expert analysts, Experts A and B, were<br />
previously familiar with the VTT project, HUBI.mobi, into which this thesis work<br />
was incorporated. They were asked to only evaluate the architecture and documentation<br />
provided and to disregard any prior knowledge they may have had regarding<br />
the plat<strong>for</strong>m.<br />
The expert analysts were first presented with two scenarios (see Table 5) in which<br />
a m.HUBI <strong>Plat<strong>for</strong>m</strong> mobile web application might be useful. They were asked to<br />
familiarize themselves with the plat<strong>for</strong>m requirements, design, architecture and, in<br />
particular, the Developer’s Javascript API. The experts were then asked to rate the<br />
plat<strong>for</strong>m according to how well the requirements defined in section 3 were met in the<br />
architecture (see Table 6). Finally, the experts commented generally on the design<br />
and documentation of the m.HUBI <strong>Plat<strong>for</strong>m</strong> architecture (see section A1).<br />
5.1 Scenario Implementations<br />
The three expert analysts that evaluated the m.HUBI <strong>Plat<strong>for</strong>m</strong> architecture design<br />
and documentation were provided with two fictional usage scenarios in which a<br />
plat<strong>for</strong>m-based mobile application might be useful (see Table 5). They were asked<br />
to indicate whether they could implement an appropriate plat<strong>for</strong>m application <strong>for</strong><br />
each scenario. If they found that such an application could not be implemented, the<br />
experts were asked to describe why that was and what components were lacking or<br />
insufficient. Similarly, if they found the development of a relevant plat<strong>for</strong>m application<br />
plausible, the experts were asked to describe which components they would use<br />
<strong>for</strong> the implementation. Expert C was unable to contribute to the scenario analysis,<br />
as such the corresponding column is missing from Table 5.<br />
The first scenario is one of a housewife who is taking her two children to Helsinki<br />
<strong>for</strong> a day trip. The trip will include going to Korkeasaari zoo and then having<br />
dinner with their father in downtown Helsinki. The housewife needs public transport<br />
routing in<strong>for</strong>mation from her home to the zoo and also needs to reserve a table at<br />
a family-friendly downtown restaurant. Experts A and B both indicated that an<br />
application <strong>for</strong> this scenario was plausible, but only partially implementable due to<br />
an inadequacy in the retrieval of a particular POI type. The experts indicated that<br />
the public transport route option retrieval was straight<strong>for</strong>ward, but the filtering of<br />
family-style restaurants from the POI list was an unavailable function. As indicated<br />
in item 14 of Table A1, this issue was subsequently resolved by supplying a type<br />
parameter <strong>for</strong> POI retrieval.<br />
The second m.HUBI <strong>Plat<strong>for</strong>m</strong> usage scenario is one of a young urbanite who<br />
suddenly has an hour to spend in downtown Helsinki. The mock user is a frequenter<br />
of local art galleries and exhibits and would prefer not to view an exhibit he has<br />
already seen. Expert A determined that with the amendment of a type filter <strong>for</strong><br />
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.<br />
Expert B concluded that a plat<strong>for</strong>m application to fit the scenario was implementable<br />
by utilizing the user’s profile and preferences to retrieve POIs to meet his interests<br />
and using the Friends service to view nearby Friends. However, Expert B stipulated<br />
that the implementation is conditional upon the retrieval, review and updating of<br />
the user’s profile preference in<strong>for</strong>mation.<br />
Table 5: As part of an objective plat<strong>for</strong>m evaluation, three expert analysts were presented with<br />
scenarios in which a m.HUBI <strong>Plat<strong>for</strong>m</strong> mobile web application might be useful. The analysts were<br />
asked to evaluate if they would be able to develop a plat<strong>for</strong>m-based application to be used in the<br />
example scenarios.<br />
49<br />
No. Scenario Expert A Expert B<br />
1 Laura is a thirtyish housewife who lives in<br />
Riihimäki, Finland with her husband Pekka,<br />
their two children, Onni 2-years-old and Essi<br />
5-years-old, and the family dog Peppi. Laura<br />
is taking the kids on a day trip into Helsinki<br />
to do some shopping, visit Korkeasaari zoo and<br />
meet Pekka <strong>for</strong> a family dinner in the evening.<br />
Laura would usually drive the car the 70 km<br />
to Helsinki, but Pekka has taken it. As an unaccustomed<br />
public transit user, Laura is aware<br />
that there is a train station in Riihimäki, but<br />
doesn’t know the schedules <strong>for</strong> Helsinki-bound<br />
trains. Also, since Laura had planned on using<br />
her car’s onboard GPS navigation system<br />
to drive directly to the zoo, she doesn’t know<br />
how to get from the Helsinki train station to<br />
the Korkeasaari zoo.<br />
When Laura and the kids meet Pekka <strong>for</strong> dinner<br />
in Helsinki, which is something that the<br />
family does every few months, Pekka usually<br />
leaves the choice of restaurant and making of<br />
reservation up to Laura. Laura hasn’t been<br />
able to reserve a table at any of the family’s<br />
regular restaurants and she usually likes<br />
to make sure the restaurant they dine at offers<br />
a children’s menu and is generally familyfriendly.<br />
2 Mikko is a twenty-five year-old graphic design<br />
student who lives in Kallio, Helsinki. Mikko<br />
is meant to be meeting his mother <strong>for</strong> coffee<br />
in downtown Helsinki, but his mother sends<br />
him a text message saying that the meeting she<br />
is currently in will run late and suggests they<br />
can meet an hour later <strong>for</strong> dinner instead. As<br />
Mikko is already downtown he doesn’t see any<br />
point in going home to Kallio in the meantime,<br />
so he now has an hour to spend in the Helsinki<br />
city center.<br />
As a graphic design student, Mikko has visited<br />
most of Helsinki’s art museums and galleries<br />
many times, but he isn’t sure if some of the<br />
exhibits have recently changed. Mikko is not<br />
generally a solitary art-lover and usually takes<br />
a friend to galleries with him.<br />
Plausible / partially<br />
implementable.<br />
Use getRouteToPoi,<br />
displayRoute and<br />
getPois Javascript<br />
API functions. Would<br />
require a method <strong>for</strong><br />
retrieving particular<br />
POI types e.g. restaurants,<br />
family-friendly<br />
restaurants (see item<br />
14 in Table A1).<br />
Plausible / partially<br />
implementable. Use<br />
displayBuddies and<br />
getPois. Would require<br />
only museum or<br />
gallery POIs i.e. type<br />
parameter <strong>for</strong> getPois<br />
function (see item<br />
14 in Table A1) and<br />
sorted according to the<br />
most recent exhibit.<br />
Plausible / partially<br />
implementable. Use<br />
the Journey Planner<br />
service and map to<br />
retrieve and display<br />
route from Riihimäki<br />
to Korkeasaari zoo.<br />
Would require a type<br />
parameter <strong>for</strong> getPois<br />
function to specify<br />
the type of POI to<br />
return (see item 14 in<br />
Table A1).<br />
Implementable. Use<br />
user profile preferences<br />
and getPois function<br />
to retrieve nearby<br />
POIs and Friend service<br />
to view nearby<br />
friends. Would require<br />
user profile retrieval<br />
and updating.
5.2 Requirement Fulfillment<br />
The second part of the m.HUBI <strong>Plat<strong>for</strong>m</strong> analysis comprised of rating the architecture<br />
in regards to how well the requirements specified in section 3 were met. The<br />
experts were asked to mark each requirement with a rating from 0 to 5, whereby a<br />
score of 0 indicates that the requirement is not met at all and a rating of 5 denotes<br />
that the requirement is met perfectly. The experts were also permitted to comment<br />
on their ratings, especially if there was a particular deficiency that contributed to<br />
their rating. The expert analysis requirement rating results are presented in Table 6.<br />
Some ratings were left blank by the experts and they are indicated by n/a. The last<br />
column of the table is the average rating <strong>for</strong> each requirement, which was calculated<br />
in relation to the total amount of ratings given <strong>for</strong> that requirement.<br />
In terms of overall rating <strong>for</strong> the plat<strong>for</strong>m architecture reaching the plat<strong>for</strong>m<br />
requirements, the expert analysis result is mediocre. The average rating <strong>for</strong> all the<br />
requirement groups, functional, non-functional and service-specific, is just above 3.<br />
This indicates that the architecture has adequately achieved the goals specified, but<br />
there is also room <strong>for</strong> improvement.<br />
The functional requirements R1–R6 were rated an average of 3.2, which was the<br />
highest average score out of the three requirement groups. Additionally, having<br />
earned a rating ratio of 5 ratings to 1 n/a, received the highest number of ratings<br />
out of the three requirement groups. The R4: Map requirement earned the highest<br />
average rating out of the functional requirements with a score of 4.0. Expert B<br />
justified his rating of 4 by stating that it was unclear whether the implemented map is<br />
interactive, as was specified in the original requirement on page 13. The lowest scorer<br />
of the functional requirements was R3: Data Input Interfaces, which only received<br />
a single rating of 1. The lone rating came from Expert B, who noted that there was<br />
an absence of input interfaces in the architecture description of section 4. The lack<br />
of data interface in the architecture documentation may explain why Experts A and<br />
C did not evaluate R3 at all. Requirements R1–R2 and R5–R6 received an overall<br />
average rating of 2.6–3.6.<br />
The non-functional requirements R7–R10 received an average rating of 3.1 and<br />
a rating ratio of 7 ratings to 12 n/a’s. 3.2 received the highest relative rating, with<br />
an average of 3.5. Expert A noted that his rating was based on the support <strong>for</strong><br />
various mobile device screen sizes and resolutions provided by the content templates<br />
described in section 4.5. Potentially this rating could have been higher, if more<br />
device characteristics besides screen size and resolution were taken into account,<br />
such as device plat<strong>for</strong>m or browser. 3.2 received the lowest rating out of the nonfunctional<br />
requirements with an average of 2.6. Expert A commented that there<br />
were no explicit figures or descriptions regarding the per<strong>for</strong>mance scalability of the<br />
plat<strong>for</strong>m and Expert C stated the lack of physical deployment in<strong>for</strong>mation <strong>for</strong> his<br />
mark. The scalability issue is further discussed in section 5.3.<br />
The third and final requirement group of service-specific requirements R11–R13<br />
earned an average rating of 3.0, although the statistics are skewed due to the rating<br />
ratio of 1 rating to every 2 n/a’s. The only analyst to rate this group of requirements<br />
was Expert B, who found some deficiencies with the enabling of the R12: Events<br />
50
service and the documentation of the R13: Recommender service. Expert B commented<br />
that there were fields specified in the Events requirement on page 20 which<br />
were not included in the Javascript Class POI (see section 4.4.6, such as organizer<br />
and language. He also stated that the documentation regarding the Recommender<br />
<strong>Service</strong> (see section 4.2.3) was lacking. The latter issue is discussed in more detail<br />
in section 5.3.<br />
Table 6: As part of an objective plat<strong>for</strong>m evaluation, two expert analysts were asked to rate the<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong> in regards to how well the requirements defined in section 3 are met.<br />
51<br />
No. Requirement Expert A Expert B Expert C ¯X<br />
Functional Requirements 3.2<br />
R1 Location-awareness 3 3 5 3.6<br />
R2 Context-awareness 1 3 4 2.6<br />
R3 Data Input Interfaces n/a 1 n/a 1.0<br />
R4 Map 3 4 5 4.0<br />
R5 User Profile 3 2 5 3.3<br />
R6 User Activity Tracking 3 3 n/a 3.0<br />
Non-functional Requirements 3.1<br />
R7 Reusability n/a 4 n/a 4.0<br />
R8 Cross-device Functionality 3 4 n/a 3.5<br />
R9 Scalability 1 4 3 2.6<br />
R10 Multilingual Content Support n/a 3 n/a 3.0<br />
<strong>Service</strong>-specific Requirements 3.0<br />
R11 Journey Planner n/a 4 n/a 4.0<br />
R12 Events n/a 3 n/a 3.0<br />
R13 Recommender n/a 2 n/a 2.0<br />
5.3 Critical Issues<br />
As the final part of the expert analysis of the m.HUBI <strong>Plat<strong>for</strong>m</strong> architecture design<br />
and documentation, the three experts were asked to comment freely and mention<br />
any inadequacy, discrepancy or inconsistency they found. The full list of comments<br />
is listed in Table A1 of Appendix 6. The more prominent and significant issues<br />
raised are discussed at length in this section.<br />
A distinct inadequacy in R2: Context-awareness of the functional requirements<br />
(see section 3.1), was noted by two of the three experts. The comments concerned<br />
the lack of a concise description of what the term context inferred in the scope of the<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong>. Expert A was concerned that the only contextual in<strong>for</strong>mation<br />
to be collected and utilized by the plat<strong>for</strong>m is locational, whereas Expert B also<br />
mentioned the Friends service. The root of the issue lies in the original requirement<br />
wording and ambiguous nature of the term context itself. In relation to the plat<strong>for</strong>m,<br />
the context-awareness requirement actually stands <strong>for</strong> providing mechanisms to add<br />
new contextual sensor input data to the plat<strong>for</strong>m architecture. Such data could be<br />
future mobile device sensor gathered in<strong>for</strong>mation including acceleration, tempera-
ture, audio and video data. The requirement does not make any assumptions on<br />
how the contextual input is used, but should require the plat<strong>for</strong>m to facilitate the<br />
collection, storage and dissemination of the data.<br />
A number of comments were made on the plat<strong>for</strong>m architecture documentation<br />
provided in section 4. The issues raised were concerned with the nonexistent data<br />
input interfaces (see requirement R3: Data Input Interfaces), the scalability characteristics<br />
of the architecture specified in R9: Scalability and the operations of the<br />
Recommender <strong>Service</strong> defined in R13: Recommender. The comments made on R3:<br />
Data Input Interfaces and R13: Recommender were deemed so severe by the writer,<br />
that the architecture description in section 4 was modified accordingly. An external<br />
data input interface was appended to Figure 8 and the corresponding text and the<br />
description of the Recommender <strong>Service</strong> in section 4.2.3 was revised and expanded<br />
to better explain the inner processes of the Recommender <strong>Service</strong> component.<br />
The remarks made regarding the scalability of the plat<strong>for</strong>m architecture, as mentioned<br />
also in section 5.2, were that there was no reference, explicit or implicit, of any<br />
kind of scalability parameters or statistics. Per<strong>for</strong>mance, distribution and physical<br />
deployment metrics of the plat<strong>for</strong>m and its components would have provided a practical<br />
view of the plat<strong>for</strong>m’s response to its scalability requirement (see section R9:<br />
Scalability).<br />
52
53<br />
6 Conclusion<br />
<strong>Web</strong>sites of the 21st century are hardly recognizable as the ancestors of the first<br />
static web pages implemented almost 20 years ago. Not only has the complexity of<br />
the pages themselves increased, but the technologies and software plat<strong>for</strong>ms used to<br />
serve the pages facilitate a multitude of dynamic content creation. Mobile phones<br />
have undergone a similar and simultaneous evolution that has trans<strong>for</strong>med them<br />
from simple telephony and messaging instruments to portable personal computers<br />
complete with high-resolution full-color screens, web access and synchronized applications.<br />
Through the confluence of these services and devices a need has emerged<br />
<strong>for</strong> context-sensitive, personal, feature-rich, quickly and easily accessible mobile web<br />
applications.<br />
<strong>Web</strong> services and rich web applications utilize technologies that allow desktopquality<br />
application functionalities and content to be disseminated over the Internet<br />
via a web browser interface. Modern web applications harness the modularity and<br />
distributed nature the web and promote the <strong>Web</strong> 2.0 tenets of utilizing the web itself<br />
as a plat<strong>for</strong>m and implementing lightweight and interactive architecture components<br />
that yield services instead of products. Rich web applications (RIAs) enable webbased<br />
applications to act and look more like desktop applications. They facilitate<br />
asynchronous data retrieval and server interactions, so the user is saved from having<br />
to communicate on the application’s terms and can instead focus on the activity<br />
they want to complete. <strong>Web</strong> services and RIAs also facilitate the population and<br />
delivery of personal content that is produced on-demand as the in<strong>for</strong>mation or service<br />
is requested. This mode of production allows <strong>for</strong> situationally relevant and highly<br />
personalized content to be automatically injected into the application.<br />
Smartphones, which are essentially hand-held mobile phone computers, have<br />
completely revolutionized the field of mobile applications. In addition to native applications,<br />
which are created specifically <strong>for</strong> a particular mobile operating system<br />
or device firmware, and cross-plat<strong>for</strong>m applications, which use application middleware<br />
to provide a uni<strong>for</strong>m runtime environment <strong>for</strong> various systems and plat<strong>for</strong>ms,<br />
smartphones are equipped with desktop-quality web browsers that can gracefully<br />
execute web applications. <strong>Web</strong> application development consumes less time and<br />
resources than native or cross-plat<strong>for</strong>m application development, because all web<br />
browsers are designed to correctly interpret and execute the same code regardless<br />
of the environment they are deployed in. In other words, where native applications<br />
require program code to be tailored separately <strong>for</strong> each operating system or mobile<br />
phone model and cross-plat<strong>for</strong>m applications require underlying operating system<br />
dependent middleware to be installed, merely a single program version of a web<br />
application needs to be written.<br />
The growing sophistication and penetration of smartphones in the mobile phone<br />
market combined with the advances in web technologies and standards has provided<br />
a fertile foundation <strong>for</strong> mobile-specific web applications. As these mobile webapps<br />
progressed, developers realized there was an untapped resource in the mobile device<br />
itself. The inherent sensing capabilities that modern smartphones provide combined<br />
with the dynamic capabilities and technologies of rich web applications enable the
automatic collection and utilization of tacit situational in<strong>for</strong>mation from the usage<br />
scenario.<br />
Interpretation of tacit in<strong>for</strong>mation is a notoriously difficult task <strong>for</strong> machine<br />
processing to accomplish. Tacit or implicit in<strong>for</strong>mation is knowledge that is not<br />
obvious, but can be inferred from a situation or the context of a situation. For<br />
instance, if a man is standing at a street corner with a map in his hands and is<br />
looking at the street signs around him it could be deduced that he is lost. Similarly,<br />
if the man is looking at his map and suddenly starts walking determinedly down<br />
the street one could assume that he has located where he is on the map and is now<br />
moving towards his destination. These details are relatively easy <strong>for</strong> a human being<br />
to conclude if they were observing the situation, but a machine would not easily<br />
make the correlation. The ability to automatically collect, interpret and store this<br />
kind of implicit data in a machine-accessible <strong>for</strong>mat is paramount to context-aware<br />
system design.<br />
The reason context and situational in<strong>for</strong>mation is viewed as a valuable addition<br />
to mobile applications is the facilitation of better and more appropriate operations<br />
and content. Situational in<strong>for</strong>mation af<strong>for</strong>ds a system to provide more relevant<br />
services and in<strong>for</strong>mation to the user’s particular scenario. Additionally, if the data<br />
can be automatically gathered and processed it relieves the user of the strain of<br />
manually inputing that in<strong>for</strong>mation. At the moment, mobile web applications suffer<br />
from the limitation of a difficulties in accessing mobile device’s other applications or<br />
content. Native applications do not have this dilemma, because they are executed by<br />
the device’s operating system in a plat<strong>for</strong>m-compatible programming language and<br />
are subsequently able to communicate with other applications or device hardware<br />
directly. An enhancement in this field would be the acceptance and implementation<br />
of the W3C Permissions <strong>for</strong> Device API Access working draft [78] that suggests<br />
the provision of a uni<strong>for</strong>m interface <strong>for</strong> web applications to access mobile device<br />
hardware and software elements.<br />
In this thesis, the requirements and specifications <strong>for</strong> a web-based mobile application<br />
plat<strong>for</strong>m were defined. <strong>Based</strong> on the accumulated requirements, a plat<strong>for</strong>m<br />
architecture was designed and documented and was finally evaluated by a panel of<br />
experts. This Master’s dissertation and the work involved was completed as part of<br />
the HUBI.mobi Project, which ran from 2009 to 2011, in the employ of VTT Technical<br />
Research Centre of Finland (VTT). The initial thesis specification was to design<br />
the architecture <strong>for</strong> a situation-sensitive, user-specific, feature-rich, highly portable<br />
and easily maintainable application plat<strong>for</strong>m with which the rapid development and<br />
deployment of mobile web applications would be possible. The resulting requirements<br />
were gathered in part from literature and in part dictated by the HUBI.mobi<br />
Project Management.<br />
The requirements outlined in this thesis <strong>for</strong> a web-based mobile application plat<strong>for</strong>m<br />
were listed by their characteristics into functional, non-functional and servicespecific<br />
requirements (see section 3). The functional requirements specified were R1:<br />
Location-awareness, R2: Context-awareness, R3: Data Input Interfaces, R4: Map, R5:<br />
User Profile and R6: User Activity Tracking. The non-functional requirements outlined<br />
<strong>for</strong> the plat<strong>for</strong>m were R7: Reusability, R8: Cross-device Functionality, R9:<br />
54
Scalability and R10: Multilingual Content Support. Finally, the plat<strong>for</strong>m’s servicespecific<br />
requirements were identified as R11: Journey Planner, R12: Events and R13:<br />
Recommender.<br />
<strong>Based</strong> on the requirements specified the architecture <strong>for</strong> the m.HUBI <strong>Plat<strong>for</strong>m</strong><br />
was designed and its documentation presented (see section 4). The plat<strong>for</strong>m consists<br />
of server-side and client-side components. The client-side includes a Javascript API<br />
and optional layout and structure content templates. Implemented plat<strong>for</strong>m-based<br />
client applications may also include proprietary Javascript and content. The plat<strong>for</strong>m’s<br />
server-side consists of <strong>Service</strong> Components, a Database Management module,<br />
an Identity and Authorization Management module, a Recommender <strong>Service</strong> and a<br />
Support Function component. The <strong>Service</strong> Components module is comprised of several<br />
functionally independent subcomponents. Each subcomponent communicates<br />
with and executes processes between a corresponding component in the client-side<br />
Javascript API and the server-side Database Management module. Communication<br />
between the plat<strong>for</strong>m’s client-side and its server-side is handled via HTTP GET and<br />
POST messages that carry data in standard XML <strong>for</strong>mat.<br />
Following the design and documentation of the architecture of the m.HUBI <strong>Plat<strong>for</strong>m</strong>,<br />
it was evaluated by three expert analysts. The experts utilized their experience<br />
in mobile web application development and in<strong>for</strong>mation systems design to assess the<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong> in regards to how well it meets the requirements set <strong>for</strong> it and<br />
how exhaustive and relevant its documentation is. The analysis consisted of three<br />
segments; a user scenario, an architecture rating and an open comment segment.<br />
The first segment consisted of two fictional usage scenarios in which a plat<strong>for</strong>mbased<br />
webapp might be useful. The experts were asked to indicate whether they<br />
believed they would be able to implement an appropriate m.HUBI <strong>Plat<strong>for</strong>m</strong> webapp<br />
<strong>for</strong> each scenario. The second evaluation segment was a straight<strong>for</strong>ward rating<br />
task, in which the experts indicated how well they felt each architecture requirement<br />
(see section 3) was met with a rating of 0 through 5. The third segment allowed<br />
the expert analysts an open <strong>for</strong>um to comment on any deficiencies, superfluities or<br />
discrepancies they found in either the architecture or its documentation.<br />
The results of the first segment of the expert evaluation are subject to scrutiny<br />
due to the small number of analysts that provided their estimations. Although the<br />
two experts to complete the evaluation viewed the fictional usage scenarios presented<br />
to be at least partially implementable with only minor changes enabling full implementation,<br />
the judgments were purely theoretical and based on the architecture<br />
documentation provided. A larger set of appraisers or more varied usage scenarios<br />
would result in a more credible evaluation outcome and provide a more objective<br />
result. The second evaluation segment, which entailed numerical rating of each architecture<br />
requirement in relation to its fulfillment in the designed and documented<br />
architecture, also suffers from similar credibility issues although all three experts<br />
submitted their appraisals. Despite the statistical disputability of the second evaluation<br />
segment, the plat<strong>for</strong>m requirements received an acceptable average rating of<br />
3.1, which is just above the scale median of 3.<br />
The expert evaluation, although limited in scope, revealed a number of relevant<br />
functional and superficial issues. An inadequacy brought up by several analysts was<br />
55
the ambiguous definition of context in regards to the plat<strong>for</strong>m architecture requirement<br />
R2: Context-awareness. The concern was that the architecture design did not<br />
incorporate enough variety in contextual data integration. The experts felt that<br />
the only context available to the plat<strong>for</strong>m was locational in<strong>for</strong>mation regarding the<br />
users and their service-using friends. Another critical issue raised was the lack of<br />
focus on requirement R9: Scalability in terms of the plat<strong>for</strong>m system’s per<strong>for</strong>mance,<br />
distribution and physical deployment. These metrics are left unaddressed, but they<br />
would provide valuable insight into the handling capabilities and system characteristics<br />
of the plat<strong>for</strong>m scalability. A number of remarks were made regarding the<br />
documentation of the architecture that primarily pertained to vague or ambiguous<br />
descriptions and specific functionalities of the Javascript API.<br />
In relation to existing comparable context-aware mobile application research<br />
frameworks and plat<strong>for</strong>ms, the m.HUBI <strong>Plat<strong>for</strong>m</strong> is distinct in its solely web environment.<br />
Other frameworks such and the JCAF [6], xFace [43] and Lively <strong>for</strong><br />
Qt [49] rely on middleware programs to provide runtime environments <strong>for</strong> their contextual<br />
applications. Although, at present, m.HUBI <strong>Plat<strong>for</strong>m</strong> has limited access to<br />
mobile device hardware or software which creates difficulty in accessing contextual<br />
data, the problem will be significantly mitigated if not overcome with the adoption of<br />
standardized Device APIs [78]. The m.HUBI <strong>Plat<strong>for</strong>m</strong> resembles its framework and<br />
plat<strong>for</strong>m counterparts by emphasizing the attributes of lightweightness, extensibility<br />
and plat<strong>for</strong>m independence. Although it also shares an open standards philosophy<br />
with the xFace web application engine, the m.HUBI <strong>Plat<strong>for</strong>m</strong> is entirely based on<br />
W3C endorsed technologies whereas the xFace plat<strong>for</strong>m also utilizes standards published<br />
by other organizations.<br />
A comprehensive evaluation of the m.HUBI <strong>Plat<strong>for</strong>m</strong> architecture and documentation<br />
is difficult to execute thoroughly without an appraisable working implementation.<br />
A portion of any potential architectural deficiencies are such, that they do<br />
not manifest or are at least highly challenging to detect until a working version of<br />
the plat<strong>for</strong>m has been constructed. However, the existing architecture design and<br />
documentation was perceived as adequate in regards to the requirements laid out<br />
<strong>for</strong> it and acceptable as a mobile web application development plat<strong>for</strong>m.<br />
Potential improvement areas and considerations <strong>for</strong> future work are contextrelated<br />
plat<strong>for</strong>m component specification, context input identification and collection<br />
implementation, scalability testing, and capability verification. The author views<br />
context input identification and the implementation of contextual data collection<br />
as a particularly crucial issue and potential pitfall <strong>for</strong> the architecture and plat<strong>for</strong>m<br />
as a whole. A central focus <strong>for</strong> future work regarding the m.HUBI <strong>Plat<strong>for</strong>m</strong><br />
is pilot application implementation by both existing project members, whom are<br />
already familiar with the architecture, and external parties, that have no previous<br />
knowledge of the architecture and could provide valuable insight into the quality<br />
and suitability of the plat<strong>for</strong>m. Following application implementation, a pertinent<br />
parallel research avenue would be the comparison of various context-aware mobile<br />
applications created with frameworks and plat<strong>for</strong>ms similar to and including the<br />
m.HUBI <strong>Plat<strong>for</strong>m</strong>.<br />
56
57<br />
References<br />
[1] Adomavicius, G. and Tuzhilin, A. Toward the Next Generation of Recommender<br />
Systems: A Survey of the State-of-the-Art and Possible Extensions.<br />
IEEE Transactions on Knowledge and Data Engineering, 2005. Vol. 17. pp.<br />
734–749. ISSN 1041-4347.<br />
[2] Allied Business Intelligence, Inc. More than 60% of Handsets Will Have Mobile<br />
Browsers in 2015. URL: http://www.abiresearch.com/press/1705-More+<br />
than+60+of+Handsets+Will+Have+Mobile+Browsers+in+2015. August 3,<br />
2010. [Accessed January 12, 2011].<br />
[3] Alonso, G., Casati, F., Kuno, H. and Machiraju, V. <strong>Web</strong> <strong>Service</strong>s: Concepts,<br />
<strong>Architecture</strong>s and Applications. Heidelberg, Germany, Springer-Verlag, 2004. p.<br />
354. ISBN 3-540-44008-9.<br />
[4] Anagnostopoulos, C. B., Tsounis, A. and Hadjiefthymiades, S. Context Awareness<br />
in Mobile Computing Environments. Wireless Personal Communications:<br />
An International Journal, 2007. Vol. 42:3. pp. 445–464. ISSN 0929-6212.<br />
[5] Atterer, R., Wnuk, M. and Schmidt, A. Knowing the User’s Every Move—User<br />
Activity Tracking <strong>for</strong> <strong>Web</strong>site Usability Evaluation and Implicit Interaction.<br />
Proceedings of the 15th International Conference on World Wide <strong>Web</strong>. Edinburgh,<br />
Scotland, May 22–26, 2006. New York, New York, ACM, 2006. pp.<br />
203–212. ISBN 1-59593-323-9.<br />
[6] Bardram, J. E. The Java Context Awareness Framework (JCAF) - A <strong>Service</strong><br />
Infrastructure and Programming Framework <strong>for</strong> Context-Aware Applications.<br />
In: Gellersen, H. W., Want, R. and Schmidt, A. (Eds.) Pervasive Computing,<br />
Lecture Notes in Computer Science. Vol. 3468. 2005. pp. 98–115. DOI:<br />
10.1007/11428572 7.<br />
[7] Bergsten, H. JavaServer Pages TM . Cali<strong>for</strong>nia, United States, O’Reilly, 2002. p.<br />
684. ISBN 0-596-00317-X.<br />
[8] Berners-Lee, T. Design Issues. URL: http://www.w3.org/History/<br />
19921103-hypertext/hypertext/WWW/DesignIssues/Overview.html. 1992.<br />
[Accessed January 12, 2011].<br />
[9] Berners-Lee, T. ECHT90. URL: http://www.w3.org/History/<br />
19921103-hypertext/hypertext/Conferences/ECHT90/Introduction.<br />
html. 1992. [Accessed January 12, 2011].<br />
[10] Bondi, A. Characteristics of Scalability and Their Impact on Per<strong>for</strong>mance. Proceedings<br />
of the Second International Workshop on Software and Per<strong>for</strong>mance.<br />
Ottawa, Ontario, Canada, September 17–20, 2000. New York, New York, ACM,<br />
2000. pp. 195–203. ISBN 1-58113-195-X.
[11] Brodt, A., Nicklas, D., Sathish, S. and Mitschang, B. Context-Aware Mashups<br />
<strong>for</strong> Mobile Devices. In: Bailey, J., Maier, D., Schewe, K., Thalheim, B. and<br />
Wang, X. S. (Eds.) Proceedings of the Ninth International Conference on <strong>Web</strong><br />
In<strong>for</strong>mation Systems Engineering. Auckland, New Zealand, September 1–3,<br />
2008. Berlin, Springer-Verlag, 2008. pp. 280–291.<br />
[12] Carr, E. Location Technologies Primer. TechCrunch, 2008. URL: http:<br />
//techcrunch.com/2008/06/04/location-technologies-primer/. June 4,<br />
2008. [Accessed January 19, 2011].<br />
[13] Cecchet, E., Chanda, A., Elnikety, S., Marguerite, J. and Zwaenepoel, W. Per<strong>for</strong>mance<br />
comparison of middleware architectures <strong>for</strong> generating dynamic web<br />
content. Proceedings of the ACM/IFIP/USENIX 2003 International Conference<br />
on Middleware. Rio de Janeiro, Brazil, June 16–20, 2003. New York, NY,<br />
Springer-Verlag, 2003. pp. 242–261. ISBN 3-540-40317-5.<br />
[14] Choi, J. Software <strong>Architecture</strong> <strong>for</strong> Extensible Context-aware Systems. International<br />
Conference on Convergence and Hybrid In<strong>for</strong>mation Technology,<br />
Daejeon, South Korea, August 28–30, 2008. pp. 811–816. DOI:<br />
10.1109/ICHIT.2008.236<br />
[15] Chung, L. and do Prado Leite, J. On Non-Functional Requirements In Software<br />
Engineering. In: Borgida, A., Chaudhri, V, Giorgini, P. and Yu E. (Eds.) Conceptual<br />
Modeling: Foundations and Applications. Vol. 5600. Springer Berlin,<br />
2009. pp. 363–379. (Lecture Notes in Computer Science).<br />
[16] Clarkin, L. and Holmes, J. Enterprise Mashups. The <strong>Architecture</strong> Journal, 2007.<br />
Vol. 13. URL: http://msdn.microsoft.com/en-us/architecture/bb906060<br />
[Accessed January 18, 2011].<br />
[17] Curbera, F., Duftler, M., Khalaf, R., Nagy, W., Mukhi, N. and Weerawarana,<br />
S. Unraveling the <strong>Web</strong> <strong>Service</strong>s <strong>Web</strong>: An Introduction to SOAP, WSDL and<br />
UDDI. IEEE Internet Computing, 2002. Vol. 6:2. pp. 86–93. ISSN 1089-7801.<br />
[18] Dao, D., Rizos, C. and Wang, J. Location-based services: technical and business<br />
issues. GPS Solutions, 2002. Vol. 6:3. Heidelberg, Germany, Springer. pp. 169–<br />
178. ISSN 1080-5370.<br />
[19] Davidyuk, O., Riekki, J., Rautio, V-M. and Sun, J. Context-Aware Middleware<br />
<strong>for</strong> Mobile Multimedia Applications. Proceedings of the 3rd International Conference<br />
on Mobile and Ubiquitous Multimedia, College Park, Maryland, October<br />
27–29, 2004. New York, New York, ACM. pp. 213–220.<br />
[20] Desrosiers, C. and Karypis, A. A comprehensive Survey of Neighborhood-based<br />
Recommendation Methods. In: Ricci, F., Rokach, L., Shapira, B. and Kantor,<br />
P. B. (Eds.) Handbook on Recommender Systems. Springer New York, 2009. pp.<br />
107–144. ISBN 978-0-387-85819-7.<br />
58
[21] Dey, A. Understanding and Using Context. Personal Ubiquitous Computing,<br />
2001. Vol. 5:1. pp. 4–7. ISSN 1617-4909.<br />
[22] DocForge <strong>Web</strong> Application. URL: http://doc<strong>for</strong>ge.com/wiki/<strong>Web</strong>_<br />
application [Accessed December 22, 2010].<br />
[23] DuVander, A. 5 Years Ago Today the <strong>Web</strong> Mashup Was Born. Programmable<br />
<strong>Web</strong> Blog, 2010. URL: http://blog.programmableweb.com/2010/04/08/<br />
the-fifth-anniversary-of-map-mashups-on-the-web/ [Accessed January<br />
18, 2011].<br />
[24] Eirinaki, M. and Vazirgiannis, M. <strong>Web</strong> Mining <strong>for</strong> <strong>Web</strong> Personalization. Journal<br />
of ACM Transactions on Internet Technology, 2003. Vol. 3:1. New York, New<br />
York, ACM. pp. 1–27. ISSN 1533-5399.<br />
[25] Encyclopædia Britannica. Smartphone. URL: http://www.britannica.com/<br />
EBchecked/topic/1498102/smartphone. [Accessed January 13, 2011].<br />
[26] Encyclopædia Britannica. Wi-Fi. URL: http://www.britannica.com/<br />
EBchecked/topic/1473553/Wi-Fi. [Accessed January 18, 2011].<br />
[27] Fielding, R. T. Principled Design of the Modern <strong>Web</strong> <strong>Architecture</strong>. Journal<br />
of ACM Transactions on Internet Technology, 2002. Vol. 2:2. New York, New<br />
York, ACM. pp. 115–150. ISSN 1533-5399.<br />
[28] Fisher, M. B. Why require registration? Part 1. URL: http:<br />
//completeusability.com/why-require-registration-part-1/. May<br />
5, 2009. [Accessed January 27, 2011].<br />
[29] Fisher, M. B. Why require registration? Part 2. URL: http://<br />
completeusability.com/why-require-registration-part-2/. August 17,<br />
2009. [Accessed January 27, 2011].<br />
[30] Gartner, Inc. Clark, W. Fundamentals of Context Delivery <strong>Architecture</strong>: Provisioning<br />
Context-Enriched <strong>Service</strong>s, 2010 Update. URL: http://www.gartner.<br />
com/DisplayDocument?id=1372919. May 20, 2010. [Accessed January 20,<br />
2011].<br />
[31] Gartner, Inc. Clark, W. Key Issues <strong>for</strong> Context-Aware Computing, 2010. URL:<br />
http://www.gartner.com/DisplayDocument?id=1354514. April 16, 2010.<br />
[Accessed January 4, 2011].<br />
[32] Gartner, Inc. Jones, N. Cross-<strong>Plat<strong>for</strong>m</strong> Mobile Application Development Tools:<br />
Interest and Capability Expected to Grow. URL: http://www.gartner.com/<br />
DisplayDocument?id=1293616. February 2, 2010. [Accessed January 4, 2011].<br />
[33] Global Intelligence Alliance. Native or <strong>Web</strong> Application? How Best to Deliver<br />
Content and <strong>Service</strong>s to Your Audiences over the Mobile Phone. URL:<br />
http://www.globalintelligence.com/insights-analysis/white-papers/<br />
59
native-or-web-application-how-best-to-deliver-cont/. April 2010.<br />
[Accessed January 13, 2011].<br />
[34] Google. Google Maps API Family. URL: http://code.google.com/apis/<br />
maps/. [Accessed December 22, 2010].<br />
[35] Griswold, W. G. Five Enablers <strong>for</strong> Mobile 2.0. Computer, 2007. Vol. 40:10. pp.<br />
96–98. ISSN 0018-9162.<br />
[36] Haerder, T. and Reuter, A. Principles of transaction-oriented database recovery.<br />
ACM Computing Surveys, 1983. Vol. 15:4. pp. 287–317. ISSN 0360-0300.<br />
[37] Hernandez, E. A. War of the Mobile Browsers. IEEE Pervasive Computing,<br />
2009. Vol. 8:1. pp. 82–85. ISSN 1536-1268.<br />
[38] Hinz, M. and Fiala, Z. Context Modeling <strong>for</strong> Device- and Location-Aware Mobile<br />
<strong>Web</strong> Applications. Workshop of the Third International Conference on<br />
Pervasive Computing, Munich, Germany, May 8–13, 2005.<br />
[39] HSL: Helsinki Regional Transport Authority. Reittiopas API Developer’s<br />
Guide. URL: http://developer.reittiopas.fi/pages/en/home.php. [Accessed<br />
January 24, 2011].<br />
[40] Huang, S. and Tilley, S. Issues of content and structure <strong>for</strong> a multilingual web<br />
site. Proceedings of The 19th Annual International Conference on Computer<br />
Documentation, Sante Fe, New Mexico, USA, 2001. New York, New York,<br />
ACM. pp. 103–110. ISBN 1-58113-295-6.<br />
[41] International Press Telecommunications Council. IPTC Standards.<br />
URL: http://www.iptc.org/std/NAR/1.5/documentation/<br />
IPTC-G2-Implementation-Guide_2.zip. 2009. [Accessed January 27,<br />
2011].<br />
[42] International Telecommunication Union. The World in 2010: ICT<br />
Facts and Figures. URL: http://www.itu.int/ITU-D/ict/material/<br />
FactsFigures2010.pdf. 2010. [Accessed January 12, 2011].<br />
[43] Jiang, F., Feng, Z. and Luo, L. xFace - A Lightweight <strong>Web</strong> Application Engine<br />
on Multiple Mobile <strong>Plat<strong>for</strong>m</strong>s. The Tenth IEEE International Conference on<br />
Computer and In<strong>for</strong>mation Technology, Brad<strong>for</strong>d, West Yorkshire, UK, June<br />
29–July 1, 2010. pp. 2055–2060.<br />
[44] Koskela, T., Kostamo N., Kassinen O., Ohtonen J. and Ylianttila M. Towards<br />
Context-Aware Mobile <strong>Web</strong> 2.0 <strong>Service</strong> <strong>Architecture</strong>. International Conference<br />
on Mobile Ubiquitous Computing, Systems, <strong>Service</strong>s and Technologies, Papeete,<br />
November 4–9, 2007. pp. 41–48.<br />
[45] Li, D and Chandra, U. Building <strong>Web</strong>-<strong>Based</strong> Collaboration <strong>Service</strong>s on Mobile<br />
Phones. The 2008 International Symposium on Collaborative Technologies and<br />
Systems, Irvine, Cali<strong>for</strong>nia, May 19–23, 2008. pp. 295–304.<br />
60
[46] Martin, S., Castro, M., Talevski, A. and Potdar, V. A Middleware <strong>for</strong> Mobile<br />
and Ubiquitous Learning Ecosystems based on a Reconfigurable Plug-and-Play<br />
<strong>Architecture</strong>: Application to Mashups. 24th IEEE International Conference on<br />
Advanced In<strong>for</strong>mation Networking and Applications Workshops, Perth, Australia,<br />
April 20–23, 2010. pp. 1–6.<br />
[47] Mazzetti, P., Nativi, X., Sacco, A. and Bigagli, L. Integration of REST style and<br />
AJAX technologies to build <strong>Web</strong> applications. Third International Conference<br />
on In<strong>for</strong>mation and Communication Technologies: From Theory to Applications,<br />
Damascus, Syria, April, 7–11, 2008. pp. 1–6.<br />
[48] Miah, S. J. and Gammack, J. A Mashup <strong>Architecture</strong> <strong>for</strong> <strong>Web</strong> End-user Applicaiton<br />
Designs. 2nd IEEE International Conference on Digital Ecosystems and<br />
Technologies, Phitsanulok, Thailand, February 26–29, 2008. pp. 532–537.<br />
[49] Mikkonen, T., Taivalsaari, A. and Terho, M. Lively <strong>for</strong> Qt: A <strong>Plat<strong>for</strong>m</strong> <strong>for</strong> Mobile<br />
<strong>Web</strong> Applications. Proceedings of the 6th international Conference on Mobile<br />
Technology, Application and Systems, Nice, France, September 2–4, 2009.<br />
New York, New York, ACM. pp. 1–8.<br />
[50] MozillaWiki. Open <strong>Web</strong> Apps Wiki - Manifest. URL: https://wiki.mozilla.<br />
org/Labs/Apps/Manifest. October 20, 2010. [Accessed December 28, 2010].<br />
[51] Mozilla Labs. Open <strong>Web</strong> Apps Technical Overview. URL: https://apps.<br />
mozillalabs.com/oneFile.html. October 18, 2010. [Accessed November 2,<br />
2010].<br />
[52] Murugesan, S. and Venkatakrishnan, B. A. Addressing the Challenges of <strong>Web</strong><br />
Applications on Mobile Handheld Devices. International Conference on Mobile<br />
Business, Sydney, Australia, July 11–13, 2005. pp. 199–205.<br />
[53] Nokia Corporation. Qt - A cross-plat<strong>for</strong>m application and UI framework. URL:<br />
http://qt.nokia.com/ [Accessed December 28, 2010].<br />
[54] Oracle, Inc. GlassFish Wiki. What is an Application Server?. URL: http:<br />
//wikis.sun.com/display/GlassFish/FaqWhatIsAppServer. June 2, 2010.<br />
[Accessed February 10, 2011].<br />
[55] Oracle, Inc. MySQL 5.0 Reference Manual. URL: http://downloads.mysql.<br />
com/docs/refman-5.0-en.a4.pdf. 2011. [Accessed February 10, 2011].<br />
[56] Offutt, J. Quality attributes of <strong>Web</strong> software applications. IEEE Software, 2002.<br />
Vol. 19:2. pp. 25–32. ISSN 0740-7459.<br />
[57] OpenStreetMap Wiki. OpenLayers. URL: http://wiki.openstreetmap.org/<br />
wiki/OpenLayers. November 30, 2010. [Accessed December 20, 2010].<br />
[58] OpenLayers. OpenLayers: Free Maps <strong>for</strong> the <strong>Web</strong>. URL: http://www.<br />
openlayers.org/. [Accessed December 20, 2010].<br />
61
[59] O’Reilly, T. What is <strong>Web</strong> 2.0. URL: http://oreilly.com/pub/a/web2/<br />
archive/what-is-web-20.html. September 30, 2005. [Accessed December 27,<br />
2010].<br />
[60] O’Reilly, T. and Battelle, J. <strong>Web</strong> Squared: <strong>Web</strong> 2.0 Five Years<br />
On. <strong>Web</strong> 2.0 Summit Conference, San Francisco, Cali<strong>for</strong>nia, October<br />
20–22, 2009. URL: http://assets.en.oreilly.com/1/event/28/web2009_<br />
websquared-whitepaper.pdf [Accessed December 27, 2010].<br />
[61] Paulson, L. D. Building Rich <strong>Web</strong> Applications with Ajax. Computer, 2005.<br />
Vol. 38:10. pp. 14–17. ISSN 0018-9162.<br />
[62] Pokraev, S., Koolwaaij, J., van Setten, M., Broens, T., Dockhorn Costa, P.,<br />
Wibbels, M., Ebben, P. and Strating, P. <strong>Service</strong> <strong>Plat<strong>for</strong>m</strong> <strong>for</strong> Rapid Development<br />
and Deployment of Context-Aware, Mobile Applications. IEEE International<br />
Conference on <strong>Web</strong> <strong>Service</strong>s, Orlando, Florida, July 11–15, 2005. pp.<br />
639–646.<br />
[63] Privacy Laws and Business. Data Protection and Privacy Law Links URL:<br />
http://www.privacylaws.com/templates/Links.aspx?id=404#411. 2011.<br />
[Accessed January 27, 2011].<br />
[64] QtMapNews. URL: http://wn.com/qtmapnews [Accessed December 28, 2010].<br />
[65] QtWeatherCameras. URL: http://wn.com/QtWeatherCameras [Accessed December<br />
28, 2010].<br />
[66] Quirksmode. Mobile Browsers URL: http://www.quirksmode.org/mobile/<br />
browsers.html [Accessed January 24, 2011].<br />
[67] Rademacher, P. HousingMaps.com. URL: http://www.housingmaps.com/.<br />
2005. [Accessed January 18, 2011].<br />
[68] Raento, M., Oulasvirta, A., Petit, R. and Toivonen, H. ContextPhone: A Prototyping<br />
<strong>Plat<strong>for</strong>m</strong> <strong>for</strong> Context-Aware Mobile Applications. IEEE Pervasive Computing,<br />
2005. Vol. 4:2. pp. 51–59. ISSN 1536-1268.<br />
[69] Raman, T. V. Toward 2W, Beyond <strong>Web</strong> 2.0. Communications of the ACM,<br />
2009. Vol. 52:2. pp. 52–59. ISSN 0001-0782.<br />
[70] Reynolds, F. <strong>Web</strong> 2.0 – In Your Hand. IEEE Pervasive Computing, 2009. Vol.<br />
8:1. pp. 86–88. ISSN 1536-1268.<br />
[71] Rogers, R. <strong>Developing</strong> Portable Mobile <strong>Web</strong> Applications. Linux Journal, 2010.<br />
Vol. 2010:197. pp. 3. ISSN 1075-3583.<br />
[72] Shaw, R., Troncy, R, and Hardman, L. LODE: Linking Open Descriptions<br />
of Events. In: Gómez-Pérez, A., Yu, Y. and Ding, Y. (Eds.) The Semantic<br />
<strong>Web</strong>, Lecture Notes in Computer Science. Vol. 5926. 2009. pp. 153–167. DOI:<br />
10.1007/978-3-642-10871-6 11.<br />
62
[73] Siyu, M., Qiu, Z. and Luo, L. Research on Mobile <strong>Web</strong> Applications End to End<br />
Technology. 10th IEEE International Conference on Computer and In<strong>for</strong>mation<br />
Technology, Brad<strong>for</strong>d, UK, June 29–July 1, 2010. pp. 2061–2065.<br />
[74] Sun Microsystems, Inc. Hadley, M. <strong>Web</strong> Application Description Language.<br />
URL: http://www.w3.org/Submission/2009/SUBM-wadl-20090831/. August<br />
31, 2009. [Accessed December 14, 2010].<br />
[75] Truong, H-L. and Dustdar, S. A Survey on Context-aware <strong>Web</strong> <strong>Service</strong> Systems.<br />
International Journal of <strong>Web</strong> In<strong>for</strong>mation Systems, 2009. Vol. 5:1. pp. 5–31.<br />
ISSN 1744-0084.<br />
[76] Ullman, C. What is Ajax?. URL: http://www.wrox.com/WileyCDA/Section/<br />
What-is-Ajax-.id-303217.html. 2007. [Accessed December 27, 2010].<br />
[77] Vaughan-Nichols, S. J. Will Mobile Computing’s Future Be Location, Location,<br />
Location?. Computer, 2009. Vol. 42:2. pp. 14–17. ISSN 0018-9162.<br />
[78] W3C: World Wide <strong>Web</strong> Consortium. Byers, P. (Aplix), Hirsch, F. (Nokia)<br />
and Hazaël-Massieux, D. (W3C). (Eds.) Permissions <strong>for</strong> Device API Access.<br />
URL: http://www.w3.org/TR/2010/WD-api-perms-20101005/. October<br />
5, 2010. [Accessed December 28, 2010].<br />
[79] W3C: World Wide <strong>Web</strong> Consortium. Bray, T. (Textuality and Netscape),<br />
Paoli, J. (Microsoft), Sperberg-McQueen, C. M. (W3C), Maler, E. (Sun Microsystems,<br />
Inc.) and Yergeau, F. (Eds.) Extensible Markup Language (XML)<br />
1.0. URL: http://www.w3.org/TR/REC-xml/#sec-origin-goals. November<br />
26, 2008. [Accessed December 22, 2010].<br />
[80] W3C: World Wide <strong>Web</strong> Consortium. Haas, H. (W3C) and Brown, A. (Microsoft,<br />
Inc.). (Eds.) <strong>Web</strong> <strong>Service</strong>s Glossary. URL: http://www.w3.org/TR/<br />
2004/NOTE-ws-gloss-20040211/. February 11, 2004. [Accessed December 14,<br />
2010].<br />
[81] W3C: World Wide <strong>Web</strong> Consortium. Hickson, I. (Google, Inc.). (Eds.) HTML5:<br />
A vocabulary and associated APIs <strong>for</strong> HTML and XHTML. URL: http://www.<br />
w3.org/TR/2010/WD-html5-20101019/. October 19, 2010. [Accessed December<br />
28, 2010].<br />
[82] Weaver, A. C. Secure Sockets Layer. Computer, 2006. Vol. 39:4. pp. 88–90. ISSN<br />
0018-9162.<br />
[83] Wikipedia Graphic Display Resolutions. URL: http://en.wikipedia.org/w/<br />
index.php?oldid=417030472 [Accessed March 7, 2011].<br />
[84] Wikipedia List of common resolutions. URL: http://en.wikipedia.org/w/<br />
index.php?oldid=417556789 [Accessed March 7, 2011].<br />
63
[85] Wikipedia <strong>Web</strong> Application. URL: https://secure.wikimedia.org/<br />
wikipedia/en/wiki/<strong>Web</strong>_application [Accessed December 22, 2010].<br />
[86] Xu, K., Zhang, X., Song, M. and Song, J. Mobile Mashup: <strong>Architecture</strong>, Challenges<br />
and Suggestions. International Conference on Management and <strong>Service</strong><br />
Science, Wuhan, China, September 20–22, 2009. pp. 1–4.<br />
[87] Yahoo! Inc. Yahoo! Maps <strong>Web</strong> <strong>Service</strong>s. URL: http://developer.yahoo.<br />
com/maps/. [Accessed December 22, 2010].<br />
[88] Ye, W., Hu, W., Zhao, W., Gao, X., Zhang, S. and Wang, L. Towards<br />
Lightweight Application Integration <strong>Based</strong> on Mashup. World Conference on<br />
<strong>Service</strong>s - I, Los Angeles, Cali<strong>for</strong>nia, July 6–10, 2009. pp. 500–506.<br />
[89] Yu, J., Bentallah, B., Saint-Paul, R., Casati, F. and Daniel, F. Understanding<br />
Mashup Development. IEEE Internet Computing, 2009. Vol. 12:5. pp. 44–52.<br />
ISSN 1089-7801.<br />
64
65<br />
Appendix: Comments from Expert Analysis<br />
Table A1: The results of the expert analysis discussed in section 5 and the possible actions taken<br />
in response are listed here.<br />
No. Issue<br />
=⇒ Action taken<br />
Requirements<br />
1 Requirement sections 3.1–3.3 are not concise enough<br />
=⇒ Added summary tables 2–3 to section 3<br />
2 No sources listed <strong>for</strong> the requirements in section 3. What are they based on?<br />
3 What is ‘context’ in the scope of the m.HUBI <strong>Plat<strong>for</strong>m</strong> architecture?<br />
4 Do mini browsers and full browsers (see section R8: Cross-device Functionality) both support plat<strong>for</strong>m<br />
applications to the same extent?<br />
5 Does multilingual content management (see section 3.2) consider language-specific layout issues such<br />
as width of textual elements?<br />
6 <strong>Service</strong>-specific requirements in section 3.3 are too product-specific. Requirements should be specified<br />
from a higher level e.g section R11: Journey Planner could be Routing.<br />
<strong>Architecture</strong> Documentation<br />
7 <strong>Architecture</strong> is missing a viewpoint definition. What is the meaning of the different colored boxes in<br />
Figure 8?<br />
8 External data sources and input interfaces not mentioned in plat<strong>for</strong>m architecture.<br />
=⇒ Added external data input interfaces to architecture description in section 4.<br />
9 Map interactivity: Are the maps served by the Map <strong>Service</strong> Component (see Figure 10) interactive<br />
as indicated in the requirement R4: Map?<br />
10 What relationship do the architecture’s client-side proprietary elements have with the client-side<br />
plat<strong>for</strong>m elements?<br />
11 What is the physical deployment of the plat<strong>for</strong>m especially in terms of scalability (see section R9:<br />
Scalability)?<br />
12 How does the Recommender <strong>Service</strong> (see section R13: Recommender) create the recommendations?<br />
=⇒ Added subsection 4.2.3 to architecture description.<br />
13 How is user activity tracking (see section R6: User Activity Tracking) handled <strong>for</strong> actions that do<br />
not require server communication?<br />
Javascript API<br />
14 Analysis scenarios: Unable to sort POIs by type.<br />
15 No explicit function <strong>for</strong> immediate location retrieval e.g. getLocation.<br />
16 No functions <strong>for</strong> explicit geocoding or reverse geocoding e.g. geocodeLocation( locString ) and<br />
reverseGeocodeCoordinate( lat, lon ).<br />
17 No corresponding start function <strong>for</strong> stopLocationShare in API Positioning Module.<br />
18 No functions <strong>for</strong> viewing, updating or managing user profile in API Foundation Module.<br />
19 No function <strong>for</strong> creating a new user account in API Foundation Module.<br />
20 No function to change application language.<br />
21 Is the positioning technology used relevant to the plat<strong>for</strong>m e.g. updateLocation( mode ) in API Positioning<br />
Module?<br />
22 Inefficient use of multiple functions <strong>for</strong> similar execution i.e. initializeIphoneMap and<br />
initializeWidgetMap and showUserOnMap and showPoisOnMap in API Map Module.<br />
23 All Event fields from R12: Events not represented in Javascript Object Class POI in API module POI.<br />
24 Amount of function-specific in<strong>for</strong>mation in section 4.4 insufficient. Either add more detailed in<strong>for</strong>mation<br />
i.e. return values and function descriptions or move function lists to appendix.