Performance Evaluation of Mobile Web Services - IEEE Xplore

7 downloads 205037 Views 822KB Size Report
mobile device host with main focus on the battery consumption. We applied our experiments to both SOAP and RESTful Web. Services. The results we have ...
2011 Ninth IEEE European Conference on Web Services

Performance Evaluation of Mobile Web Services Rabeb Mizouni

M. Adel Serhani

Rachida Dssouli

Computer Engineering Dept., Khalifa University, Abu Dhabi, UAE email: [email protected]

Faculty of Information Technology, UAE University, Al Ain, UAE email:[email protected]

CIISE, Concordia University, Montreal, Canada email:[email protected]

Abdelghani Benharref

Ikbal Taleb

Department of Computer Engineering, Abu Dhabi University, Abu Dhabi, UAE email:[email protected]

Faculty of Information Technology, UAE University, Al Ain, UAE email:[email protected]

Abstract—Due to the advances on mobile technology, it is becoming feasible to host Web Services on a mobile device, making it perceived as potential data collector and provider. Hosting Web Services on mobile devices gains in importance when it comes to deliver real-time contextual data, such as current location or real-time heart rate. In addition to the characteristics of the available network, the usability of the Mobile Host depends on computational resources of the device itself. Currently, some emerging lightweight frameworks to host web services on mobile devices have been developed. They are recognized for their low resources footprint but they are barely tested. Consequently, the potential of utilizing them in reallife settings is not known yet. In this paper, we address this issue and we propose to test the performance of Web Services hosted on mobile devices. We first propose an architecture that allows the deployment of Web Services on mobile devices. The architecture implements an important feature that provides the possibility of resuming and managing the connection state when disconnections happen. Then, we identify and evaluate the QoS of these web services such as response time, availability, throughput, and scalability. We also evaluate the overall performance of the mobile device host with main focus on the battery consumption. We applied our experiments to both SOAP and RESTful Web Services. The results we have obtained are promising and confirm the fact that RESTful Web Services are more convenient for mobile devices as their QoS does not degrade considerably and is kept at a satisfactory level. It also proves the potential hosting of Web Services on current mobile devices with acceptable battery consumption.

this need, many researchers [6], [5] have proposed lightweight frameworks to deploy Web Services on mobile devices. In addition, new generation of commercial light-weight servers have been developed, to fit with the resource constraints of mobile devices, such as iFMW [1], FineWS [2], and I-Jetty [3]. These web servers and frameworks have high reputation for their very low CPU occupancy and memory footprint. However, to the best of our knowledge, the performance of these servers when deployed in the new generation of mobile devices and when they are used in real-life settings as well as the limitations of the solution they offer are barely tested. In this paper, we propose to test the performance of Web Services hosted on mobile devices under real-life settings and using the current available technology. Web service testing targets to ensure correct functionality of the Web Service as well as its reliability, scalability and performance with varying user load. We are interested in investigating the quality of service delivered by these Mobile Web Services on the one hand and the impact on the performance of the hosting device on the other hand. In addition to the characteristics of available network, we strongly believe that these are the main factors that will encourage (or discourage) the wide adoption of these Web Services. To compare the performance of these Web Service under different implementation technologies, we test both RESTfull [8], [16] and SOAP [9] Web Services. Throughout the paper, we use the term m-service to refer to Web Service hosted on mobile devices. The rest of the paper is organized as followed. Section II discusses related work in m-service provisioning and testing. Next, we present mobile Web Service hosting, its challenges and the possible application domains. In section IV, we present a solution to the deployment of mobile Web Services and their invocation using the available technology. Section V presents the result of our experiments and compares them to similar approaches. Section VI concludes the paper and outlines some future work.

I. I NTRODUCTION The last decade has witnessed the proliferation and the rapid growing rate of mobile devices’use. It is even projected that their use will soon surpass laptops as consumers’mobile platform of choice [15]. Comparing to desktop devices, handheld devices have been seen as resource-restricted devices that suffer from mobility-related constraints. However, with the new generation of these devices, their processing power and devices capabilities have increased drastically opening the door to their usage in different application domains [18]. While previously seen as not necessary efficient, hosting Web Services on mobile devices is nowadays emerging as a promising technology for the support of service provision. To answer

