Share via

Designing Transactional Web Applications

  • Article

One of the most important design concepts for transactional Web applications is the distinction between business processes and physical transactions. Business processes are the day-to-day processes of most organizations; an example is processing a sales order. A physical transaction corresponds to the actual updating of the data resources that are used to record the business process. A business process will usually be made up of more than one physical transaction.

For example, when a sales order is processed, there are at least three distinct steps that need to be accomplished:

  • Verify product availability.

  • Obtain payment.

  • Commit the order.

Each of these steps could represent one or more physical transactions, depending on the system design.

The connectionless nature of the Internet mandates that steps be broken into distinct physical transactions. When a physical transaction is begun, all other users will be prevented from updating the resources that participate in the transaction until the transaction completes. Imagine what would happen if the entire sales order process described above was grouped into a single physical transaction. A user could begin a transaction by indicating his or her interest in a product, which would lock the customer's account and mark the product as no longer available in the inventory database. The customer could then leave his or her browser running while attending to other business, but before committing to the sale. Because the entire order has been treated as one physical transaction, all of the resources are locked either until the customer commits, or until your system throws out the order due to a business rule. Such a design is not feasible for a transaction-processing system that is exposed on the Web.

The design requirements for transactional Web applications will probably always be presented in terms of business processes. It is important, therefore, to establish some design techniques for breaking business processes into physical transactions. One important technique is to always limit physical transactions to a single .asp file.

Note

Business processes can span multiple .asp files, but physical transactions should not.

Another design technique is the use of status codes within transactional resources to indicate if a transaction is pending or committed. By including status codes you can reserve a resource without actually committing it. When the business process is complete, you can initiate another physical transaction that commits all pending resources by changing their status code. The Fabrikam, Inc. custom bicycle company case study illustrates how these two principles affect the implementation of transactional Web applications.

The Fabrikam, Inc. Web Application

The Fabrikam, Inc. Custom Bicycle Company is a manufacturer of hand-made bicycles distributed throughout North America. Employees have decided to begin taking orders for their bicycles through a Web application. They use Microsoft? SQL Server to maintain customer and inventory records and have already developed data and business-logic components that are registered with Component Services. Now they need to develop the .asp files that will allow their customers to access these components within the scope of a single business process.

The following illustration shows the distinct physical transactions and the .asp files that make up their Web application design.

IIS Transaction Processing in a Scenario

The sales order application is made up of four .asp files: Login.asp, Credit.asp, Inventory.asp, and Commit.asp. Notice that each of the physical transactions is represented by a separate .asp file. (Each .asp file contains the @Transaction = Required directive.) Login, Credit, and Inventory each interact with a COM component called Sales Order, which exposes methods for accomplishing the three steps of taking an order.

When the customer is ready to commit to the sale (that is, when the business process is completed), Commit.asp groups the entire logical transaction into a single physical transaction that changes all of the status codes in the data resources from "pending" to "complete." This design accommodates both the connectionless nature of the Web and the need to provide the user with a unified business process.