he instructions on the screen about where to send a check, and then fax a note to your agent, saying that you've switched your coverage.
You weren't the only visitor to CHI's Web site at that moment. In fact 1000 other people concurrently strained the capacities of CHI's 20 Web servers and 10 database servers as they looked for a way to save money. You all saw quick response times because CHI used a transaction-processing (TP) monitor -- specifically, Microsoft's Transaction Server -- when it designed its Web-based insurance-quoting application.
Transaction Server is software that doesn't help you enter data, nor does it store any data or calculate results. And yet you would be hard-pressed to implement a large, complex client/serve
r application without using a product like it. Middleware -- the category of software that includes Transaction Server -- ensures transaction integrity, balances application work loads across multiple servers, and enforces appropriate, secure access at the application and transaction levels.
To explore Transaction Server fully, I developed a hypothetical car-insurance-quoting application and exercised it in an intranet environment. The application has all the essential ingredients for use with a TP monitor: three-tier architecture, the need to synchronize database updates, a thin-client presentation layer, and the potential for high-volume access.
In general, the experience taught me that multiple-server distributed applications absolutely require middleware -- without it, developing large-scale applications is a horror show. I also discovered what makes Transaction Server in particular a worthwhile package and also stumbled across a few of its shortcomings. For example, before you can use Transac
tion Server, you must first render your application's business logic as an ActiveX component. Once you switch to (and learn) ActiveX, however, declaring transactions within Transaction Server and then at run time -- letting it manage those transactions -- is painless.
Requiring NT Server 4.0 and only 32 MB of RAM, Transaction Server integrates nicely into organizations that have already decided to use Microsoft products. Mixed-platform environments, such as those using Oracle's database manager, have more work to do or must wait until Microsoft makes Transaction Server work with more database managers, languages, and platforms.
Why Bother with Middleware?
Middleware helps you build high-volume business applications that can run on several applications servers and update multiple database servers. Thousands of clients, through a battery of Web servers, might use such applications simultaneously. Business-logic analysts and programmers have neither the time nor the expertise to cr
eate the transaction-oriented, network-based architecture these applications require for everyday use -- they have enough work to do automating business procedures and rules.
Middleware, and TP monitors in particular, give programmers the plumbing -- the intra-application network linkages and services -- that enables a distributed application to service a large number of clients. A three-tier application (with separate presentation, business-logic, and data storage) is a prime candidate for the sort of control and coordination that middleware provides.
As it manages interactions among the three tiers, middleware balances the work load among the servers, enforces transaction-level security, dynamically routes messages, and ensures transaction integrity across multiple databases. Because you configure your middleware with information about which database servers are equivalent copies of each other, it can monitor server activity and send transaction requests to less-busy servers. If a database serve
r fails, the middleware queues the SQL request and delivers it when that server returns to the network.
Alternatively, middleware can reroute a message to a different database server that (as you've designed) is a replicated copy of the failed server. Without skipping a beat, the system continues to process transactions that don't need access to the failed server. Some middleware products can even route HTML and other Web traffic to less-busy servers, thus making response times even shorter.
The Field
Middleware categories include, in addition to TP monitors, DCE/RPC environments, messaging, database-access tools, and object-oriented approaches. A TP monitor brackets developer-defined application operations (i.e., transactions) with implied BEGIN TRANSACTION and END TRANSACTION SQL statements. By using TP-monitor services, applications do not have to specifically provide for transaction integrity. Besides Microsoft's Transaction Server, TP-monitor products include BEA's Tuxedo,
IBM's Transaction Server (formerly CICS for OS/2, CICS for NT, and CICS for AIX), Kiva's Enterprise Server, and Visigenic's VisiBroker.
BEA offers Java programmers transaction services with its Jolt product, a collection of class libraries and functions that complement the Tuxedo middleware product. Jolt also replaces HTTP with its own Jolt Transaction Protocol, which gives Jolt-based Java programs extra capabilities beyond the limited, document-presentation-oriented HTTP. Visigenic's VisiBroker is a CORBA 2.0 object request broker (ORB). It uses the IIOP protocol for interprocess communications between network nodes and supplies an IDL-to-Java code generator. Kiva's product is specially designed for the Web, while IBM's middleware products connect more computers and applications in more diverse ways than any others on the market.
Microsoft Transaction Server, like most other TP monitors, has a proprietary API. While other vendors plan to implement the new X/Open standard APIs in the future, Micro
soft intends to stick with its ActiveX component model and simple calling conventions. Transaction Server adds just two new APIs,
GetObjectContext()
and
SafeRef()
.
The Middle of the Road
My hypothetical car-insurance-quoting application is a J++ ActiveX server component. It collects data from a prospective customer through a series of Web pages, retrieves and updates a series of database tables, and calculates the price of the car insurance. Note that the rates are not actual insurance rates, and, for the sake of simplicity, I didn't code a function to communicate automatically with individual states' motor-vehicle departments to verify driving records.
An
Active Server
Page VBScript entry in the HTML code of the data-entry Web page invokes the J++ program, which I defined as a "transaction" using the graphical Transaction Server Explorer. The three database tables I designed hold fictional insurance rates for each of the 50 states, adjust
ment factors for the make and model of the car being insured, and driver (i.e., customer) information. I replicated the database tables across all the servers in one test. In another, I distributed the tables unevenly among the servers, forcing Transaction Server to decide which updates completed successfully and which did not as I altered the availability of database servers.
In the lab, I set up a LAN consisting of 25 desktop computers connected via 10-Mbps Ethernet. I used 15 Windows 95 clients and 10 NT 4.0 servers to exercise Transaction Server. The servers acted as Web servers (using Internet Information Server [IIS] 3.0) and as database servers (using SQL Server 6.5). Not a stress test, this nonetheless gave me a good idea of what Transaction Server can do.
How It Works
The Transaction Server environment consists of base processes (client programs, such as the Netscape Navigator and Microsoft Internet Explorer [MSIE] browsers); application components (implementations of b
usiness logic, which have to be rendered as ActiveX components); the Transaction Server Executive (which manages transactions and provides services to application components); resource dispensers (distributors and controllers of the shared resources, such as database connections); and a resource manager (the database manager itself). With its support for ODBC, Transaction Server should be able to work with any resource manager that offers ODBC connectivity, and Microsoft plans to add Extended Architecture (XA) support in a future version of Transaction Server. It will provide this support in the form of an XA-to-ODBC mapping layer that exposes ODBC functions and procedures through the XA interface.
Functionally, Transaction Server acts as a transaction clearinghouse on busy, complex networks. It manages low-level OS resources (e.g., processes and threads), thus allowing concurrently running clients to access server applications. Transaction Server synchronizes the access to multiple databases, lessening
the effect of busy SQL message traffic as it routes transactions to applications servers and database servers.
Transaction Server supports (and requires)
ActiveX
, has a simple programming interface for hooking into your application, and offers just-in-time instantiation of object components.
Just-in-time instantiation
refers to Transaction Server's delaying the removal of an object's methods from memory for a short while, in case another subsequent transaction might happen to use that same object.
Transaction Server 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. This repository lets programs share global variables among themselves as if they were a single process. The application components that Transaction
Server manages
are location-transparent, so they can reside virtually anywhere on a network; the application
doesn't have to keep track of which server, drive letter, or directory structure contains them. Transaction Server hides these messy details from the business-logic programmer.
Transaction Server Explorer, a management tool with the look and feel of the file-and-folder-oriented Windows 95 Explorer, is the tool that programmers use for declaring packages, inserting components into each package, and giving the packages and components the appropriate attributes. Through the Transaction Server Explorer user interface, programmers can easily monitor activity levels,
manage transactions
, configure transaction support, establish security, and create transaction packages.
Transaction Server controls security at both the process level and the component level. By simply right-clicking on an object and then selecting Properties in the object's pop-up menu, you can assign process-level security and enable interface-authorization checking (as you insert a component into a package) with T
ransaction Server Explorer's point-and-click hierarchical interface.
TP is only one part of the Transaction Server programming model. Packages whose objectives do not include TP can still take advantage of the package's Distributed Component Object Model (DCOM) and the process-level security system. In these situations, Transaction Server manages object instances and object lifetimes.
How Did It Fare?
In my tests, I found that Transaction Server distributes application work loads (i.e., transactions) evenly across servers and reacts appropriately to the sudden removal of servers. Incorporating Transaction Server into the J++ program was a simple matter.
Through the pool of threads it maintains, Transaction Server handles the management of processes and threads and isolates them from one another. In contrast to classic intra-application thread management (in which a programmer hand-codes the creation, allocation, and termination of threads), Transaction Server's automatic t
hread pool keeps application components from having to be thread-aware, and programmers no longer have to program thread management into the business logic.
But you cannot mix threading models in the same package: If one component in a package is single-threaded, they all must be single-threaded. Components with different threading models cannot be part of the same transaction within a single applications-server process. I discovered this restriction when I tried to mix Visual Basic and Visual C++ components in the same package. I had to declare the Visual C++ components as single-threaded (or put them into a separate package, which is easy to do).
One View
Distributing transaction work load and ensuring transaction integrity are the two biggest problems applications designers face as they work to scale applications for high-volume use. Microsoft's Transaction Server addresses precisely these problems, and it does so in an easy-to-configure, easy-to-manage, point-and-click manne
r.
I had ambivalent feelings about Transaction Server's requirement that business logic be rendered as ActiveX components. On the one hand, Microsoft's Transaction Server architecture and its OLE Automation model go together naturally. On the other, the ActiveX requirement may mean slower adoption of Transaction Server as applications programmers wrestle legacy business logic into ActiveX form.
Fortunately, ActiveX-language support from compiler vendors is, by the time this article sees print, either here now or on the near horizon. Microsoft's own language products (C++, Visual Basic, and J++), of course, can be used to create ActiveX components, and Microsoft even includes Wizards to help you get started. Other vendors -- notably Borland (Delphi, C++ Builder), Powersoft (PowerBuilder, Optima++), and both Microfocus and Fujitsu (COBOL) -- are currently working on similar Wizards and verifying that their compiler products work well with Transaction Server.
The future of Transaction Server ho
lds more in store than an XA interface for database access. Microsoft plans to embed Transaction Server into NT Server 5.0, and the company says it will rearchitect IIS to be transaction-oriented. For example, you will someday be able to mark a Web page that uses Active Server Page technology as a "transaction" and have IIS automatically manage the resulting database accesses in an atomic fashion.
Especially with respect to object-orientation and components, Microsoft believes it's jumped in front of the TP-monitor marketplace with Transaction Server. BEA, IBM, Oracle, and other middleware vendors disagree with this assessment. For my part, I think Microsoft has taken a big step toward supporting enterprise-level, run-your-business-on-it vertical applications, an arena in which Microsoft does not have much experience.
As it gains experience with enterprise-level business automation, I expect Microsoft will release other products it hopes that major companies will incorporate into their core data-p
rocessing efforts. However, I doubt Microsoft will see the benefit of producing a Transaction Server product for non-NT platforms.
Editor's Note:
You can download the sample code from the BYTE Site at
http://www.byte.com/art/download/download.htm
(jquote.zip).
Balance the Load with Transaction Server
