Providing access to a Public Transport Schedule system for Smart Phone Clients

Department of Science and Technology

Institutionen för teknik och naturvetenskap

Linköping University Linköpings Universitet

SE-601 74 Norrköping, Sweden

601 74 Norrköping

LiU-ITN-TEK-A--10/054--SE

Providing access to a Public

Transport Schedule system for

Smart Phone Clients

Katrin Hameseder

LiU-ITN-TEK-A--10/054--SE

Providing access to a Public

Transport Schedule system for

Smart Phone Clients

Examensarbete utfört i transportsystem

vid Tekniska Högskolan vid

Linköpings universitet

Katrin Hameseder

Handledare Anders Peterson

Examinator Anders Peterson

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –

under en längre tid från publiceringsdatum under förutsättning att inga

extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,

skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för

ickekommersiell forskning och för undervisning. Överföring av upphovsrätten

vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av

dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,

säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ

art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i

den omfattning som god sed kräver vid användning av dokumentet på ovan

beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan

form eller i sådant sammanhang som är kränkande för upphovsmannens litterära

eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se

förlagets hemsida

http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possible

replacement - for a considerable time from the date of publication barring

exceptional circumstances.

The online availability of the document implies a permanent permission for

anyone to read, to download, to print out single copies for your own use and to

use it unchanged for any non-commercial research and educational purpose.

Subsequent transfers of copyright cannot revoke this permission. All other uses

of the document are conditional on the consent of the copyright owner. The

publisher has taken technical and administrative measures to assure authenticity,

security and accessibility.

According to intellectual property law the author has the right to be

mentioned when his/her work is accessed as described above and to be protected

against infringement.

For additional information about the Linköping University Electronic Press

and its procedures for publication and for assurance of document integrity,

please refer to its WWW home page:

http://www.ep.liu.se/

Abstract

This master thesis was conducted during an internship at HBT GmbH with the purpose of providing access to an existing public transport schedule system in Hamburg (Germany) for smart phone clients. A state-of-the-art literature review and an evaluation of an existing SOAP (Simple Object Access Protocol) based web service to access public transport schedule information were conducted to identify the drawbacks of the existing interface with respect to the limitations and characteristics of smart phone clients. One of the main drawbacks is that the use of SOAP based web services and the associated data exchange format XML introduces a high amount of overhead that has to be transmitted between client and server. Additionally the information that is returned from the existing SOAP web service is not adjusted to the needs of smart phone clients. Based on these drawbacks recommendations are given how to implement an interface which provides an improved access to public transport schedule information for smart phone clients. These recommendations include the identification of public transport information that is most relevant for smart phone clients as well as to use REST (Representational State Transfer) web services and the data formats JSON and Fast Infoset for the implementation. To quantify the improvements that were achieved by accessing a newly implemented REST web service in terms of transferred data volume, request-response time and serialisation/deserialisation time a performance test was conducted. Therefore a native iPhone application was developed which accesses the existing SOAP based web service and the newly implemented REST style web service. The performance test showed that the use of the implemented REST web service to access public transport information from smart phone clients leads to a significant improvement in contrast to the existing SOAP based web service.

Contents

List of Abbreviations xiii

1 Introduction 1

1.1 Background . . . 1

1.2 Organisation of public transport in Hamburg . . . 1

1.3 Aim of this master thesis . . . 4

1.4 Overview of the master thesis . . . 5

2 Smart Phones 7 2.1 Why are native applications developed? . . . 9

2.1.1 Market analysis - smart phones . . . 10

2.2 Available operating systems for Smart Phones . . . 12

2.2.1 Symbian OS . . . 12

2.2.2 iOS . . . 14

2.2.3 Windows Mobile . . . 15

2.2.4 Android . . . 16

2.3 Comparison of available smart phones . . . 16

3 Web Services 19 3.1 Web service architecture . . . 20

3.1.1 Web Services Styles . . . 22

3.1.2 RPC web services . . . 22

3.1.3 SOAP web services . . . 23

3.1.4 REST web services . . . 25

3.1.5 Comparison of RPC/SOAP/REST web services . . . 26

3.2 Web service description . . . 27

3.3 Web service frameworks . . . 29

3.3.1 Apache Axis2 . . . 29

3.3.2 Apache CXF . . . 31

3.3.3 GlassFish Metro . . . 33

3.3.4 JBossWS . . . 34

3.3.5 Comparison Axis2/CXF/Metro/JBossWS . . . 35

3.4 Data exchange formats . . . 36

3.4.1 XML . . . 36

3.4.2 JSON . . . 37 iii

3.4.3 Fast Infoset . . . 38

3.4.4 Comparison XML/JSON/Fast Infoset . . . 38

4 Literature Review 41 5 Existing Public Transport Schedule Systems 47 5.1 Hamburg . . . 47 5.1.1 GEOFOX . . . 48 5.1.2 Other services . . . 52 5.2 Vienna . . . 53 5.2.1 PT schedule information . . . 53 5.2.2 Qando . . . 55 5.2.3 Additional services . . . 57 5.3 Stockholm . . . 57 5.3.1 Trip Planner . . . 58

5.4 Comparison of existing systems . . . 61

6 Practical Analysis 65 6.1 Evaluation of the existing GEOFOX SOAP web services . . . 65

6.1.1 Architecture . . . 66

6.1.2 Core web services . . . 67

6.1.3 Clients . . . 69

6.1.4 Identified drawbacks . . . 70

6.2 Recommendations to reduce identified drawbacks . . . 72

6.2.1 Information adjustment . . . 72

6.2.2 Use of REST web service style . . . 73

6.2.3 Different access control approach . . . 83

6.3 Implementation of new web service . . . 84

6.3.1 Design of new web service . . . 84

6.3.2 Implementation of new web service using Apache CXF . . . 86

6.4 Conduction of performance test . . . 89

6.4.1 Identification of test environment . . . 90

6.4.2 Identification of performance indicators . . . 96

6.4.3 Planning and design of test . . . 96

6.4.4 Configuration of test environment . . . 99

7 Results 103 7.1 Transferred data volume . . . 104

7.2 Serialisation/Deserialisation time . . . 107

7.3 Request-response time . . . 109

8 Discussion and Conclusion 115 8.1 Future work . . . 120

Bibliography 121

List of Figures

1.1 Organisation of local PT in HVV service area . . . 2

1.2 Access statistics GEOFOX Mobile June 2010 . . . 4

2.1 Classification of mobile devices . . . 8

2.2 Market shares 2008/2009 - worldwide smart phone market by vendors 11 2.3 Comparison of supported programming languages of Symbian OS . 14 2.4 Layers of iPhone OS . . . 14

2.5 Simplified overview of Android OS architecture . . . 16

3.1 Client/Server communication via web services . . . 20

3.2 Simplified overview of web service architecture . . . 21

