Keywords

1 Introduction

The smartphone landscape has made significant leap and transformed the phone from a handset used merely for voice calls into a state-of-the-art mobile computing device [1]. Today, smartphones are capable of hosting a large variety of client-side applications in areas such as banking, education, and health. There are also attempts to turn the smartphone into a development environment such as the Android IDEFootnote 1.

On the other hand, developing applications using service-oriented architecture (SOA) and resource-oriented architecture (ROA) has paramount importance [2]. In this regard, client-side applications which are composed of SOA/ROA based Web service components can also be hosted on the smartphones. However, to the best of our knowledge, the smartphone is not yet in use as a Web service composition device.

The end-user development research community, on the other hand, confirms that end-users can innovatively develop their own applications with little or no programming knowledge [3, 4]. Thus, a possibility of composing Web services on smartphones would enable the exploitation of smartphone users’ creativity so that they can develop their own applications and also contribute their work to app stores for use by others. For example, a supplier may need a custom made application for his smartphone to find customers with the best price offer for products to sale, negotiate a contract, arrange billing details, and logistics for shipment as shown in Fig. 1.

Fig. 1.
figure 1

Service composition on smartphones

Full size image

Figure 1 depicts a system design (a scenario) of Web service composition on a smartphone. The figure demonstrates Web services being provided from customers’ devices (left), the smartphone being used in the wiring of workflows for composing Web services (middle), and Web services being provided from third-party organizations’ devices (right). Accordingly, the supplier performs Web service composition by wiring interfaces of the exposed services.

The above described scenario requires identifying the most appropriate Web service and associated technologies for simplicity of composing on smartphones. In this regard, although many of the available mash-up tools are claimed to be for end-users too, they are generally targeted towards data integrators for use on classic computing devices. Moreover, practice shows that they also require significant programming skill [5].

Additionally, a client application is required to be thick enough for interactive business applications [6]. It is also worth mentioning the situations of low bandwidth and intermittent Internet connectivity like the case of many developing economies [7]. Thus, hosting composite applications on the smartphone as a thick-client would compensate the negative impact of intermittent and low bandwidth mobile connectivity. However, to the best of our knowledge, there is no established trend in the hosting of service-based (composite) client-side applications on the smartphone.

Thus, composing Web services directly on the smartphone and hosting the resulting client-side application on it has paramount importance. However, smartphones are still constrained in terms of input mechanisms, storage, and screen size and these are essentially the challenges which could limit the operations of Web service composition and hosting.

In fact, service composition is an existing challenge already [8]. For example, Beaton et al. [9] reveal that service consumers encounter challenges such as fragmentation of the discovery user experience across multiple interfaces, confusing hierarchies of service navigation, lack of business modeling support, hidden relationships between services, and inconsistent Web service interface design. Some of the manifestations of these challenges are through the difficulties developers encounter while assembling data structure in Web service parameters, cycles of errors due to unclear control parameters in data structures, and difficulties to understand long identifier names.

Thus, the fast proliferation of Web services and dynamically changing user requirements are demanding increasing design consistency and simplicity of Web services. In addition, addressing design issues for the use of Web services in smartphone applications development challenges even more [8].

In smartphone application development, the software design process is driven by the limited resource of the specific device. In this paper, we concentrate on and examine Web service technologies for the required resources for composing and hosting on smartphones and the degree to which the resulting smartphone application is lightweight and usable enough to please end-user developers. Thus, the small and diverse screen sizes, storage capacity, and configurations of the smartphone need to be considered when developing Web services. In addition, issues such as performance, footprint size, and usability must all be taken into account. Accordingly, we conduct a literature-based survey of available Web service and related technologies relevant to compose Web services on smartphones structured in four categories, namely:

  • Types of Web services;

  • Messaging and data serialization formats;

  • Service composition techniques and languages; and

  • Mobile client application development approaches.

In addition, we evaluate candidate technologies for their desirable features and limitations and proposed stack of appropriate technologies aimed towards tailoring Web service composition environment for a smartphone. Thus, the paper is organized as follows. In Sect. 2, we present a survey of Web service and associated technologies in each of the above mentioned categories. Sections 3, 4 and 5 respectively detail evaluation of these technologies, discussion of results, and the conclusions drawn.

2 Survey of Web Services and Associated Technologies

