Key Presentation Tier Components

To better prepare Canaxia for the future, Kello James was considering adopting the multi-tiered architecture shown in Figure 9-1. This figure illustrates a three-tier architecture that has also become a model for many enterprise applications. One of the major benefits of this architecture is its potential for a high level of maintainability and code reuse. This architecture is composed of the user system interface (the presentation tier), the process management (the business logic tier), and the database management (the data tier). In this architecture, the presentation tier has been separated into a primary tier and a secondary tier, corresponding to the activities related to the client and the server processes. The processes on the business and data tiers have not been elaborated.

Figure 9-1. Multi-tiered software architecture.

An examination of most business solutions based on a layered component model reveals several common component types (in this case components refers to a piece or part of the overall structure). Figure 9-1 shows these component types in one comprehensive illustration. Although the list of component types shown in Figure 9-1 is not exhaustive, it represents the common types of software components found in most distributed solutions. These component types are described in depth in the following sections and throughout the remainder of this chapter.

Primary Presentation Tier Components

Most solutions today require users to interact with the system via a user interface. The primary presentation tier, called the client, consists of software that renders the user interface for the users to interact with the system. For smaller and less complex systems, users may be provided with only one client type. In recent years, many different types of client software, devices, and technologies have become increasingly popular. Users now expect systems to offer user interface in the client of their choice.

Discussion of all the client options is beyond the scope of this book. Some very important and popular client options have not been included in this chapter in the interest of maintaining the larger focus, including but not limited to character-based interface, terminal emulation, and voice response systems.

Among the many client options that are available today, the choices can broadly be grouped together in the following popular graphical user interface (GUI) categories.

Internet Browser

This client software is based upon the World Wide Web Consortium (W3C) specifications and is used for rendering Web-based applications. The Internet browser is based upon a request response paradigm that requires accessing the Web server and downloading the client code to render the user interface. In most cases, the UI is updated only after a user makes an explicit request of the system. For the UI to be quickly available to the users, the code that is downloaded needs to be small in size, and therefore, it allows for little client-side processing. The browser is also called the thin-client. Internet Explorer from Microsoft and Netscape from AOL-Time Warner are the main Internet browsers available today.

Fat-client

When the software is preinstalled on the physical computer of users for access to the system, it is called a fat-client. Since the code actually resides on the users' computer, the size of the code can be potentially larger than that used for creating the UI via a thin-client. This makes it possible for the UI to be richer in both the user experience and processing. The fat-client also makes it possible for the users to do a large amount of (and sometimes all of) the work offline without requiring to send or receive information from a remote server. A key difference in paradigm between the Internet browser and a fat-client is that the fat-client can maintain a persistent connection with the back-end systems. This makes it possible for the server to send and update information on the client without an explicit request from the user. JAVA, an open-source technology from Sun Microsystems, and several proprietary technologies from various companies, including the popular Visual Basic and VC++ from Microsoft, are used for creating the fat-client.

Mobile Devices

Mobile access technology has gained a lot of attention recently. Interest in mobile access is strong among a wide range of people and organizations involved in mobile access technology, such as hardware manufacturers, software providers, communication service providers, content providers, and end-user organizations. W3C is working toward making information on the World Wide Web accessible to mobile devices. The key challenge is in the device that is characterized by small screens, limited keyboard, low bandwidth connection, small memory, and so on. These devices are highly portable and connect to the server using a wireless network. On one end of the spectrum are devices that are primarily phones, and on the other are smart devices that are primarily miniaturized computers. As the devices continue to grow in their telephony and computational power, their adoption is increasing manyfold. Several critical applications are offered now to users on their mobile devices. These applications include content serving, such as news; actual transaction processing, such as banking; and several others.

Secondary Presentation Tier Components

The secondary presentation tier consists of components that run on the server and prepare the presentation of the UI that is sent to the client for display to the users. Here is where most application developers tend to dilute the true modularity of the multi-tiered architecture. In a truly tiered architecture, the presentation tier has the following design requirements:

• Should use a well-defined interface to access the application's other tiers. Using APIs that the other tiers publish achieves this.

• Without requiring a change in the APIs, the presentation tier should not only be able to add newer ways of presenting an interface but also to allow the users to manipulate the data based upon their needs.

• Newer access mechanism can be introduced without requiring a change in the APIs.

• The system should be able to be deployed in any distributed configuration.

A popular architectural pattern used for generating the user interface and keeping it separate from the back-end API and data are the Model View Controller (MVC) pattern. The MVC pattern is surprisingly simple, yet incredibly useful. Essentially, the pattern (Figure 9-2) forces one to think of the application in terms of the following three modules:

• Model: This is the information that the presentation tier receives from the APIs from the business logic tier (and other tiers). The model knows about all the data that need to be displayed. It also knows about all the operations that can be applied to transform the model. However, it knows nothing whatsoever about the user interface, the manner in which the data are to be displayed, or the UI actions that are used to manipulate the data.

• Controller: The user interface presented to the user to manipulate the application (model).

• View: The user interface that displays information about the model to the user.

Figure 9-2. Model View Controller pattern.

