DTP Monitors Add Scalable Services To The Web

By Anthony Frey  At first glance, deploying enterprise applications over a corporate intranet looks ideal because the browser is a ready-made, standards-based thin client. But the HTTP servers running behind them make a poor platform for running application servers. DTP (distributed transaction processing) monitors can be the perfect solution to this problem. DTP monitors create synergy with the Web server, providing robustness and scalability precisely where it needs it the most--at the application layer. The most difficult aspect of developing an application for the Web once was integrating it with corporate databases. Today, this capability is frequently built into the Web server. Now the problem centers around performance limitations such as those found with the HTTP protocol and CGI. DTP monitors complement Web servers well because they enable application logic to be further isolated from the Web server and its processing of client sessions. Our recent review of DTP monitors gave us an opportunity t o illustrate this union (see "Four DTP Monitors Build Enterprise App Servers," at www. NetworkComputing.com/820/820r1.html). For our investigation we stacked BEA Systems' TUXEDO System/T and Jolt next to Microsoft Corp.'s IIS (Internet Information Server) 3.0 in our lab at the University of Wisconsin. BEA's products represent two strategies for integrating DTP monitors and Web servers. Other DTP systems have similar strategies, and the techniques used here also will apply. DTP Monitors Using CGI The first strategy we followed used the traditional Web server-CGI approach. CGI running on the Web server acted as a client to our TUXEDO application servers, communicating via TUXEDO's built-in messaging layer. In most cases, CGI simply dispatches a function request to one of the application servers for processing. But CGI performs all of the necessary formatting of HTML output, which is ultimately sent to the browser client. This fits neatly into the three-tier model because CGI is only responsible for " presentation" logic. The test configuration we used is depicted in "DTP Monitor Architecture Using CGI" on page 154. We used Microsoft's IIS 3.0 running on a Pentium Pro 200 with 128 MB of RAM; because the data model for our application did not require a distributed database, we could get by with a single RDBMS (relational database management system). Our database of choice was Oracle7.3 running on a Hewlett-Packard Co. HP 9000/817. Finally, we ran the TUXEDO System/T on two SPARC application servers from Sun Microsystems. These were configured in a single administrative domain that let us load-balance application requests across the two. To develop this application, we employed the same banking application used in our DTP testing. Deploying DTP applications in a Web environment is primarily a client-development issue because TUXEDO applications are defined in terms of a set of services, similar to function calls. All Is Not Roses While designing this application, we discovered that many of t he deficiencies inherent in the HTTP protocol and CGI continue to plague CGI-based DTP integrations: These implementations are slow, consume many CPU resources and have a difficult time maintaining state. You might think that the transactional capabilities of DTP monitors would ease the burden of tracking a transaction across multiple Web pages. This is not so because transaction tracking is primarily a state-maintenance issue and not a transactional integrity issue. In order to complete a deposit or withdrawal with our banking application, you need to maintain a virtual session between the time the user is authenticated and the time she submits her action. This can be accomplished by exchanging cookies with the browser (or by watching the user's IP address).

Other Workshops Remote Control: Let Your Browser Do the Walking By Mike Fratto