Many factors contribute to the success (or failure) of a mobile solution. These include the mobile device, wireless network connectivity, enterprise integration, and most important, the application architecture. Many people do not realize that several application models are available for mobile development, each with a different set of characteristics that make it appropriate for some applications and inappropriate for others.
In this chapter we introduce three mobile application architectures: wireless Internet, smart client, and messaging. A summary of each application model is provided, along with the advantages and disadvantages it offers. But before we investigate the architectures, we will look at some of the key criteria used for determining which architecture is best suited for a given application.
Many factors come into play when selecting a mobile application architecture. Evaluating the target audience, device type, network connectivity, enterprise integration, and security requirements, along with the specific criteria in the following list will enable you to select the architecture that is most suitable for your particular situation. Finding the answers to these questions, along with any others that may arise is an important step to determining which application architecture is most appropriate for your particular application.
Who are the end users of this application?
Do they have technical skills?
What are the expected usage scenarios?
Understanding the end users is important in meeting their needs and is a fundamental requirement for any mobile application. The success of many mobile applications is often determined by the adoption and usage by end users.
For corporate solutions, are there devices already deployed that must be used, or are new devices being provisioned for this application?
What type of device is most appropriate? Some factors that will affect this include the data input mechanism, wireless connectivity options, and form factor.
Is the device a complete package? Some devices come with wireless capabilities, while others need to be coupled with wireless components.
What are the capabilities of the components? For instance, some wireless PCM-CIA cards cannot be connected to the Internet and receive SMS messages simultaneously.
For some corporate solutions and many consumer solutions, you may not be allowed to dictate the target device. In that case, the questions must be approached from a different angle.
What functionality is available within a specified group of devices?
Do any devices preclude certain functionality?
How will the mobile device connect to the enterprise?
Does it require wireless access, or is wired access (for example, USB, dial-up, serial) acceptable?
If wireless, what type of networking will it use: WPAN, WLAN, WWAN, or satellite?
Does the type of networking affect the amount of data transferred from the mobile application to the enterprise server?
How much data has to be available to the mobile user?
Where does this data reside: on the client device or enterprise server?
Is it feasible to download the data in real-time over a wireless network, or is client-side data storage required?
What is the longevity of the data and how often must it be refreshed? For example, stock quotes are only valuable when they are current, while an inventory list may not require daily updates.
Is it assumed that each end user will have only one device?
Can users share a device without mixing their data?
If a local data store is chosen, how will you reconcile local data with enterprise data?
Do you have a conflict-resolution scheme for updates to your corporate database?
Does your client-side method of integration match your server-side API? For example, an application that has a local data store may choose to synchronize its changes up to the corporate database. Usually this process requires direct access to the corporate database or access to a data buffer which sends the data to the corporate data store later.
What if the only access to the corporate data store is through an API? In that case, you will need to use business logic to call the API using the data buffer.
One of the fundamental reasons to deploy mobile solutions is to extend the reach of enterprise data to mobile workers. To accomplish this, an application architecture must integrate with enterprise data. This can range in time and complexity, from trivial to impossible, and could be considered the most important area for concern.
For these reasons, many companies that are extending existing Internet sites will choose a wireless Internet model even though other application models may be more appropriate based on the other selection criteria.
Do users need to be notified of new information during the day?
If the only message needed is a "ping" to the user, can existing mobile phones or paging device be used? For example, if a field technician must be informed that he or she must synchronize because another customer has been added to the schedule, can the message be sent via phone, pager, or to a smart client device? Does the message have to be sent at all, because the field technician will synchronize at the end of every job anyway?
Does the notification have to communicate some specific information directly to the mobile application, allowing for a lookup value, hyperlink, or automatic login to speed up the process? Receiving a message that reads: "New customer added. Click here to view details," is certainly easier for the end user.
What happens if the device is off or in another mode, which does not permit notifications to be received?
The ability for mobile users to be notified or updated during the day is a growing requirement for many mobile applications. This ability to push information can make mobile applications much more effective, and more manageable from the users' perspective.
Is the mobile data sensitive in nature? Sensitive data must be protected from within the corporate network, during transmission, and on the device.
How can data be kept secure over public networks? Is Secure Sockets Layer (SSL) available for Internet content?
Is your data store on the device protected from casual prying and/or from serious hacking?
In addition to hosting your planned application, the device can provide access to other corporate resources. For this reason, access to the device and corporate network needs to be monitored.
How strong is your authentication method?
Where does user authentication take place: on the device, on the server, or in both locations?
Are viruses a concern? If so, where does virus scanning take place?
How about the device itself? What happens if a device is lost or stolen?
Is power consumption a concern?
Does wireless connectivity consume too much power?
Can devices be recharged during the day?
Is it possible to provide backup batteries for the device?
Will users abandon devices that they don't find convenient?
If surfing the Web for one hour will drain the battery of the device, is it worth it?
The battery life of the mobile device is a major concern. Mobile phones can often last several days on a single charge, while PDAs often only last a single day. Furthermore, applications that have frequent wireless communication require substantially more battery power than offline applications.
In addition to the line-of-business application being developed, are there other services that mobile users will require? This may include access to corporate email, wireless Internet support, or instant messaging.