Mobile Web Services

The challenge for architects designing software is to be able to seamlessly support mobile devices. Where a software architect could before count on a keyboard, mouse, and monitor together with a hard disk drive, a reasonable amount of memory and processing power, she can no longer count on such a fixed and well-defined target platform. Instead, the architect must now concern herself with whether a display is available at all, and whether the available processing resources are sufficient to provide a reasonable latency to the application. Moreover, as the number and type of mobile devices increase, architects must think about how the nuances between different devices will affect their software.

Web services are an interesting addition to the technology mix for developing mobile applications. The use of Web services allows some, if not most, of the application's business logic to run on remote servers, which are independent of the mobile device's computational resource limitations. This has the added benefit that a variety of mobile devices can effectively access the same functionality or business logic.

With much of the business logic implemented and executed on remote servers, the developer can focus her time on the application's user interface (UI). It is amazing how little time engineers devote to thinking about and designing an application's UI. The UI is the gateway between the user and the application's business logic. Even the most valuable of applications, if coupled together with an ill-thought-out and ill-presented UI, will have only limited market success. The extra days or weeks spent in thinking about and developing an appropriate, intuitive, and easy-to-use UI for each target device are well worth it.

Since the use of Web services separates some of the business logic and does not require that the entire application be run on the mobile device itself, the time to download (over a wireless network) an application to run it can be greatly reduced. Assuming that most of the business logic is provided by Web services, the only portions of the application that must be downloaded are the user interface and the integration logic necessary to invoke, coordinate, and integrate the various Web services.

If the required functionalities of an application already exist as Web services, the development time and overall time-to-market can be greatly reduced, creating competitive advantages for those who use Web services for mobile applications. Testing and maintenance time and costs can also be reduced through a distributed and modularized Web services architecture.

Table 10-1 enumerates and compares some of the advantages of using Web services for mobile applications. The data provided is for a mobile chess game application. The column labeled Monolithic Chess Game lists data for a monolithic Java application that includes the user interface together with all of the business logic. The column labeled Web Service Chess Game lists data for a distributed application that implements a local (on the mobile device) user interface but relies on a remote Web service to determine the next move for the computer.

Table 10-1. Comparison of download file size, download time, and performance between a monolithic mobile application and a Web service-based mobile application

	Monolithic Chess Game	Web Service Chess Game
Download File Size	621 KB	56 KB
Wireless Network File Download Time	00:07:34	00:00:41
Wireless Network Monthly Data Allowance (10MB plan) Usage	6.2%	0.006%
Application performance (seconds per move)	54 to 720	10 to 81

The file that must be downloaded for the monolithic chess game application is more than eleven times larger than that for the Web services-based application. This results in a download time of more than seven minutes and thirty-four seconds for the monolithic application as compared to just forty-one seconds for the Web services application. Mobile users with a flat-rate monthly data bandwidth billing will use up almost ten percent of their monthly allowance downloading the monolithic application, but less than one percent with the Web services application.

The large file size will dissuade most mobile users from downloading the application over the air, where the forty-one second download time for the Web services-based application will motivate even users unfamiliar with the application to download the application, on an impulse. Of course, the Web services application will use additional bandwidth or time as the user uses the application. However, by this time, the user will have made a determination as to the positive value of the mobile application, and the continued wireless network usage will be justified.

The Web services-based chess game application also shows a lower and more consistent latency than the monolithic application. The latency measured is the amount of time necessary for the chess game application to determine its next move given the user's current move. Since the Web service is running on a powerful server, its latency increases minimally as the game progresses and the next-move computations become increasingly complex. The Web service latency is bounded on the lower end by network delays. The monolithic application runs completely on the mobile device. As the computations become increasingly complex, the latency increases significantly.

Now that we have seen some of the benefits of using Web services for mobile applications, in the next section we take a deeper look at some of the challenges with developing applications for mobile environments and best practices for addressing those challenges.