3.3 Web service architecture stack . . . 21

3.4 RPC message . . . 22

3.5 SOAP message . . . 23

3.6 SOAP web service . . . 24

3.7 HTTP request containing SOAP message . . . 24

3.8 REST web service . . . 26

3.9 Differences WSDL 1.1 / WSDL 2.0 . . . 28 3.10 Axis2 architecture . . . 30 3.11 CXF architecture . . . 32 3.12 Metro architecture . . . 34 3.13 JBossWS architecture . . . 35 3.14 Example of XML document . . . 37

3.15 Example of JSON message . . . 38

3.16 Comparison XML document/Fast Infoset document . . . 39

4.1 XML compression and the impact on resonse time . . . 42

4.2 Data traffic when using JXTA, XML web service and WBXML web service and resulting transmission delay . . . 43

4.3 Connection overhead vs. packet overhead using different SOAP bindings . . . 44

4.4 Framework architecture to eliminate XML processing on mobile clients 45 5.1 Hamburg: PT schedule system GEOFOX . . . 48

5.2 Hamburg: GEOFOX - check input . . . 49

5.3 Hamburg: GEOFOX - result screen . . . 50

5.4 Hamburg: GEOFOX - mobility information . . . 51

5.5 Hamburg: GEOFOX Mobile for iPhone and cell phones . . . 52

5.6 Hamburg: SMS ticket . . . 52

5.7 Vienna: PT schedule system . . . 54

5.8 Vienna: PT schedule system - result screen . . . 55

5.9 Vienna: personal schedule . . . 56

5.10 Vienna: journey planner (AnachB) . . . 58

5.11 Stockholm: trip planer . . . 59

5.12 Stockholm: trip planer - result screen . . . 60 v

5.13 Stockholm: mobile trip planer . . . 60

6.1 Wired devices accessing GEOFOX SOAP web services . . . 66

6.2 Structure of test web service . . . 75

6.3 Axis2 work flow . . . 76

6.4 CXF workflow . . . 80

6.5 Access control - signature . . . 84

6.6 Excerpt of WSDL of new web service . . . 86

6.7 Access control approach using HMAC-SHA1 . . . 88

6.8 Flow diagram of access control interceptor . . . 88

6.9 Accessing GEOFOX from wired and wireless devices . . . 89

6.10 Core performance testing activities . . . 90

6.11 Test environment . . . 91

6.12 Start screen of iPhone application . . . 91

6.13 iPhone application - checkname UI / input data . . . 92

6.14 iPhone application - activity indicator/checkname . . . 92

6.15 Program flow of iPhone application . . . 93

6.16 Serialisation and deserialisation process . . . 101

6.17 Storing of measurement results of performance test . . . 102

7.1 Transferred data [bytes] when accessing the web service method checkname of the GTI web service using supported data formats . 105 7.2 Transferred data [bytes] when accessing the web service method getroute of the GTI web service using supported data formats . . . 105

7.3 Transferred data [bytes] when accessing the web service method checkname of the GTI and GEOFOX SOAP web service . . . 106

7.4 Transferred data [bytes] when accessing the web service method getroute of the GTI and GEOFOX SOAP web service . . . 106

7.5 Serialisation/Deserialisation time [ms] when accessing the web ser-vice method checkname of the GTI and GEOFOX SOAP web serser-vice108 7.6 Serialisation/Deserialisation time [ms] when accessing the web ser-vice method getroute of the GTI and GEOFOX SOAP web serser-vice 109 7.7 Request-response time [ms] when accessing the web service method init of the GTI and GEOFOX SOAP web service (2G network con-nection) . . . 110

7.8 Request-response time [ms] when accessing the web service method getroute of the GTI and GEOFOX SOAP web service (2G network connection) . . . 111

7.9 Fluctuations of request-response time [ms] when accessing the web service method getroute of the GTI and GEOFOX SOAP web ser-vice (2G network connection) . . . 111

7.10 Request-response time [ms] when accessing the web service method init of the GTI and GEOFOX SOAP web service (3G network con-nection) . . . 112

7.11 Request-response time [ms] when accessing the web service method getroute of the GTI and GEOFOX SOAP web service (3G network connection) . . . 113 7.12 Fluctuations of request-response time [ms] when accessing the web

service method getroute of the GTI and GEOFOX SOAP web ser-vice (3G network connection) . . . 113 7.13 Fluctuations of request-response time [ms] when accessing the web

service method getroute of the GTI and GEOFOX SOAP web ser-vice (Ethernet connection) . . . 114

List of Tables

2.1 Market shares 2008/2009 - worldwide smart phone market by OS . 11

2.2 Runtime features . . . 13

2.3 Windows Mobile APIs . . . 15

3.1 REST data elements . . . 25

3.2 Elements of JSON message . . . 37

5.1 Hamburg: GEOFOX - optional parameters . . . 49

5.2 Vienna: PT schedule system - optional parameters . . . 54

5.3 Vienna: Qando - provided features . . . 56

5.4 Comparison of existing systems in Hamburg, Vienna and Stockholm 61 5.5 Comparison of existing smart phone systems in Hamburg, Vienna and Stockholm . . . 62

6.1 GEOFOX SOAP web services representing core features . . . 67

6.2 GEOFOX SOAP InitData web service . . . 68

6.3 GEOFOX SOAP CheckName web service . . . 68

6.4 GEOFOX SOAP GRSearch web service . . . 69

6.5 SOAP message vs. REST message . . . 73

6.6 CXF configuration file: registration of SOAP and REST web services 80 6.7 Comparison of Axis2/CXF: REST, JSON, Fast Infoset support . . 82

6.8 Message types - init web service method . . . 98

6.9 Average overhead introduced by the measurement method in seconds101 7.1 Results: transferred data volume [bytes] . . . 104

7.2 Results: serialisation time [ms] . . . 107

7.3 Results: deserialisation time [ms] . . . 108

7.4 Results request-response time [ms] when using 2G network connection110 7.5 Results request-response time [ms] when using 3G network connection112 7.6 Results request-response time [ms] when using the iPhone simulator and Ethernet connection . . . 114

8.1 Identified drawbacks and recommendations to reduce drawbacks . 115 8.2 Summary performance test: best performing web service/data ex-change format . . . 119

Listings

6.1 Skeleton of REST style web service when using Apache CXF . . . 79 6.2 Interface of GTI web service . . . 86 6.3 Measuring time difference in Objective-C . . . 100

List of Abbreviations

2G 2nd Generation 3G 3rd Generation ADB Axis Data Binding

API application programming interface

BKG Bundesamt für Kartographie und Geodäsie CF Compact Framework

CSS Cascading Style Sheets CPU Central Processing Unit DOM Document Object Model DTD Document Type Definition

EDGE Enhanced Data Rates for GSM Evolution FIS Fahrgast-Informations-System

