android - web service

Web Service Clients on Mobile Android DevicesA Study on Architectural Alternatives and Client Performance

Johannes Knutsen

Master of Science in Computer ScienceSubmission date: June 2009 Supervisor: Dag Svans, IDI Co-supervisor: Erlend Stav, Sintef

Norwegian University of Science and Technology Department of Computer and Information Science

Problem DescriptionIn the ongoing EU IST project MPOWER, an open platform to simplify and speed up the task of developing and deploying services for persons with cognitive disabilities and elderly have been developed. This master assignment will investigate architectural choices and realization mechanisms for developing web service based applications for the Android platform, with the MPOWER services as the main case. By developing one or more proof-of-concept application using MPOWER services from the handheld device, it will be evaluated how different architectures affects the properties of the client and whether direct invocation of SOAP based Web services from Android is a viable approach. MPOWER - Middleware platform for empowering cognitive disabled and elderly - is an ongoing IST research project. MPOWER has defined and implemented an open platform to simplify and speed up the task of developing and deploying services for persons with cognitive disabilities and elderly. The services of the platform cover two focus areas: - A collaborative environment for distributed and shared care, providing requirements for information security, information models, context awareness, usability and interoperability. - A SMART HOUSE environment, providing requirements for information security, information models and usability. The MPOWER middleware services been released for free and are available in open source from: http://sourceforge.net/projects/free-mpower/.

Assignment given: 19. January 2009 Supervisor: Dag Svans, IDI

AbstractThis paper studies Android, a new open source software stack initiated by Google, and the possibilities of developing a mobile client for MPower, a service oriented architecture platform based upon SOAP messaging. The study focuses on the architectural alternatives, their impacts on the mobile client application, Androids performance on SOAP messaging, and how Web services design can be optimized to give well performing Android clients. The results from this study shows how different architectures directly impacts properties, like off-line usage support, of a SOAP client application on Android. Additionally, the performance measurements shows that building Android client applications which directly invokes Web services with SOAP messaging is possible to make effective enough for typical usage situations. Further, the results indicates how Web services should be designed with care to minimize the required data transfer and processing on the device. Such careful design can be achieved by using coordinating Web services which hides complexity and provides an interface designed for the specic client applications.

i

PrefaceThis report is a documentation of the work carried out throughout the spring of 2009 by Johannes Knutsen in TDT4900, Computer and Information Science, Master Thesis. The work is performed in the tenth, and last, semester of the Master of Technology education in computer science in The Norwegian University of Technology and Science, NTNU. The project was dened by co-supervisor Erlend Stav at Sintef, and is supervised by Dag Svans at the Department of Computer and Information Science. I would like to thank both supervisors for their feedback, guidance, encouragements, and an interesting topic to work on during my master.

Trondheim, June 2009

Johannes Knutsen

iii

GlossaryDalvik The Android virtual machine. One Dalvik instance runs for each running Android application. EDGE (Enhanced Data rates for GSM Evolution) Data transmission rate extension to GSM networks. GPRS (General Packet Radio Service) Packet switch mobile service of the 2G GSM service. HSPA (High Speed Packet Access) Higher speed transmission protocol, typically deployed on UMTS mobile services. IDE Integrated Development Environment. Mobile client In the context of this thesis, a mobile client is a application running on a mobile platform like Android, which accesses SOAP based Web services. SOA Service oriented architecture. An architecture where functionality is divided into loosely coupled communicating services. SOAP A protocol specication which describes the representation of messages in an XML format and how they can be transported over application protocols like HTTP or SMTP. Third party code library Ready to use code which solves a specic task developed by a party external to the ofcial platform API. For example a third party XML library, helps developers to parse XML data. UMTS (Universal Mobile Telecommunications System) Third generation mobile services (3G). XML Extensible Markup Language, is a structured, hierarchical, textbased data format widely used as a data exchange format[17].

v

Contents1 Introduction 1.1 Research questions 1.2 Research method . 1.3 Research design . . 1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 2 4 5 6 6 6 7 7 10 11 11 11 12 12 13 14 15 15 15 16 16 17 18 19 20 20 20 20

2

Prestudy 2.1 Android platform . . . . . . . . . . . . . . . . . . 2.1.1 Android Software development kit (SDK) 2.1.2 Why Android? . . . . . . . . . . . . . . . 2.1.3 Android availability . . . . . . . . . . . . 2.1.4 Third party code library support . . . . . 2.2 Service Oriented Architecture introduction . . . 2.3 Web service messaging . . . . . . . . . . . . . . . 2.3.1 Plain HTTP Post . . . . . . . . . . . . . . 2.3.2 JSON and REST . . . . . . . . . . . . . . . 2.3.3 SOAP messaging protocol . . . . . . . . . 2.3.4 Conclusion . . . . . . . . . . . . . . . . . 2.4 Mobile computing characteristics . . . . . . . . . 2.5 Time limits on user feedback . . . . . . . . . . . 2.6 Android Web services support . . . . . . . . . . 2.6.1 Manually create SOAP messages . . . . . 2.6.2 Third party libraries for SOAP support . 2.7 The MPower platform . . . . . . . . . . . . . . . 2.7.1 MPOWER benets of mobile clients . . . 2.8 RPC versus document style Web services . . . . 2.9 Existing research . . . . . . . . . . . . . . . . . .

3

Architectural alternatives and their impacts 3.1 Architectural alternatives for mobile Web service access 3.1.1 HTML frontend . . . . . . . . . . . . . . . . . . . 3.1.2 Direct Web service invocation . . . . . . . . . . . 3.1.3 Web service gateway . . . . . . . . . . . . . . . . vii

CONTENTS 3.2 Quality attributes and attribute tactics 3.2.1 Availability . . . . . . . . . . . 3.2.2 Modiability . . . . . . . . . . 3.2.3 Performance . . . . . . . . . . . 3.2.4 Security . . . . . . . . . . . . . 3.2.5 Testability . . . . . . . . . . . . 3.2.6 Usability . . . . . . . . . . . . . Architecture development impacts . . Conclusion . . . . . . . . . . . . . . . . 3.4.1 HTML frontend . . . . . . . . . 3.4.2 Direct Web service invocation . 3.4.3 Web service gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 22 23 24 25 25 26 28 29 29 30 30 31 32 32 32 33 34 35 35 35 35 36 40 41 42 42 42 42 43 46 48 48 48 48 49 53 55 55 55 55 55

3.3 3.4

4

Basic Web service invocation on Android 4.1 Basic invocation . . . . . . . . . . . . . . . . . . 4.1.1 Research action, justication and goals 4.1.2 Results . . . . . . . . . . . . . . . . . . . 4.1.3 Evaluation . . . . . . . . . . . . . . . . . 4.2 Code generation support . . . . . . . . . . . . . 4.3 Invocation performance . . . . . . . . . . . . . 4.3.1 Research action, justication and goals 4.3.2 Testing environment . . . . . . . . . . . 4.3.3 Test measurements . . . . . . . . . . . . 4.3.4 Results . . . . . . . . . . . . . . . . . . . 4.3.5 Evaluation . . . . . . . . . . . . . . . . . MPower proof of concept Android client 5.1 MPower proof of concept client application . . 5.1.1 Research action, justication and goals 5.1.2 Test environment . . . . . . . . . . . . . 5.1.3 Benchmark description . . . . . . . . . 5.1.4 Results . . . . . . . . . . . . . . . . . . . 5.1.5 Evaluation . . . . . . . . . . . . . . . . . 5.2 Proof of concept invocation performance . . . 5.2.1 Research action, justication and goals 5.2.2 Test environment . . . . . . . . . . . . . 5.2.3 Benchmark description . . . . . . . . . 5.2.4 Results . . . . . . . . . . . . . . . . . . . 5.2.5 Evaluation . . . . . . . . . . . . . . . . . 5.3 Android compared to native Java performance 5.3.1 Research action, justication and goals 5.3.2 Test environment . . . . . . . . . . . . . 5.3.3 Benchmark operations . . . . . . . . . . 5.3.4 Results . . . . . . . . . . . . . . . . . . . viii

5

CONTENTS 5.3.5 Evaluation . . . . . . . . . . . . . . . . General development experiences . . . . . . 5.4.1 Android development . . . . . . . . . 5.4.2 KSoap2 and Android . . . . . . . . . . 5.4.3 Best practices in mobile SOAP clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 58 58 58 58 61 62 62 63 63 64 64 65 67

