A few years ago mobile computing was sizzling hot. Everyone, it seemed, was working on some kind of killer wireless app -- even though most developers would admit they had no idea what customers actually wanted. At that time, mobile applications was though of as completely new and different from desktop software. Mobile applications, it was said, would revolutionize the way we worked, spent our free time, communicated, and much more.

It took some time to realize that mobile technology is actually just another channel. Applications are applications, and customers want to be able to use them from a variety of devices. Well-built software should be adaptable to a variety of user interfaces and connections. As applications are designed more and more with this principle in mind, they are pervasive applications; that is, applications capable of running in more than one device or configuration.

These days, computer systems are everywhere, from mainframes to microwaves, and almost every system eventually has pervasive features. So, rather than focusing on changing the world, many developers are beginning to focus on designing pervasive systems -- that is, systems that are adaptable to a changing world.

This article serves as an introduction to the design and development of pervasive application architectures. You'll learn about the overall process of creating an architecture, the essential features of a pervasive application, and the different architectural styles you can use in developing pervasive applications. The article concludes with a checklist to assist you in designing your own pervasive architectures.

Creating an architecture

A system's architecture is its backbone; as such, it defines the system's strengths and limitations. Ideally, a system's architecture should be created with future modification or development in mind. If the system is built ad hoc, with no design at all, future modifications can be very expensive and difficult.

The architecture should be created at the beginning of the project after defining the functional and non-functional (or quality) requirements of the system. Creating the architecture is typically an iterative process in which you first do a functional analysis, then a quality assessment, and finally modify the architecture iteratively until you meet all the quality requirements (see Resources). Figure 1 illustrates the iterative process of creating a software architecture.

There are many ways to build up a system architecture. One of the most popular at the moment seems to be the four-plus-one (4+1) view model. In the 4+1 view model the architect looks at the system from five different views:

1. Logical: What classes, methods, packages, and so on, will be required for the project?
   
   
2. Process: Are there any simultaneous processes, and do they communicate?
   
   
3. Development: What are the components of the system? What source code files need to be created?
   
   
4. Deployment: How will the software be deployed?
   
   
5. Use case: How will different users interact with the system?

Back to top

Features of a pervasive architecture

The first step in designing pervasive software (or software that might become pervasive) is the creation of a pervasive architecture. Following are some of the most important issues to consider when designing a pervasive architecture:

