INTRODUCTION

Security is always one of the biggest concerns when designing any application, but particularly distributed applications. Distributed applications operate over networks, involve multiple users, and have many other properties that make them more vulnerable to security breaches. Though there are stand-alone mobile applications, as we have discussed earlier in this text, most mobile applications, at their core, are distributed applications. Unfortunately, to date, there remain many unsolved problems with security concerns of mobile applications.

Our goal in this chapter will be to first introduce a taxonomy of mobile application security problems, look at few general approaches in solving these problems, and finally review those problems that remain unsolved. Security also tends to be a system-wide problem, not just an application problem, whether dealing with mobile or stationary applications. So, we are not out to show you sample code, standards, or specific techniques; such discussions are completely beyond the scope of our discussion. Our main purpose is to take a step back and look at the big picture of mobile application design and see where security concerns may be. Security is intimately bound to the design of the platform for which the mobile application is being built.

INTRODUCTION

The word replicate means “to produce a copy of itself” and originates from the Latin word replicates. The word synchronize is defined by the Webster dictionary to mean “to represent or arrange (events) to indicate coincidence or coexistence.” Synchronization and replication are two essential operations in distributed computing. Although synchronization can mean a variety of things, replication is typically used in reference to data. Like the literal definitions of synchronization and replication in the English language, their definitions within the field of computing are different but related. In this chapter, we will limit our discussion of synchronization and replication to data synchronization and data replication. As you may have already noted, we used the term synchronization, in Chapter 8, when synchronizing contents and actions transmitted across multiple communication channels. We are discussing synchronization in the context of data replication in this chapter.

Data replication, in its broadest sense, simply refers to copying data from one or more data storage locations to one or more other data storage locations. Note that these locations are virtual locations and not physical locations—it is not required for the virtual locations to be at different physical locations. The taxonomy of the types of replication technologies depends on the domain problem as well as the infrastructure on which replication is being performed. However, we can break nearly all data replication into two groups: complete replication and partial replication.

INTRODUCTION

Because of the depth of the design discussions in this text, we have had little chance of discussing coherent examples of mobile applications as applied to the various techniques introduced. The goal of this chapter will be to create a large fictitious project, based on a real project, define requirements for it, and then build the application using the techniques introduced. Obviously, we will not be able to use all of the techniques that we have discussed; there are far too many in this text. Nonetheless, we will aim at discussing as many as possible in reasonable detail.

The example we will be introducing will be in the field of automation. Namely, we will be creating an application to help an electrical repair crew with a variety of tasks in the field. We will start by working on the requirements, then create an architecture that satisfies the requirements, follow it up with a detailed level design, and work our way into implementation.

REQUIREMENTS DRIVING THE ARCHITECTURE

First, let us understand the basic needs of the customer for which we are building an application. The reader should know that this example is based on the needs of a real company, the Noor Electrical and Engineering Company, located in Costa Mesa, California.

INTRODUCTION

Much of what we have discussed in this text has been focused on design problems and high-level approaches to building mobile applications. We have intentionally stayed away from a more syntactical-driven approach because languages and tools are evolving rapidly in the space of mobile applications. We have looked at a variety of design patterns and architectural solutions that address the problems associated with mobile applications. In this chapter, we are going to take a step back, look at some very high level architectures, and discuss how we should use them in building our mobile applications.

In an abstract manner, a software system is to the domain problem it solves what the solution may be to a math problem. Through the years, mathematicians have refined “canonical” solutions to a wide variety of mathematical problems. “Canonical,” as defined by the Webster dictionary, is an adjective for something “conforming to a general rule or acceptable procedure.” Much of the purpose of various fields of engineering is to define these canonical “best practices and ways” of doing things for given problems. A large part of the field of software engineering involves defining canonical solutions for developing software applications so that every problem in building a software application does not have to be solved from scratch.

INTRODUCTION

The Extensible Markup Language—XML—is a subset of the Standard Generalized Markup Language (SGML) specified in ISO standard 8879. SGML was created to create and maintain complex and portable documents to be used in highly scalable systems in a nonproprietary manner to any particular vendor. XML has become a key technology in the development of content for the World Wide Web. Today, with the birth of Web services, it is used for more than its original purpose of representing documents.

There are many excellent writings and books on the topic of XML. If you are not familiar with XML, you should probably stop here, familiarize yourself with the basics of XML, and then come back and continue. In this chapter, our intent is to outline some XML-based or XML-related technologies that are key in developing mobile applications.

To understand how and why XML is used in mobile applications, we should understand a brief history of how it came to be.