II. R ELATED W ORK Many research projects provided frameworks and architectures to help the deployment of m-services. All the researchers

A two-page work in progress paper has been published in SCC 2011

978-0-7695-4536-3/11 $26.00 © 2011 IEEE DOI 10.1109/ECOWS.2011.12

184

have tried to answer the following requirements: (1) developing frameworks suitable for mobile devices, and/or (2) comparing between the two technologies used nowadays to develop Web Services: SOAP and RESTful. The development of new frameworks is driven by the idea that standard frameworks are too large to be deployed on resource constraint environment [6]. In [20], the authors proposed to extend SOA architecture to lightweight mobile devices. They have presented the challenges that offering Web Services on small devices may face and they argued the need for a full extension of SOA to mobile devices as a solution of these challenges. In [17], the authors illustrated the conceptual and technological differences between RESTful and SOAP services and outlined the fact that RESful Web Services are well suitable for basic ad-hoc integration scenarios. And in a recent publication [10], the authors compared the performance of RESTful and SOAP services when invoked from mobile devices. As expected, RESTful services have been proven to offer more flexibility with lower overhead. The authors in [5] proposed a MobWS (Mobile Web Services) provisioning system based on REST architectural principles to avoid the overheads of SOA based systems. They have shown that REST based MobWS provisioning reduces significantly the payload comparing to SOAP. In the same range of ideas, the authors in [6] have developed two frameworks to allow the provisioning of the m-services and they have tested their performance. The first framework is based on RESTful architectural principles and the second framework is based on SOAP. The tests were conducted on a Nokia N80 mobile running Symbian OS. They have shown that RESTful based framework is more suitable for mobile environments. While the above-mentioned research projects compared SOAP and RESTful services, they did not answer three recurrent and critical questions: (1) what is the battery consumption due to the deployment of these services on mobile devices?, (2) Is it worth with the current mobile devices and using the available technologies to deploy Web Services in our mobiles?, and (3) what are the limitations of using these m-services, if any?

Fig. 1.

Web Service and m-service basic Operations

a fact that adds challenges on adapting the m-service resources’needs according to this changing context of use. • Handling disconnections during service execution [13]: In a mobile environment, disconnections may be frequent due to battery, mobility-related issues, location change, communication costs, etc. Again because of the simultaneous mobility of the provider and the requester, the rate of disconnections is expected to be higher than in applications where mobile devices communicate with fixed servers. Such potential disconnections may affect the reliability and the availability of the m-service, a fact that decreases drastically the QoS of m-services, services that may be used to deliver contextual real-time data to the requester. Mobile hosting Web Services opens up a new set of applications. In [18], the authors have enumerated some of these applications that can benefit from hosting the Web Service on the mobile devices from commercial and management prospective. They suggested the guided parcel service application that delivers an exact tracking of the client parcels throughout the delivery process by providing its current location details to the client, avoiding him/her hours of waiting time. In fact, we extend this view to include all applications that deliver to the client real-time contextual data of the service provider on the one hand and consulting services that uses the service provider expertise on the other hand. m-services can provide the service client with on-demand up-to-date, real time information. Contextual data may refer to any data related to the user, his profile, his device or/and his environment, data that may be of capital importance when it comes to use these data to assess on real-time the current situation. We present next the case of m-health applications. m-health are advanced applications that provide healthcare to people anywhere, anytime using broadband and wireless communications, as well as mobile computing devices. The past few years have witnessed a rapid advancement of such mobile healthcare systems [14], [12]. Some of the motivations for such interest are the escalating cost of health care and the increase in the number of aged population who have chronic illnesses. In order to improve home care delivery, many health applications are developed to provide the medical team with