• Business logic and environments can change rapidly. For maximum flexibility, the business logic (or domain) must be kept separate from the UI logic and persistence management.
  
  
• Maintenance is 70 percent of the total system cost. Design your architecture with future maintenance in mind; proper documentation is essential to proper maintenance, as well as the success of future development efforts.
  
  
• It might not be pervasive now, but that can change. Be sure that new interfaces, devices, units, and so on, can be easily added over time. Using design patterns like Proxy, Facade, or Bridge can make your system more adaptable.
  
  
• Secure the whole system, inside and out. When establishing your system's security requirements, consider both threats from the outside (how easy would it be for a hacker to gain control of your factory or CRM system) and the inside. Some security threats aren't necessarily hostile; they could be the result of employees using the system incorrectly or without a permission. All components in the system, as well as all devices or units connected to the system, should be secured.
  
  
• Design for scalability. While your application might start out on one physical server, it should not be tied to that server. Decentralization is a key component of scalability, so design your system with that in mind.
  
  
• Focus on what's important. It's no secret that badly built or designed systems can be slow (even so slow that they're ultimately useless!), but speed comes at a cost of its own. Carefully consider the functions or use cases in which efficiency is vital to the success of your system.

Back to top

Features of pervasive applications

Basically, any application with more than one user could turn out to be a pervasive application in the future, but there are some areas where applications more often are pervasive. In this article, I'm focusing on two categories of pervasive application: applications with different user interfaces (Web, native, mobile) and applications that manage embedded systems (production management, and so on).

In pervasive application design, your system should be adaptable to a wide variety of user interface (UI) types. User interfaces are usually defined as either thin or fat. The interface for Web, WAP, and iMode applications is typically thin, whereas the interface for native Windows applications is typically fat. In a thin-client application, the client contains minimum functionality. Thin clients are usually run in a browser, and the functions are performed on the server. A fat client might contain more functionality than a thin one, but it doesn't have to. Fat clients are more complex to maintain than thin ones because their functions are performed inside the client rather than on the server.

Architecturally speaking, the biggest difference between the two user interface types is how each one is implemented. With thin clients, the functionality is implemented on the server side, which makes for a relatively clear-cut development process. With fat clients, however, all functionality might reside on the client; only data flows to the server. In this type of application, it is very important to keep all business logic away from the user-interface layer. And with fat clients, you actually have to develop a separate client application.

The most interesting part of an embedded-system application (such as a production-management system) is usually the business logic, which is connected to production units (if any). These units are typically embedded systems, which are controlled using known interfaces.

Back to top

Differences between channels

The biggest differences between UI channels are usually the capabilities of the screen, the pointing devices, and the communication protocols. The system should be built so that adding a new UI channel requires a minimal amount of work. The difference between thin and fat clients also must be accounted for.

Taking MIDP 1.0 as an example, we can easily understand the need to build adaptability into the client-side software. The market currently holds dozens of MIDP devices, and almost all of them utilize a different screen size. If objects are drawn on the screen with static coordinates the application will work properly only in devices with exactly that screen size. Therefore, it is much better to read the screen size dynamically and draw screen objects accordingly. For example, if you want to draw a circle in the middle of the screen, the correct way is to ask the width of the screen from the system and calculate the placement.

The only communication protocol usable in MIDP 1.0 is HTTP, and the client application will run in the device. In order to ensure a pervasive design, the usability and structure of the client application must be identified in advance. Limitations include user input capabilities, screen size, speed, colors, network speed, memory, and so on. On the server side, the functionality must be implemented in an HTTP interface. See Resources to learn more about building pervasive applications in MIDP 1.0.

Back to top

Architectural styles

When it comes to developing pervasive applications, you have a number of architectural styles to choose from. Each architectural style has its own approach to defining system components and connectors and transmitting data from one component to another, as well as describing (and thus creating) the "big picture" of the system.

Take a look at the following partial listing of architectural styles. I'll then describe the ones that are most commonly used for pervasive application development.

• From mud to structure
  • Layered architecture
  • Pipes and filters
  • Blackboard
• Distributed systems
  • Broker
• Interactive systems
  • Model-view-controller (MVC)
  • Presentation-abstraction-control (PAC)
• Adaptable systems
  • Microkernel
  • Reflection

Layered architecture

Probably the best-known architectural style is the layered architecture, which is very popular among Java developers. In a layered architecture the system is divided into several layers such as user interface, application logic, business logic, and persistence logic. There are several ways to name the layers, but they all go from high-level to hardware or database.

Layered-architecture development has many pros, but it also has some cons. I'll start with the good things: a layered architecture makes it easy to understand the whole system; it can be used almost always; it minimizes dependencies between different parts of the system; and it supports maintainability and component re-use. Downsides include efficiency issues (with many layers the system can be slow), difficulty in handling exceptions, maintenance difficulties, and inappropriate application (the layered approach can be too time consuming and expensive when applied to smaller applications).

Pipes and filters

Pipes and filters is a very popular architecture style in real-time computing and Unix and Linux systems. It consists (not surprisingly) of filters that use and modify data and pipes that connect filters.

Broker

Broker is a very popular architecture style in distributed systems, where it is better known as CORBA and RMI. The broker architecture consists of a client, server, client-side proxy, server-side proxy, and broker (and, in some cases, bridges between brokers).

Model-View-Controller

MVC is often described as a design pattern, but it can also be described as an architectural style. MVC consists of the model, view, and controller. The model holds the business logic, registers views, and notifies registered views of changes in the model. The view is responsible for showing the model's data and updating the changes in the model to the user. The controller is responsible for receiving the user input and passing it to the model.

MVC sounds a bit like a layered architecture, but the two architectures are different -- mainly in that MVC is focused on keeping the user interface and model loosely coupled. On the other hand, the "model" part of an MVC architecture can consist of three or four layers, and it's common practice to use the layered approach and MVC together.

Back to top

Solutions for pervasive development

Any architectural style that allows for future changes to the layers, components, UIs, and databases that comprise your system is a good style. MVC makes it easy to change and update screens, the layered architecture makes it easy to change or modify different layers or components of the system, and the broker (or CORBA and RMI) architecture relieves us of some of the agony usually associated with distributed application development.

In closing, I'll leave you with a tool for designing pervasive architectures. How does your planned architecture address the design issues raised by the following checklist?

• What is the nature of the system? Is it a production management system, a complex Web site, PIM, CRM, embedded system, or something else? A production management system is more likely to require pervasive business or domain logic, whereas a CRM must be adaptable to many types of user interfaces. Learn to predict where in the system effort should be made.
  
  
• Is the system adaptable? Wherever possible (and even some places where it seems impossible) presentation logic and the upper parts of the application logic should be adaptable to different types of user interface.
  
  
• Is the system open? If possible, design and implement open interfaces so that other applications can access your system.
  
  
• What communication protocols does the system use? HTTP is implemented almost everywhere, but it has some limitations.
  
  
• How scalable does the system need to be? If the system will remain small, maintainability and scalability are not so important; you can focus on managing expenses and performance. If the system will grow, scalability is an essential consideration for choosing your architectural style.
  
  
• How is data transmitted in the system? Will you transmit the data between layers (if any) and components in value objects, in XML files, in a string, or in some other form? XML seems a popular format, but use it inside your system only if you must.
  
  
• What are the system's quality requirements? Quality requirements usually are along the lines of security, ease of use, overall speed, and ease of maintainability, which all are very hard to measure. Wherever possible, your quality requirements should be both realistic and measurable.
  
  
• How is the persistence logic designed? If there is a database, you must account for persistence logic (or data access objects), or you might need to support multiple databases.
  
  
• How is transaction handling managed? Can you use an application server to handle transactions, or do you have to do it manually?
  
  
• Is a legacy system involved? Legacy systems introduce all kinds of complexities; for example, what if the system is changed? You could prepare for this by designing a general proxy or wrapper component between your system and the legacy system. If the legacy system is changed to another, you only have to re-implement the proxy component.
  
  
• What about exception handling? If you haven't already thought about it, now is the time. Exception handling is a very important side of good system design, especially in a layered architecture.

Resources

• You'll find a good summary of the different approaches to architectural design in Design & Use of Software Architectures: Adopting and Evolving a Product-Line Approach (Jan Bosch, Addison-Wesley, 2000).
  
  
• Learn more about the "4+1" design process by reading "Architectural Blueprints: The "4+1" View Model of Software Architecture" (Philippe Kruchten, Rational Software Corp., 1995).
  
  
• Pattern-Oriented Software Architecture (Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, John Wiley & Sons, 1997) is a good reference for learning more about the application of patterns in designing software architectures.
  
  
• In my article "Custom GUI development with MIDP 2.0" (developerWorks, May 2003) I explain different techniques for developing adaptable GUIs under the new MIDP 2.0 specification.
  
  
• It can be helpful to study different approaches to architectural development. See the "Web Services architecture overview" (IBM Web Services Architecture team, developerWorks, September 2000) for starters.
  
  
• Anne Zieger's "Microbrowser architectures" (developerWorks, August 2001) is an early look at the architectures that support the addition of wireless devices to the Internet.
  
  
• Bruce Anderson's "Adventures in architecture" (developerWorks, February 2002) is a hands-on approach to learning about the relationship between architecture and design.
  
  
• In "Pervasive computing: e-business anywhere, anytime" (developerWorks, July 2003), authors Albee Jhoney, Manu Kuchhal, and Rohit Jaiswal present an architectural blueprint for building wireless e-business solutions capable of seamlessly integrating into an existing e-business infrastructure.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Creating an architecture
• Features of a pervasive architecture
• Features of pervasive applications
• Differences between channels
• Architectural styles
• Solutions for pervasive development
• Resources
• About the author
• Comments