5.4

6

Conclusion 6.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Which architectural alternatives exists for using SOAP based Web services on Android, and how do the architectural choice affect the client application? . 6.2.2 Is it possible to directly invoke SOAP Web services on Android, and will such invocation be effective enough? 6.2.3 How can the design of SOAP Web services be optimized for use on mobile devices running Android? 6.3 Further work . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Bibliography Appendices

A Android API vs Java API A-1 A.1 Supported Java 2 Platform Standard Edition 5.0 API packages A-1 A.2 Unsupported Java 2 Platform Standard Edition 5.0 API packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2 A.3 Included third party libraries . . . . . . . . . . . . . . . . . . A-3 B Android SDK tools C Proof of concept application screenshots B-5 C-7

ix

List of Figures2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5.1 5.2 Android system architecture as found in [13] . . . . . . . . . Nokia N800 running NITdroid (Android port) . . . . . . . . Service Oriented Architecture request overview as found in [7, p. 117] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HTML frontend illustrated . . . . . . . . . . . . . . . . . . . . Direct Web service invocation illustrated . . . . . . . . . . . . Web service gateway illustrated . . . . . . . . . . . . . . . . . Sequence diagram which shows what happens in a KSoap2 Web service invocation. . . . . . . . . . . . . . . . . . . . . . . Total request duration for a simple SOAP request. Requests lasting longer than 4000 ms is not shown on the plot. . . . . Measure points duration results. Measurements lasting longer than 250 ms is not shown on the plot. . . . . . . . . . 6 8 10 21 21 21 37 38 39 43 44 44 45 45 51 51 52 52 53

Benchmarks running on Nokia N800 with WLAN connection Benchmarks running on Android Emulator with LAN connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Benchmarks running on Android Emulator with UMTS simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Benchmarks running on Android Emulator with EDGE simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Benchmarks running on Android Emulator with GPRS simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Benchmarks running on Nokia N800 with WLAN connection 5.7 Benchmarks running on Android Emulator with LAN connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8 Benchmarks running on Android Emulator with UMTS simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.9 Benchmarks running on Android Emulator with EDGE simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.10 Benchmarks running on Android Emulator with GPRS simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

LIST OF FIGURES 5.11 Benchmarks running on native Java. . . . . . . . . . . . . . . 5.12 Performance benchmarks running on native Java. . . . . . . C.1 Authentication screen. . . . . . . . . . . . . . . . . . . . . . . C.2 Progress dialog while loading messages. . . . . . . . . . . . . C.3 List of messages retrieved from MPower. Available when authenticated as a patient. . . . . . . . . . . . . . . . . . . . . C.4 Conrmation dialog when deleting a message. . . . . . . . . C.5 Screen for posting messages. Available when authenticated as a doctor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 57 C-8 C-8 C-9 C-9 C-10

xii

List of Tables2.1 4.1 5.1 Nokia N800 compared with HTC Dream . . . . . . . . . . . . Total request duration measurement percentiles.1 . . . . . . 8 38 50

Androids message retrieval performance on large responses.

Percentile is here dened as the request duration below which a certain percent of measures fall. For example do 60% of the measurements last 98ms or less.

1

xiii

Chapter 1

IntroductionSmart mobile devices have become increasingly popular in the recent years. Together with the popularity, a range of system platforms and application programming environments have been created for the phones. This includes Symbian, PalmOs, J2ME, Blackberry, Windows Mobile and iPhone. In this context, Google together with the Open Handset Alliance1 recently released an open source mobile software stack named Android. Android supports a subset of the Java API, uses Java as its programming language, has broad customization support, has built-in graphical user interface components and comes with a set of core applications accessible by thirdparty developers. Googles heavy effort in Android has resulted in a range of mobile device manufacturers to announce their support and commitment to the Open Handset Alliance. This includes Motorola, HTC, Samsung, LG, Sony Ericsson and many more. A range of service platforms have recently been built based on a Service Oriented Architecture (SOA) with the SOAP messaging protocol. By creating mobile clients for these application platforms, an increased support for in-eld usage of the systems is possible. MPOWER[12] is one such service platform which aims to support rapid development and deployment of services for cognitive disabled and elderly[11]. MPOWER has been seen as a success from the end-users perspective and Android is an upcoming mobile platform, which makes them particular interesting in light of the research questions. Hence they are both chosen as research platforms for this thesis. This thesis evaluates which architectural choices must be made and how such choices impacts client applications on mobile devices running Android. Further, a study of how directly invoking Web services and the performance of such invocations, is performed on Android. It will also analyze to what degree existing Web services must be redesigned to t such1

http://www.openhandsetalliance.com

1

CHAPTER 1. mobile access.

INTRODUCTION

1.1

Research questions

The main topic of this thesis is a study on how mobile devices running Android can be incorporated in service oriented architectures and the following research questions will be answered: 1. Which architectural alternatives exists for using SOAP based Web services on Android, and how do the architectural choice affect the client application? 2. Is it possible to directly invoke SOAP Web services on Android, and will such invocation be effective enough? 3. How can the design of SOAP Web services be optimized for use on mobile devices running Android? A mobile client is in this thesis context dened as a Web service client application which runs on a mobile handheld device, like a device running Android. Further, are these Web services implemented on a SOAP based service oriented architecture. The meaning of architectural alternatives is in this context the composition of nodes, like servers and clients, between the service oriented architecture endpoint to the client, including the transmission protocols and communication paths. The internal composition alternatives of the client application and service platform is thus not evaluated.

1.2

Research method

The research method used, is based upon a design science[10] research methodology. Design science is performed by implementing an artifact, testing it and using the gathered knowledge to further develop the artifact. The artifact development used the services available on the MPOWER service oriented platform platform, described in section 2.7.

1.3

Research design

In order to answer the research questions, the following research activities was performed. A search for architectural alternatives In order to nd alternative architectures, a search for architectures described and used on other platforms than Android is performed. 2

CHAPTER 1.

INTRODUCTION

Analyse architectural alternatives The analysis should evaluate the architectural alternatives found for using SOAP Web services on Android and identify how the architectural choice affects the client application. The analysis is based upon quality attributes as dened by Bass, Clements and Kazman[3]. Implement a simple Android SOAP client Create a simple SOAP client which makes a simple SOAP request and parses the SOAP response. The goal is to identify a suitable approach for performing SOAP invocations directly from Android and through basic benchmarks identify potential bottlenecks and problems. Additionally, this will be the rst use of the Android SDK and the research action should provide a better understanding of the new platform. Implement Android SOAP client against a MPOWER service Access the MessageBoard service on MPOWER and create a mobile client which is able to send a message through the message board to another user. The client should call the required Web Services directly. This will be a proof of concept application on the Android, showing how the direct invocation architecture works on Android. The goal is to use it for further benchmarking of direct SOAP invocation against the MPower platform. Additionally, it should prove that direct SOAP invocation is possible on Android. Measure performance on expected MPower MessageBoard user operations A set of dened user operations which are likely to be performed on an Android client application for the MPower MessageBoard, should be performed on the proof of concept application. The measurements should help identify Androids effectiveness and performance on parsing SOAP responses. Additionally, by performing the operations an impression of the application responsiveness is experienced. Measure performance on large SOAP responses A dened set of SOAP responses with increasing complexity should be processed by the proof of concept application and the processing duration of each response should be measured. The action should identify Androids performance on parsing larger responses and by this help to identify how Web services can be designed to better t client applications running on Android. Measure performance on native Java The same measurements performed on Android, are to be run on a desktop computer with native Java. 3

CHAPTER 1.

INTRODUCTION

The results creates a reference for the measurements on Android. The comparison of the Android and native Java results enables a comparison on how Web services should be design for use on Android in difference to a desktop computer.

1.4

Outline

Chapter 1 Introduction Gives an introduction to the project, research questions, research method and this outline. Chapter 2 Prestudy An initial study of the Android platform, its development tools, introduction to service oriented architectures, SOAP, the MPower platform, and a basic introduction to existing research. Chapter 3 Architectural alternatives and their impacts A presentation of architecture alternatives and an analysis of quality attributes for each presented architecture. Chapter 4 Basic Web service invocation on Android An initial study and implementation of a Web service client on Android. Identify minimal requirements and an initial response time measure. Chapter 5 MPower proof of concept Android client Description of a MPower proof of concept application on Android, and a deeper study of the performance of such an application. Identies best practice guidelines for clients and Web services. Chapter 6 Conclusion A nal conclusion which answers the research questions dened in the introduction.

