Transactionalmiddleware products meet the requirements of multitier TP applications.Twenty years ago, transactional middleware was delivered to market as asingle product category, the TP (or OLTP) monitor. Many of theseproducts are still in production, but the most popular transactionalmiddleware environments are now delivered in the Java EE and .NETFramework environments.
Asthe new environments have gained popularity, components of the originalmonolithic TP monitors now are sold as independent products. Examplesinclude forms products, database management systems, system managementconsoles, distributed computing communications systems, and applicationdevelopment environments. Modern TP applications often include servercomponents of legacy TP monitors, general purpose products, andcomponents from the .NET Framework, Java EE-compliant applicationservers, or both. We expect the trend toward componentization tocontinue. Yet the features and functions of transactional middlewareremain unchanged—to help scale up, improve performance, reliability,security, manageability, maintenance, transaction control, recovery,and availability.
TPapplications typically consist of two or more tiers that provide thefunctions of the front-end program, request controller, and transactionserver. In their simplest and most direct design, a front-end programmight directly access the transaction server in a database. However,since connections between front-end programs and databases can beexpensive to maintain, one or more middle tiers often are introduced toimprove scalability and performance. Transactions can be controlled bythe resource manager or the transactional middleware. Differenttransactional middleware systems provide different options forcomposing multiple resources into local and distributed transactions.
Mosttransactional middleware systems also support the use of web servers asrequest controllers, and rich Internet applications such as AJAXdeliver desktop-like levels of interactivity and features to the webbrowser. All transactional middleware, including legacy TP monitors,supports access from web browsers either directly or through anintermediary.
Transactionalmiddleware products typically support both an implicit and explicitprogramming model for transaction control. The implicit model usesconfiguration properties of abstract runtime containers toautomatically begin, propagate, and terminate a transaction. Theexplicit model relies on APIs incorporated directly into programs. Thetradeoffs are generally between ease of use of the implicit model andflexibility of control of the explicit model.
LegacyTP monitors such as CICS, IMS, ACMS, Tuxedo, and Pathway continue to beused in many production environments. They now include support formodern front ends such as .NET, Java, and Web Services, for integrationwith newer applications and SOA-based designs.
Microsoft’s.NET Framework includes multiple technologies for creating front-endprograms, such as WPF, Silverlight, and ASP.NET. WCF can be used todevelop request controllers and transaction servers. SQL Server can runstored procedures, which functions as a complete transaction server insome environments.
Transaction management in the .NET Framework uses theSystem.TransactionsAPI set. It underlies the implicit programming model in WCF and canalso be accessed explicitly from .NET Framework objects. When used withWCF, attributes embedded within .NET objects cause them to execute astransactions. Annotations can also be embedded in programs andinterfaces to automatically complete and propagate a transaction.
TheJava EE environment includes multiple technologies for creatingfront-end programs, such as Swing, JSP, JSF, and servlets. EJBs can beused to develop request controllers and transaction servers, and caninclude JPA beans for object-relational persistence. SQL databasesystems run stored procedures, which can function as transactionservers.
Transactionmanagement in the Java EE environment uses the Java Transaction API(JTA), which underlies the implicit programming model in EJBs, and canalso be accessed directly from Java objects. As in WCF, annotationsembedded in EJBs control transaction initiation, termination, andpropagation. In the Java world, the Spring Framework is emerging as analternative for TP application development. It includes a transactionmanagement abstraction API that’s configurable for either JDBC- orJTA-managed transactions.
InJava EE the same set of annotations is used for transaction control andpropagation, whereas these functions can be controlled separately inthe .NET Framework. Another difference between the environments is thatthe .NET Framework automatically promotes a single resource transactionto a multiresource transaction when it detects an application accessinga second resource manager.System.Transactionscan automatically reassign coordination responsibility from theresource manager’s transaction manager to an independent transactionmanager (i.e., DTC). In the Java EE environment, such a change has tobe explicitly programmed.
SOA-baseddesigns are gaining adoption for TP applications using varioustechnologies, such as Web Services and REST/HTTP. The transactionalmodels differ for these two approaches. In Web Services, transactionalRPC and compensation protocols are formalized in the WS-Transactionsspecifications, which make mapping transactional capabilities fairlystraightforward. With REST/HTTP, a transaction can be modeled as aresource. The server maintains the state of the resource and thefront-end program maintains the application state separately.Representations of state changes are exchanged using HTTP verbs.
Persistenceabstractions enable easier access to resource managers, especiallyrelational databases. The initial abstraction was designed to improvethe use of remote database connections, and was formalized in ODBC andJDBC, which are still widely used. Newer abstractions includeobject-relational mappings such as JPA and entity data models such asADO.NET Entity Framework. The abstraction mechanisms typically includetransaction management capabilities.
TPstandards help promote interoperability of TP environments andportability of applications. The most widely adopted is the XAprotocol, which defines the relationship between a resource manager andan independent transaction manager, so resource managers andtransaction managers from different vendors can easily integrate. Otherwidely-adopted standards include the Object Transaction Service fromOMG, which is included in Java EE’s JTA, JTA itself, andWS-Transactions for Web services transactions. Emerging standardsgaining adoption include SCA, OSGi’s enterprise edition, and AMQP.
