Compaq ACMS for OpenVMS
Concepts and Design Guidelines

Previous Contents Index

3.3 Defining Additional Requirements for Business Functions

After you have identified each business function that your application performs, define additional requirements that affect the:

3.3.1 Defining Run-Time Requirements

You described the business functions in terms of the business activities required to carry them out. Business functions are also affected by additional requirements. Identify and include in your Requirements Specification the following:

3.3.2 Defining Implementation Requirements

A Requirements Specification takes into account factors that affect the implementation of the application:

3.4 Analyzing Data Entities

After you analyze each business function and identify additional requirements for each business function, you can identify the following information for database design:

Entities, attributes, and relationships are established through the database design, based on the Requirements Specification. However, good application design depends upon an understanding of the entities, attributes, and relationships to create proper access to the data.

3.5 Completing the Requirements Analysis

The result of your requirements analysis is a Requirements Specification for use in both the database design and the application design. Appendix A contains a sample template for a Requirements Specification.

Once the requirements analysis is complete and the initial database design exists, the application design moves to the functional analysis described in Chapter 4.

Chapter 4
Creating a Functional Specification

This chapter provides guidelines for determining the transaction processing functionality needed to meet the business requirements detailed in your Requirements Specification. It illustrates how to determine one or more transactions, or atomic units of work, within each business function. It also illustrates how to decide if your application should use distributed forms processing. (An application with distributed forms processing is sometimes referred to as a distributed application.) Use these guidelines to create a Functional Specification in which you:

Appendix B contains a Functional Specification template.

4.1 Identifying TP Functionality

Chapter 3 described how to define the business functions and the business activities comprising those functions, resulting in a Requirements Specification. The process of defining these business functions and activities is essentially linear: for example, describing a series of steps the user takes to carry out the processing of a reservation.

The next step is to relate the business functions to TP functionality in a Functional Specification by identifying one or more transactions within each business function. The focus of this step is modular or matrix-oriented, rather than linear: for example, several business functions may require the same transaction in the course of carrying out the work. Or, a single business function may require repeated use of a single transaction.

Database design is an integral part of this iterative design process. The database design analysis of transactions depends on the application design of transactions. And conversely, the application design of data access depends upon the transaction analysis carried out in database design. This section describes the process of transaction analysis from the point of view of application design.

4.2 Mapping Business Functions to Transactions

As you identify the transactions that relate ACMS tasks to databases, you must differentiate between two types of transactions:

Database transactions and distributed transactions are both atomic units of work, and must succeed or fail as a whole. They may appear to the user as identical operations, but they require very different design and implementation strategies.

For example, suppose that you and a friend use branches of the same bank in different cities. Your friend writes you a check that you deposit in your branch. If the bank uses one central database for all accounts, your account is credited and your friend's account is debited in a single database transaction. If, however, each branch maintains a separate database for local accounts, a distributed transaction credits your account using one database transaction and debits your friend's account using another database transaction. In both scenarios, the credit and debit constitute an atomic unit of work---a single transaction from the point of view of ACMS.

This manual uses the term transaction to cover both database and distributed transactions, unless the distinction is necessary for the description of a particular design issue.

4.2.1 Determining the Need for Distributed or Nondistributed Transactions

When you describe the organization of your business and the flow of information for each business function, you provide the basis for determining whether you need:

You determine the number and type of resource managers and their expected interaction from the information supplied about the business functions in the Requirements Specification. With that information, you can design the needed transactions.

At this point, the initial database design should have been completed. You now know whether the information accessed by each business function is stored in one or multiple databases or files. As you map the flow of data for each business function from submitter to resource manager, you determine when to use distributed and nondistributed transactions.

Integral to this process is the determination of whether or not you need distributed transactions. Generally, nondistributed transactions are preferable because distributed transactions are more difficult to design and to control, and because they use more resources. However, in some cases distributed transactions are unavoidable. In other cases, they have advantages which outweigh a similar nondistributed transaction.