4

Chapter 2

PrestudyThis chapter gives an introduction to the Android platform and the development tools. It gives a brief introduction to service oriented architectures (SOA) and describes MPower, a service oriented architecture research platform used throughout the study.

5

CHAPTER 2.

PRESTUDY

Figure 2.1: Android system architecture as found in [13]

2.1

Android platform and development environment

Android is a software stack for mobile devices that includes an operating system, middleware and key applications[13]. It relies on a Linux 2.6 kernel for core system functionality[13] and runs code written in the Java programming language on a specially designed virtual machine named Dalvik. Dalvik executes Dalvik Executable les which are Java compiled classes optimized to minimize memory footprint[13]. The overall system architecture is found in gure 2.1.

2.1.1

Android Software development kit (SDK)

The Android SDK consist of several tools to help Android application development. This includes both an Eclipse IDE plugin, emulator, debugging tools, visual layout builder, log monitor and more. The tools included in the SDK are described in appendix B.

2.1.2

Why Android?

In contrast to most other mobile platforms, Android is available as open source software. This enables devices to be customized without 6

CHAPTER 2.

PRESTUDY

restrictions and enables any device manufacturer to ship devices with Android. Likewise are developers able to distribute applications to any Android device trough the Android market. Unlike Apples iPhone platform, application distribution does not require any external review or acceptance and multiple application markets exists. Within the context of this thesis, Android is especially interesting due to its state of the art status. It is a newly released platform which has already gained massive support from device manufacturers like HTC, LG, Motorola, Samsung, and Sony Ericsson. This is expected to make it an attractive platform, since the development of a single application can reach a broad range of devices, all with a rich user interface experience.

2.1.3

Android availability

By the beginning of this project HTC Dream, marketed as T-Mobile G1, was the only available Android device. This device was only available at T-Mobile markets, thus not available in Norway. The rst phone to be released on the Norwegian market is the HTC Magic, which is available for pre-orders as of 4th of June 2009. Because of this lack of available Android devices, applications and analysis performed during this thesis, will be performed on a Nokia N800 internet tablet which runs Android thanks to the NITdroid project1 . NITdroid is a kernel and userspace port from scratch of the Android operating system to the Nokia internet tablets hardware[1]. The device is shown in gure 2.2. Nokia N800 compared to the HTC Dream Running NITdroid on the Nokia N800 implies a rather undocumented hardware support. Hardware driver compatibility issues and bugs, are likely to appear or give performance penalties to the Android system running on the device. After booting Android on the device, this is immediately shown by the touch screen being a bit hard to use and the software keyboard constantly crashing. Nevertheless, the Nokia N800 device is believed to give a good indication of Androids performance, although the HTC Dream is rated with a processor running at 528 MHz versus Nokia N800s 330 MHz. A summary of the device specications are given in table 2.1.

2.1.4

Third party code library support

The Android platform is not a complete implementation of the Java API. Instead it is a dened subset of the API. This imposes challenges in using external libraries which depends on parts of the API which is not included.1

Available at http://code.google.com/p/nitdroid

7

CHAPTER 2.

PRESTUDY

Figure 2.2: Nokia N800 running NITdroid (Android port)

Processor (CPU) Memory Network

Nokia N800 ARM1136, 330 MHz 128MB 802.11b/g WLAN

HTC Dream ARM11 Qualcomm MSM7201A 528 MHz 192MB HSPA/WCDMA, GSM/GPRS/EDGE, 802.11b/g WLAN

Table 2.1: Nokia N800 compared with HTC Dream

8

CHAPTER 2.

PRESTUDY

A complete list of the Android implemented and missing packages is found in appendix A. Missing Java API dependencies are unfortunately not possible to add, since application developers are not allowed to add classes within the java.* or javax.* packages. The restriction is not found documented, but is conrmed on the ofcial Android IRC chat room and an attempt to create a class within these package names, gives a compilation error. This limits the choice of usable third party libraries to the ones which only depends on Android implemented Java API classes or where the source code is available. In such cases, Android specic implementations of the dependencies can be added to the libraries. Unfortunately, this often would require major rewrites of the libraries and requires a deep knowledge the library itself and the missing dependencies.

9

CHAPTER 2.

PRESTUDY

Figure 2.3: Service Oriented Architecture request overview as found in [7, p. 117]

2.2

Service Oriented Architecture introduction

A service oriented architecture (SOA) is based on the principle of separation of concerns[7, p. 32]. These concerns are separated as modules, or services, which communicates with each other through messages. Although SOA can be built using a range of technologies, the scope of this thesis limits and focuses SOA to consist of an architecture which a) uses SOAP as messaging protocol; b) uses HTTP to transport messages; and c) uses Web Services Description Language (WSDL) to describe available services. Figure 2.3 shows multiple clients requesting a services response. Response messages are not shown, but are returned to the initial requester. Figure 2.3 also shows how services can be both service providers and requesters. This enables a range of services to be assembled so that they together solve a larger task[7, p. 125].

10

CHAPTER 2.

PRESTUDY

2.3

Web service messaging

A SOA architecture is not dependent upon a specic technology, since different protocols for messaging can support the principle of separation of concerns. Different protocols are mainly interesting for this thesis due to the different processing and memory requirements they may have. It is to be noticed that most SOA platforms supprts only a single or a few messaging protocols, thus making use of new protocols a non-trivial task for large scale systems.

2.3.1

Plain HTTP Post

Plain HTTP Post requests are typically simple messages encoded as application/x-www-form-urlencoded as dened by the HTTP protocol [22]. The response is typically in an application specic XML encoded format. This makes processing and memory requirements of message creation and parsing low, but it also restricts the messages by making complex requests hard to create and responses are very specic to a expected result.

2.3.2

JSON and REST

JavaScript Object Notation (JSON) is a lightweight, text-based, languageindependent data interchange format[6]. Android have built-in support for JSON, thus making it a compelling alternative to XML within the context of this thesis. Representational State Transfer (REST) is an architectural style for distributed hypermedia systems[8, p. 76]. It describes an architecture where each resource, such as a web service, is represented with an unique URL. The principle of REST is to use the HTTP protocol as it is modelled[20], thus accessing and modifying the resources through the standardized HTTP functions GET, POST, PUT, and DELETE. REST is not in itself a standardized protocol, but denes principals on how to use existing standards. In combination with for instance JSON, they dene a Web service architecture with an increasing support. Notice that REST does not require JSON as data interchange format. REST based Web services success is exemplied by major websites like Flickr, del.icio.us, eBay, Google, and Amazon which now offers access to Web services based on REST and JSON. Additionally, the WSDL 2.0 specications now supports all HTTP functions[5], which enables REST services to be described. JSON/REST based Web services are designed to be lightweight and easy to access, but lacks more complex functionality like type checking and adhesion to a contract. 11

CHAPTER 2.

PRESTUDY

2.3.3

SOAP messaging protocol

SOAP is a message transport protocol which has been accepted as the default message protocol in SOA[7, p. 142]. SOAP messages are created by wrapping application specic XML messages within a standard XMLbased envelope structure[15, p. 55]. The result is an extendable message structure which can be transported through most underlying network transports like SMTP and HTTP. SOAP Criticism One of the main criticisms of SOAP relates to the way the SOAP messages are wrapped within an envelope. With HTTP as transport layer, most requests are typically sent as POST requests to a single URL, thus ignoring the HTTP resource-oriented design[20]. For example modelling requests as POST when they in fact could be modelled as GET, PUT, POST or DELETE requests results in HTTP trafc which is hard to monitor by for example rewalls[2].

2.3.4

Conclusion

Within a larger context, SOAP is the de-facto standard for Web service message exchange. A range of tools and application platforms are available with SOAP support, which enables techniques like model-driven development to be used in service design. Within a mobile context, the REST architecture is considered as more light-weight[20] than a SOAP based Web service architecture. Additionally the Android platform have built-in JSON support which enables that objects can be directly converted from Java to JSON objects and back again. A move towards a JSON/REST based Web service architecture and its impact on mobile clients is outside the scope of this thesis, although an interesting subject for further investigation.

12

CHAPTER 2.

PRESTUDY

2.4

Mobile computing characteristics