III. W EB SERVICE HOSTED ON MOBILE DEVICES : P RELIMINARIES An m-service is seen as any Web Service that can be operated on a mobile device, such as both voice and data services, for example, roaming, SMS and MMS, video streaming, and location-based services. Similar to fixed server ( refer to Figure 1 (a)) , Web Service hosted on mobile devices architecture is based on publish-find-bind mechanism (as shown in Figure 1 (b)). However, the Web Service provider is implemented on the mobile device. Such assumption brings mainly two challenges: • Restricted use of resources: Web Services for mobile devices need to be more reserved in their usage of computation, memory and energy resources [7]. In addition, the requester as well as the provider are mobile,

185

much more closely to web-based design and is tied to the HTTP transport model. As such, SOAP is more heavy-weight than REST. However, while SOAP is standardized, REST still suffers from a lack of standards support. When deploying Web Services on mobile devices, it is important to consider the limited resources mobile hosts are offering comparing to fixed server and to the characteristics of wireless networks. Consequently, Web Services on mobile devices should be simple in terms of treatment they can perform and in terms of the message size they handle. 4) Dynamic DNS: As we explained previously, mobile devices have intermittent connectivity to the network. In a typical scenario, when a mobile host disconnects and reconnects to the network, its IP will most probably change. Imagine now a client using the m-service hosted on that mobile device. With the IP address change, the URL the client has is no more valid. The client has to search the registry to find the service again and get the new URL to re-bind with the m-service, a process that will decrease dramatically the quality of service of the m-service. The m-service needs to have a unique identify, independently from the IP change. We propose to use Dynamic DNS. As defined in [4], Dynamic DNS is a network service that provides the capability for a networked device, such as a router or computer system using the Internet Protocol Suite, to notify a Domain Name System (DNS) to change, in real time, the active DNS configuration of its configured hostnames, addresses or other information. Using dynamic DNS in our case offers many advantages: (1) After a first discovery of the Web Service in the registry, the same identify is used by the client whenever s/he requires to invoke again that mobile Web Service; (2) It is mostly transparent to applications; finally, (3) it allows resuming and managing the state when the disconnection happens.

the current patient status such as pulse rate, glucose level, and weight. This information is needed to help a remote and proper monitoring of the patient. In this context, m-services can be used on the patient side and on the practitioner side: it helps the data collection and distant access on the patient side and real-time advice delivery to nurse and/or patient on the practitioner side. IV. D EPLOYING M - SERVICES : AN ARCHITECTURE Hosting Web Services on mobile devices is challenging. Any architecture should overcome the two main issues mentioned before: frequent disconnections and restricted resources. In what follows, we first propose a new architecture that allows efficient hosting of m-services. Then, we present the different m-service properties as well as the hosting device properties we are targeting to test. A. Proposed Architecture Figure 2 shows the proposed architecture. Next, we present its components and justify their choice. 1) m-service: The Web Service is provisioned on the mobile device of the provider. When the mobile is on, the Web Service keeps listening to any request from different clients. A lightweight server has to be installed on the mobile device. 2) Client: The m-service can be invoked from a mobile node like a mobile device or a fixed node. The client application may be an m-service itself. 3) RESTful Web Services vs. SOAP Web Service : Simple Object Access Protocol (SOAP) is recognized to be the dominant architecture for service-oriented architecture (SOA). However, SOA can also be implemented using other technologies such as REST [8]. SOAP is an XML based messaging protocol. It consists of four parts : • an envelope that defines a framework for describing the body of the message (what is in a message) and the header that contains information about how to process it [17], • a set of encoding rules, • a convention for representing remote procedure calls and responses, and • a binding convention for exchange messages using an underlying protocol. REST is seen as design approach. It stands for REpresentational State Transfer and it is based on four principles. • Resource Identification through URI (Uniform Resource Identifier) • Uniform Interface for all resources using four messages: GET to fetch the information and retrieve its representation, POST to add new information, PUT to update information, and finally DELETE to remove an information, • Self-Descriptive Messages through Meta-Data, and finally • Hyperlinks to define the application state. Obviously, SOAP and RESTful Web Services have different philosophies. SOAP is really a protocol whereas REST adheres