The following figures illustrate a range of business organizations, from single-site, single-database businesses to multiple-site, multiple-database organizations. The implications of each type of organization are outlined, particularly from the point of view of distributed and nondistributed transactions.

Figure 4-1 illustrates a single-site business with a single database.

Figure 4-1 A Single-Site Business with a Single Database

This business probably does not use distributed transactions. For example, a retail shop with a single database for inventory uses nondistributed transactions. However, the existence of a single database does not preclude the possibility of a distributed transaction. For example, the use of a queued task with access to a single database requires that the transaction be distributed.

Figure 4-2 illustrates a single-site business with multiple databases.

Figure 4-2 A Single-Site Business with Multiple Databases

A single factory, for example, uses a vertically partitioned database for functional partitioning of the data: parts, customers, and employees. This business may or may not require distributed transactions. Most update transactions probably affect only a single database. However, if some update transactions involve more than one database, those transactions are distributed transactions.

Figure 4-3 shows a business with multiple sites and multiple databases.

Figure 4-3 A Multiple-Site Business with Multiple Central Databases

In this example, the databases are centrally located. Branch sites can access databases in two ways:

Your TP system can include elements both of remote access and of task calling to the central application.

The AVERTZ company uses this model. Section 6.6.2 describes design issues for remote data access.

A similar business organization can use distributed forms processing for an entirely different TP system. Distributed forms processing places front-end forms at the car rental sites and back-end processing at the central databases. Branch sites do not have applications that communicate by direct remote access to databases or by indirect access through task calling to a central application. (See Section 4.3 for guidelines on distributed forms processing.)

A configuration with central databases is easier to maintain and control than one with local databases, but if the central system fails, no application work can be done. However, you can maintain high availability with a VMScluster at the central site. Allow for higher application availability by creating a configuration in which if one central system fails, you can failover to an alternate system.

Note that a similar configuration might include a single central database, rather than multiple databases. While multiple databases indicate the likelihood of the need for distributed transactions, keep in mind that a single database can require distributed transactions if task queuing is used.

Figure 4-4 describes a system with multiple databases at multiple sites.

Figure 4-4 A Multiple-Site Business with Multiple-Site Databases

This model contains the same elements as the multiple-site, central databases model, but adds local databases at branch sites. An example is a bank that maintains local databases for the accounts of regular branch patrons, but also maintains one or more central databases.

Such a system improves performance and allows local application availability to continue if the link goes down, but is more difficult to manage and control than a system with a database or databases in a central location. This configuration is likely to have a relatively high need for distributed transactions. This configuration might also make extensive use of distributed transactions for initiating queued tasks, particularly for ensuring the integrity of distributed transactions if links fail.

These examples do not exhaust the possible combinations of business sites and resource managers. To design the most successful application, take into account the organization of your business and the type and configuration of your resource managers. Consider not only the current organization, but also likely growth scenarios. You can then maximize your design to take best advantage of that configuration.

The AVERTZ reservation processing application that is referred to in this manual stores all of its information in two Rdb databases. The reservation processing information originates at the users' terminals and terminates in a single database, the VEHICLE_RENTALS database. However, a second database, VEHICLE_HISTORY, stores information for auditing purposes. At several places in the reservation, check out, and check in of a car, the following operations must be performed on the two databases:

Using a distributed transaction to update these two databases ensures that if the first database transaction succeeds and the second database transaction fails, the first is rolled back.

In such a scenario, the use of multiple databases mandates a distributed transaction. Figure 4-5 depicts the data flow for this distributed transaction.

Figure 4-5 Determining Data Flow for Business Functions

4.2.2 Determining the Processing Immediacy for Each Business Function

You may identify transactions that do not need to be processed immediately, or that are better left for later processing. In this case, even if your application requires only a single database you may need to design one or more distributed transactions. You do this by designating a distributed transaction that includes both the database and the task queue as resource managers (if you need to coordinate the enqueue or the dequeue of the queued task with modifications to the database).

Queuing allows your application to:

See Chapter 6 for details about designing distributed transactions that include queuing.