FTP File Transfer Protocol GK Gauss Krüger

GSM Global System for Mobile Communications GPS Global Positioning System

GTI GEOFOX Thin Interface

HBT Hamburger Berater Team für Personal, Organisation und Datenverarbeitung GmbH

HMAC Keyed-Hash Message Authentication Code HSDPA High Speed Downlink Packet Access HTC High Tech Computer Corporation HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure HVV Hamburger Verkehrsverbund GmbH ID Identification

IDE Integrated Development Environment JDK Java Development Kit

JSON JavaScript Object Notation JSP Java Server Pages

ME Mobile Edition

MEP Message Exchange Pattern

MIDP-2 Mobile Information Device Profile - version 2 MIME Multipurpose Internet Mail Extensions

MSIL Microsoft Intermediate Language MTRC Mass Transit Railway Corporation OOP object-oriented programming OS operating system

PDA Personal digital assistant POI point of interest

POJO Plain Old Java Object P&R Park-and-Ride

PT public transport RAM random-access memory

REST Representational State Transfer RIM Research in Motion

RPC Remote Procedure Call SAX Simple API for XML SDK Software Development Kit SHA1 Secure Hash Algorithm 1 SL Storstockholms Lokaltrafik SME small and medium-sized enterprise SMS Short Message Service

SMTP Simple Mail Transfer Protocol SOAP Simple Object Access Protocol TCP Transmission Control Protocol UDP User Datagram Protocol UI user interface

UMTS Universal Mobile Telecommunications System URI Uniform Resource Identifier

URL Uniform Resource Locator

VOR Verkehrsverbund Ost-Region GmbH W3C World Wide Web Consortium WGS84 World Geodetic System 1984 Windows CE Windows Compact Edition Wiener Linien Wiener Linien GmbH & Co KG WSDL Web Services Description Language WWW World Wide Web

XML Extensible Markup Language ZVU Zentrale Verkehrsunternehmen

Chapter 1

Introduction

1.1

Background

In the last years the interest for native smart phone applications in many different fields (e.g. travelling, cooking, music) has gained momentum. This interest is originated by smart phones entering the market that are characterised by high usability and contain a number of helpful applications addressing a large target group. By now it is also possible for third parties to develop native applications for most of the smart phones that are currently available on the market.

The Hamburger Verkehrsverbund GmbH (HVV) (a transport association in North-ern Germany) currently offers a personal public transport (PT) schedule system – called GEOFOX – on their website which was implemented by the Hamburger Berater Team für Personal, Organisation und Datenverarbeitung GmbH (HBT). In order to improve the accessibility of this system for the PT customers and to also address the target group of smart phone users the idea of the HBT and HVV is to offer GEOFOX as a native application for smart phones.

1.2

Organisation of public transport in Hamburg

The HVV is a transport association in Northern Germany and provides transport and customer services on the behalf of the PT authorities. The actual service offer is provided by different transport operators (e.g. Hamburger Hochbahn AG) while the HVV coordinates their work to ensure that an integrated offer is easily accessible to the customers in and around Hamburg. The organisational structure

2 Introduction

of the local PT in the HVV service area is shown in Figure 1.1. One characteristic of this organisational structure is that some of the transport operators (see op-erational level Figure 1.1) are “Transport operators performing centralized duties” - Zentrale Verkehrsunternehmen (ZVU). This means that common tasks are dis-tributed among transport operators and are performed by them on behalf of the HVV based on commissioning contracts. Next to the implementation of an inte-grated fare system and schools advisory service also the provision of “central HVV

passenger information” is one of the distributed tasks. This task is performed

by the Hamburger Hochbahn AG. The existing GEOFOX system offered by the HVV was implemented by the company HBT while the Hamburger Hochbahn AG as a transport operator performing centralised duties has the right of use for the software.

Figure 1.1. Organisation of local PT in HVV service area adapted from [31]

This master thesis is conducted during an internship at HBT. HBT was found in 1983 as a general partnership by Ilse and Hans-Joachim Habermann. Shortly after the foundation it was turned into a limited liability company. The company belongs to the group of small and medium-sized enterprise (SME) and is offering IT services and services in the field of organisation development. Their customers are primarily from the sectors of:

• transport/logistics • bank/insurance industry • public authorities

One core project is a personal PT schedule system where the first version was developed in 1990 by Friedemann Weik and Michael Malsch. This pilot project

-1.2 Organisation of public transport in Hamburg 3

called Fahrgast-Informations-System (FIS) - was established in collaboration with an institution of the University of Hamburg dealing with artificial intelligence. FIS was implemented using the programming language Common Lisp and based their routing on the A* algorithm. In 1992 a new version of the system – called GEOFOX – was launched that contained an adaptation of the A* algorithm. One year later the Hamburger Hochbahn AG acquired the right of use for the system. In 1996 GEOFOX was ported from Common Lisp to Java and in 1998 the service was offered on the Internet the first time.

Since 2005 the features of GEOFOX are also available as a Simple Object Access Protocol (SOAP) web services. However the GEOFOX SOAP web services are subject to restricted access. Right now the GEOFOX SOAP web services are accessed by:

• voice portal of the directory enquiries of the HVV • ticketing system for mobile phones

• University of Applied Sciences Wedel for educational purposes

As applications for mobile devices became more popular and many other transport operators and transport associations offered applications in the field of PT the HVV launched GEOFOX Mobile in 2009. GEOFOX Mobile is available on a website and offers a subset of the existing GEOFOX system optimised for mobile devices. The screen size was adjusted to the display size of mobile devices and as an additional feature routing from the actual position of the user (using a Global Positioning System (GPS) receiver) was added. GEOFOX Mobile is available in four different versions (smart phone: iPhone, other smart phones (small), other smart phones (wide) and cell phones) where each version is adjusted to the screen size of specific mobile devices [32].

As the interest for native applications increased and the optimised website GEO-FOX Mobile only offers limited functions and does not fully utilise the characteris-tics of mobile devices (look&feel characterischaracteris-tics of the application, characterischaracteris-tics with respect to handling) the HVV desires to offer GEOFOX as a native smart phone application. When looking at the access statistics of the GEOFOX Mobile website (see Figure 1.2) it becomes apparent that the vast majority of access orig-inates from smart phone users. The majority of these smart phone users facilitate an iPhone to access the website. In consequence the HVV decided to choose the iPhone as the mobile platform for the future native application. Since HBT im-plemented the existing GEOFOX web services that are accessed by a number of services they want to provide an interface that can deal with the requirements and limitations of smart phones. Although the HVV has decided to use the iPhone as the mobile platform the HBT wants to provide an interface that is not tailor-made for a specific platform.

4 Introduction

Figure 1.2. Access statistics GEOFOX Mobile June 2010 adapted from [34]