B. m-service QoS Several works have been done on the evaluation of QoS of Web services, however, very few works have tackled the evaluation of QoS of m-services. The QoS properties of mobile services are varied and large in number. In this study, we consider the following QoS parameters: Throughput, Availability, Response Time, and Scalability. • Scalability: As defined in [19], “ a system is described as scalable if it is able to accommodate an increasing number of elements or objects to process growing volume of requests gracefully ”. It describes the performance of the Web Service under different load conditions. It is usually characterized by the number of responses in total, the number of successful vs. erroneous responses, the average of the execution time (defined as the time from the last byte sent to the first byte received), and finally the average of server time (defined by the time from the first byte sent to the last byte received) [11]. • Availability: represents the probability that an m-service is accessible (available for use) or the percentage of time that it is operating.

186

Fig. 2.

• •

Hosting m-service: Proposed Architecture

A. Test Environment

Throughput: represents the number of requests processed per seconds. Response Time: represents the time needed between issuing a request and getting its response.

The Mobile Host was developed and deployed on a smart phone. Using a Wi-Fi network, the client invokes different mservices deployed within the Mobile Host. The Mobile Host processes the service request and sends the response back to the client. The performance of the Mobile Host and the network latency were observed while processing the client request. The following is the experimentation setup we have used for the evaluation of the above-mentioned QoS properties of m-services: • Nokia Mobile N900, running linux OS Maemo, CPU Cortex (600 MHz), 32 GB mass storage, 256 MB RAM; • Two Access points; • Jetty Web Server on which Web Services are deployed; • JMeter software for trace collection and analysis; • Oracle Java SE for embedded 1.6; • Netbeans 6.9.1 for SOAP and RESTful Web service implementation and testing. Figure 3 describes the experiments setup we have built to evaluate the scenarios we will describe in the subsequence section. We use a JMeter to generate extensive user requests.

These properties need to be tested under optimal conditions, when the mobile host is only listening to the requests for the m-service, and under normal conditions, when the mobile phone is used for other tasks such as talking. C. Mobile Host Performance The performance of mobile devices can be characterized by diverse factors that include for instance the battery time, memory, CPU and other features. We are mainly interested by the battery level of such mobile devices. The battery consumption can be affected by following factors: a. Current applications/servers running b. Number/period of phone calls/reception and conversations per period of time. c. Number/size of SMS send/received. d. Picture display, music and movie playback. e. Number of requests received/handled over a period of time. f. Network bandwidth. g. Bluetooth ON/OF. h. Etc.

B. m-services’ Description We have used a set of m-services to evaluate their QoS when deployed on mobile devices. All these m-services have been implemented in both SOAP and RESTful. The two categories provide the same functionalities and exhibit exactly the same operations. Table I provides a brief description of these mservices.

In our experiments, we will consider factors a, b, e, f, and g as enumerated above. The other constraints are beyond the scope of this paper.

C. Test Scenarios

V. E XPERIMENTS

We just remind that we have settled the following assumptions for our experiments: • There are no firewall restrictions and ports are open; • DNS is used to maintain connectivity once the IP changes due to mobility (Handover) and disconnections.

In this section, we describe our experimental setup as well as the m-services we have implemented for testing purpose, the list of scenarios we have selected to evaluate the QoS of the m-services, and finally we discuss the results.

187

Fig. 3.

Web Service Basic Web service WS Global Weather (GW) Web service Image Catalog Web Service (IC)

Experimental Setup

Service Type SOAP WS & RESTful WS SOAP WS & RESTful WS SOAP WS & RESTful WS

Description Returns a varying text messages. Provides the current weather and weather conditions for major cities around the world. Provides a set of pictures classified by category, size, rate, and type.

TABLE I D ESCRIPTION OF THE M - SERVICES USED DURING THE EXPERIMENTS

D. Test Results and Discussion

We have used the following scenarios for the evaluation of m-services with main focus on service availability, response time, throughput, battery consumption, and scalability.