Brief History

In the beginning, there was SGML. And then, from SGML, came the less intelligent, but more likable son, XML.

If there were a bible of computer science, it would tell us the history of XML with a bit more flare. But, that essentially sums up where XML came from.

When the Web was first created, XML's sister, HTML, was born first.

INTRODUCTION

One of the first topics that we discussed in this text was the definition of mobility and how it differs from wireless connectivity. By definition wireless connectivity between a mobile device and another device requires a physical layer networking technology. To cover all of the subjects that will allow one to comprehensively understand wireless connectivity and its currently existing permutations is impossible, not just in this text, but even in a dedicated text. One may require an entire library to gather all of the various topics on wireless connectivity and related inventions. So, the first thing that we might do is to reduce the scope of what wireless connectivity may mean in our discussion of mobile computing.

In this chapter, we will first look at a basic introduction to wireless communication that will include examples of techniques and technologies from the various abstraction layers in wireless communications.

We can qualify two types of connectivity to the network: strong and weak. We use the concept of strong and weak connections in various places in this text. Essentially, a weak connection refers to lower QOS than strong connectivity but higher than disconnection. This way of distinguishing weak and strong connections is fairly subjective and relative to the application. Unfortunately, because of the changing landscape of communication and computing, we cannot quantify the QOS properties of strong and weak connectivity.

INTRODUCTION

Location, location, location. The changing location of the user and the device used by the user make mobile applications fundamentally different from their stationary counterparts. Yet, most software developers, even those who have some experience with mobile applications, have little experience and understanding in how location-based information is gathered and distributed and how this information may be utilized by mobile applications. Although we will not be able to cover all aspects of location-based information in mobile applications, we will try to tackle the basic problems in this chapter.

If you have looked into developing mobile applications, you have certainly heard of “location-based services.” The UTMS Forum defines location-based services as follows:

This definition is somewhat narrow as it limits location-based services to 3G services. There are many location-based services that do not have any relationship with 3G services. So, location-based services are those things that provide the mobile device, the mobile application, and the mobile user with location information about themselves or other devices, applications, and users.

INTRODUCTION

Much of the research done in software engineering is dedicated to solving practical problems that come up when building software applications. Techniques such as Extreme Programming and RUP are two such techniques and methodologies, addressing some of the issues associated with the process of building software applications.

The dimensions of mobility, as we have seen, add to the complexity of developing mobile applications. In this way, an entirely new set of hurdles and problems are introduced. In this chapter, we will briefly look at a few of these problems. Some of these problems will be addressable by the tools that we have introduced previously in this text; others will not.

Some of the basic hurdles are caused by the fact that most developers either have experience building call centers and other types of voice systems using the telephony channel or they build PC applications with GUIs. So, we will start by looking at hurdles associated with building a VUI for those developers who come from a server-side or GUI-based development background.

VOICE USER INTERFACE HURDLES

The first question that will come to your mind will be related to the infrastructure. This will be a hurdle in real deployments.

INTRODUCTION

As their name indicates, voice user interfaces (VUIs) are interfaces that allow users to interact with computing systems through use of voice. Although our voice can be used in different ways, VUIs typically refer to communication through the use of language. This narrows down the problem at hand as communication through VUIs is a subset of communicating through aural user interfaces. It is possible to communicate with computers through sounds other than pronounced words and sentences. Different sounds can be used to communicate information through their frequency, amplitude, duration, and other properties that make them unique. However, language is how we naturally communicate, be it through voice or text; therefore, when referring to VUIs, we refer to communicating with machines through using pronounced language.

It is also true that most us have had very frustrating experiences trying to bypass the voice recognition system and reach an operator. However, this is not an indicator of the lack of value of voice recognition systems. In fact, most systems that lead users to be frustrated are those that have not been well designed or those that require a high degree of cognition by the computing system: something that computing systems do not do well yet. As we have already seen, the user interface problem is one of the biggest problems in mobile computing.

INTRODUCTION

Mobile computing systems are computing systems that may be easily moved physically and whose computing capabilities may be used while they are being moved. Examples are laptops, personal digital assistants (PDAs), and mobile phones. By distinguishing mobile computing systems from other computing systems we can identify the distinctions in the tasks that they are designed to perform, the way that they are designed, and the way in which they are operated. There are many things that a mobile computing system can do that a stationary computing system cannot do; these added functionalities are the reason for separately characterizing mobile computing systems.