Web services are implementation technologies of SOA and ROA. They are inspired by the need to integrate and reuse software for the dynamically changing and highly collaborative stakeholder needs of today’s businesses. Additionally, we provide the associated technologies which are used for developing applications using Web services as presented below. Accordingly, we approached the survey by classifying the Web services and associated technologies in four categories as depicted in Fig. 2.

Fig. 2.
figure 2

Web service technologies in categories

Full size image

Figure 2 shows a client-server interaction between mobile clients and Web services through messaging formats. In addition, the composition techniques and languages component in the figure signifies the technology with which the code logic of a mobile client can be developed. Accordingly, these Web services and associated technologies are described next.

2.1 Type of Web Service

Web services can be broadly categorized into SOAP (Simple Object Access Protocol) and REST (Representational State Transfer). SOAP services work in the context of SOA based-on foundational Web technologies like the DOM, URL based discovery, and HTTP messaging with XML [10]. REST services, on the other hand, correspond to the ROA which works based-on the concept of Web resources’ URL addressability and the mechanism of passing-in parameters via the URL [10, 11]. A review on the challenges of composing Web services on smartphones is presented next.

In SOA, self-contained software services are used to build applications or other software services and the process is called Web service composition. Thus, software components are made interoperable leveraging the flexibility to meet customers’ use cases, to have access to data in a unique context, and to meet customers’ preferences to interact from a smartphone device [12].

Srirama et al. [8] pointed out that the smartphone can be used as a Web service requestor, and as a host. However, it faces a number of hardware challenges such as the small screen size which would limit the use of the smartphone as Web service composition device [19].

The composition of Web services on smartphones could also be challenged due to usability limitations of the Web services themselves. For example, usability of Web services could be impeded due to the complex data structures in SOAP; and the manual operation in REST [9, 11]. Thus, from the perspective of type of Web service, composition requires programming skill which prohibits non-programmers for building applications [5].

2.2 Messaging Format

The type of messaging and data serialization format is among such associated technologies for Web service composition. Nurseitov et al. [15] pointed out that the choice of data format can have significant consequences on data transmission rates and performance. Today, many data formats are available like XML, JSON, Protobuf, efficient XML interchange (EXIFootnote 2), and Thrift [17]. However, with the ever increasing access to a diversity of Internet-connected devices, choosing the appropriate data serialization format for use on the constrained smartphone has become a challenge [16]. Thus, comparing data format as text versus binary with respect to the smartphone has paramount importance.

2.3 Web Service Composition

Orchestration and choreography are among the service composition techniques applicable on both SOAP and REST Web services and selecting among them is dependent on the purpose of the application in question [18]. In this paper, we concentrate on the use of a smartphone as a coordinator in the orchestration of Web services for building applications. However, the difference in the conventional practices of the SOAP and REST services has induced differences in the composition techniques and languages.

Thus, service composition approaches can be categorized either as control flow, data flow, and assisted by service consumer [19]; or as static, automatic, and semi-automatic [20]. The composition languages, on the other hand, are BPMN, WS-BPEL and HTML5 together with JavaScript APIs; these can all be categorized as graphical modeling, XML-based, and Web 2.0 technologies, respectively. Both the BPMN and WS-BPEL have standard business process execution engines. Here our intention is not to provide generic comparison of such a varying collection of technologies and their variants like the BPEL for REST servicesFootnote 3 in the WS-BPEL. Accordingly, we concentrate on the WS-BPEL industry standard for its role in the composition of SOAP services [18], and HTML5 which is in use as a mash-up language together with JavaScript APIs (in the Web 2.0 context) for REST services as representative alternative technologies for our perspective. These technologies are evaluated with respect to the requirements of composing on smartphones.

2.4 Mobile Client Application

The composition tool in use also influences the task of composing Web services on smartphones. Essentially, this represents the mobile client application and it denotes the Web service consumer in the composition. Due to the proliferation of smartphones, it is a common practice today that Internet users employ mobile Web client applications such as Opera, Chrome, and Safari browsers for their Web experiences [1]. In addition, native and cross-platform smartphone application development approaches are also employed to communicate with Web services [21]. Thus, studying the characteristics of mobile client applications with respect to the goal of composing Web services on smartphones and the need to host the composite applications is of paramount importance.

In general, the existing literature provides significant insight into the Web services and the associated technologies; and Web service composition. However, to the best of our knowledge, composition with respect to the resource limited smartphone environment is not sufficiently explored. Thus, further review of literature focusing on the influence of the technologies for enabling composition on smartphone platforms is presented next.

3 Evaluation of Technologies

3.1 Methodology

