Can you have multiple Web servers, application servers, and database servers without transaction-oriented middleware? We doubt it.
Oh, what a tangled Web we weave when first we practice to write three-tier Web-based applications without using transaction processing (TP) monitor middleware. The same software technology mainframes use to process millions of transactions per day, recast into Web-suitable form, is a sine qua non for developing and running business-automation applications on an intranet or the Internet.
The effort to program the business logic isn’t the issue here. Supporting thousands of clients is. Business logic analysts and programmers have neither the time nor the expertise to create the transaction-oriented, network-based architecture a high-volume application will demand in everyday use; they have enough work to do automating business procedures and rules.
Fortunately, a small but growing group of vendors offers Web-aware TP monitor tools you can choose from. Some of these are mature, pre-Web products to which vendors have added Web awareness, while others are new tools designed expressly for use within applications based on Web browsers and HTTP servers. Read on to explore the software technologies embodied by Web-based TP monitors.
People sometimes call middleware “glue” or “plumbing,” and a few even mystically say, “If you need to ask what middleware is, you don’t need it.” Web-based TP monitor middleware is simpler to understand than vague metaphors and churlish misdirections imply.
The levels of a three-tier architecture are presentation, business logic, and data storage. Middleware exists between each of the tiers, connecting the presentation layer to the business logic layer and the business logic layer to the data storage layer. For example, you might use a Cisco router or a transaction-aware Java class library to distribute incoming HTTP traffic among several Web servers–the router or the Java class performs a middleware role. Software you incorporate into the application to help distribute transactions among multiple application servers (running the business logic) is middleware. Whether purchased or home-grown, application components that distribute database server requests across several relational database management system (RDBMS) servers are also middleware. The connectivity software (or, in some cases, hardware) is the middleware, and its place in the system assures transaction integrity and enforces security, in addition to balancing the work load. Web middleware, and TP monitors in particular, gives designers and programmers the intra-application network linkages and services that let a distributed Web-based application handle a large number of clients.
Middleware categories include TP monitors, Distributed Computing Environment (DCE) and remote procedure call (RPC) environments, messaging, object request brokers (ORBs), and database access tools. TP monitor products offer a middleware environment oriented toward handling transactions over a network. For example, TP monitors bracket developer-defined application operations with implied BEGIN TRANSACTION and END TRANSACTION. By using TP monitor services, applications don’t have to specifically provide for transaction integrity.
TP monitors help the various parts of an application running on several computers coordinate with each other, performing tasks such as queuing transactions, balancing transaction work load, managing and isolating transaction processes and threads, monitoring the completion of transactions, and verifying rights and permissions. Further, a Web-based TP monitor overcomes HTTP’s inherent statelessness by recognizing which HTTP messages (Web pages, most likely) belong to each transaction, or by augmenting HTTP with the monitor’s own state-maintaining protocol.
You integrate TP monitor services into an application in several ways. You can insert statements into your application program that call the TP monitor’s APIs, or register with the TP monitor those application components and resources that relate to a transaction, or sometimes by taking both actions. Some TP monitor APIs are extremely simple, while others are more involved. In either case, invoking the APIs is usually quite easy once you identify where in your application’s flow the transactions occur. TP monitor vendors currently have proprietary APIs, but most say they plan to implement the new X/Open standard APIs.
Here’s another example of how a Web-based TP monitor can help an application run smoothly in the face of a high volume of transaction requests. Because you configure the middleware with information about which database servers are equivalent copies of each other, as well as which databases a transaction can affect, the middleware can monitor server activity and send SQL messages to less busy database servers. If a particular server fails, the middleware queues the SQL request and delivers it when the server returns to the network. Alternatively, the middleware can reroute the message to a different database server that (as you’ve designed) is a replicated copy of the failed server. Without faltering, the system continues to process transactions that don’t need access to the failed server. Some middleware products can even route HTTP messages to Web servers that are less busy.
Companies such as BEA Systems, IBM, Microsoft, Oracle, Prolifics, Visigenics, and KIVA are in the forefront of Web TP monitor technology. Each takes a somewhat different approach to helping your application process transactions.
BEA offers Java programmers transaction services with its Jolt product, a collection of class libraries and functions that complement BEA’s well-known Tuxedo middleware. Jolt also replaces HTTP with its own Jolt Transaction Protocol (JTP), which gives Jolt-based Java programs extra capabilities beyond the limited, document-presentation-oriented HTTP. JTP helps Jolt maintain transaction state information and helps servers distribute transaction workloads.
Tuxedo, which supplies the basic middleware services to a Jolt/Java application, is a distributed transaction monitor. It gives developers message-oriented functions implemented in terms of transaction semantics. Tuxedo consists of a transaction manager, queue services, a domain feature, DCE integration functions, and client components. The transaction manager provides naming services, dynamic message routing, load balancing, configuration management, transaction management, and security. Queue services provide a messaging framework that insulates business logic from the specifics of the underlying transport layers of the network. The domain feature allows you to segment application components on a large network into administratively autonomous groups. Tuxedo’s DCE integration is a set of utilities and libraries that can provide DCE services and functions to Tuxedo-based applications.
Programmers use Application-to-Transaction Manager Interface (ATMI), a set of 30 API function calls, to incorporate Tuxedo into their applications. The Open Group has adopted ATMI as a standard X/Open API. The ATMI toolset gives developers asynchronous service calls (callback functions), typed buffers, service request forwarding, service request prioritization, and dynamic, programmatically controlled data routing.
Borland’s Midas (a not-quite acronym for Multitier Distributed Application Services), in development as we went to press, is an object monitor for Web applications. It consists of three broker components: Business ObjectBroker, Remote DataBroker, and ConstraintBroker. The Business ObjectBroker performs load balancing and assures transaction integrity for OLE Automation objects (i.e., ActiveX components) registered with it. The Remote DataBroker acts as an intermediary between thin clients (e.g., browsers), business logic, and database servers. ConstraintBroker copies database constraint logic onto the computer running the business logic and lets the business logic use those constraints as data edits. Without ConstraintBroker, applications must either contain data edits that express the same database integrity rules as the constraints in the database or face the likelihood of insert/update failures when issuing SQL statements to the RDBMS. Constraint Broker reduces network traffic and simplifies application maintenance.
Likely the neatest feature of Borland’s Midas technology is that you don’t have to insert code into your applications to take advantage of it. Borland says it will supply graphical tools for registering applications with Midas and configuring their behaviors.
IBM’s numerous middleware products currently connect more computers and applications, in more diverse ways, than any other. For Web-based applications, IBM supplies developers with IBM Transaction Server, which runs on OS/2 Warp, AIX, and Windows NT and was formerly called CICS for OS/2, CICS for AIX, and CICS for NT. It acts as an enterprise-wide coordinator and integrator of servers and clients, managing applications and data sources across a network. IBM also offers Encina, MQSeries, and the CICS Gateway for Java.
IBM Transaction Server is a TP monitor middleware product that ensures integrity for transactions involving a set of related updates (all the updates succeed or all the updates fail and get rolled back), allocates system resources to transaction-oriented applications, launches applications as necessary to process transactions, balances workloads across application servers, and even initiates transactions within Lotus Notes. IBM bundles CICS Gateway for Lotus Notes and IBM CICS Internet Gateway with its Transaction Server products. The CICS Internet Gateway interfaces Web servers and CICS applications, translating between HTML and 3270 data streams in order to, for example, let Web browsers display 3270 screens as if they were Web pages.
IBM’s complementary products for Transaction Server include Encina and MQSeries. Encina is a DCE-integrated (and RPC-based) transaction processing solution. MQSeries is a platform-neutral messaging facility; it uses a message queue coupled with a transaction monitor to free interbusiness developers from having to comply with one another’s network infrastructure and timing requirements. The CICS Gateway for Java consists of small Java class libraries developers can use to connect their applets to CICS programs running elsewhere on the network.
Microsoft Transaction Server manages low-level operating system resources, such as processes and threads, thus allowing concurrent client access to applications. It synchronizes access to shared data, lessening the effect of multiuser database access as it routes transactions to application servers and database servers. Transaction Server supports ActiveX, has a simple programming interface for hooking into your application, and offers just-in-time instantiation of object components. This middleware product manages a pool of ODBC connections that clients can draw from, and it can act as a repository for shared data variables that multiple concurrently executing processes can access. The application components that Transaction Server manages are location-transparent, meaning they can reside virtually anywhere on the network without the application having to keep track of which server, drive letter, or directory structure contains them.
An application environment that includes Transaction Server has an architecture consisting of base processes (client programs, which might be browsers), application components (implementation of business logic, written as ActiveX components), the Transaction Server Executive (manages transactions and provides services to application components), resource dispensers (distribute and control shared resources, such as database connections), and resource managers (SQL Server is an example).
Microsoft Transaction Server, like most other TP monitors, has a proprietary API. While other vendors plan to implement the new X/Open standard APIs, Microsoft plans to stick with its ActiveX component model and simple calling conventions. Transaction Server adds just two new APIs: GetObjectContext() and SafeRef().