[Bernstein09] Chapter 10. Transactional Middleware Products and Standards

Chapter 10. Transactional Middleware Products and Standards

Introduction

Web Browser Front-End Programs

.NET Framework

Java Enterprise Edition

Service-Oriented Architecture

Persistence Abstraction Mechanisms

Legacy TP Monitors

TP Standards

Summary

10.1. Introduction

In this chapter, we’ll survey some popular transactional middleware products and standards, including:

• Current products from Microsoft and Java vendors

• Popular persistence abstractions mechanisms that simplify database access

• Legacy TP monitors, including information on how each product can be reused in a modern system, such as a Service Oriented Architecture (SOA)-based application

• Widely-adopted TP standards

Trends in Transactional Middleware

Overthe past 20 years, we have seen a continual repackaging oftransactional middleware functionality, both the aggregation ofcomponents into transactional middleware packages and the decompositionof packages into independently configurable components. For example,transaction management is a basic capability in most databasemanagement systems. It is also offered in enterprise service buses andother products designed for use with an SOA-based application. Somefeatures and functions of front-end programs, request controllers, andtransaction servers have migrated from integrated TP monitors andapplication servers to separate products. Others are migrating intooperating systems, such as distributed transaction management. Theinnovations of large web sites such as Amazon.com,Google, and eBay have also been influential, such as the use of customtransactional middleware components for replicated state management andsimple scalable data management.

Thegoal of this chapter is to give you a feeling for the state of the artof transactional middleware products and some confidence that thetechnical issues discussed in this book do give you the necessarybackground to understand transactional middleware. A secondary goal isto help you think about which technology is most appropriate for yourspecific requirements.

Itis not a goal of this chapter to provide sufficiently detailed featurecomparisons to help you select the exact products that best suit yourneeds. Product features change with each succeeding product release, sowe recommend that you evaluate the latest information from a product’svendor when making such a decision. It is also not a goal to explaineach product in enough detail to enable you to use it. In particular,example programs are meant only to illustrate each product’s approach,not to be used as a template for developing applications.

Forthe most part, when describing each product or technology, we use thisbook’s terminology rather than that of the product or technology. Ifyou know a given product well, it may seem strange to see it describedusing unfamiliarterms. However, for a reader learning about the product for the firsttime, we hope this approach makes it easier to gain a basicunderstanding of how the product is structured and what features itoffers.

Transactional Middleware Programming Models

Today’stransactional middleware products provide a configurable deploymentcontainer for application objects. The goal of the container is toreduce complexity by packaging together system capabilities such astransaction control, threading, and persistence, and enabling adeveloper to customize them using configuration properties. Deploymentof a transactional object into a container requires a configurationstep to set its properties. This is the approach described in Section 2.2, Transaction Bracketing in Object-Oriented Programming. Both the .NET Framework and Java-based products recommend using container-managed transactions for most applications.

Container-managed transactions are called the implicitprogramming model because an application developer creates TP programsthat incorporate the business logic without describing transactionalbehavior. This simplifies programming by not requiring the developer tothink about which parts of the code need to run as transactions. Italso helps address the transaction composition problem by enablingprograms to be composed in different combinations without beingrewritten.

Inthis model, transactional behavior is defined in another step, perhapsby another person, using configuration properties. Configurationproperties can be defined in a separate file associated with theprogram, as attributes embedded within a program and its interface, oras a combination of the two. Sometimes the separate configuration fileis generated from the embedded attributes. Some technologies allowattributes in a configuration file to override embedded attributes.Others do not.

Theimplicit model is increasingly popular, but there are cases wheredevelopers want the flexibility to express transactional behavior inthe business logic. To meet this need, both the Java-based and.NET-based transactional middleware systems also offer explicitprogramming control of transactions. In this model, developers usetransaction management APIs to explicitly start and end transactionswithin their objects.

Theexplicit programming model adds flexibility, but usually at the cost ofmore difficulty in creating and maintaining complex systems. However,whether developers use explicit or implicit transaction control, thebehavior of the underlying transactional system remains the samebecause the execution of the transaction control operations relies onthe same transactional infrastructure.

Java EE and the .NET Framework

Currently,the two primary transactional middleware environments are JavaEnterprise Edition-based application servers and Microsoft’s .NETFramework. Both environments provide comprehensive capabilities forcreating and deploying TP applications.

Inkeeping with the ongoing trend to repackage transactional middlewarefunctionality, some TP environments use only parts of the JavaEnterprise Edition (EE) and .NET Frameworks. Sometimes these parts arecombined with legacy TP monitors, for example, to modernize an existingapplication or to enable new applications to interoperate with olderones.

Comparingthe Java EE and .NET Framework environments, one obvious difference isplatform coverage. For example, Microsoft’s .NET Framework offers acomprehensive and full-featured programming model for developing anddeploying TP applications, but it is available only on Windowsoperating systems. A second significant difference between products istheir set of programming interfaces and communication paradigms. Forexample, .NET Framework APIs differ from Java EE APIs. Although theAPIs share many common features, they each offer some unique ones. Athird difference is standards conformance. Products typically conformto various TP standards, but not necessarily to the same ones.

We describe the details of the .NET Framework and Java EE in Sections 10.3 and 10.4,respectively. But first, we discuss technologies for developingfront-end programs using web browsers, since they are largely common toboth environments.