This study was conducted using literature survey on Web services and associated technologies according to the four categories depicted in Fig. 2. Performance, amount of communication and storage footprint; and the level of simplicity to work on the constrained input components and the small but variable screen real-estate of the smartphone landscape were given due consideration for evaluating each category presented in the previous section. Thus, description of each evaluation criteria is presented next.

Type of Web Service.

Here, we concentrated on the distinct features and shortcomings of the SOAP and REST services with respect to the smartphone platforms [14]. That is, the SOAP service uses a standard XML-based message envelope and a set of rules for exchanging structured information which means it has a significant message payload, a parser, and an explicit interface description with WSDL. The REST service, on the other hand, is a lightweight implementation which uses HTTP and URIs to characterize its addressability, uniformity, connectivity and statelessness [14]. Thus, the literature indicates that these inherent characteristics leverage for using complexity, performance, flexibility, footprint, reusability, usability, and scalability as evaluation criteria (see Table 1).

Table 1. Literature summary on the evaluation of Web service technologies
Full size table

Messaging Format.

Messaging is a fundamental function in distributed environment that requires data serialization and de-serialization. Thus, the literature shows performance, footprint, and usability as major evaluation criteria for XML, JSON, Protobuf, and Thrift with respect to their appropriateness for smartphone platforms [16]. In addition, we extend these criteria by adding complexity, flexibility, reusability and scalability for their influence during service composition and invocation (see Table 1).

Composition Techniques and Languages.

Here, our literature survey was focused on identifying the criteria for static, semi-automatic, and automatic composition techniques as in [19, 20]; and the WS-BPEL and Web 2.0 languages (see Sect. 2). Thus, we found out that performance, footprint and usability are significant criteria for the resource-constrained smartphone [8, 19]. In addition, the use of WS-BPEL standard with SOAP services versus Web 2.0 with REST have strong influence on performance, footprint, and usability [18, 22]. Hence, we adopted these as our criteria along with complexity, flexibility, reusability and scalability evaluate the technologies with respect to the smartphone platform (see Table 1).

Mobile Client Application.

In a similar context, we identified criteria to evaluate the mobile client application development approaches. In this regard, Dalmasso et al. [21] used criteria like software quality, usability, development cost, time to market, adaptability, and extensibility when comparing the native, Web, and cross-platform mobile client development approaches. These in many ways represent our complexity, performance, flexibility, footprint, reusability, usability, and scalability criteria described above with respect to evaluating the client development approaches (see Table 1).

In general, the mapping of the Web service and associated technologies into the smartphone environment is influenced by complexity, performance, flexibility, footprint, reusability, usability, and scalability. Thus, evaluation of the four categories technologies conducted by mapping against the criteria as presented next.

3.2 Evaluating Types of Web Service

SOAP service consumers use the SOAP protocol to locate, contact, and invoke the service while the standard HTTP verbs and URIs are sufficient for the REST [23]. In order for a client to use SOAP Web services, it must generate a client code from the WSDL interface which is quite a complex effort [13]. This complexity is also magnified by the fact that developers must produce the same mobile application for several platforms. REST, however, is designed to operate with thin clients without a strict prerequisite for explicit interface description [25]. Thus, REST is less complex than its SOAP counterpart.

In the SOAP service, the process of generating client code from WSDL must make use of heavyweight parsers which are too heavy for the resource-constrained smartphone [9]. This leads to greater performance degradation of the application that employs SOAP services [14] as compared to the WSDL-less REST counterpart [26].

The SOAP service is highly structured which implies that changing a service requires a significant change in the corresponding WSDL and hence change of client code [26]. Moreover, disseminating such change for multiple smartphone platforms is cumbersome. Although similar descriptive languages like WADL and WSDL 2.0 are proposed for the REST services, they do not represent its resource-centric, self-descriptive, and loosely coupled nature [13, 18]. Thus, making a change in a REST service does not significantly affect client code, which makes it a more flexible approach than SOAP.

In the SOAP services, a SOAP protocol specifies an XML-based message envelope and a set of rules for converting platform specific data types into XML representations [14]. With large message payloads, the footprint for enveloping and setting the rules require more memory to be composed on the smartphone. However, the REST service is directly invoked with HTTP and the response is a representation of the resource itself [25]. Thus, no XML overhead is needed for encapsulating communication interfaces, and specifying input/output data types. As a result, the amount of storage and communication footprint of REST is significantly lower for the smartphone than its SOAP counterpart [26].