Mobile computing is in [21] characterized by four constraints: Mobile elements are resource-poor relative to static elements. Mobility is inherently hazardous. Mobile connectivity is highly variable in performance and reliability. Mobile elements rely on a nite energy source. All these constraints puts restrictions and consequences for any architectural choices made. The constraints also are self contradicting. On one side, because of the resource poorness, lower trust and robustness, the constraints argues for a static server design. On the other, the varying network and nite energy resources argues for self reliance.[21]. An architecture for mobile SOAP clients must at least be able to support a static server design. The degree of self reliance on the other hand depends on the end users requirements. A mobile client can be as simple as a web application with a HTML frontend designed for small screens. Clients will in these cases have no self reliance, since they are dependent upon an available static server. On the other hand, by having the clients cache its data and do synchronization against the server, almost complete self relied clients is possible. A description of the identied architectures for mobile SOAP clients and their differences is found in chapter 3. This analysis uses the constraints given above as a basis for the evaluation of each architecture. Most of this analysis is believed to be applicable not only to Android, but also most other modern mobile platforms.

13

CHAPTER 2.

PRESTUDY

2.5

Time limits on user feedback

In order to evaluate how effective a Web service client on Android must be, basic usability guidelines from Jacob Nielsen have been studied and used as guidelines. Jacob Nielsen is regarded as one of the gurus on Web usability and describes three time limits on user feedback in Web driven applications. These limits are described as follows in [19]. 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result. 1.0 second is about the limit for the users ow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data. 10 seconds is about the limit for keeping the users attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to nish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect. It should be noticed that the limits are not to be treated as absolute, but rather be part of the evaluation on how quick a user expects some kind of feedback. For this thesis, the limits are used in the evaluation on how fast a Web service client actually must respond to user actions in order for the user to stay focused and perceive the application as responsive.

14

CHAPTER 2.

PRESTUDY

2.6

Android Web services support

The Android platform has no built in SOAP support for Web services. However, it does have built in libraries for both HTTP communication through Apache HTTPClient and XML construction and parsing through application programming interfaces (APIs) like SAX, DOM and XmlPull v1.

2.6.1

Manually create SOAP messages

Androids built in XML and HTTP support enables SOAP request messages to be constructed manually and dispatched through the HTTPClient API. The SOAP response is then manually parsed and converted into Java objects. Since mobile devices have limited resources, this manual way of creating and parsing SOAP messages could help minimizing memory and processing requirements. Additionally, mobile applications are built more task oriented than desktop and web applications which normally makes such manual SOAP handling far less complex than other SOAP clients. Although manual SOAP handling could be justied in many cases, this thesis will focus on the use of third party libraries.

2.6.2

Third party libraries for SOAP support

Through Apache Axis2 found at http://ws.apache.org/axis2, Java is given full support for SOAP based Web services. This includes code stub generators from WSDL denitions. KSoap2 is a SOAP library made specically for J2ME. This makes it much more light-weight than Axis2, thus believed to t Android better. Several posts on the Android development forums conrms that KSoap2 works good not only on J2ME, but also on Android. However since KSoap2 is designed for J2ME, KSoap2 is not using Java features like reection which is not available in J2ME. KSoap2 does not have support for stub generation from WSDL denitions, but do have mechanisms to help serialization and deserialization of Java classes.

15

CHAPTER 2.

PRESTUDY

2.7

The MPower platform

MPOWER is a SOA platform targeting easier development and deployment of services helping persons with cognitive disabilities and elderly[12]. Currently, the platform has been tested with various proof of concept clients, including HTML based frontend and Windows Mobile client. The proof of concept applications currently released has been rewarded with positive response from the end users making it a interesting platform to extend with new clients. Throughout this thesis, all architectural analysis and performance benchmarks have been performed with the MPower platform in mind. However, the MPower platform is built on a standard service oriented architecture. Therefore the results and evaluations should be applicable also on other similar platforms.

2.7.1

MPOWER benets of mobile clients

So far the MPOWER platform primarily have been tested with desktop or web based clients. Such clients are restricted to be used in the physical location where they are deployed. A mobile MPOWER client is identied to improve several of the features announced to be particularly supported in MPOWER, found at [12]. These features are foremost gained by the a) increased system availability to mobile users which often change context; and b) access to mobile devices sensors like GPS location and accelerometer sensor. Additionally, a mobile client would allow a tight integration with basic phone functionality like initiating phone calls, SMS or MMS messages. One could also benet from bundled applications like the calendar with alarms and to-do lists by implementing synchronization services. Such use of built in functionality on the mobile device is believed to decrease required development time and increase the usability from a end users perspective.

16

CHAPTER 2.

PRESTUDY

2.8

RPC versus document style Web services

RPC and document style Web services have a confusing dual meaning in a SOA architecture. Within a WSDL and SOAP formatting context, document style and RPC style describes syntactical differences of a SOAP message. Within a broader context, the difference between document style and RPC style Web services is based on the invocation and response type. A document style Web service is designed, as the name implies, to respond with a document type of response. This typically means a lager chunk of data, like a list of complex data. A RPC style Web service on the contrary, is designed to have a larger number of requests, each with a smaller response. In the latter years, document style Web services has become more and more common. Although a clean SOA architecture should enforce to use only one of the invocation styles, there is no technical problems mixing them within an environment. It should also be noticed that document style invocations, generally are harder to make abstract and reusable since a larger response will require more information on what to return. MPower is designed to use as much document style services as possible.

17

CHAPTER 2.

PRESTUDY

2.9

Existing research

Topics concerning the use of service oriented architectures on mobile devices is not a new research eld. Mobile platforms like Microsofts .NET Compact Framework have had SOAP messaging support since its release[4]. Likewise has the J2ME platform had Web service support through the use of libraries like KSoap[16] and the JSR-172 Web Services Specication[14]. However, in contrast to the .NET Compact Framework, Android does not have any built in SOAP support neither in the development tools nor in the platform API. Like the J2ME platform, Android is Java based, but Android is supposed to be much closer to the desktop Java (J2SE) and devices running Android will typically run on faster hardware than devices with J2ME. These differences makes it hard to directly use the studies performed on other platforms. Since Android is a new and community supported platform, the most current research and documentation is the resources made available by people who have tried the platform and shares their knowledge and experience on blogs, developer forums, and communication channels like IRC. The lack of articles and books, especially on topics like SOAP messages on Android, makes these shared experiences the only updated source of information.

18

Chapter 3

Architectural alternatives and their impactsThis chapter presents three architectural alternatives for accessing SOAP based Web services on an Android client. Further, an analysis of the three architectures and how they will affect the client application is performed and the results are presented.

19

CHAPTER 3.

ARCHITECTURAL ALTERNATIVES AND THEIR IMPACTS

3.1

Architectural alternatives for mobile Web service access

Three well suited client/server architecture patterns are identied for mobile devices and SOA architectures. HTML frontend, Web service gateway[16] and direct Web service invocation[16].

3.1.1

HTML frontend

A Web service client is placed on a server as a web application serving dynamically generated HTML responses to HTTP requests. A standard web browser is used on the mobile client to access and communicate with the web application. As seen in gure 3.1, requests are plain HTTP requests from the browser to a HTTP server. The HTTP server runs a web application which uses the available SOAP services, and returns a HTML formatted response. User input is handled through standard HTML form posts.

3.1.2

Direct Web service invocation

All requests to the Web services are performed from the mobile device. Implies that the mobile client must be able to wrap and unwrap SOAP messages.

3.1.3

Web service gateway

A Web service client is placed as a gateway server and converts incoming requests from the mobile client to Web service invocations. Web service responses are then converted to a more lightweight format than SOAP and returned to the client. Responses can typically be formatted as XML, WBXML, JSON or other formats with a simpler structure than complete SOAP messages. The architecture is seen in gure 3.3. Notice that one request to the gateway, could result in multiple SOAP request and responses.

20

CHAPTER 3. IMPACTS

ARCHITECTURAL ALTERNATIVES AND THEIR

HTTP request

SOAP request

Mobile client

HTTP Server

Web service server

HTML response

SOAP response

Figure 3.1: HTML frontend illustrated

SOAP request

Mobile client

Web service server

SOAP response

Figure 3.2: Direct Web service invocation illustrated

HTTP request

SOAP request

Mobile client

Middleware Proxy/gateway

Web service server

XML, JSON, ...

SOAP response

Figure 3.3: Web service gateway illustrated

21

CHAPTER 3.


3.2

Quality attributes and attribute tactics