This leads to the aim of HBT to provide a non restraining interface that can easily be accessed by different native smart phone applications keeping their require-ments and limitations in mind. This should ease future work and projects for the implementation of applications for state-of-the-art smart phones.

1.3

Aim of this master thesis

As the features of the PT schedule system GEOFOX can already be accessed by a number of SOAP based web services the aim of this master thesis is to evaluate the existing interface with respect to the characteristics and limitations of smart phone clients. Based on this evaluation the master thesis aims to recommend and implement possibilities to improve the access to PT schedule information for smart phone clients. In order to verify that improvements have been achieved a performance test is conducted that measures the following performance indicators:

• request-response time [ms]

• serialisation/deserialisation time [ms] • transferred data volume [bytes]

The following list of questions summarises the aim of the master thesis:

• Can the existing interface be used for the data transfer between the server and smart phone clients?

1.4 Overview of the master thesis 5

• How can these web services be adjusted in order to deal with the requirements and limitations of smart phones?

• What are the main criteria of designing a new interface that is tailor-made to the requirements and limitations of smart phones?

• What information is relevant for smart phone clients and is there potential to simplify it?

• Has the new interface achieved improvements?

1.4

Overview of the master thesis

As an introduction the master thesis provides insight into the smart phone market and web services. By analysing the current smart phone market the leading ven-dors, the most sold smart phones and the characteristics of their operating systems are identified. Only by understanding the basics of the operating systems it is pos-sible to identify different possibilities on how native applications can be developed. The analysis includes the available Software Development Kit (SDK), Integrated Development Environment (IDE) and platforms on which the application can be developed. This knowledge is important as it depicts limitations that have to be taken into account when designing a client/server interface. As the existing GEOFOX interface is implemented by using SOAP based web services the possi-bilities and associated drawbacks are determined based on the current literature about web services. Additionally the topic of common web service frameworks are described as well as data formats that can be used for the exchange of the data between the client and server. Next to this introductory information a literature review about other research that is related to the thesis topic is conducted. This is followed by a practical analysis. In order to ensure that a structured approach is used for the practical analysis a methodology was developed which consists of:

1. Evaluation of the existing GEOFOX SOAP web services 2. Recommendations for improvements

3. Implementation/adjustment of web service based on the recommendations 4. Conduction of performance test

5. Results

6 Introduction

1. Evaluation of the existing GEOFOX SOAP web services

An evaluation of the existing GEOFOX SOAP web services was performed in order to determine if they are suitable to be accessed by smart phone clients. This evaluation includes an overview of the architecture, the core features and an analysis of the clients that currently use the GEOFOX SOAP web services. This evaluation enables the identification of drawbacks of the existing GEOFOX SOAP web services with respect to the limitations of smart phone clients.

2. Recommendations for improvements

Based on the identified drawbacks possibilities to implement an improved interface to access PT schedule information is recommended. These recommendations con-tain measures how to create a new interface in order to improve the performance indicators, namely request-response time, processing time and transferred data.

3. Implementation of new web service

Based on the given recommendations a new web service was implemented.

4. Conduction of performance test

To verify that the newly implemented web service leads to improvements of the performance indicators a performance test was conducted. To ensure that the test is close to the future use of the web service a native smart phone appli-cation was implemented to conduct the performance test. For this purpose the iPhone was chosen as the mobile platform for the native application. The native iPhone application accesses the existing GEOFOX SOAP web services and the newly implemented web service and takes measurements of the performance indi-cators request-response time, serialisation/deserialisation time on the iPhone and transferred data volume. The response time is the time difference of sending the request to the web service and receiving the response on the iPhone. It will be mea-sured using common 2nd Generation (2G) and 3rd Generation (3G) technologies (Enhanced Data Rates for GSM Evolution (EDGE), Universal Mobile Telecom-munications System (UMTS), High Speed Downlink Packet Access (HSDPA)). EDGE is considered as a 2G technology and is an extension of the Global System for Mobile Communications (GSM) standard. In contrast the technologies UMTS and HSDPA are considered as 3G technologies. HSDPA is based on UMTS and provides higher data rates.

5. Results

The measurement results of the performance test are shown and visualised.

6. Discussion & Conclusion

Chapter 2

Smart Phones

To provide an existing personal public transport schedule system for a new tar-get group - in this case users of smart phones - a first step is to investigate the characteristics of the target group of smart phones. In the following chapter an overview and market shares of state-of-the-art smart phones and their vendors is given. Based on this information it is possible to give suggestions of how to cre-ate a client/server interface that can be used from clients (stcre-ate-of-the-art smart phones) with different requirements and characteristics.

First of all it is important to understand what is at the bottom of the term smart phone. Smart phones number among the term mobile devices where Brans [15, p. 52] categorises mobile devices into:

• cell phone • smart phone

• Personal digital assistant (PDA) • tablet computer

• notebook computer

Devices of the different groups differ in computing power, provided features, costs, size/weight, and battery life. Figure 2.1 classifies the different mobile devices by the parameters costs and features.

8 Smart Phones

Figure 2.1. Classification of mobile devices [15, p. 53]

Brans [15, p. 62] describes smart phones as “devices that perform the function of

both phones and PDAs”. This means smart phones come with higher computing

power and offer next to phone and data services (e.g. Short Message Service (SMS)) additional functions like calendar or the possibility to take notes.

There are a number of requirements of smart phones that have to be taken into account when developing applications for smart phones:

• limited resources • no hard disc • power management • compact size • reliability

The most important factor is that smart phones are limited in their Central Pro-cessing Unit (CPU), main memory and random-access memory (RAM) which has to be kept in mind when developing applications. As mobile devices and particu-larly smart phones only have limited power supplies it is of importance to design the application in a way that ensures that as less power as possible is consumed and that the processed data is kept in case of power loss. Smart phones are char-acterised by their compact size resulting in less space for the user interface (UI) of the application. Finally the core function of a smart phone is the phone function-ality that should always have the highest priority. This means that applications should be able to detect incoming calls and notify the user at all times [39, p. 10].

2.1 Why are native applications developed? 9

2.1

Why are native applications developed?

When using the term native applications in this context applications designed to run on a specific platform are meant. To answer the question why native appli-cations should be developed first the alternative to native appliappli-cations has to be identified. As almost all smart phones had a browser application preinstalled the only way to access applications other than native applications (applications in-stalled on the smart phone) was the Internet by accessing web applications. When the first iPhone was launched no native SDK was available and Apple argued that there is no need for a native SDK as developers should build web appli-cations using JavaScript, Cascading Style Sheets (CSS) and Hypertext Markup Language (HTML) [2, p. 1-3]. In the meanwhile, also caused by the developer community, there is a native SDK available and also all other vendors of operating systems provide the possibility to create applications running on their platform (see Chapter 2.2).