SOAP service uses a complex data structure which generally restricts its reusability [9, 23]. Reusability of the REST, on the other hand, takes the advantage of the Web 2.0 paradigm which prefers direct access to Web resources [19]. Similarly, the complex data structure attributed to SOAP makes the composition difficult and error prone [9]. In addition, the lengthy process used to locate, contact, and invoke the service limits developer productivity [23]. These characteristics of the SOAP service limits its usability. Unlike SOAP, however, the URI accessibility of REST services attributes to its ease of reuse. Thus, REST services are widely used to build composite applications [27]. However, they also have usability challenges due to the difficulty of encoding a large amount of input data in the resource URIs and the lack of automated tools [26].

For many of the above mentioned reasons, SOAP services also have scalability limitations. The REST services, however, are designed to support caching and parallelization on URIs. For example, GET responses can be cached in proxies and gateways. Moreover, compared to the ad-hoc partitioning of operations behind SOAP interfaces, REST provides a very simple way to support load balancing based on URI partitioning. Hence, together with the possibility of making stateless interactions, the REST service can enable the building of more scalable systems; and the fact that the whole Web is built on REST principles proves its scalability [28].

3.3 Evaluating Messaging Format

XML and JSON are text-based formats which need to be parsed character by character, hence demand heavyweight parsing [16]. However, Protobuf and Thrift are binary formats and use a technique called positional-binding to store a message’s name part of the name-value pair in a separate file [16]. In addition, binary formats incur an extra step because they are language dependent and therefore need to be compiled before use. Thus, both text-based and binary formats exhibit a certain level of complexity.

Sumaray and Makki [16] pointed out that XML produces the largest amount of data, followed by JSON, and then Thrift, with Protobuf being the smallest, hence serialization performance is inverted. A related study by Pentland et al. [7] also confirmed that the data transfer speed of JSON is better than XML. Any change on the data serialization format of the service being invoked may introduce system faults. As long as the substitute data serialization format and the services are compatible with the client’s technology, the choice of data format is not a real concern. However, the human-readable characteristic of the text-based protocols is generally a better choice for subsequent use of the data [16].

Because XML and JSON are easily read by human, the resulting data can be reformatted as required and also opens an opportunity for cross-platform compatibility. In addition, XML and JSON are supported by a multitude of programming language APIs. Thus, a Web service that implements XML or JSON as its data format is generally more reusable [16].

The human-readability characteristic of XML and JSON is especially important for reading the context of the data while debugging and making them more usable than the binary formats. Yet, the usability of XML and JSON prevails over the binary formats because they have better documentation and user base [16].

The scalability criteria of data formats can be seen from the perspectives of the data and the application that uses it. Thus, XML is scalable and the scalability of JSON can also be achieved using JSON-schemaFootnote 4. However, the ability to support multiple platforms and the need to minimize footprint size as more services are invoked makes the choice of data serialization format a design trade-off. Thus, the literature shows that text-based messaging and data serialization formats appear to be highly important for smartphone.

3.4 Evaluating Composition Technique and Language

Among the composition techniques described in Sect. 2, the semi-automatic is regarded as difficult for nonprogrammers while the automatic technique is the simplest [4, 20]. Similarly, the complexity of a composition language depends on how the states and transitions are managed. Thus, WS-BPEL is more complex than Web 2.0 as it needs to track the states and transitions between the client and each Web service [28].

Automatic service composition, on the other hand, strives to automate user goals extracted from the request and builds the causal link matrix among the inputs and outputs of the services participating in the composition [20]. Thus, transforming natural language into formal requests, the discovery of services and execution sequencing are all made using an automated tool, which significantly degrades the performance of smartphone applications. However, Web 2.0 applications are lightweight and run faster than WS-BPEL based tools which need to execute a graphical workflow designer, process flow logic template, and the BPEL engine on the client [29].

Arguably, questions of flexibility are not appropriate for static techniques. However, the semi-automatic technique has a higher flexibility compared to the automatic [4]. For the languages, the use of HTML5 together with JavaScript APIs to compose a set of loosely-coupled REST services is more flexible when compared with the WS-BPEL standard which is generally used to aggregate the structured WSDL interfaces of SOAP services [30].

Regarding communication and storage footprint, the language of choice is more important than the composition technique. Thus, the Ajax feature of Web 2.0 intrinsically provides an asynchronous function in which a partial page refresh would reduce the amount of content drawn into the smartphone resulting in a smaller footprint, while the verbose nature of XML leads to a greater footprint in WS-BPEL [22].

