3.8. Summary
The
processing of simple requests involves receiving a request, routing it
to the appropriate application program, and then executing it. This
activity usually is distributed across components of a multitier
architecture, 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
This
architecture is aligned with service-oriented architecture, by mapping
services to transaction servers, and with object-oriented design, by
mapping business objects to transaction servers.
The
front-end program is responsible for interacting with the end user via
menus and forms, gathering input for the transaction request and the
name of the transaction to be executed. After gathering input, the
front-end program constructs the request message and sends it to the
request controller. The front-end program needs a suitably secure
connection to the request controller, optionally using geographical
entitlement to check that the user is authorized for the specific
device. Currently, the most popular technology for these functions is
the web browser running on the end user’s device, communicating with a
web server that executes many of the front-end program’s functions.
When money or personally identifiable information is involved, the
connection between web browser and web server often is enabled by use
of Transport Layer Security.
The
main goal of the request controller is routing. It decodes the request
message, determines the location of the transaction program to be
called, and makes the call. The request controller brackets the
transaction that executes the request. Its application code is
structured to solve the transaction composability problem using
whatever mechanisms are available from the underlying middleware or
platform. It ensures that each request is not lost if its corresponding
transaction aborts. It typically runs in a multithreaded process, often
partitioning front-end sessions by request controller for scalability.
It also bridges the per-user security model of the front ends with the
process-oriented authorization model that usually is needed for
communication with back ends.
The
transaction server executes program logic to fulfill the request, such
as retrieve data from a database or update data with new values
provide$ by the request. It usually is implemented as a multithreaded
process, which in turn communicates with multithreaded database servers
using pooled database sessions.
Transactional
middleware products provide APIs, development tools, system management
tools, and integration with popular database systems and front-end
programs. Transactional middleware products typically provide an
abstraction called a container that helps TP application developers
handle the complexities of transaction management and low-level
operating system functions such as multithreading, communications, and
security.
Many
functions previously performed only by transactional middleware
products are now features of database servers. Transactional middleware
products still provide features that database servers don’t yet have,
such as request routing, server classes, transactions distributed
across multiple types of resource managers, composable transactions by
setting transaction attributes, and certain system management and
administrative functions for TP applications programs and systems.
However, database servers are suitable for many applications and their
range of applicability is growing.
|