Bass, Clements and Kazman denes the concept of quality attributes for architectural evaluation. These attributes are characterized by a set of quality attribute scenarios[3]. In order to compare the three architectural designs given in section 3.1, these quality attributes and their characterisation through general attribute scenarios are used. As described in [3], each quality attribute have a set of tactics which should enforce the architecture to support the focused quality attributes. During the following sections, each of the quality attributes are briey presented and dened based on the general quality attributes given in [3]. Further are the three architectural designs evaluated on how they support the achievement of each quality attribute. It should be noticed that this evaluation is based on the tactics presented for each attribute as given in [3, chp. 5].

3.2.1

Availability

Availability is dened to concern any failure which makes the system unable to deliver the service it is design to deliver[3, chp 4]. This includes both service for the end user and other systems relying on the system. It also includes a systems possibility to recover from an unavailable state and resume its normal operation. With the increasingly available mobile networks, one could have believed that off-line support became an issue out of date. However, questions like how to handle connectivity interruptions are of more interest than ever. Applications are expected to be available at all times and always updated with the most recent data. A transparent handling of changes in network connectivity includes dealing with conicting revisions, data changes, and avoidance of locked data. All with as little user intervention as possible. In this analysis it is focused on loss of network connectivity, which should be expected to happen frequently in a mobile environment. HTML Pros A web application enables a centralized point of control which makes the system availability easy to monitor and redundancy tactics can be applied. Synchronization issues of data is typically easy to handle, since clients are directly requesting data from the server. Cons Since the HTML frontend architecture is based on HTTP requests of basic HTML pages, such an architecture would not be possible to use in an environment without a network connection. The web application does 22

CHAPTER 3. IMPACTS


neither have any ways of detecting which clients are online and in use, except when the clients actually are sending a HTTP request. Depending on the implementation and security measures applied, recovering after loosing network connectivity might require users to relogon to the system. This is especially true if the clients IP address is changed or a session has timed out. This makes rapid loss of network connectivity annoying to the users. Direct invocation Pros Direct Web service invocation supports availability tactics like ping/echo and heartbeat. This means that each mobile client can publish their availability to the server by sending frequent messages about its presence and detect the server availability by issuing frequent response requests to the server. The client can by this be designed to use an internal storage when it is off-line and resynchronize with the server when it is online again. This enables clients both to be used without network connectivity and to quickly detect a required network connection and recover its normal operation. Cons Implementing a system which transparently handles online and off-line modes is hard, since resynchronization is hard in a multiuser environment. Gateway Same as direct invocation.

3.2.2

Modiability

The purpose of a SOA architecture in itself is to localize changes and separate concerns. Within a mobile client context, the question of portability and the work of extending the MPower platform with new services is especially relevant. HTML Pros Web applications are relatively easy to make and a range of frameworks are available with direct SOAP support. One web application will support any mobile device with a internet browser and deployment is only necessary on one server. Thus, are new features and changes very quick and easy to set in production. 23

CHAPTER 3.


Cons Multiple views could still be necessary in order to support multiple screen sizes. Direct invocation Pros Client applications can use existing device functionality like calendar and contact list instead of implement such features. Cons Updated application versions must be deployed to all devices. Gateway Pros Could make porting clients to new devices easier, since the gateway may hide Web services complexity and serve more client specic communication interfaces. Cons Three points of implementation creates more complexity when a new service is created, changed or removed.

3.2.3

Performance

The overall goal of performance attribute is to lower the time from request to response is available. HTML Pros All SOAP and heavy processing is done server side. Cons Each request requires a complete post and wait for a new page as response. Thus, the response time will be dependent on size of each page. Direct invocation Pros Supports to have local cache of both already retrieved data and, by using optimistic fetching, data expected to be requested. Thus, network usage can be optimized and the response times can be minimal. Such optimizations are especially important in high latency data networks like GPRS, EDGE and UMTS networks. Cons Direct invocation with SOAP messages typically have a signicant size and complexity overhead. This leads to more data transfer and more processing required to create and read the messages. 24

CHAPTER 3. IMPACTS Gateway


Pros Supports the same tactics as direct invocation but additionally can reduce computational overhead by using more lightweight, system specic, transport formats than SOAP. Cons None major cons identied.

3.2.4

Security

Small mobile devices are easy to loose and get hijacked by third-party which should not have access to sensitive data. With MPower, this is especially true due to its medical sensitive application context. HTML Pros As long as a secure transport protocol like HTTPS or VPN systems is ensured, a minimal amount of data is stored on the actual client. Cons Cache is still vulnerable and HTML suffers from security issues like session hijacking. The web server is vulnerable to attacks and adds another software system to secure. Direct invocation Pros The developer will have complete control of the data stored locally on the actual device. Enables encryption and cache deletion when appropriate. Cons Cached and saved data on the mobile device is vulnerable since the data is stored on the actual device. If anyone gains access to the device, they do not need access to the actual system to get the data. Gateway Pros Same as direct invocation. Cons Data is replicated at least three places. In addition to secure the Web service server, the gateway must also be secured.

3.2.5

Testability

Testability concerns the implications of testing the correctness of the system. 25

CHAPTER 3. HTML


Pros A number of web application test frameworks exists, making HTML frontends easy to test. Cons The HTML rendering on mobile devices might vary from device to device. How the pages are rendered on a device is hard to automatically test. Direct invocation Pros Tests can be made with unit testing frameworks and mocks1 which mimics external functionality. Cons Each mobile platform, must have platform specic tests written to them. User interfaces are in general hard to test. Gateway Pros Simpler interfaces between the remote platform and the mobile client makes testing on the mobile client easier since the mobile client can potentially be made simpler with less complexity. Cons The testing of the gateway introduces another software platform to test. Thus, simple to test, it introduces more code and another environment to test.

3.2.6

Usability

MPower is targeting persons with cognitive disabilities and elderly. Thus, usability is essential for the platform to be used. HTML Pros HTML has become a very well-known user interface to most people and is easy recognizable. Since HTML allows identical user interface on a range of devices, the interface will also be recognizable independent on the actual device a user uses.A mock is a software component which mimics another software component during software testing. A Web service mock can for example be used to return test data responses to a Web service client in order to have a controlled test environment.1

26

CHAPTER 3. IMPACTS


Cons An architecture based on a HTML frontend, disables device specic benets. A short list of example follows. Data from a GPS or an accelerometer is not possible to send to a HTML page. Integration with other device specic application like for example phone, SMS, MMS, calendar, alarm and notication functionality. User interaction styles are restricted to the ones dened by form inputs of HTML. A sporadic usage pattern of the application is difcult to achieve. Users wishing to check the system for any update must open the browser, navigate to the systems logon page, enter credentials and nd the correct page. Additionally HTML, without the use of JavaScript, only support complete page reloads. Thus, dynamic update of the user interface based upon state and user interaction is impossible. Direct invocation Pros The direct invocation architecture is dynamic by nature since it is based upon using the native user interface and programming environment. This enables better support for adaptive user interfaces, device specic functionality, and sporadic usage. Information can be regularly pulled from the server and integration with the device enables device application to be synchronized with the Web service server. Cons Building a user interface easily recognizable by users on any device, could be difcult because of the use of native user interface components. Gateway The gateway have the same pros and cons as the direct invocation above.

27

CHAPTER 3.


3.3

Architecture development impacts

The complexity of application development depends on range of factors, including but not limited to Number of supported platforms Required code and functionality abstractions and reusability Off-line usage support Possibility to auto generate code Availability of third-party code libraries SDK development support The number of supported platform is specically an issue for mobile application development. The large number of platforms, have little or no possibility to run the same application code. Hence, a pure HTML based front-end design lowers the complexity of supporting all platforms dramatically, since most devices have a web browser.

28

CHAPTER 3. IMPACTS


3.4

Conclusion

Each of the architectures in section 3.1 have their advantages and drawbacks. When choosing an architecture, the quality attributes should be prioritized against each other. This allows the architecture to be chosen based on the most important quality attributes one wishes to achieve. In the context of MPower and this thesis, a goal has been to build a dynamic platform which is easy to use. A mobile client should be usable without network connectivity and the possibility to synchronize MPower information directly with Androids device specic functionality should be available. Thus, a HTML frontend would not support these requirements and a gateway is preferred to be avoided due to the additional development complexity. A summarization of the advantages and drawbacks found for each architecture follows.

3.4.1

HTML frontend