One of the goals of Web services and compositions is to promote service reuse [4]. When considering the service composition techniques and languages, however, it is imperative to explain the reusability of the end result instead of the techniques. The lack of user involvement in the automatic composition limits reusability of the end result, however. Hence, static and semi-automatic techniques provide an opportunity for users to manipulate the result for future reuse [20]. Similarly, reusability of a Web service resulting from WS-BPEL is restricted by the highly structured nature of the WSDL [23]. HTML5/JavaScript APIs, on the other hand, takes advantage of the reusability of Web 2.0 [19].

The automatic composition provides a system for managing services’ compatibility [4] which makes the process more user friendly than static and semi-automatic; and the set of automated composition tools associated with WS-BPEL makes it preferable in terms of usability. However, the promise of uniform service interface standards has proven elusive, and absolute automation is unattainable which makes the usability arguable [28].

Web 2.0 is rich in user experience, however, the REST lacks a formal framework to describe, find and orchestrate the services [20, 28]. Thus, the capability of the Web 2.0 technologies is restricted to the use of static or semi-automatic, and the choice of a composition language is a technology selection tradeoff with respect to usability criterion.

Wajid et al. [4] also revealed that the automatic composition technique has limitations in scalability, as it is criticized for its not accommodating user preferred services on templates. The impact of a composition language on scalability is, however, more dependent on the service itself, implying that REST based applications developed with Web 2.0 technologies are more scalable than SOAP service composed with WS-BPEL [28]. In general, our survey indicated that the choice of a composition technique and language generally influences the composition of both the SOAP and REST services.

3.5 Evaluating Mobile Client Development Approach

In the mobile Web client, entering a URL into a general purpose mobile Web browser is the only necessary condition that a user is required to fulfill, which makes it a simple process. The cross-platform and the native mobile clients, however, need to be searched, downloaded, and installed on the mobile client before their actual use. The native approach is even more complex for service consumers because it requires recompiling the resulting code for many different smartphone platforms [21].

The performance of a mobile client application can also be influenced by its processing capacity and communication latency [14]. In fact, the processing capability of smartphone appliances is growing fast and surpasses the bandwidth and latency of a wireless infrastructure where a thick client plays significant role. For example, in the context of developing countries, the quality of installation and maintenance of wireless data communication infrastructure is much less than the market penetration of state-of-the-art smartphones which are usually limited to offline use. In addition, a mobile client should be thick enough to meet the fast response rate of interactive business applications [6]. Thus, while native and cross-platform approaches can implement a thick client and enhance communication performance by placing a considerable processing and caching load on the client side, the Web client does the converse and offloads client side processing.

Flexibility is another important aspect of a mobile client application that describes the ease and cost of propagating changes to each mobile user. In this case, a Web client (mobile Web browser) just sends requests to the server and presents the response content back onto the screen, which makes it the most flexible approach of all. This is followed by the cross-platform approach for its deployment on many platforms, with the native client being the least flexible [21]. A mobile Web client avoids the need for client side processing and storage, but, also incurs a considerably large amount of communication footprint.

In view of reusability, it is important to mention the fact that mobile clients can employ composition tools to aggregate multiple Web services together and result in specific applications or other reusable services [20]. That is, a mobile Web client owner executes the logic of a composite application which is exclusively located on a remote server and also stores the resulting data back. In the cross-platform and native mobile client approaches, however, the logic of a composite application and its data are stored on the smartphone. Thus, depending on the design goal, all mobile client approaches can be used to generate reusable results.

Usability is another criterion that is employed in the selection of an appropriate mobile client development approach. Thus, studies reported in [21] revealed that the native approach has the highest usability, and that the cross-platform approach provides a user experience similar to the mobile Web.

Scalability is also an important aspect in the design of a mobile client because a growing number of connected mobile clients can lead to the risk of a single point of failure, with consequent limitations in extensibility. Thus, the Web client is highly centralized while the thick client approach (cross-platform and native) would enhance scalability [6, 31]. In general, the choice of a mobile client application development approach generally influences the characteristics of a service composition environment on the smartphone.

4 Results

