Business management likes the notion of mobility because it conjures the idea of pushing productivity-enhancing information into workers' hands as they need it, where they need it. For application architects, the challenge lies in doing the pushing at a quality of experience (QoE) level that adds to productivity, rather than inadvertently reducing it through delays. A mobile application isn't the same as a desktop application, and while the difference starts in the device, it's the server side of the mobile equation that will make the difference between productivity gains and losses. An optimum server-side mobility solution will consider state control in transactions, presentation of information and management of mobile data flows.
Where a mobile application involves multistep data entries to obtain a result, it's necessary for something in the flow to keep track of what step (state) the process is in so that the messages can be interpreted. Service-oriented architecture (SOA) and online transaction processing (OLTP) practices often define state control to be in the server applications or middleware, but Web practices typically place the responsibility for state control with the client device (the REST acronym used for Web interfaces stands for representational state transfer). Mobility applications that adopt the Web practice will be able to accommodate simple browser interfaces on mobile devices more easily, and it's often easier to recover from connection failures (more common in mobility applications) with client-side state control.
Benefits of using a Web front end
Having a Web front end to an application server for mobile applications also facilitates the support of multiple devices (by providing multiple Web URLs, one for each type of device), and it's also possible to allow mobile devices with sophisticated applications to bypass the Web front end and interact with the application server directly. If this is a goal, then it's important to check the interfaces available on the mobile devices first to insure that the selected application interface can be supported on a broad community of devices.
Solving data volume problems
The question of data exchange between the server and the device extends beyond the format to the data volume, and here is where the most careful server-side design work may be needed. Mobile applications rely on a relatively low-speed link to the devices, and available mobile bandwidth may vary considerably, depending on the user's location and the local cellular traffic load. In many cases there may be usage charges applied, which could make mobile applications very expensive to run if data volumes are high.
Most data volume problems with mobile applications are created by forcing the mobile user or the mobile device to screen or correlate information. Best practice dictates that where a large amount of data must be screened to select relevant information, do the screening on a server application and send only the results to the mobile device.
Some application architects find it convenient to visualize a mobile application's server-side components as consisting of a user agent element that fields requests from the mobile device, and a series of data query and processing elements that act on decomposed requests from the user agent and return results to that agent for correlation and presentation back to the user.
Utilizing a virtual desktop
Some mobile application architects see considerable value in a virtual desktop approach to the problem. With virtual desktop infrastructure (VDI) there is a user agent that represents the user's compute capabilities, but is hosted (usually on virtual/cloud infrastructure, but in theory on any server pool), and this agent then has a connection to a thin client in the hands of the user.
The model is obviously directly applicable to browser-based mobility applications, and it could be applied to more sophisticated models where functionality is shared between the mobile device and hosted resources. The VDI agent element can also bridge between the user-access piece of the mobile application and the server/processing piece.
Building that bridge may be the common element in the three areas of mobile application development concern cited above. The agent element can provide translation between a stateless or RESTful mobile device interface that conforms to Web standards, and a more architected SOA implementation of the application on the server side.
SOA/SOAP principles can provide for intercomponent linkage, for example, to secure components and company data. The agent element can also manage orderly transaction backout should there be a connection failure. However, the agent also represents a potential single point of failure, and design of mobile applications based on the use of an agent process should manage agent availability carefully and provide appropriate failure procedures.
Value of testing
A general issue of application design, budgeting response time in multilayer applications, is of particular importance in mobility applications. Since workers are typically interacting with applications at their point of activity, delays in processing requests have disproportionate impact and may even impact customer perception -- an order entry application a salesperson in the buyer's office accesses, for example.
It's important to pilot test mobility applications in a realistic simulation of a production environment in order to validate performance and QoE. This same setup can be used to test the response of the application to loss of the mobile connection at various points in the application's cycle of use. Careful testing will validate an architect's response to each of the three critical points of mobile application development and ensure the application responds properly to business needs.
About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.