With regards to the first scenario depicted above, we have conducted series of experiments to evaluate the battery consumption over an increasing period of time while only the Jetty server is up. The Jetty server is kept running on the mobile while the other phone features were disabled (Bluetooth, Phone calls, SMS, etc.). The result of these experiments showed that the application server, when idle, does not consume significantly the battery; it slightly consumes 2% of the battery power in more than 10 hours. Therefore, the battery consumption due to the application server execution will not be consiedered for the rest of scenarios as it is not significant and does not affect the measurements we aim to collect in the other scenarios. 1) Response Time: Figure 4 illustrates the variation of the response time while increasing the number of requests of all the SOAP and RESTful m-services. As mentioned previously, SOAP and RESTful m-services offer the same functionalities and return the same response type and size. The graph shows that the response time of SOAP m-services is relatively high especially when these m-services handle large size of data (e.g. Image WS). Moreover, the SOAP Image Web Service stops accepting requests at around 40 simultaneous requests, however the RESTful m-service handles all generated requests

a) Scenario 1: evaluates the battery consumption once the JVM and the Application Server are running on the mobile device. This scenario will be used as input to the other below scenarios as we need to consider the battery consumption by the JVM and the application server as they are running all the time. b) Scenario 2: evaluates the battery consumption while varying the m-service message size. It also measures when the service reaches its full capacity. c) Scenario 3: evaluates the effect of phone calls and rings on the m-service response time. d) Scenario 4: evaluates the service availability/response time while the mobile user is moving and changes networks. To achieve this goal, we propose to build two networks (routers) and we move across them to test if the m-services maintain connectivity and continue providing the service or not. e) Scenario 5: evaluates the scalability of the m-services in terms of handling an increasing number of client requests and how this affects the battery consumption.

188

Fig. 6. Throughput in terms of number of requests per second for SOAP vs. RESTful Services: RESTful m-services can handle more requests than SOAP m-service

Fig. 4. Response Time of SOAP vs. RESTful m-services: The response time of SOAP m-services is relatively high especially when these m-services handle large size of data

is relatively high and increases when the number of generated simultaneous requests increases. However, it dramatically declines when it reaches around 65 simultaneous requests sent to the Basic RESTful m-service under test. The measured throughput of SOAP m-services are all smaller compared to the throughput of the same RESTful m-services. We deduce from the obtained results that RESTful m-services can handle more requests than SOAP m-services. These, can be explained by the time required to process SOAP request/response which is generally higher that the time required in processing RESTful executed methods, as well as the maximum capacity of the server to handle a large number of requests. 3) Battery Consumption: In Scenario 2 described above, we fixed the number of generated simultaneous request to 100. We used the Image Web Services (SOAP and RESTful) and we changed the image size at each iteration. The message size increases respectively from 500 bytes to 100,000 bytes. Figure 7 shows the results of battery consumption while the message size for both SOAP and RESTful m-services increases. The curve illustrates that the battery drains increasingly until it reaches 18% for SOAP messages and 8% for RESTful messages once a varying message size is considered. The difference between the battery drainage in both types of mservices is noticeable and the RESTful exhibited lower battery consumption. This can be explained by the less processing requirements of RESTful messages compared to SOAP messages, results that are aligned with the results regarding response time and throughput evaluation. Figure 8 describes the same scenario with the same test data but using the three m-services both SOAP and RESTful we have described above. It is noticeable that the SOAP m-services consume slightly more battery than RESTful m-services expect for the last service (Image Web service). We noticed that SOAP Image Web Service consumes 5% of the battery and RESTful Image Web Service consumes 8% of the battery, a result that is not aligned with the other results explained above. The reason behind this discrepancy is that the SOAP m-service reaches its capacity at 40 requests and stops accepting extra requests while RESTful m-service completes the generated 100 requests, which explains the battery consumption of 8%.

Fig. 5. Effect of phone rings and calls on m-service response time (SOAP and RESTful): In all situations SOAP m-services take more time than RESTful m-services