The HTML frontend is typically ideal when a device is expected to always have an available internet connection and the same application must be available on a range of different device platforms. Additionally, a HTML frontend enables efcient development thanks to the available development tools with SOAP support. Advantages HTML frontends are quick and easy to create. They can be deployed on any web server and a range of SOAP client frameworks are available to web applications. Additionally, HTML frontends are device independent. Any mobile device with an internet browser, can access the same web application. Drawbacks By using a web browser interface on the client, any device specic feature is not possible to utilize. Synchronization with device applications like a calendar, contact list, map, SMS and so on is not possible. Unfortunately, the client is required to be online for the web application to be available. When the internet connection is lost, the application is unusable with the risk of loosing data which the user was working on submitting. Although dynamic web interfaces are built for desktop browsers, mobile browsers still have very limited or no Javascript support. Thus, 29

CHAPTER 3.


HTML frontend applications are limited to the default full page reload on updates.

3.4.2

Direct Web service invocation

A direct invocation is typically ideal when a client application must be possible to use without an internet connection and a high degree of modiability is necessary. Advantages Mobile clients can have internal caching and synchronization logic. Several clients can connect to the same service architecture and make any application supported by the given services possibly without any specic service design. Drawbacks SOAP messages are XML based and typically large and complex[18]. Such complexity results in both computational and data transfer overhead.

3.4.3

Web service gateway

The Web service gateway is rst and foremost found benecial when a direct Web service invocation style is not usable due to too much message overhead or when the Web services are not open for changes. Advantages By using a gateway between the mobile client and the Web services, one can leave the services unchanged while building more lightweight interfaces for mobile clients. Possibility to use compressed and task specic data representations, reduces data trafc and processing. This improves application performance and lowers the application latency. Drawbacks A gateway creates yet another architectural element to maintain. Any new features requires implementation both on a Web service server, gateway and mobile client. Additionally, the gateway approach is not standardized. Thus, it easily becomes application specic and ignores Web services principle of separation of concerns.

30

Chapter 4

Basic Web service invocation on AndroidThis chapter presents an example approach for direct invocation of SOAP based Web services from an Android client application and an evaluation of the approach.

31

CHAPTER 4.

BASIC WEB SERVICE INVOCATION ON ANDROID

4.14.1.1

Basic Web service invocationResearch action, justication and goals

The complexity of most MPOWER services, justied an initial study of calling simpler Web services from the Android platform. The activity will have the following goals. Try to use the Axis2 library for Web service invocation. Try to use the KSoap2 library for Web service invocation. A Web service found at W3Schools website, http://w3schools. com/webservices/ws_example.asp, which converts temperatures between the Celsius and Fahrenheit scales was used for the clients.

4.1.2

Results

Axis2 for Web service invocation Axis2 is Apaches reference SOAP implementation and consists of several modules, both for Web service server capabilities, client support and code generation tools. The Axis2 did unfortunately have dependencies within the Java API, which was not implemented in Android. Thus, it is not possible to use without major changes. It is also to be noticed that Axis2 is a large and complex library possibly not well suited for mobile device with lower resources. KSoap2 for Web service invocation KSoap2 is a light-weight SOAP client library targeting Java 2 Micro Edition platforms. KSoap2 is also released with a Java 2 Standard Edition version which works without modications on the Android platform.public c l a s s C e l s i u s F a h r e n h e i t C o n v e r t e r { S t r i n g soapAction = h t t p :// tempuri . org/ C e l s i u s T o F a h r e n h e i t ; S t r i n g methodName = C e l s i u s T o F a h r e n h e i t ; S t r i n g namespace = h t t p :// tempuri . org/ ; S t r i n g u r l = h t t p ://www. w3schools . com/w e b s e r v i c e s/tempconvert . asmx ; T r a n s p o r t h t t p T r a n s p o r t = new HttpTransportSE (URL) ; public S t r i n g c e l s i u s T o F a h r e n h e i t ( i n t c e l s i u s ) throws Ex ce pti on { SoapObject r e q u e s t = new SoapObject ( namespace , methodName ) ; r e q u e s t . addProperty ( C e l s i u s , c e l s i u s ) ;

32

CHAPTER 4.


S o a p S e r i a l i z a t i o n E n v e l o p e envelope = new S o a p S e r i a l i z a t i o n E n v e l o p e ( SoapEnvelope . VER11 ) ; envelope . setOutputSoapObject ( r e q u e s t ) ; h t t p T r a n s p o r t . c a l l ( soapAction , envelope ) ; SoapObject soapResponse = ( SoapObject ) envelope . bodyIn ; S o a p P r i m i t i v e body = ( S o a p P r i m i t i v e ) soapResponse . g e t P r o p e r t y ( CelsiusToFahrenheitResult ) ; r e t u r n body . t o S t r i n g ( ) ; } }

Listing 4.1: asic KSoap2 Web service request/response example. Listing 4.1 shows a very basic use of KSoap2. It wraps an integer within a SOAP envelope and send the envelope to a services end point through a HTTP transport. The response is then extracted from the KSoap2 serialization envelope and returned as a string. It should be noticed that this only demonstrates the most basic example and KSoap2 have a much more rened support for wrapping and unwrapping requests and responses.

4.1.3

Evaluation

Although an attempt to use Axis2 on Android failed, KSoap2 seems to give a benecial support to this thesis implementation needs. By using a third-party library like KSoap2 when building a Web service client, it is easier to keep focus on the actual content of each SOAP invocation instead of the detailed XML structure of the message. Additionally, are message envelopes easy to change according to new SOAP versions or Web service implementations if necessary. Based on the initial study, the KSoap2 library will be used throughout the rest of this thesis implementations.

33

CHAPTER 4.


4.2

Code generation support

Automatic generation of code from Web services WSDL les, especially simplies the serialization and deserialization of XML and Java classes. Such serializing code would otherwise be coded by hand, often with repeating code patterns. Axis2 have built-in support for generating stub classes and provides automatic mapping between XML and Java classes. Axis2 generated stubs does not t on Android, since Axis2 is unusable, but the generator is easily tweaked to output code in other formats[9]. Such modications allows generation of custom made Java bean stubs which for example can be used in KSoap2 or manually created SOAP environments on Android. KSoap2 has not ofcially provided any tool for generating stub classes, but a user contributed patch is available at KSoap2s SourceForge page. The patch uses parts of the Axis2 library in order to analyze the WSDL and generate stub classes. Unfortunately this patch is totally undocumented, thus making it hard to use. Based on the available alternatives to automatically generate code stubs, the code generation solutions are found too demanding to be used during this project. Not only because of the work involved in customizing and adapt existing solutions, but also due to the limited number of WSDL les the client applications which are to be developed will use.

34

CHAPTER 4.


4.34.3.1

Invocation performanceResearch action, justication and goals

One of the issues concerning Web service invocation on a mobile device, is performance and latency. As a preliminary study the Androids performance on the most basic Web service call was performed. The goal was to identify Androids basic potential to host a Web service client. This includes identication of bottlenecks and performance on multiple sequential invocations. As described in section 4.1.3, KSoap2 is used to leverage the test client development.

4.3.2

Testing environment

The temperature converter service described in section 4.1.1 and the code from listing 4.1 was used as a basis. In order to avoid server bottlenecks and have a controlled server environment, soapUI1 was used to set up a ctive SOA environment serving SOAP responses to SOAP requests. The environment was set up with a local wireless network infrastructure for data transport. The Web service invocations were performed on a Nokia N800 device with Nitdroid installed. The N800 is an internet tablet device designed to run with a light-weight Linux operating system. Nitdroid is a open source port of the Android platform to the Nokia N800. It runs a patched kernel with the complete Android stack on top.

4.3.3

Test measurements

A total of seven measure points were dened. Each point measured the invocation duration of a single or small set of Android API or KSoap invocations. A total of 500 Web service invocations were performed in sequence. Each invocation measuring the durations stated above by saving the debug output to a log le. createRequestData KSoap2 method which takes a KSoap2 SOAP envelope object and writes serializes it as as a byte array with the SOAP request. setRequestProperties Creates a new connection represented as a HttpURLConnection object, which is part of the Java API andThe ofcial soapUI website states that: soapUI is the most used testing tool in the world for inspecting Web Services, invoking Web Services, developing Web Services, Web Service Simulation and Web Service Mocking, Functional Testing of Web Services, and load Testing of Web Services.1

35

CHAPTER 4.