Among the distinguishing aspects of mobile computing systems are their prevalent wireless network connectivity, their small size, the mobile nature of their use, their power sources, and their functionalities that are particularly suited to the mobile user. Because of these features, mobile computing applications are inherently different than applications written for usage on stationary computing systems. And this brings me to the central motivation behind authoring this book.

The application development and software engineering disciplines are very young engineering disciplines compare to those such as structural, mechanical, and electrical engineering. Software design and implementation, for the most part, remains part art and part science.

INTRODUCTION

Thus far, in the first three sections of this text, we have focused on recognizing the new problems facing mobile application developers, tools to solve those problems, and how to use those tools to solve each specific problem.

Let us now look at the macro view of developing mobile applications. When we develop a stationary application, we gather requirements, lay out an architecture and design, select some tools to help us implement the application, develop the application, test, and deliver. Although this is a gross oversimplification of the application development process, it lays out the rough steps of developing stationary applications. There are development methodologies that go into each of these steps in a detailed manner and lay out a methodical approach to tackle them.

The question to ask now that we know how to deal with the detailed problems of mobile application development is whether these methodologies can be used as is or whether they must be modified to develop mobile applications.

BACK TO THE DIMENSIONS OF MOBILITY

If there is one thing you should know by now, it is that the dimensions of mobility are what make mobile applications different from their stationary counterparts. The dimensions of mobility and the mobile condition of the user, cumulatively, are what make the process of developing mobile applications different from the process of developing stationary applications.

INTRODUCTION

We have thus far discussed user interfaces in some detail. We have seen that, depending on the function of the mobile application, we may want to interact with the user through audio, a traditional GUI, or a combination thereof. We have also seen that, because of the wide variety of capabilities among mobile devices and the proliferation of the platforms, there are a great number of user interfaces that we may have to implement for a given application. Although we have looked at mobile GUIs and then VUIs individually, we have not looked at the discipline of building applications that may use more than one channel of communication with the network or interact with the user through more than one mode of their user interface. This is what we will be discussing in this chapter.

First, let us define what multichannel and multimodal mean for these two terms have been incorrectly used widely in the literature on mobile computing. To start, remember that multimodal and multichannel are not the same thing. Multichannel may have two different meetings. First, it can be used to imply a user interface that establishes more than one communication channel to the user. For example, a user interface may present an audio and a video channel to the user.

INTRODUCTION

At its most primitive level, software is a set of instructions for hardware written in machine language. At a higher level, there are assemblers and higher level programming languages. There are frameworks, tools, and other methods of abstracting various aspects of software design that help us achieve one central goal: to handle complexity of software more reliability and faster. The biggest problem with software design and implementation is complexity and it is this complexity that leads into buggy systems, high cost of development, and long development cycles, and the existence of programming languages, frameworks, and other development tools is primarily to solve this very problem of software complexity. In other words, as one of the most fundamental software design concepts, abstraction reduces complexity (at least theoretically).

Today, there are many programming languages, frameworks, and tools designed to develop server-based and desktop applications. These languages, frameworks, and tools have matured through the years, becoming more efficient and more reliable as they get tested in real environments by real users. Along with the maturation of these tools has come the maturation of the process of software design and implementation. Ideas such as OOP, design patterns, and de facto standard software development processes have been developed and have matured with the tools and frameworks in a symbiotic manner.

INTRODUCTION

In Chapter 16, we briefly look at five different architecture types: fully centralized, client–server and its variations of N-tier, mobile agents, and peer-to-peer. You may want to refer to this chapter intermittently or read it first. In this chapter, we will focus on the latter two, namely mobile agents and peer-to-peer systems, as relating to mobile application development.

We focus on these systems for two reasons. First, the application of mobile agents and peer-to-peer architectures in the mobile application realm is not well documented because both are fairly recent concepts. Second, both mobile agents and peer-to-peer architectures promise to play an integral role in mobile application development as it matures. We have already discussed the properties of these two architectures that make them more desirable for mobile application development. Furthermore, we have surveyed both of these technologies. Now, you may wonder why we are making an association between the peer-to-peer and mobile agent architectures. We can find the answer in looking at some of the properties of the two architectures and their contrasts with the client–server model.

Peer-to-peer and mobile applications are similar in the following ways:

1. Unlike the centralized and client–server architectures, there is no necessity for a centralized server. There is no inherent difference between the system-level participants of peer-to-peer and mobile agent architectures, respectively peers and hosts, within the confines of the respective architecture, as there is between the client and the server in the client–server environment.

2. The participants of the system can be interconnected to each other in any manner. Both peer-to-peer architectures and mobile agent architectures allow for self-organizing and ad hoc networks.