When looking at the market of mobile devices right now native applications out-paced web applications. Primarily the purpose of the application is decisive for the decision if a web application or a native application is best suitable. Facts that outline the advantages of developing a native application are [27]:

• Considering the location of the user:

Some applications may want or need to integrate and take advantage of the current location of the user. Next to the possibility to detect the loca-tion based on the GSM cell the user is connected to more and more smart phones are equipped with GPS receivers. However there are also application programming interfaces (APIs) available enabling the determination of the location using mobile browsers (see W3C Geolocation API [85]).

• Access to functions and features of the device:

Functions and features like camera or accelerometer can only be accessed by native applications. Accessing the camera might be useful for several mobile applications (e.g. adding pictures to a note in a Todo list) and it can even be used to process bar codes. Using the accelerometer can be helpful in applications as it enables the possibility to react on the movements of the device. This means that the displayed content can be adjusted and optimised (changing orientation from vertical to horizontal or vice versa) when the device is physically rotated. This is a benefit for the user of the smart phone as the user can hold the device in the hand as he likes while the application adjusts itself to the changes.

• Access to the file system:

If the application requires that data is stored and able to be accessed (e.g. addresses, telephone numbers) on the device a native application is needed. Of course accessing the file system is associated with security and privacy

10 Smart Phones

issues. Furthermore the memory of smart phones is quite limited, therefore the storage of data on the smart phone itself should be minimised.

• Offline applications:

An obvious reason why a native application is the only way to go is when users should be able to use the application if they have no access to the Internet or they are out of range of mobile networks. There might be a number of applications where the target user group is most likely offline (e.g. public transport information for rural areas, applications for hikers). This factor is most often neglected as it is assumed that a wireless connection is always available. However native applications should also offer the user a certain extent of functionality without a wireless connection.

Certainly there are also disadvantages when developing native applications. The most important disadvantage is that the portability of native applications is much more difficult. Native applications are designed for specific hardware and therefore the target user group is limited. Another drawback, especially when developing native applications for iPhones, is that the distribution channel might be limited. However disadvantages for developers might be advantages for the user as iPhone users can find all kind of applications at one central distribution channel (the AppStore). It is also safe to say that only native applications are adjusted to the look-and-feel of the device which most often results in more appealing applications to the user. Also the use of functionalities and features of the device enables more possibilities for the developer how to create the application. At the end the purpose of the application and the target user group will be decisive for the choice between a web application or a native application.

2.1.1

Market analysis - smart phones

When looking at Figure 2.2 the five most important vendors for smart phones in the last two years were:

• Nokia

• Research in Motion (RIM) • Apple

• High Tech Computer Corporation (HTC) • Fujitsu

2.1 Why are native applications developed? 11

Figure 2.2. Market shares 2008/2009 - worldwide smart phone market by vendors adapted from [18]

For the architecture and implementation of an interface that will be used from state-of-the-art smart phones it is important to know which operating systems (OSs) are used from the leading vendors. The market leader Nokia uses Symbian OS for their smart phones [48] while RIM, the vendor of Blackberry, uses a propri-etary OS for their smart phones. Apple, the vendor with the third biggest market share, provides smart phones called iPhone that operate on iOS (former iPhone OS) developed by Apple. HTC offers smart phones based primarily on Windows Mobile, but in 2009 they began to focus on devices based on the Android operating system.

When looking at Table 2.1 the distribution of the market shares of the operating systems conform to the ranking of the vendors in Figure 2.2.

Table 2.1. Market shares 2008/2009 - worldwide smart phone market by OS adapted

from [19]

To make suggestions how to create an efficient client/server interface a deeper insight in the used operating systems and possibilities how to create native smart phone applications on the specific OS is helpful.

12 Smart Phones

2.2

Available operating systems for Smart Phones

As depicted in Table 2.1 the most common operating systems in the smart phone market are:

• Symbian OS

• Properietary OS for Blackberry • iPhone OS

• Windows Mobile • Android

As the main market for Blackberry devices is North America [20] and the PT sched-ule system will be available for the region of Hamburg (Germany) the proprietary OS for Blackberry devices will not be considered in the following overview.

2.2.1

Symbian OS

Symbian OS is an operating system for smart phones and PDAs and was developed by Symbian Ltd. for “the use in small battery-powered devices with extensive

communications capabilities” [23, p. xviii]. The OS is licensed and used by phone

manufacturers like Nokia and Samsung. In 2008 it was announced that Symbian OS will be transferred to the Symbian Foundation - an “independent, non-profit

organisation whose mission is to enable an open ecosystem that collaborates to create the most complete and richest user experiences for mobile devices” [67].

The process of moving the platform’s source code to open source was completed in February 2010 [68].

When developing a native application for smart phones running on Symbian OS the first decision to make is which programming language to use. Next to their native programming language Symbian C++ eight other programming languages namely C/C++, Flash light, Java Mobile Edition (ME), .NET, Python, Qt, Ruby, Web technologies (Widgets) are supported [65]. As all of the supported programming languages have their advantages and disadvantages the decision which language to choose depends on the:

• functionality and performance of the native application • target user group (e.g. experience)

2.2 Available operating systems for Smart Phones 13

• costs (for e.g. IDE)

The most important factor is what features (e.g. camera, Bluetooth communica-tion) of the smart phone can be accessed using a specific programming language. Table 2.2 gives an overview about the featured functionalities of the different run-time environments. As expected the native runrun-time environment of Symbian C++ enables the access of most of the available features from the native application without further restraints. The only features that are not supported are writing Extensible Markup Language (XML) files, HTML and JavaScript. Although Ruby and .NET are supported by Symbian OS their APIs support only a few possibilities to use the features of the smart phone. Depending on the purpose of the native application features like accessing the camera or communication using Bluetooth might not be needed. However environment awareness like recognising incoming calls or SMS is an essential factor. Almost all smart phone users expect that they will be notified about an incoming call while using a native application. As .NET does not support environment awareness at all this might be a knock-out criterion for choosing .NET as the programming language for the native application.

Table 2.2. Runtime features adapted from [66]

Figure 2.3 classifies the supported programming languages according to the ease of development and their functionality/performance. It can be seen that the use of native programming languages results in the best performance and allows the use of more functionality, but it is more difficult for the programmer to develop. Symbian OS gives the developer a wide range of programming languages to choose and in the end the requirements of the native application will be decisive for the choice.

14 Smart Phones

Figure 2.3. Comparison of supported programming languages of Symbian OS adapted

from [38]

2.2.2

iOS

iOS is the mobile operating system from Apple and is based on the proprietary Unix-system Mac OS X. It was developed for the iPhone and is also deployed on the iPod Touch and iPad by now. The newest operating system iOS 4 was released in June 2010 [13]. As the iPhone OS is based on Mac OS X they have similar architectures. As depicted in Figure 2.4 iOS is composed out of five layers. For writing native applications the most important layer is Cocoa Touch as it contains the key frameworks that are needed for developing native iPhone applications [6], [7].