implemented in the native Android API. Additionally, it sets some basic HTTP headers to this connection. openOutputStream Native Android API call to getOutputStream() on the current connection. outputStreamWrite Writes the request data to the current connection. connect Native Android API call to the current connection. openInputStream Native Android API call to getInputStream(). parseResponse KSoap2 method which reads the available data from the input stream and deserializes the SOAP response. An overview of the method invocations in the performance benchmark is illustrated as a sequence diagram in gure 4.3.

4.3.4

Results

The measurements shows some irregularities with random requests lasting much longer than anticipated. A total of forty requests (8%) lasted more than a second. To verify the result, the same test was repeated on the Android Emulator. When running the same code on the emulator, no requests lasts more than a second. It is believed that the long durations happens because of bugs in Nitroid or other Nokia N800 specic issues. Also notice that most of these long durations lasts close to 3 seconds as shown in gure 4.3 and could be a socket timeout on the device. As seen in table 4.1, 85% of the requests are shorter than 300 ms and more than 60% of the requests are shorter than 100 ms. When garbage collecting, which lasts approximately 120 ms and is included in the request duration measurement, is taken in account one could anticipate that approximately 85% of the readings are representable for the application running on a native Android device. The shortest total request duration was 75 ms and the average request duration of the 90 percentage shortest requests was 137 ms. As seen in gure 4.3, the opening of the output stream takes the most time in average. It should be noticed that parsing of the response only takes 15 ms in average.

36

androidHttpTransport

envelope

connection

connection

CHAPTER 4.

celsiusToFahrenheit(celsius) call(SOAP_ACTION, envelope) os

is createRequestData(envelope)

setRequestProperty setRequestProperty setRequestMethod("POST") getOutputStream write(requestData) close connect connect openInputStream getInputStream setRequestMethod("POST") openOutputStream


Figure 4.1: Sequence diagram which shows what happens in a KSoap2 Web service invocation. parseResponse(envelope, is)

37

CHAPTER 4.


Percentile 100 95 90 85 80 75 70 65 60 55 50

Request duration 21092 ms 3087 ms 675 ms 299 ms 290 ms 221 ms 216 ms 132 ms 98 ms 92 ms 90 ms

Table 4.1: Total request duration measurement percentiles.aa Percentile is here dened as the request duration below which a certain percent of measures fall. For example do 60% of the measurements last 98ms or less.

4000 3500 3000 2500 milliseconds 2000 1500 1000 500 0

Total request duration

0

50

100

150

200

250

300

350

400

450

500

Figure 4.2: Total request duration for a simple SOAP request. Requests lasting longer than 4000 ms is not shown on the plot.

38

CHAPTER 4.


250

200

createRequestData setRequestProperties openOutputStream outputStreamWrite connect openInputStream parseResponse

150 milliseconds 100 50

0

0

50

100

150

200

250

300

350

400

450

500

Figure 4.3: Measure points duration results. Measurements lasting longer than 250 ms is not shown on the plot.

39

CHAPTER 4.


4.3.5

Evaluation

Most requests lasted much less than a second, which is the limit for the users ow of thought to stay uninterrupted, even though the user will notice the delay[19]. Although the test is performed with an almost minimal SOAP request, the results indicates that the performance is well within the time limits required for building a responsive mobile client. Especially since the test device is not designed to run Android.

40

Chapter 5

MPower proof of concept Android clientThis chapter presents a proof of concept Android application, which by direct invocation allows users to access the MPower MessageBoard Web service. Several benchmarks are performed on the application and the results are presented and evaluated.

41

CHAPTER 5.

MPOWER PROOF OF CONCEPT ANDROID CLIENT

5.15.1.1

MPower proof of concept client applicationResearch action, justication and goals

In order to verify the results from section 4.3.4 and to get a more actual experience with mobile SOAP client development on Android, a small proof of concept application was decided to be developed. The goal was to create a small Android application which used some of the MPower Web services. Such a proof of concept application enabled the client response to be experienced and measured.

5.1.2

Test environment

The application was built to support a MPower MessageBoard service. This is a HL71 which enables doctors and relatives to send text messages to a patient. The application should also provide an authentication screen. The goal is not to build a complete application, but rather a working example of how a mobile MPower client can be built on Android. The client uses KSoap2 and performs direct SOAP invocations to a MPower application server located at Sintef, while the client is located at a remote site with an ADSL2 internet connection.

5.1.3

Benchmark description

The test client gives an actual feeling with the responsiveness of a SOAP client. Additionally, a set of application operations will be performed as described below. All benchmarks will be measured by the duration of each operation. Benchmark operations 1. Authenticate a user. 2. Retrieve a list of 20 messages. 3. Retrieve a list of 20 messages without updating the user interface. 4. Remove a message. 5. Retrieve a single message. 6. Retrieve a single message without updating the user interface. 7. Post a new message to a user.1

HL7 (Health Level 7) is a standardization for health information data exchange.

42

CHAPTER 5.


500 400 milliseconds 300 200 100 0

Min Average Max

Retrieve 20 messages

Retrieve a single message, no UI update

Authenticate

Remove a single message

Retrieve 20 message, no UI update

Retrieve a single message

Figure 5.1: Benchmarks running on Nokia N800 with WLAN connection All measurements includes SOAP request creation, network round-trip, response processing, and update of the user interface. Benchmarks will be performed both on the Nokia N800 device and Android emulator. Each benchmark will be performed ten times and an average measure will be calculated and plotted together with the minimum and maximum duration. In order to simulate various network environments, the benchmarks are also to be run using the built-in GPRS, EDGE, and UMTS emulation options in the emulator. In order to get an even and realistic performance measurement, measurements where the garbage collector runs or the server processes the request particularly slow, is discarded and the measurement is repeated.

5.1.4

Results

Screenshots from the proof of concept application running on Nokia N800, is shown in appendix C. The results from the benchmarks are plotted in gure 5.1, 5.2, 5.3, 5.4, and 5.5. The plots shows the maximum, minimum, and average duration of each benchmark operation listed in section 5.1.3. Throughout the benchmarks, the authentication invocation call took fairly long time to perform. Service invocations performed from native Java clients, indicates that this could be a server issue resulting in slow server 43

Post a message

milliseconds milliseconds 0 100 200 300 400 500 100 200 300 400 500 600

0

Figure 5.3: simulation Figure 5.2: connectionAuthenticate Retrieve 20 messages Retrieve 20 message, no UI update Remove a single message Retrieve a single message Retrieve a single message, no UI update Post a message Min Average Max

CHAPTER 5.

Authenticate




Benchmarks running on Android Emulator with UMTS

Benchmarks running on Android Emulator with LAN

44




Min Average Max

Post a message

milliseconds 1000 1200 1400 1600 1000 200 200 400 600 800 0 400 600 800

milliseconds

Figure 5.4: simulation

0

Figure 5.5: simulation CHAPTER 5.Authenticate Retrieve 20 messages Retrieve 20 message, no UI update Remove a single message Retrieve a single message Retrieve a single message, no UI update Post a message Min Average Max Min Average Max

Authenticate




Benchmarks running on Android Emulator with EDGE

Benchmarks running on Android Emulator with GPRS

45




Post a message

CHAPTER 5.


responses. This is also indicated by the similar results on the authentication invocation when measuring native Java performance in section 5.3.4. When latency and throughput simulation of GPRS, EDGE, and UMTS mobile networks are enabled on the emulator, the benchmark results varies more than using a LAN connection. Thus, the low number of measurements for each operation is believed to be too low to ensure valid results. The correctness of the network simulation is also uncertain and not found documented by Google. Nevertheless are the results believed to indicate the application performance when using devices within areas of good network signal strength. Both the device and emulator clearly shows how updating the user interface impacts the performance. The performance penalty of updating the user interface is also strengthened in the retrieve message operations, because of these operations running in their own thread. Thus, thread switching is added to the complexity when the user interface is to be updated.

5.1.5

Evaluation

