[Bernstein09] Section 3.2. Application Architecture

3.2. Application Architecture
Thereare three interrelated ways to decompose a TP system: by functionalcomponents, by hardware subsystems, and by operating system processes.The decomposition by functional components is shown inFigure 3.1.It consists of front-end programs, request controllers, transactionservers, and database systems. In the past, this was called a three-tier architecture,consisting of the front-end program as the first tier, the databasesystem as the third tier, and everything in between as the middle tier.As systems have become more layered, it is no longer clear how manytiers are present. We therefore call it a multitier architecture.
Figure 3.1. Multitier TP Application Architecture. Thefront-end program manages the user’s display and outputs requests. Therequest controller processes a request by calling transaction servers,which access databases and other transactional resources.

The display device, shown in the upper left, interacts with a component that we call the front-end program,which is responsible for gathering input and displaying output. Itcaptures input from forms, menu selections, and the like; validates theinput; and translates it into a request message.
Thefront-end program communicates with the device in a device-specificformat. The types of display devices change frequently based in largepart on the cost of hardware to implement them. Today, a web browserrunning on a PC is a common device. In this case, the front-end programis a web browser connected to a web server that uses the HTTP protocoland some variant of hypertext markup language (HTML) plus somescripting.
Thefront-end program may respond to some requests itself. It sends otherrequests to the next stage of the system, either by storing them on adisk in a queue or forwarding them directly for processing by theapplication, in a component that we call the request controller.
Therequest controller component guides the execution of requests. Itdetermines the steps required to execute the request. It then executesthose steps by invoking transaction servers. The application executingin this component usually runs as part of an ACID transaction.
Transaction serversare processes that run application programs that do the actual work ofthe request. They almost always execute within a transaction. Thetransaction server usually communicates with one or more databasesystems, which may be private to a particular transaction server or maybe shared by several of them.
Likeany program, a TP application usually is constructed by composingsimple components into more complex ones. Simple transaction serverapplications can be composed into a compound application using localprocedure calls, such as composingDebitChecking andPayLoan intoPayLoanFromChecking as we saw inSection 2.2.To compose distributed components, a distributed communicationsmechanism is needed, such as a remote procedure call or asynchronousmessage queue. Service-oriented components and workflow mechanisms canalso play a part in this composition. Compound applications can then becomposed into even higher level functions. This composition ofcomponents can have several levels, which sometimes makes thedistinction between request controller and transaction server programsrather fuzzy. In such situations, a program may perform both requestcontroller and transaction server functions.
Thismultitier TP application architecture means that the TP applicationitself must be split into different parts that perform these differentfunctions: front end, request controller, and transaction server. Mostof this chapter is devoted to the details of what each of thecomponents needs to do.
Multitier Architectures
TPsystems usually have two kinds of hardware subsystems, front-endsystems that sit close to the display devices, and back-end systemsthat sit close to the databases. In a simple configuration, eachfront-end system may be a PC running a web browser connected to theInternet, and the back-end system may be a single machine such as ashared memory multiprocessor running a web server and a databasemanagement system. In complex configurations, both the front-end andback-end systems may contain many machines. For example, a front-endsystem may have multiple machines that support a large number ofdevices in a retail store. A back-end system may be a large server farmthat supports hundreds of stores, with different machines runningdifferent applications, such as finance, order processing, shipping,and human resources.
A major architectural issue in TP systems is how to map the functional components ofFigure 3.1 into processes on front-end and back-end systems. One natural way is to have each function run in a separate kind of process:
The front-end program runs in a separate process, typically either a web browser or custom software to control relatively low-function end-user devices. On large systems, separate front-end machines are dedicated to front-end programs. On small systems, they run on the same back-end machine as other components.
Each request controller runs in a separate process and communicates with the front-end programs via messages. It usually runs on a back-end system.
Each transaction server runs as a process on a back-end system, preferably colocated on the same machine or local area network as the database system that it most frequently accesses. It communicates with request controllers and other transaction servers via messages.
Each database system runs as a process on a back-end system.
Mostmodern TP applications are structured in this multitier architecture toget the following benefits in a distributed computing environment:
Flexible distribution: Functions can be moved around in the distributed system without modifying application programs, because the different functions already are separated into independent processes that communicate by exchanging messages.
Flexible configuration: Processes can be located to optimize performance, availability, manageability, and so on.
Easier scale-out: The distribution and configuration flexibility makes it easier to scale out a system by adding more server boxes and moving processes to them.
Flexible control: Each functional component can be independently controlled. For example, one can control the relative speeds of transaction servers by varying the number of threads in those servers without affecting the front-end program or request controller functions, which are running in separate processes.
Easier operations: In a large system, only a few people are expert at each tier’s applications. Having them isolated makes them easier to debug and independently upgradable.
Fault isolation: Since the different functions are running in different processes, errors in one function cannot corrupt the memory of other functions, which are running in separate processes.
Themain disadvantage of this multitier architecture is its impact onperformance. The functional components are communicating via messagesbetween processes, instead of local procedure calls within a singleprocess. The former are at least two orders-of-magnitude slower thanthe latter. Since even the simplest transaction requires a round-tripbetween a front-end program and request controller and between arequest controller and transaction server, there is quite a lot ofmessage overhead in this approach.
Thereare other disadvantages of the multitier architecture due to its largenumber of moving parts. This leads to complexity of the design,deployment, configuration, and management of the multitier system. Tomitigate these problems, vendors have been steadily improving theirtools for development and system management. But there is still muchroom for improvement.
Dueto communications overhead, it is common to combine functions in asingle process. For example, most database systems support stored procedures,which are application programs that execute within the database serverprocess. One can use this mechanism to run transaction server programsas stored procedures, thereby eliminating a layer of processes betweenrequest controllers and the database system and hence eliminatingcommunication overhead. Of course, this reduces the degrees offlexibility of the multitier architecture, since it preventstransaction server programs from being distributed independently of thedatabase server processes in which they run.
Takingthis approach to the extreme, one can run all the functional componentsof the multitier architecture in a database server process. Thisreduces the multitier architecture to a two-tier architecture. This wasa popular approach in the early days of client–server computing in the1980s, but fell out of favor for large-scale systems due to its limitedability to scale out. However, as database servers are becoming morefunctional, it is looking more appealing. We will discuss this trendlater, inSection 3.7.
Service-Oriented Architecture
Inaddition to the multitier application architecture, application designmethodologies play a role in the structure of TP applications.Service-oriented architecture (SOA) is one such design methodology,which was discussed inChapter 1.In SOA, the designer identifies a service that a business provides forits customers and partners. The designer maps this business service toa software service, which is an operation. Typically, a set of relatedoperations are grouped together in a service interface. Each operationin a service interface is implemented as a software component that canbe invoked over a network by sending it a message. In SOA, operationsare intended to be relatively independent of each other, so they can beassembled into applications in different combinations, connected bydifferent message patterns.
Ina TP system, a service can implement a transaction or a step within atransaction. That is, it can play the role of a request controller ortransaction server. In either case, it is invoked by sending a messageto the service. In this sense, the notion of a service is nicelyaligned with multitier TP system architecture.
Thisalignment between SOA and TP depends only on the fact that SOAdecomposes applications into independent services. It does not dependon the particular technology that is used to define service interfacesor to communicate between services, such as RPC or Web Servicestandards.
Object-Oriented Design
Anotherpopular application design methodology that plays a role in thestructure of TP applications is object-oriented design. Object-orienteddesign offers a different perspective than SOA, focusing on modelingthings rather than functions.
Object-oriented design maps nicely onto the TP application architecture ofFigure 3.1 as shown inFigure 3.2. In this style of design, one starts by defining business objects,which are the elementary types of entities used by the business. Inprogramming terms, each business object corresponds to a class in anobject-oriented programming language, such as C++, Java, C#, or VisualBasic. It encapsulates the elementary operations on that type ofentity, called methods.Typically, these methods change slowly, because they correspond totypes of real-world objects whose behavior has been well-establishedfor a long time. For example, the following could be defined asbusiness objects:
Customer: It supports methods to create a new customer, change address, change phone number, and return customer information in several different formats.
Loan Account: It supports methods to create a new loan account, increase the amount owed, credit the amount paid, and associate the loan account with a different customer.
Credit History: It supports methods to create a credit history for a given customer, add a credit event (such as a loan or loan payment), and return all its credit events for a given time period.
Figure 3.2. Mapping Object-Oriented Application Architecture to a Multitier Model. Businessobjects, such as “Customer,” “Credit History,” and “Account” run intransaction servers, and business rules such as “Open an Account” runin request controllers.