Figure 2.4. Layers of iPhone OS adapted from [6]

For developers of native iPhone applications Apple offers the iPhone SDK for the different available versions of iOS. Since the launch of the newest operating system iOS 4 in June 2010 also the SDK4 is available. SDK4 includes the Xcode IDE, an interface builder, instruments for performance analysis, debugging tools, iPhone Simulator and the iPhone Reference Library for creating applications for iPhone and iPod touch which operate on iOS 4. The SDK can only be installed on an Intel-based Macintosh computer running Mac OS X Leopard. In order to download the necessary SDK it is required to be registered as an Apple Developer. The registration itself is for free and enables the development of native applications that can be tested on the iPhone Simulator. However, if the developer wants to test the application on the device it is necessary to sign the application which requires enrolment in the Apple Developer Program that is not for free. The enrolment

2.2 Available operating systems for Smart Phones 15

is possible for individual persons or for companies allowing them to install their developed applications on the device and distribution over the AppStore [91, p. 6].

For developing native iPhone applications Ojective-C and the Apple’s Cocoa frame-work has to be used. According to Davidson et al. [5, p: 8-9] Cocoa can be de-scribed as an “advanced object-oriented framework” including “an integrated set of

shared object libraries, a runtime system and a development environment”. Cocoa

applications for Mac OS can be built in the programming languages Objective-C, Java and Apple Script while Objective-C is the “native language of Cocoa”. For the development of applications for iOS Objective-C has to be used.

Apple dictates the developers which programming language and frameworks to use when developing native iPhone applications. This constraint has on the one hand the disadvantage that the access hurdle for developers is higher. However on the other hand this constraint ensures that each developer uses the same tool kit resulting in applications that have the same look-and-feel characteristics.

2.2.3

Windows Mobile

Windows Mobile is the version of Windows for embedded devices and is based on Windows Compact Edition (Windows CE). For developing applications for Win-dows Mobile the developer can choose from five WinWin-dows Mobile APIs. Table2.3 shows the supported APIs and the respective programming language [90].

Table 2.3. Windows Mobile APIs adapted from [90]

For developing the IDE Microsoft Visual Studio 2008 can be used. One big dif-ference between the provided APIs is that applications using the .NET Compact Framework (CF) are compiled into the portable machine language Microsoft In-termediate Language (MSIL). All other APIs create native executable files. This means that applications compiled into MSIL can run on every system containing the .NET runtime environment which includes the just-in-time compiler.

As the CF is a subset of the .NET Framework it is easier for programmers that are familiar with the .NET framework to create applications. The .NET Framework offers - unlike Win32 - the benefit of supporting object-oriented programming

16 Smart Phones

(OOP). However depending on the functionality of the application it could be required to use Win32 code (e.g. for writing device drivers) [90].

2.2.4

Android

Android is a mobile phone operating system that was developed by the Open Hand-set Alliance and was announced in November 2007. The Open HandHand-set Alliance is a group of more than 70 companies that is “committed to fostering innovation on

mobile devices and bringing consumers innovative new mobile experiences” [50].

As can be seen in Figure 2.5 the Android OS is based on a Linux kernel and con-tains several libraries, the Android runtime, an application framework and a set of core applications. The android runtime contains the Dalvik virtual machine that

“runs classes compiled by a Java language compiler that have been transformed into” the Dalvik Executable format .dex [3].

Figure 2.5. Simplified overview of Android OS architecture adapted from [3]

For creating applications running on the Android platform the Android SDK was released. It contains next to development and debugging tools also a set of libraries and a device emulator [50]. Android SDK requires the Java Development Kit (JDK) for developing applications using the Java programming language.

2.3

Comparison of available smart phones

Looking back at the previous chapters it can be summarised that native appli-cations are able to make use of functionalities and features of the smart phone, to integrate onboard sensors and to design an adjusted UI. All of these factors improve the user experience - and at the end this will be one driving factor for purchasing a specific device or application.

2.3 Comparison of available smart phones 17

The market analysis showed that there are five important vendors offering state-of-the-art smart phones while these smart phones run on five different operating systems. While most of the vendors stick to one operating system for their smart phones HTC brought smart phones running on Windows Mobile and Android to the market. Depending on the operating system there are SDKs available to de-velop applications that run on the smart phone. Apple adheres to their policy to offer products and applications fulfilling Apple’s corporate identity - therefore it is only possible to develop native applications using the iPhone SDK and the programming language Objective-C. On the other hand smart phones operating on Symbian OS allow the developers more options to decide in which program-ming language the application is developed. However all vendors of the operating systems recommend to use the native programming language when developing applications.

Another factor for choosing the platform might be the possibilities of distributing the applications. Again Apple chose a restrictive policy as the only way to dis-tribute native iPhone applications is over the AppStore. Which platform to choose is left to the developer depending on the target user group and the purpose of the application.

Chapter 3

Web Services

A web service is commonly used to exchange data between distributed systems over a network using standard-based Internet protocols and is therefore one possibility to implement a client/server interface. This chapter will describe the architecture of web services (Chapter 3.1), the technologies behind web services and how web services can be used practically to realise a client/server interface (Chapter 3.3). The official definition of a web service was given in a Note released by the World Wide Web Consortium (W3C) [81] where a web service is defined as

“a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialisation in conjunction with other Web-related standards. A Web service is an abstract notion that must be implemented by a concrete agent.”

This definition already contains a number of protocols, but it also does not state constraints about programming languages or operating systems. This leads to the most important advantage of web services. They can be used in different environ-ments, using different programming languages by communicating via standardised communication protocols and data exchange formats. Figure 3.1 illustrates the communication between client and server using a web service.

20 Web Services

Figure 3.1. Client/Server communication via web services adapted from [61, p. 2]

3.1

Web service architecture

In order to explain the architecture it is important to define some terms that are used [81].

Agent: a computational resource that implements web services

Provider: a person/organisation that provides an agent to implement the service Requester: a person/organisation that uses the provider’s web service

Service description: a machine-processable specification of the web service

in-terface (written using Web Services Description Language (WSDL))

As the entire architecture is quite complex it makes sense to divide the architecture into several parts where in each part another aspect of web services is highlighted. The following paragraphs will give an short overview of four different models that form the web service architecture namely (see Figure 3.2):

• Service oriented model: this model focuses on the meta-data that describes the service, the provider that owns the web service and the agent that realises it. As a service relates to messages also messages are part of the view. • Message oriented model: web services are explained from the perspective

of the message itself. This includes the structure of the message (body, header) and the message protocol, the agent (as sender and receiver), delivery policies, etc. This model does not attempt to show the relation between messages and services.

