Mobile Architecture: One Size Fits So Few - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

10:18 AM

Mobile Architecture: One Size Fits So Few

Fat client, thin client, fat client--the debate over mobile-app architectures looks more like the revolving door of a weight-control salon. Real progress will only happen when designers realize that every client is beautiful in its own way, Giga's Carl Zetie says.

Every year seems to highlight another school of fashion in mobile-application architectures as the focus swings from fat client to thin client and back again. Each shift is accompanied by a sheaf of arguments purporting to prove why a particular architecture delivers the best network performance, a characteristic that will be key in the user experience. Sometimes the culprits are vendors trying to promote the technology they happen to support that year, but just as often it's designers hoping for a quick fix to an inherently challenging problem. The reality is that no one architecture is "right." As in life, one size does not fit all.

One reason mobile applications are so interesting--and so challenging--is that unlike previous delivery channels, many architectures play various roles in wireless. The client-server model was originally pitched as offering a future of networked, distributed services providing discrete, componentized business functions integrated via clean, standardized interfaces (a picture remarkably similar to the pitch for today's Web services). The reality turned out to be, with a few honorable exceptions, fat clients exchanging SQL with remote databases.

Then along came the Internet and with it an entire generation of thin-client HTML interfaces, which have slowly grown richer over time. The latest wave is Web services, which will probably feature prominently in both server-to-server and client-to-server exchanges. Intriguingly, the short history of mobile devices in enterprise IT has rapidly recapitulated this history, having passed through its own fat client and thin client waves, and the current wave of misinformation about the relative network characteristics of fat and thin clients is largely driven by advocates for Web services on mobile devices.

Some have argued that rich clients using Web services are better than thin clients because they don't waste bandwidth transmitting both data and apps as HTML does, while thin-client proponents argue that their model is better because it only has to transmit screen updates, not all of the application data. Both arguments sound superficially plausible, suggesting that deeper examination is required.

In reality it's an oversimplification to believe that any single architecture is inherently better than another in this regard. A designer has to consider three dimensions--the overall architecture, the design of the specific app, and user behavior--to determine how efficiently a given application communicates and what the trade-offs are.

Consider a simple example: an application that provides the user with a list of flight times, for example, that allows searching or sorting. Suppose the user performs a search that identifies 100 flights, sorted by price. A simple thin-client application would transmit just enough data to fill the screen of a Wireless Application Protocol phone with the first four hits. Now the user decides to view by departure time: The application discards the displayed rows, asks the server to re-sort, and another four hits are delivered.

A more sophisticated application might transparently fetch the next four hits in a "cache behind" design, ready to display if the user scrolls down the list, thus reducing the apparent latency at the cost of sometimes fetching rows that aren't needed. In general, the thin-client application designer can trade latency for network efficiency by increasing the size of the cache. Make the cache too large and you waste network traffic fetching unneeded data. Make the cache too small and you make the user wait between pages.

By contrast, a simple rich-client application would fetch all 100 flights, a much larger data transfer than the thin client. If the user views just a few rows, then discards them in favor of a different search, that bandwidth was wasted. However, if the user repeatedly scrolls, re-sorts, or filters the data, the rich client doesn't need to keep fetching rows, and the total network usage may eventually be less than with the thin client.

As with the thin client, the application designer can take steps to reduce the network traffic by fetching rows on demand (sometimes called a lazy fetch), to the point that ultimately the rich client actually matches the thin client, fetching only what is to be displayed, but in so doing, the client sacrifices the ability to sort locally. Whether the thin client, thin client with cache, rich client, or rich client with lazy fetch ultimately produce less network traffic will depend on the users of the application. Despite what the hype might suggest, inserting Web services into the middle of the exchange doesn't change this fundamental point.

Ultimately, the choice between thin client and rich client shouldn't be determined by arguments about network round trips. More important criteria include availability (rich clients may offer offline functionality) and ease of deployment (no download or install to manage for markup applications), as well as basic capability (rich clients are, after all, richer). Resolving those trade-offs, as well as predicting the network behavior of the application, doesn't come from academic discussions but only by getting close to actual users and understanding their requirements and their behaviors--or in one word, usability.

Carl Zetieis the VP of Giga Information Group

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
The State of IT & Cybersecurity Operations 2020
The State of IT & Cybersecurity Operations 2020
Download this report from InformationWeek, in partnership with Dark Reading, to learn more about how today's IT operations teams work with cybersecurity operations, what technologies they are using, and how they communicate and share responsibility--or create risk by failing to do so. Get it now!
10 Cyberattacks on the Rise During the Pandemic
Cynthia Harvey, Freelance Journalist, InformationWeek,  6/24/2020
IT Trade Shows Go Virtual: Your 2020 List of Events
Jessica Davis, Senior Editor, Enterprise Apps,  5/29/2020
Study: Cloud Migration Gaining Momentum
John Edwards, Technology Journalist & Author,  6/22/2020
Register for InformationWeek Newsletters
Current Issue
Key to Cloud Success: The Right Management
This IT Trend highlights some of the steps IT teams can take to keep their cloud environments running in a safe, efficient manner.
White Papers
Twitter Feed
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.
Sponsored Video
Flash Poll