(100 requests) and shows a response time that is significantly lower than its SOAP counterpart. The same applies to other RESTful m-services. Other experiments have been conducted and all of them consolidate this same result. In line with the result published in [6], we conclude that RESTful m-services are lighter than SOAP m-services and exhibit better response time. This is explained by the fact that RESTful m-services do not require the large processing time and the handling of extra XML parsing that SOAP messages require. For scenario 3, we have experienced the following situations: (1) optimal situation where no phone calls and rings are observed, (2) successive phone rings are performed, and (3) phone rings and short conversations are performed. We measure the response time for both SOAP and RESTful with regards to the three situations. Figure 5 shows that in all situations SOAP m-services take more time than RESTful m-services. The response time of the m-services are slightly affected by rings and phone conversations as the mobile phone will allocate resources to handle these unexpected processes. The obtained results of the CPU consumption in this scenario are aligned with the response time results. 2) Throughput: Figure 6 illustrates the variation of throughput measured as number of requests handled per second. The results demonstrate that the throughput of RESTful m-services

189

the type of mobile host and its resources. The maximum number of requests the Image Web Service processed in our experiments is around 100,000 requests after what the m-service drops the coming requests. • The battery consumption does not drop dramatically. As an example and based on our experiments, the maximum battery drainage was 18% once SOAP m-service is experimented and the number of requests was around 100,000 requests. Therefore, the battery drainage should not be a restriction to service provision; it might affect the service provision if the initial battery level is very low. • The phone calls and rings affect slightly the m-service response time as well as the mobile phone CPU consumption, proving the fact that m-service hosting will not degrade significantly the performance of the mobile device. During our experiments, we noticed that the interval between successive readings of the battery level is relatively long. The battery level is retrieved using a shell script that comes with the Maemo OS. This makes it difficult to collect significant readings. Therefore, to overcome this problem and to avoid discrepancies in the battery readings, we executed the scenario of battery reading (Scenario 2) many times then we considered the average of the obtained readings.

Fig. 7. Battery Consumption per message size of SOAP vs. RESTful mservices: RESTful exhibits lower battery consumption

VI. C ONCLUSION AND F UTURE W ORK This paper proposes to measure the performance of Web Services hosted on mobile devices. We first proposed an architecture for the deployment of m-services. Then, we implemented six m-services: three SOAP m-services and their counterpart RESTful m-services. These m-services range from light, that manipulate text, to heavy, that manipulate images up to 1 MBytes. The experiments have shown four major results: (1) mservices can be used efficiently with todays mobile devices, (2) RESTful m-services are lighter than SOAP m-services. As such, they have better response time and CPU usage and drain less the device battery, (3) Battery consumption is considered reasonable and acceptable, and finally (4) mservices are not meant to be a replacement for high-end servers hosting Web Services designed for heavy transactions processing and they are recommended for relatively small number of straightforward transactions. As a future work, we are planning to extend our experiments to cover other platforms and mobile devices, such as the iPhone, and compare their performances.

Fig. 8. Battery Consumption for SOAP and RESTful m-services: the SOAP m-services consume slightly more battery than RESTful m-services expect for the Image Web Service

4) Availability: With regards to Scenario 4 described above, we conducted a series of experiments to evaluate the effect of mobility on the availability of both SOAP and RESTful mservices. The results we obtained are very promising where the m-service remains available and continues to provide the service. However in this operation its response time is slightly affected as the handover guaranteed by the Dynamic DNS solved the network disconnection but requires a small processing time to allow the authentication required to establish the connection to the new network. Up on connection the service resumes handling the client request(s). 5) Discussion: Finally, and based on the results of the scenarios we have described above, we draw hereafter the following conclusions: •



R EFERENCES

RESTful m-service is lightweight and proved that it is more suitable to be deployed and used via mobile host comparing to SOAP m-services. The results demonstrated that almost 30% is gained in response time and throughput and 10% is gained in terms of battery consumption. The capacity of the m-service in handling large number of requests is limited by a certain threshold. This threshold depends on the size of requests and their frequencies, and

