[Bernstein09] Section 3.6. Transactional Middleware

3.6. Transactional Middleware
Softwarevendors have developed transactional middleware products that make iteasier to create, execute, and manage TP applications by integratingdiverse runtime functions. The main product category for this markettoday is the application server. Before the advent of the World WideWeb, the main product category was the TP monitor or On-Line TP (OLTP)monitor. Descriptions of transactional middleware products arepresented inChapter 10.
Themain job of transactional middleware is to provide an environment thattakes applications that are written to process a single request andscale them up to run efficiently on large, often distributed systemswith many active users submitting requests and many servers processingrequests. By enabling this scale-up, transactional middlewareincreases the capacity and lowers the per-transaction cost of theapplication. From a business perspective, it lowers the cost of retailsales, ticket reservations, funds transfers, and such.
Transactional middleware typically includes software in four major functional areas:
An application programming interface that offers the type of runtime functions described in earlier sections of this chapter. It integrates these functions, thereby simplifying the environment in which applications are programmed. Some of these functions may be directly implemented by the transactional middleware. Others may be offered by lower-level products, which the application server passes through either as functions in its integrated API or directly through system-level APIs. Some functions may be defined using attributes embedded in class definitions, or as policies and configuration attributes of the application execution environment.
Program development tools for building transaction programs, such as program templates for the main application components, and smooth integration of its API into a particular programming language and development environment.
A system management interface and accompanying runtime functions to configure a TP application for a distributed system, deploy it, and then monitor and control its execution.
Integration with popular database management systems and front-end programs.
Transactionalmiddleware is a software framework or application execution environmentin which application programs run and in which users interact with thecomputer system. The execution environment often is called a container.The container ties together the underlying system components that areneeded by all TP applications—multithreading, user interface services,communications system, operating system, and the database system. Italso may offer components of its own. For example, it may addtransactional capability to the built-in RPC mechanism or it may addtwo-phase commit, if these are absent from the operating system and/ordatabase system.
Thecontainer provides a single, smooth interface, so that developers andend users don’t need to deal with each of these componentsindependently or learn multiple low-level APIs (seeFigure 3.8).Instead of writing application programs that talk independently to theforms system, web server, operating system, communication system, and so on, the programmer writes an application using a single interface that talks to the transactional middleware.
Figure 3.8. TransactionalMiddleware Container. The transactional middleware container providesservices, such as request management, transactional communications, andtwo-phase commit. Its container provides a single abstraction toapplication programmers and system managers.

Sometransactional middleware systems integrate their runtime functions witha particular programming language. A notable example of this is JavaEE, which consists of Java classes that encapsulate the applicationserver’s functionality. Older examples of the language-specificapproach developed in the 1980s are HP’s Screen COBOL and TaskDefinition Language (see alsoSection 3.4).
Othertransactional middleware products offer language-independent runtimefunctions. IBM’s CICS is one example of this approach, introduced inthe late 1960s and still widely used. A more recent example isMicrosoft’s .NET Framework, where runtime functions are available inall .NET languages. There is a trend toward exposing transactionalmiddleware features as extensions to the normal development experience,rather than making them available only in a closed developmentenvironment.
Java EE-based application servers are portable in the sense that they run on a variety of platforms,or operating systems (e.g., Windows, IBM mainframes, and many flavorsof UNIX); they support the same APIs on these platforms; and theyintegrate with multiple database systems and front-end programs. Thus,TP applications can usually be ported from one Java EE applicationserver to another with moderate effort.
Interoperabilityis the ability of programs to participate as part of the sameapplication. Programs may find it hard to interoperate because theywere independently developed in different languages, with incompatibleinterfaces, and using incompatible data types. Or interoperations maybe difficult because they run on different machines with differentunderlying platforms. This latter issue requires that there areimplementations of the same protocols on the machines forcommunication, two-phase commit, and other shared functions.
Interoperabilitycan be achieved by running instances of the same application server ondifferent machines that run different platforms or by using applicationservers that support the same protocol. For example, two RPC protocolsthat are in common use by different application servers are RMI/IIOPand SOAP/HTTP. Sometimes, interoperability is sacrificed by offeringcustom features, by disabling features of an interoperability standard,or by using nonstandard protocols for better performance. For example,some platforms implement a custom two-phase commit protocol that hasspecial features and better performance than standard protocols.
Systemmanagement functions include load balancing, fault monitoring andrepair, performance monitoring and tuning, and the ability to changethe configuration by creating and destroying processes, creating anddestroying communication sessions, and so on. For example, thetransactional middleware may store a description of which serverprocesses are running on which machines. Instead of just telling thesystem manager that an operating system process has failed, thetransactional middleware might say that the bank’s loan server processhas failed, thereby giving the system manager a better idea of wherethe problem is and what to do about it. It may also automate recoveryby creating a new copy of the failed process on another machine thathas spare capacity. System management functions also are required toset up and maintain security information to protect access to displaysand to ensure that only authorized users can access sensitivetransaction control programs. These kinds of system managementfunctions often are provided for TP applications by generic systemmanagement tools, such as CA’s Unicenter, IBM’s Tivoli, and HP’sOpenView.
Thetransactional middleware also provides some application developmenttools to make it easier to write the code for each of the components ofa multitier architecture. We’ll describe examples of programdevelopment inChapter 10.