• Resource oriented model: shows the relation between resources and their owners. Each resource is identified by a Uniform Resource Identifier (URI) and can have several representations (e.g. the data and content-type of the resource).

• Policy model: the focus lies on constraints that are applied to agents, services or resources and have impact whether an action is performed by the agent or not. These policies are established by the provider.

3.1 Web service architecture 21

Figure 3.2. Simplified overview of web service architecture adapted from [81]

These models give an overview about important parts of a web service in an abstract way while they do not make a statement about technologies that are supported to realise web services. The technologies that can be used for the realisation of web services can be termed as web service architecture stack. This stack is organised in several layers as depicted in Figure 3.3. From the bottom up the first layer is responsible for the transport of the messages between provider and requestor. Technologies like Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP) or File Transfer Protocol (FTP) can be used for transporting the messages. The message layer is responsible for putting the message in a given format. As a common protocol SOAP can be used. The description of the web service and its components is realised as a separate layer using WSDL (see also Chapter 3.2). At the top the processing layer handles functionality like discovering a web service. Discovering is defined as “the act of

locating a machine-processable description of a Web service that may have been previously unknown and that meets certain functional criteria” [81].

22 Web Services

3.1.1

Web Services Styles

The web service architecture stack shown in Figure 3.3 already contains a number of technologies that can be used to build and access web services which offers the developer many possibilities how to concretise the web service. Beside of the used technologies it is possible to define three styles how to use web services. Thereby each possibility brings another aspect of the architecture (see Figure 3.2) to the fore. The three web service styles are:

• Remote Procedure Call (RPC) • SOAP

• Representational State Transfer (REST)

3.1.2

RPC web services

As the name implies RPC allows the client to call a procedure (also called method) that is executed on another system within a distributed system. Thereby the client and server do not have to be aware of the underlying network. Most RPC web services use XML-RPC, a protocol that uses XML to describe the calls, which are then transmitted between the client and server using HTTP. Simplified the use of XML-RPC combines the three technologies RPC, XML and HTTP and facilitate client and server to share resources over a network. The principle is quite simple: the procedure call requires the name of the procedure and a number of parame-ters and returns a result [64]. Figure 3.4 illustrates a RPC web service and the structure of the RPC message containing the procedure (XML-tag methodName) and parameters (XML-tag params).

3.1 Web service architecture 23

Instead of using XML for the description of the remote procedure call it is also possible to use JSON (see Chapter 3.4.2) [40].

The disadvantage of using RPC web services is that the abstraction level is quite low due to the simplicity of the RPC archtiecture. This leads to the limitation that the complexity increases with an increasing number of different requests [64]. Due to this simplicity RPC web services will not be described in detail.

3.1.3

SOAP web services

SOAP is a protocol for exchanging information in a distributed system that relies on XML for its data format. SOAP is the successor of XML-RPC. SOAP fits in on the top of the network and transport layers and can be used in combination with any transport protocol. However due to the pervasiveness of HTTP this is the most common transport protocol used to exchange SOAP messages. Furthermore HTTP is the only protocol that is included in the W3C recommendation that describes how SOAP is used in combination with HTTP [82].

The structure of a SOAP message can be seen in Figure 3.5. A SOAP message consists of an SOAP Envelope that contains an optional SOAP header element and a required SOAP body. While the optional SOAP header can be used to define how the message has to be processed (e.g. routing information, authentication assertions) the SOAP body contains an actual valid, well-formed XML message [61, p. 13-15].

Figure 3.5. SOAP message adapted from [61]

Figure 3.6 illustrates a SOAP web service and the structure of the SOAP message. Although the figure contains a request and a response message SOAP messages are fundamentally one-way transmissions. Combinations of messages (such as request-response) are possible by using so called Message Exchange Pattern (MEP) [82]. When a SOAP message is sent from a sender (client) to a receiver (server) or vice

24 Web Services

versa the message may pass several intermediate nodes where it is processed and maybe changed. Thereby the SOAP headers can be used to specify which parts of the message are intended for processing by a specific intermediate node.

Figure 3.6. SOAP web service

SOAP also allows the definition of special messages that are sent when an error occurs during the processing of the SOAP message (called SOAP Fault). SOAP Faults are sent in the SOAP Body and contain a fault code, an explanation of the error, an identifier of the processing node where the error has occurred and application specific details about the error [61, p. 19].

When using HTTP for transmitting SOAP messages only HTTP POST or GET methods can be used. The SOAP message has to be placed in the HTTP en-tity body. The HTTP headers can be used to set the content-type to the defined media type “application/soap+xml”. Additionally the HTTP request header

SOA-PAction must be set. However it is possible to set the value of the SOASOA-PAction

header to an empty string. This means that the intent of the SOAP message is indicated by the URI. Figure 3.7 shows an example of SOAP using HTTP as the transport protocol [82].

3.1 Web service architecture 25

Since version SOAP 1.1 was submitted to W3C as a successor of XML-RPC in 2001 [77] there has been a lot of development in this area. The XML Protocol Working Group within W3C developed the protocol further and the results were announced in a new version SOAP 2.1 as a W3C recommendation in 2003 [80]. One big change was that since version 2.1 SOAP is no longer an acronym as the expansion of Simple Object Access Protocol is misleading.

3.1.4

REST web services

Fielding [26] defined the term REST in his dissertation as an “architectural style

for distributed hypermedia systems”. The best known example following the REST

style is the World Wide Web (WWW). While the web service styles RPC and SOAP can be classified as service-oriented web services REST web services focus on resources. This focus becomes clear when looking at the data elements of REST shown in Table 3.1.

Table 3.1. REST data elements adapted from [26]

Applying the REST style to web services means that each web service operation is described as a resource and can be accessed by a resource identifier. This re-source identifier can be seen as an address where to find the rere-source. There are a number of terms referring to resource identifiers like URI or Uniform Resource Locator (URL). When transferring information between components (e.g. clien-t/server) - this means accessing a resource by a resource identifier - the state of the information received by the resource at a specific time is called representa-tion. Next to the representation also metadata describing the media type of the representation is transmitted [26]. Figure 3.8 illustrates the connection between resources, resource identifiers, representations and their meta-data applied to web services.

One important characteristic is that all REST interactions are stateless. This means that each request must contain all necessary information for the receiver to handle and process the request. Previous requests from the receiver are not used for processing the current request [26].

26 Web Services

Figure 3.8. REST web service adapted from [87]

3.1.5

Comparison of RPC/SOAP/REST web services

Assuming that HTTP is used as the transport protocol when comparing the trans-ferred information, the difference between SOAP and REST is that SOAP uses its own envelope. This encapsulation of the actual data gives the possibility to add processing information in the SOAP header. Although this may add functions (e.g. definition which intermediate nodes are allowed to access which parts of the message), it also adds the overhead of the SOAP Envelope when the SOAP Header is not used. In contrast REST puts the actual data in the HTTP body without adding an envelope.