After defining the business objects in an application, one defines business rules,which are actions that the business performs in response to things thathappen in the real world. For example, the business rule for opening anew loan might involve creating a new customer object (if this is a newcustomer), checking the customer’s credit history, and if the credithistory is satisfactory, then creating an account. Business ruleschange more frequently than business objects, because they reflectchanges in the way the business operates in the real world. It istherefore useful to program business rules in modules that are separatefrom business objects.
Onecan map this object-oriented application design onto TP applicationarchitecture by running business objects as transaction servers andbusiness rules as request controller programs. This is an efficientarchitecture, since business objects make frequent access to thedatabase that stores the object’s state and can be colocated with thedatabase. It is also a flexible structure, since business rules can bechanged within request controllers without affecting the businessobjects (i.e., transaction servers) that they call.
Applicationscreated using objects can be service-enabled to participate in an SOA.Externally callable methods of an object-oriented application are goodcandidates for services. Services might expose only portions of thefunctionality of the objects through the service interface.
Simple Requests
In this chapter, we’ll focus on simple requests. A simple requestaccepts one input message from its input device (a display device orspecialized device such as an ATM), executes the transaction, and sendsone message back to the input device. Examples are making a bankaccount deposit, placing an order, or logging a shipment. Each simplerequest is independent of every other simple request.
Agiven user interaction may actually require a sequence of relatedrequests. For example, a user might want to arrange a trip, whichrequires reserving airline seats, reserving a car, and reserving ahotel room. A travel web site may offer this as one request, eventhough it may actually run as three separate requests. We’ll look atmulti-request interactions inChapter 5. In this chapter, we’ll assume that all requests are simple—one message in and one message out.
The next three sections,Sections 3.3 through3.5,cover the main components of TP application architecture: front-endprograms, request controllers, and transaction servers. They look atboth the application’s functions and issues related to building theunderlying component.Section 3.6 looks at transactional middleware that provides support for these components.Section 3.7revisits the two-tier versus three-tier system models, exploring inmore detail the decision to group front-end programs, requestcontrollers, and transaction servers into the database server process.