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.
Transactional Superglue
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, bus
iness 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 a
nd programmers the intra-application network linkages and services that let a distributed Web-based application handle a large number of clients.
TP Middleware
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 righ
ts 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 (see the figure
"TP to the Rescue"
). 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.
Web-Based Solutions
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 appro
ach 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.
Prolifics
, a company that offers a product of the same name, gives Tuxedo-based application designers a visual tool for incorporating database-oriented business logic. The
tool emits HTML, JavaScript, and (soon) Java to help Tuxedo IS shops develop three-tier Web applications.
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 w
hen 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 in
volving 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 tim
ing 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 witho
ut 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().
KIVA's product is a TP monitor specially built for the Web. KIVA designed its Enterprise
Server product as an application server environment for Web-based business applications; it contains no support for legacy (pre-Web) applications. KIVA's middleware works with Web browser clients and supports both Java and ActiveX.
Enterprise Server consists of a transaction and request manager, several APIs for programmatic control over transaction processing activities, a security module, administrative tools, a deployment manager, and a data access manager. The transaction and request manager relies on state and session information to manage multistep complex requests as atomic transactions. The security module can use cookies, database access controls, Secure Sockets Layer (SSL), Secure HTTP (S-HTTP), and HTTP challenge-response authentication, and it creates an audit trail of transaction events.
Enterprise Server has six service classes: transaction management, application and server management, system services (such as load balancing), thread management and application partitioning, data acc
ess, and application logic management. KIVA's implementation of these service classes is modularized, so you can configure them to run on one or several (distributed) machines. Enterprise Server is multithreaded and includes caching and streaming functions to minimize response times. The load-balancing feature doles out transaction requests to instances of application programs running on multiple networked computers.
Visigenic's VisiBroker for Java and C++ is a CORBA 2.0 ORB that uses the Internet Interoperable ORB Protocol (IIOP) for interprocess communication between network nodes. Visigenic's paradigm for transaction processing is ORB-based and well suited for applications whose development follows object-oriented programming standards. The IIOP within the C++ product is a native implementation, while the IIOP of VisiBroker for Java is written entirely in Java.
Both the Java and C++ versions of VisiBroker use an agent-based architecture, perform automatic configuration (and reconfiguration as t
he network changes), balance transaction work loads across a network, and offer smart binding. Multiple instances of VisiBroker "smart agents" keep track of which network server objects are running and which are down. These same agents perform load balancing by keeping track of transaction activity and response times.
VisiBroker for Java features a code generator that goes from interface definition language (IDL) to Java. VisiBroker is multithreaded, and it supports both client-side and server-side Java. The design-time portion of VisiBroker for Java converts object interfaces, rendered in IDL, into skeleton Java code. The run-time portion manages communications between distributed applets and other objects.
VisiBroker for C++ offers an IDL-to-C++ compiler, static and dynamic invocation interfaces, an object-activation daemon, and object administration and ORB monitoring tools. The IDL compiler is a full CORBA implementation and complies with CORBA's C++ Mapping specification. The object-activatio
n daemon conserves server resources by making sure only those objects that are currently in use (or that are frequently needed, a configuration option a developer can select) are running and available.
Web Application Server, from Oracle, consists of a Web server, TP monitor function, and a set of development tools for Web-based applications. Oracle calls its TP monitor the Web Request Broker (WRB). The Web server, a relabeled version of the Spyglass server and termed the Web Listener, accepts incoming HTTP requests from the browser and passes them directly to the WRB, which examines the requests. If an association exists between a request and an entry in the WRB configuration file, WRB forwards the request to the appropriate
cartridge
--a program built with Oracle's development tools. For unassociated HTTP messages, the Web Listener behaves as an ordinary Web server.
The WRB itself consists of three separate components types: the Dispatcher (WRBD), one or more Execution Engines (WRBXes) ass
ociated with each WRB service (such as Java or PL/SQL), and a common API to interface with each WRBX. The WRBD recognizes the object types specified by incoming URL requests by examining the WRB configuration file and identifying a match between the URL and a list of virtual directories. Each of these directories is associated with a WRB service, which is conceptually a combination WRBX and associated shared library. For instance, a URL directory field starting with /Java might be configured to initiate the Java interpreter. The WRBD also controls the number of incarnations of WRB service initiated from a particular WRBX. Programmers create WRB cartridges by registering three callback functions with the WRBX: an initialization function, a request handler, and a shutdown function.
Web Application Server, in contrast to products such as Microsoft's Transaction Server, lets developers treat multiple related Web pages (HTML requests) as a single atomic transaction. Additionally, the WRB instantiates a separ
ate process to handle each different transaction type, thus isolating the handling of transactions from the TP monitor and Web server processes. If the business logic handling a particular transaction crashes, the failure will likely not affect the WRB or the Web server (
see the figure
). Web Application Server, Oracle says, will become more object-oriented later this year when the product gains an IDL compiler and ORB features.
Which One for You?
If you have existing application code that you need to incorporate into a transaction processing environment, BEA's Tuxedo/Jolt (along with the Prolifics tools) or IBM's Transaction Server may be the best answer. For new development projects revolving around other Microsoft developer tools, Microsoft's Transaction Server is worth a look. KIVA's Enterprise Server is appropriate for new development that's entirely Web-based. Oracle's Web Application Server has a robust architecture and promises great things in the future. If you're
involved in a development effort not needing TP monitor support until later this year, you might want to defer choosing a TP monitor until Borland's Midas suite is available. And if you're a heavily object-oriented shop, Visigenic Software's VisiBroker for Java will help you distribute the work load.
Complex, high-volume, Web-based applications are the wave of the future for many companies. TP monitor middleware technology can save these companies (perhaps yours?) many person-months of time and effort.
Where to Find
BEA Systems
Sunnyvale, CA
Phone: 800-817-4232
Internet:
http://www.beasys.com
Guaranteed Delivery