[1] http://ifmw.mobi/ifmw/index.php, November 2010. [2] http://www.goldenpack.com/en/product finews en.asp, November 2010. [3] http://www.cuteandroid.com/open-source-android-apps-for-developers-ijetty-webserver-for-the-android-mobile-platform, February 2011. [4] http://en.wikipedia.org/wiki/dynamic dns, January, 2011. [5] F. Aijaz, S. Ali, M. Chaudhary, and B. Walke. Enabling high performance mobile web services provisioning. In Proceedings of the 2009 IEEE 70th Vehicular Technology Conference Fall, page 6, Anchorage, Alaska-USA, Sep 2009. IEEE.

190

[6] F. AlShahwan and K. Moessner. Providing soap web services and restful web services from mobile hosts. In Internet and Web Applications and Services (ICIW), 2010 Fifth International Conference on, pages 174 – 179, May 2010. [7] S. Berger, S. McFaddin, Chandra Narayanaswami, and Mandayam Raghunath. Web services on mobile devices-implementation and experience. In Mobile Computing Systems and Applications, 2003. Proceedings. Fifth IEEE Workshop on, pages 100 – 109, oct. 2003. [8] Justin R. Erenkrantz, Michael Gorlick, Girish Suryanarayana, and Richard N. Taylor. From representations to computations: the evolution of web architectures. In Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, ESEC-FSE ’07, pages 255–264, New York, NY, USA, 2007. ACM. [9] Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, Anish Karmarkar, and Yves Lafon. Soap version 1.2 part 2: Adjuncts (second edition), 2007. [10] Ramzi Abed Hatem Hamad, Motaz Saad. Performance evaluation of restful web services for mobile devices. International Arab Journal of e-Technology, 1, January 2010. [11] Sander Kikkert. Performance of web services on mobile phones, 2010. [12] Sunil Kumar, Kashyap Kambhatla, Fei Hu, Mark Lifson, and Yang Xiao. Ubiquitous computing for remote cardiac patient monitoring: a survey. Int. J. Telemedicine Appl., 2008:3:1–3:19, January 2008. [13] Zakaria Maamar, Quan Z. Sheng, and Boualem Benatallah. On composite web services provisioning in an environment of fixed and mobile computing resources. Information Technology and Management, 5:251– 270, 2004. 10.1023/B:ITEM.0000031581.31936.b9. [14] Hailiang Mei, Bert-Jan van Beijnum, Pravin Pawar, Ing Widya, and Hermie Hermens. A*-based task assignment algorithm for context-aware mobile patient monitoring systems. In Proceedings of the 2009 15th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, RTCSA ’09, pages 245–254, Washington, DC, USA, 2009. IEEE Computer Society. [15] Earl Oliver. A survey of platforms for mobile networks research. SIGMOBILE Mob. Comput. Commun. Rev., 12:56–63, February 2009. [16] Cesare Pautasso and Erik Wilde. Restful web services: principles, patterns, emerging technologies. In Proceedings of the 19th international conference on World wide web, WWW ’10, pages 1359–1360, New York, NY, USA, 2010. ACM. [17] Cesare Pautasso, Olaf Zimmermann, and Frank Leymann. Restful web services vs. ”big”’ web services: making the right architectural decision. In Proceeding of the 17th international conference on World Wide Web, WWW ’08, pages 805–814, New York, NY, USA, 2008. ACM. [18] Satish Srirama, Matthias Jarke, and Wolfgang Prinz. Mobile host: A feasibility analysis of mobile web. In Service Provisioning, Proc. UMICS 2006, @ CAiSE06, pages 942–953, 2006. [19] S.N. Srirama, M. Jarke, Hongyan Zhu, and W. Prinz. Scalable mobile web service discovery in peer to peer networks. In Internet and Web Applications and Services, 2008. ICIW ’08. Third International Conference on, pages 668 –674, June 2008. [20] R. Tergujeff, J. Haajanen, J. Leppanen, and S. Toivonen. Mobile soa: Service orientation on lightweight mobile devices. In Web Services, 2007. ICWS 2007. IEEE International Conference on, pages 1224 – 1225, 2007.

191