[Bernstein09] Section 3.8. Summary

3.8. Summary
Theprocessing of simple requests involves receiving a request, routing itto the appropriate application program, and then executing it. Thisactivity usually is distributed across components of a multitierarchitecture, consisting of the following:
Front-end programs, for interaction with an end user or special device
Request controllers, for routing a request to the correct transaction program
Transaction servers, to do the work necessary to fulfill the request, usually involving accesses to transactional resources, such as databases, and typically returning results to the caller
Thisarchitecture is aligned with service-oriented architecture, by mappingservices to transaction servers, and with object-oriented design, bymapping business objects to transaction servers.
Thefront-end program is responsible for interacting with the end user viamenus and forms, gathering input for the transaction request and thename of the transaction to be executed. After gathering input, thefront-end program constructs the request message and sends it to therequest controller. The front-end program needs a suitably secureconnection to the request controller, optionally using geographicalentitlement to check that the user is authorized for the specificdevice. Currently, the most popular technology for these functions isthe web browser running on the end user’s device, communicating with aweb server that executes many of the front-end program’s functions.When money or personally identifiable information is involved, theconnection between web browser and web server often is enabled by useof Transport Layer Security.
Themain goal of the request controller is routing. It decodes the requestmessage, determines the location of the transaction program to becalled, and makes the call. The request controller brackets thetransaction that executes the request. Its application code isstructured to solve the transaction composability problem usingwhatever mechanisms are available from the underlying middleware orplatform. It ensures that each request is not lost if its correspondingtransaction aborts. It typically runs in a multithreaded process, oftenpartitioning front-end sessions by request controller for scalability.It also bridges the per-user security model of the front ends with theprocess-oriented authorization model that usually is needed forcommunication with back ends.
Thetransaction server executes program logic to fulfill the request, suchas retrieve data from a database or update data with new valuesprovide$ by the request. It usually is implemented as a multithreadedprocess, which in turn communicates with multithreaded database serversusing pooled database sessions.
Transactionalmiddleware products provide APIs, development tools, system managementtools, and integration with popular database systems and front-endprograms. Transactional middleware products typically provide anabstraction called a container that helps TP application developershandle the complexities of transaction management and low-leveloperating system functions such as multithreading, communications, andsecurity.
Manyfunctions previously performed only by transactional middlewareproducts are now features of database servers. Transactional middlewareproducts still provide features that database servers don’t yet have,such as request routing, server classes, transactions distributedacross multiple types of resource managers, composable transactions bysetting transaction attributes, and certain system management andadministrative functions for TP applications programs and systems.However, database servers are suitable for many applications and theirrange of applicability is growing.