While the model is the core responsibility of the other tiers (usually the business logic tier), the view (referred to as the user interface component in Figure 9-1) and the controller (referred to as the user process component in Figure 9-1) comprise the core responsibility of the presentation tier.

User Interface Components

Most solutions need to provide a way for users to interact with the application. In Canaxia's retail application, a Web site lets customers view automobile accessories and submit orders, and an application lets sales representatives enter order data for customers who have telephoned the company. User interfaces are implemented using various building blocks. Some building blocks include forms, Web pages, controls, or any other technology to render and format data for presentation on the UI. The controls may be related to the formatting UI or with presenting and manipulating data on the UI. The user interface components can be characterized as follows:

• Generic native controls: These are screen elements that the operating or the execution environment of the client makes available to the UI. Some controls are available across most client environments, although they may differ in their internal name, some attributes, and display characteristics. Label, text box, list box, radio button, check box, push button, and table are a few examples of such controls.

• Proprietary native controls: These controls are available for use from the operating or the execution environment but may not be available on all platforms. Spinners, sliders, and SWING extensions in VisualCafe are a couple of examples of such controls.

• Widgets or custom controls: These are either a complex collection of existing native controls or new controls. These often address specific presentation needs and may have prepackaged functionality. Grid, tree, and data table are examples of such controls.

• Native screens: These are screens that most operating or execution environments make available for the application to use. File Open and File Save are examples of such components.

• Custom screens: These are screens or a collection of screens created with prepackaged functionality. Wizards, shopping carts, and catalogues are some examples of such components.

The choice of the appropriate control or component and its presentation in a layout on the UI are critical to the overall usability and success of the solution. The software industry has struggled for several decades to address this issue and create a model and patterns that can define and describe this. Since the appropriate choice of the control depends upon the context, it becomes difficult to capture this information in one single manner. User Interface Markup Language (UIML) is one among a few initiatives that attempt to capture the display or the UI generation attributes in a UML-like meta language.

For more information on User Interface Markup Language (UIML), see www.uiml.org.

User Interface Process Components

The user process component typically captures the controller-related information in the MVC paradigm. The responsibility of the controller includes, but is not limited to, housekeeping and session tracking: logging the request, managing session and local variables, tracking the user, keeping session data, and managing the connection. The controller knows what can be done to the model and what user gestures are required to get those things done. Controllers may be generalized to work at three levels:

• Controllers that work on widgets or portions of the screen. For example, one such controller would understand the dragging of the slider to increase or decrease the volume in a media player application. The position of the slider translates to the commands to the model to reflect the new volume level. Another controller might accept keyboard commands. Another might allow the user to change the volume by speaking to a speech-enabled application. Many controllers can manipulate the same model, as there are many views that display the model.

• Controllers that work on screens or a group of screens. For example, in Canaxia's retail application, customers could view the automobile accessories by first selecting an appropriate category from a list of available product categories and then selecting an individual product in the chosen category to view its details.

• Controllers that work on a predefined process. In many cases, a user interaction with the system follows a predictable process. In the Canaxia retail application example, when the user makes a purchase, the interaction follows a predictable process of gathering data from the user, in which the user first supplies details of the products to be purchased, then provides payment details, and then enters delivery details.

In some of the previous examples, the controller is dynamically generated from the information contained in the model. To help synchronize and orchestrate these user interactions and the work flow, it can be useful to drive the process using separate user process components. By doing this, the process flow and state management logic are not hard-coded in the user interface elements themselves, and the same basic user interaction can be reused in multiple user interfaces.

Application Adaptor Components

When the presentation tier needs to communicate with the business and data component, functionality must be provided in some code to manage the semantics of communicating with that particular component. These components require interfaces that support the communication (message-based communication, formats, protocols, security, exceptions, and so on) required by the different consumers.

Resource Components

Security, operational management, communication, caching, and device manager are a few examples of resources that the presentation tier may create and share with other components. The application also will use components to perform exception management, to authorize users to perform certain tasks, to communicate with other components/applications, for data persistence, and to map UI components to a particular client/device platform.

Business Tier Components

After the required data are collected and the model updated, the data can be used to perform a business process. For example, Canaxia's retail system would calculate the total value of the order, validate the credit card details, process the credit card payment, and arrange delivery of the goods. In this application, you would need to implement the functionality that calculates the total price of the goods ordered and adds the appropriate delivery charge. Business components implement the business logic of the application.

Regardless of whether a business process consists of a single step or an orchestrated work flow, the application will probably require components that implement business rules and perform business tasks. Additionally, the business logic function may take an indeterminate amount of time to complete, so the required tasks and the data required to perform them will have to be managed.

Data Tier Components

In a multi-tier architecture, the presentation tier is not expected to interact directly with the data tiers; rather, it needs the data that mirror the real needs of the users. For example, in the Canaxia retail application, the presentation tier needs product data from a database to display product details to the user, and it needs to insert order details into the database when a user places an order. The data are used to represent real-world business entities, such as products or orders.

The logic necessary to access data is abstracted into a separate layer of data access logic components. Doing so centralizes data access functionality and makes it easier to configure and maintain. Most applications require data to be passed between components.