Chapter 6 also describes the use of queuing for distributed forms processing in applications which use a front-end node for data entry and then queue tasks for processing by a back-end node. When both nodes are available, the back-end node processes queued tasks at regular intervals. If the back-end node goes down, the front-end node continues to queue tasks, providing users with uninterrupted access to the application for entering data on the front-end node. The tasks remain queued until the back-end node becomes available for processing.

Using the DECdtm transaction services and an ACMS queue file marked for recovery unit journaling, ACMS guarantees that changes made to a database by a queued task are committed only once.

4.2.3 Defining Transactions to Avoid Lock Contention

In TP systems, locking is a necessary control technique for regulating concurrent access to shared data in a database. Because multiple users concurrently access a shared database in a TP system, locking issues are of great importance when designing TP applications. The goal is to design the smallest possible transactions---the smallest atomic units of work---to allow quick release of servers and maximum access to records.

You must often segment a business function into multiple transactions to minimize lock contention. While User A updates Record A, the record is locked. User B must wait for User A's transaction to finish before updating Record A.

Figure 4-6 illustrates locking from the point of view of two users needing access to the same record in a database.

Figure 4-6 Record Locking

ACMS allows you to retain context if you need to retain record locks between processing steps. Because both Rdb and DBMS support only a single active recovery unit in any one server process at a time, server context is always retained within the bounds of a distributed transaction. Server context includes:

Retaining server context can adversely affect performance both by withdrawing the server from use by other task steps, and by handling a transaction that holds locks on databases across steps, thereby blocking other users from the records that are locked.

4.2.4 Identifying Transactions Within Each Business Function

Keeping in mind the issues of lock contention and of distributed and nondistributed transactions, this section offers guidelines for identifying the transactions related to each business function.

Consider the following in deciding when to have a specific operation or set of operations execute within the bounds of a transaction:

4.2.5 Identifying Transactions in the AVERTZ Application

Table 3-3 listed business functions and the specific business activities within each business function of the AVERTZ Company's reservation processing. This section identifies the transaction processing transactions associated with each AVERTZ business function. (Chapter 5 describes the parallel process of identifying the ACMS tasks associated with each AVERTZ reservation processing business function.) Table 4-1 lists the business functions and their related transactions. Note that a transaction may be used in one or more business functions.

Table 4-1 Business Functions and Sequence of Transactions in the AVERTZ Reservation Processing Area
Business Function Step Transactions Read Update Dist? Database
Reserve a car 1 Find a site Read No VEHICLE_RENTALS
  2 Read existing information about the customer Read No VEHICLE_RENTALS
  3 Update the customer information Update Yes VEHICLE_RENTALS, VEHICLE_HISTORY
  4 Write the reservation Update Yes VEHICLE_RENTALS, VEHICLE_HISTORY
Check out a car (at reservation time) 1 Find a car Update No VEHICLE_RENTALS
  2 Update the customer information Update Yes VEHICLE_RENTALS, VEHICLE_HISTORY
  3 Complete the checkout or cancellation Update Yes VEHICLE_RENTALS, VEHICLE_HISTORY
  4 Write the checkout or cancellation history Update Yes VEHICLE_RENTALS, VEHICLE_HISTORY
Check out a car (not at reservation time) 1 Read existing information about the customer Read No VEHICLE_RENTALS
  2 Update the customer information Update No VEHICLE_RENTALS
  3 Find a car Update No VEHICLE_RENTALS
  4 Complete the checkout or cancel Update Yes VEHICLE_RENTALS, VEHICLE_HISTORY
  5 Write the checkout or cancellation history Update Yes VEHICLE_RENTALS, VEHICLE_HISTORY
Check in a car 1 Read existing information about the customer Read No VEHICLE_RENTALS
  2 Update the customer information Update No VEHICLE_RENTALS
  3 Find the rental history Read No VEHICLE_RENTALS
  4 Complete the checkin Update Yes VEHICLE_RENTALS, VEHICLE_HISTORY

Previous Next Contents Index