With a high speed network connection, like a wireless network, all measures are timed below 500 ms which is well within Jacob Nielsens one second limit described in section 2.5. Even though the performance decreases on benchmarks with mobile network simulation, most of the measures are still within Nielsens one second limit. Thus, simple service invocation might be performed without having any progress bar shown, but might feel a bit sluggish to the user[19]. From the measured results, it should also be noticed that SOAP client applications which requires more than one SOAP invocation to show a response to a users interaction, quickly will reach the one second limit. Such applications should either have Web services designed specically to reduce the number of invocations or show a progress bar to indicate remaining time. RPC versus document style requests In order to evaluate RPC versus document style SOAP requests on mobile clients, a scenario where a user have 20 messages which he wants to retrieve on his mobile device is dened. By considering the retrieval of a single message as a RPC style invocation and the retrieval of 20 messages as a document style invocation, the performed benchmark clearly show how mobile SOAP clients benets from avoiding pure RPC style services. In the given scenario, retrieving the messages with only RPC style invocations would require 20 invocations. Thus, retrieving the messages would last approximately 20 130ms = 46

CHAPTER 5.


2600ms on average. In contrast did the document style retrieval of 20 messages last 199ms on average. However, the given scenario can be extended by having the mobile client to regularly check for new messages. In the implemented proof of concept application, this is performed by retrieving all 20 messages for each check, since retrieving all of the users messages is the only way MPower allows messages to be retrieved. The list of messages is then compared to the list currently shown. A RPC style service would in this case allow the client to check if the list of messages have been changed and only download the new messages, thus dramatically reduce data transfer in the long run. The given scenario calls for service platforms to support both RPC style and document style Web services. This would enable clients to use document style services typically to retrieve an initial data set and the RPC style services to update its state according to changes. This combination would help to minimize both processing requirements, thus maximizing battery life, and data transfer.

47

CHAPTER 5.


5.25.2.1

Proof of concept invocation performanceResearch action, justication and goals

The results from the proof of concept application, clearly demonstrated how a direct invocation architecture can be used on an Android device. The relatively low response times on the previously dened benchmark operations, justied a study on how the performance scales on larger sets of response data. For this research action, the same proof of concept application will be used to test retrieval of large sets of user messages. The goal is to identify how the processing duration scales according to the SOAP response size. Additionally, are the measurements comparable with the results from the invocation performance of the same code running on native Java found in section 5.3.4.

5.2.2

Test environment

In order to create controlled responses for the benchmark operations described in the following section, a service mock was set up in SoapUI as in section 4.3.2.

5.2.3

Benchmark description

Benchmark operations 1. Retrieve 100 messages and update the user interface. 2. Retrieve 100 messages without updating the user interface. 3. Retrieve 500 messages and update the user interface. 4. Retrieve 500 messages without updating the user interface. 5. Retrieve 1000 messages and update the user interface. 6. Retrieve 1000 messages without updating the user interface. Each of the operations dened above will be run on the Nokia N800 device and emulator. The operations will also be run on the emulator with the different network simulation modes, UMTS, EDGE, and GPRS. Each operation will be performed ten times and minimum, maximum, and average measurements are calculated for each operation and plotted. 48

CHAPTER 5.


Response complexity In order to relate the results to other systems and SOAP responses, the response complexity from the operations is presented as the size of each response. However, if these results are to be compared with other SOAP responses, an evaluation of how the responses differs in respect to the number of children and siblings in the XML tree, should be taken in account. The response is shown in listing 5.1. For each message in the response a new XML element is added to ActRetrieveMessages. T e s t message f o r p a t i e n t 0 0 1241769279779

Listing 5.1: Retreieve messages response example The size of each response is given in table 5.1 together with the measurement results.

5.2.4

Results

The results from the benchmarks are plotted in gure 5.6, 5.7, 5.8, 5.9, and 5.10. The plots shows the maximum, minimum, and average duration of each benchmark operation listed in section 5.2.3. The results show that updating the user interface have a much more constant time penalty than actually retrieving and parsing the responses. 49

CHAPTER 5.


Response Device 20 messages 100 messages 500 messages 1000 messages Emulator 20 messages 100 messages 500 messages 1000 messages Emulator, UMTS 20 messages 100 messages 500 messages 1000 messages Emulator, EDGE 20 messages 100 messages 500 messages 1000 messages Emulator, GPRS 20 messages 100 messages 500 messages 1000 messages

Size 7kB (6725B) 32kB (31604B) 156kB (156004B) 312kB (311504B) 7kB (6725B) 32kB (31604B) 156kB (156004B) 312kB (311504B) 7kB (6725B) 32kB (31604B) 156kB (156004B) 312kB (311504B) 7kB (6725B) 32kB (31604B) 156kB (156004B) 312kB (311504B) 7kB (6725B) 32kB (31604B) 156kB (156004B) 312kB (311504B)

Average duration 199ms 641ms 2612ms 5368ms 293ms 537ms 2114ms 4068ms 407ms 887ms 3107ms 5869ms 544ms 1428ms 5928ms 11370ms 836ms 3678ms 16571ms 32662ms

Throughput (kB/s) 33.8 49.3 59.7 58.0 23.0 58.9 73.8 76.6 16.5 35.6 50.2 53.1 12.4 22.1 26.3 27.4 8.0 8.6 9.4 9.5

Table 5.1: Androids message retrieval performance on large responses.

50

CHAPTER 5.


8000 7000 6000 milliseconds 5000 4000 3000 2000 1000

Min Average Max

500 messages

500 messages, no UI update

Figure 5.6: Benchmarks running on Nokia N800 with WLAN connection5500 5000 4500 4000 milliseconds 3500 3000 2500 2000 1500 1000 500 500 messages 500 messages, no UI update 1000 messages, no UI update 100 messages, no UI update 1000 messages 100 messages 0 Min Average Max

Figure 5.7: connection

Benchmarks running on Android Emulator with LAN

51



1000 messages

100 messages

0

CHAPTER 5.8000 7000 6000 milliseconds 5000 4000 3000 2000 1000


Min Average Max


Figure 5.8: simulation14000 12000 10000 milliseconds 8000 6000 4000 2000 0

Benchmarks running on Android Emulator with UMTS

Min Average Max



Benchmarks running on Android Emulator with EDGE

52


1000 messages

100 messages

500 messages



1000 messages

100 messages

500 messages


0

CHAPTER 5.35000 30000 25000 milliseconds 20000 15000 10000 5000 0


Min Average Max

500 messages



Benchmarks running on Android Emulator with GPRS

5.2.5

Evaluation

In a real world application, very few responses would be as large as 500 or 1 000 messages. However, the results shows how Android actually handles such large responses. The given results supports the conclusion in section 5.1.5; data should be transfered in batches and larger responses are preferred over multiple Web service invocations. As seen in table 5.1, even with UMTS simulation 500 messages were transferred in approximately three seconds. Such reasonable response times, allows mobile clients to prefetch data likely to be requested by the user. Based on the calculated throughput of 500 and 1 000 messages, the transfer and parsing time seems to scale linearly when the responses are large enough. Constant operations like the creation of the SOAP request and network connection are getting relatively smaller to the entire operation as the response grows. Thus, these constants seems to be negligible on invocations with large responses. In respect to Nielsens response time guidelines, response time up to about ten seconds actually will keep the users attention on the dialog[19]. In respect to this limit, even retrieving 1 000 messages with EDGE network simulation is close to acceptable. 53



1000 messages

100 messages

CHAPTER 5.


Although most results are satisable, it should be noticed how poor the GPRS simulation performed. The throughput of less than 10kB/s would be a major issue for any real world application. However, is this not an Android specic issue and the throughput is actually on line with the theoretical maximum throughput of GPRS networks. It should also be noticed that most mobile networks today is upgraded to support EDGE network speeds or better.

54

CHAPTER 5.


5.35.3.1

Android compared to native Java performanceResearch action, justication and goals

As a reference, the operations will also be run on a simple native Java client. The native Java client will use the same code as the proof of concept application, except that the user interface is removed. The goal is to compare how a native Java desktop client would perform compared with the mobile Android application. It also helps to identify if the best practices described in section 5.4.3 are to be treated as Android specic practices or if they also are applicable to native Java clients.

5.3.2

Test environment

For the large service responses with 100, 500, and 1 000 messages, the same test responses are set up using SoapUI as in section 5.2.2. SoapUI is during these tests running on the same machine as the client application, causing no network latency in the results. All other requests will be sent to the MPower test server at Sintef. The client application is executed on a desktop computer with an Intel Q6600 quad core CPU, 3GB of memory, Ubuntu 9.04, and Suns Java SE Runtime Environment v1.6.0 13.

5.3.3

Benchmark operations

The basic benchmark operations will be the same as listed in section 5.2.3 and 5.1.3 and each operation will be run ten times. Additionally will the large performance test operations describ

android - web service

Documents