When comparing REST and RPC the major difference is that RPC messages contain parameters and the name of the procedure. This means it is necessary to read the message in order to know which procedure has to be called. As in REST anything can be exposed as a resource the procedure name would be accessed by the resource identifier and would not be part of the message in the HTTP body. Beside the fact that RPC exposes only one URI the HTTP POST method is supported. In addition to the HTTP POST method SOAP supports the HTTP GET method as well. However only REST allows the use of more HTTP methods (POST, GET, PUT, DELETE). This is due to the fact that REST is tied to HTTP as the transport protocol, RPC and SOAP are not restricted on the used transport protocol. Hence REST takes advantage of more HTTP specific functions than RPC and SOAP [55, p. 14].

SOAP and REST also differ in the way how errors are handled. While SOAP defines SOAP Faults that are sent in case of an error REST uses HTTP status codes (see [76]) to specify the error.

Another important fact is that SOAP was designed for end-to-end communication in contrast to REST. While SOAP provides the possibility to modify the message by an intermediate node, REST assumes a point-to-point communication. SOAP and REST also differ in terms of security. REST web service secure the commu-nication using Hypertext Transfer Protocol Secure (HTTPS) while SOAP defines

3.2 Web service description 27

security extensions (e.g. encryption, signature) [54].

3.2

Web service description

In general there are two different approaches how to create a web serivce: • code-first

• contract-first

The code-first approach starts with the implementation of the web service classes and web service types in a specific programming language. Based on the actual code the description of the web service is generated (for example using offered generators). When using the contract-first approach the first step is to describe the web service. Afterwards the web service is implemented based on the web service description. Both approaches require a description of the web service in a specific format. For this description the Web Service Description Language (WSDL) can be used. Erl et al. [25] describes the importance of WSDL as:

“WSDL is considered to be the most fundamental and important technology for Web services development because it has become the de facto language for writing Web service contracts”.

WSDL is a XML format that provides the possibility to define web services based on “a set of endpoints operating on messages containing document-oriented or

procedure-oriented information” [79]. The description of the web service consists

out of two parts: • abstract part • concrete part

The abstract part describes operations (input and/or output) which are related to messages in an abstract way. In this part no declaration about a specific technology or data format is made. Solely the message that should be transported is defined. The concrete part defines the web service style, which network protocol is used to transport the message and the endpoints where the web service can be accessed (e.g. URI of the resource using REST style or SOAPAction using SOAP style). For the SOAP web service style five different binding formats, namely RPC/encoded, RPC/literal, document/encoded, document/literal and document/literal wrapped, can be used to specify how the types that are defined in the abstract part of the WSDL, are translated into a SOAP message [17].

28 Web Services

WSDL was primarily developed by Microsoft and IBM and submitted to W3C by 25 companies (inter alia Microsoft Corporation, Oracle Corporation, International Business Machines Corporation) in May 2001 [78]. Based on this submission W3C published a WSDL 1.1 Note [79]. The current version of the WSDL specifica-tion is WSDL 2.0. In comparison to WSDL 1.1 the current version WSDL 2.0 is a Recommendation. Differences of elements in the abstract and concrete part can be seen in Figure 3.9. In WSDL 2.0 the element message was removed and input/output operations are directly connected to the type element. More-over the port element was renamed into endpoint and the portType element into interface. In addition to these changes WSDL 2.0 supports new features like MEP, complete HTTP 1.1 support (support of all HTTP methods, cookies, HTTPS, URL replacement, etc.) and SOAP 1.2 [83].

Figure 3.9. Differences WSDL 1.1 / WSDL 2.0 adapted from [63]

The WSDL is the visible interface between client and server and describes all relevant parts (structure of message, how the message can be transmitted, receiver of the message) in order to communicate with each other. Based on the WSDL the client and server can start to implement their applications. The server side has to implement the business logic that can be accessed using the web service while the client application has to implement code to access this business logic and process/display it depending on the purpose of the client application. For example when a public transport schedule system is realised by using a web service the business logic on the server side would be to calculate the route between the start and destination points thate were received by the client. The task of the client application would be to send that start and destination points to the web service and to visualise and display the received result.

3.3 Web service frameworks 29

3.3

Web service frameworks

Web service frameworks contain tools and libraries for developing web services in a specific programming language. Web services are essentially independent of the programming language. However if one wants to choose a web service framework it is required to know which programming language is supposed to be used for the implementation of the web service. Depending on the chosen programming language a number of web service frameworks are available. To create a platform independent web service the programming language Java was chosen. Therefore only web service frameworks for Java will be considered.

When analysing the current literature several web service frameworks for Java can be found for different use cases - four of them are:

• Apache Axis / Apache Axis2 • Apache CXF

• GlassFish Metro • JBossWS

Which web service framework is most suitable for developing the web service de-pends on the characteristics of the framework. Criteria for choosing a framework are:

• documentation & support • supported standards • provided tools • compatibility

In the following the characteristics of the listed web service frameworks are de-scribed which have influence on the choice of the web service framework that is most suitable for the task that has to be implemented.

3.3.1

Apache Axis2

[71] describes Axis2 as “a Web Services / SOAP / WSDL engine” which is the

“successor to the widely used Apache Axis SOAP stack”. The following

30 Web Services

• Web Service Style: RPC, SOAP (SOAP 1.1, SOAP 1.2), REST • Web Service Description: WSDL (WSDL 1.1, WSDL 2.0) • Data Formats: XML, JSON, Fast Infoset

• Transport Protocols: HTTP, SMTP, TCP, JMS

• Data Binding: Axis Data Binding (ADB), XMLBeans, JibX, JAX-B (Ex-perimental)

• Code Generator: WSDL2Java, Java2WSDL

• Standards: WS-Addressing, WS-Policy, SwA/SAAJ 1.1, MTOM, XOP • Optional Modules: Security, SecureConversation, Trust,

WS-Reliable Messaging

Architecture

The architecture of Axis2 is structured modularly. The entire architecture consists of the modules shown in Figure 3.10.

Figure 3.10. Axis2 architecture adapted from [70]

In the following the core modules are described in more detail.

The information model is used for storing and handling information. The two main hierarchies of the information model are contexts and descriptions. The description hierarchy consists of static data (e.g. loaded from a configuration file), while the context hierarchy represents dynamic information [70].

The XML processing model is the most important part and responsible for handling SOAP messages. As only the efficiency of this model decides the per-formance of Axis2 a separate module called AXIOM (AXis Object Model) was created for this purpose. AXIOM is a model for processing (reading and writ-ing) XML messages. AXIOM is based on the standard streaming pull-parser API StAX. In order to provide convenient access to the information AXIOM uses de-ferred building. This means objects are build in memory according to the events