Our analysis has identified SOAP and REST services as the main candidate technologies for service composition on smartphones. Regarding SOAP, studies in [8, 26] suggested kSOAP2 and kXML2 should be used for resource-limited smartphones. However, Mohamed and Wijesekera [26] pointed out that REST services are generally less resource consuming and more efficient to implement on smartphones. That is, the fact that REST services focus on the description of resources rather than describing how operations are performed presents a fundamental difference for consumers compared to the use of SOAP [27]. Thus, although SOAP services have been in use for long and appear as the only choice, REST services have come into the frame backed by quantitative data as a better choice for building flexible, scalable and loosely-coupled applications on smartphones (see Table 1).

In the messaging and data serialization formats category, the text- binary feature has made clear distinctions. That is, the text-based formats are generally characterized as human-readable and platform independent, and the quantitative data in [16] reveals their low serialization speed and large footprint compared to binary formats. In addition, Sumaray and Makki [16] recommended that unless there is a compelling reason, XML must be avoided from mobile applications. However, although JSON’s serialization speed is a bit lower than that of the binary formats, its human-readability and platform independence outweigh this slight performance limitation.

Our analysis has also revealed important characteristics of the composition techniques and languages in view of implementing on smartphones. Thus, as described in Table 1, the semi-automatic composition technique prevails in respect of many of the specified criteria, with the exception of usability. Similarly, although Web 2.0 technologies lacks standard tool support for composing services, it is best suited for the smartphone when compared to WS-BPEL in respect of many of the criteria, including performance. In addition, the capability of Web 2.0 technologies to write and parse JSON data on any platform leverages its use on smartphones.

The mobile client application development approaches category also showed significant prospect. That is, the literature-based summary in Table 1 demonstrates that among other criteria, communication performance of the native and the cross-platform mobile client approaches outweigh those of the mobile Web client, while being characterized by a lower processing performance and a high storage footprint.

Thus, the cross-platform approach can be tweaked just like the native approach for better usability and reaching a large number of users of different platforms; and it is more appropriate to design a thick cross-platform client to compensate for the communication bandwidth and latency limitations of the smartphone.

Overall, our analysis of the state of the art of technological readiness for Web service composition on smartphones has portrayed important insights into the selection of appropriate technologies. Accordingly, we present our findings based on the features and shortcomings identified during the mapping of technologies to the smartphone platform as follows.

  • The REST service works based on limited standards and tools, however, its light-weight, easily accessible, scalable, and self-descriptive design makes it more appropriate for service composition on smartphone.

  • Semi-automatic composition of REST services using Web 2.0 technologies enables the achievement of flexibility, performance, and simplicity. In effect, the matching of Web 2.0 technologies with the REST service [22] can reward certain limitations of the recommended technologies such as easing usability during semi-automatic composition.

  • Regarding the messaging and data serialization formats, we highlighted earlier that JSON has an acceptable data serialization speed and that it can be written and parsed on any platform. In addition, the fact that JavaScript contains APIs which can easily parse JSON data makes it well-matched to Web 2.0 technologies provisions.

  • Similarly, the cross-platform mobile client application development approach is found more appropriate for reasons explained in the above sections. In addition, our previous research [24, 32] pointed out that a cross-platform approach can be used to implement a REST service composition tool with Web 2.0 technologies.

Overall, the REST services, semi-automatic service composition with Web 2.0 technologies, messaging and data serialization with JSON, and the use of cross-platform mobile client approaches all together constitute a stack of appropriate technologies.

5 Conclusion

The purpose of this paper is to conduct a literature-based survey of available Web service and associated technologies relevant to compose Web services on the smartphone environment. Accordingly, because REST services are light-weight, easily accessible, scalable, and self-descriptive, they are found more appropriate for composing Web services on smartphones. In the same setting, semi-automatic composition with Web 2.0 technologies demonstrated appropriate combination of composition approach and language mainly because of better flexibility, performance, and simplicity.

In the case of messaging and data serialization formats, JSON is found more appropriate given its human-readability, platform independence, acceptable data serialization speed and ease of data parsing with JavaScript APIs. Similarly, approaches for mobile client development are evaluated and the cross-platform approach was found to best suit our study’s criteria, mainly for compensating potential bandwidth and latency limitations, a better user experience and reaching a large audience while fully exploiting a smartphone device’s capability.

In general, the REST service, semi-automatic composition with Web 2.0 technologies, messaging and data serialization using JSON and the cross-platform mobile client approach constitute a stack of appropriate technologies for the composition of Web services on the constrained smartphone platform. However, these set of technologies revealed usability limitations due to lack of standards and automated composition tools. In addition, issues such as security are not included in the scope of this study. Our future work will address both limitations.