The Middleware Muddle1

Application servers and TP monitors are finding new life on the Net.

David Ritterdhr@webmine.com

1 This article originally appeared in the May 1998 issue of DBMS. It is reprinted with the permission of thepublisher, Miller Freeman, Inc. Recently, DBMS and Database Programming and Design magazinesmerged into a new publication, entitled Intelligent Enterprise (http://www.intelligententerprise.com).

A new menagerie of middleware is emerging.These products promise great flexibility inpartitioning enterprise applications across thediverse corporate computing landscape. Whatfactors should you consider when choosing asolution, and how do current products stack up?More important to the focus of this article, whatrole should Web servers play?

What’s What

These days, “middleware” describes anysoftware component that sits between applicationusers at their PCs and the RDBMS or legacysystem that directly manages underlying data.This term, like many others in the field, isapplied so broadly that it’s lost its meaning. Tohelp sort things out, I’ll propose some morespecific categories. Still, these things are rarelyclear cut — the functionality of a particularproduct may cut across several layers.

I’ve ordered the categories from simple tocomplex. Some middleware just provides amechanism for data to get from place to place.More sophisticated offerings help manageapplication logic and resources. The most robusttools directly support significant applicationfunctionality, such as credit card transactions fore-commerce. This article focuses on the morecomplete offerings, but I’ll also offer somebackground on the basic plumbing.

Database Transparency

If you’re dealing with multiple database systems,a common access API is almost essential. Thisallows the use of standard tools and greatlysimplifies the application development process.The most visible examples of APIs for databasetransparency are Microsoft’s ODBC, OLE DB,and ActiveX Data Object (ADO) interfaces. ForJava developers, JDBC is gaining acceptance asa common database access interface. In the C++

world, RogueWave Software’s DBTools++ has awide following.

IPC and Objects

These protocols and products facilitateinterprocess communication (IPC) and objectdistribution. They form the basic glue that holdsmultitier applications together. Most of thehigher-level products I’ll discuss use one ormore of these underlying protocols. The keyplayers are:

• Remote Procedure Call (RPC) and itsJava equivalent, Remote MethodInvocation (RMI). Essentially, theseprotocols allow your application to callfunctions and pass parameters acrossprocess and machine boundaries. They’reusually synchronous, meaning that eachoperation is completed before the nextoperation begins. These services areprovided by the operating system orlanguage development environment. RPC isusually based on the Distributed ComputingEnvironment (DCE) infrastructure.

• Messaging systems. In contrast, messagingsystems are typically asynchronous.Requests for services are queued andprocessed according to priority and theresource availability, and responses arereturned to the requester to indicate thesuccess or failure of the operation. They’reoften used for workflow and process-controlapplications, as well as for WANapplications with slower, less reliableconnections.

• Distributed object systems. Object systemsprovide facilities for locating and interactingwith objects in a distributed environment.Objects are identified by name or by theservices and interfaces they support. Theimplementation of the object and theplatform on which it runs are transparent tothe client.

War rages in this area. On the surface, it’sMicrosoft’s Distributed COM and ActiveXtechnologies vs. the Object ManagementGroup’s combination of CORBA, the InternetInter-ORB Protocol (IIOP), and JavaBeans.More deeply, this battle reflects the strugglebetween the openness, maturity, and scalabilityof Unix and the growing Microsoft NTjuggernaut. Interoperability between thesestandards is emerging slowly, but it has yet togain the confidence of either camp. What’s yourreligion?

Objects are the real currency of modernmultitiered applications. All higher-levelproducts discussed here focus on themanagement of objects in ever more completeways. Planning your enterprise strategy in termsof objects and components will allow you to bestleverage this rapidly emerging technology.Judith Hurwitz provided a round-up of productsat this layer in her DBMS article, “Sorting OutMiddleware” (January 1998, page 10).

Transaction ProcessingMonitors

Simply put, heavy access to shared resourcesleads to bottlenecks that prevent work fromgetting done. Many early forays into client/servercomputing at the enterprise level fell flat as theresult of inadequate database resourcemanagement. Early attempts to use RDBMSs todrive dynamic content on the Web met a similarfate for the same reasons. In many cases, itwasn’t the actual processing of the SQLstatements that caused the problem. Theslowdowns resulted from inadequate databaseconnection management and ineffectiveapproaches to caching.

Beginning with IBM’s Customer InformationControl System (CICS, pronounced “kicks” bywar-torn veterans) in the early 1970s, systemshave been developed to provide databaseresource and transaction management forapplications. The success of these products isclearly demonstrated by the fact that of the top20 TPC-C benchmark results (ranked bytransactions per minute as of February 2, 1998),every single test environment included adatabase middleware technology. If the sameresults are ranked by price/performance, 18 of

the top 20 used a TP monitor (sources:www.tpc.org andtuxedo.novell.com/action/tpc.htm).

TP monitors evolved out of these needs andothers:

• Many organizations use more than onedatabase system, and business needs call fortransactions to be performed that span acrossthem.

• Many database systems require an entireoperating system process per connecteduser. For applications with hundreds ofusers, even the largest hosts areoverwhelmed.

• Establishing a connection to the database isfrequently slow. With many usersconnecting and disconnecting frequently,system performance degrades severely.

• TP monitors attack these problems by:• Offering connectivity to a variety of

different database systems simultaneously.• Providing a two-phase commit protocol,

which guarantees the completeness ofdatabase transactions across multipledatabases.

• Processing user requests using lightweightoperating system threads, rather than fullprocesses. This allows TP monitors toexploit today’s SMP systems, such as theSun Enterprise, Digital Alpha, and CompaqProliant.

• Maintaining a persistent pool of databaseconnections and sharing them across users.In most applications, each user is actuallyaccessing the database for only a fraction oftheir total time online. Often, hundreds of“simultaneous” users can be efficientlyserved by one-third or even one-tenth thenumber of database connections required fordirect access.

• Keeping shared database connections openover long periods, dramatically reducing theamount of connection traffic.

• Load balancing, which involves measuringthe usage of shared resources and directingrequests to the least-used servers. Monitorscan also detect and act on situations where aserver or other resource has failed and needsto be restarted.

• Managing requests asynchronously,distributing multiple requests over separatedatabase connections to the same server(known as pipeline parallelism).

• Distributing requests over multiple databaseservers. This technique is known as fan-outparallelism.

• Communicating peer-to-peer with othertransaction processing monitors tocoordinate the operation of partitioned anddistributed applications.

The advent of TP monitors has led to someinteresting questions about how databaseproducts are licensed. Most vendors, includingOracle, Sybase, and Informix, license theirproducts on the basis of the number ofconnections. The more simultaneous connectionsto the database, the more you pay. But with a TPmonitor, many users may share a small numberof connections. Does this mean you can get abargain on your RDBMSlicense? Probably not — the major vendors nowtake this into account and require pricing to bebased on the number of actual users connecting,regardless of whether they use middleware.

This discrepancy is especially painful for Web-based applications, where there are oftenmillions of users. In many cases, the interactionof these users with the database is very limited.For example, a Web site that uses a databaseonly for user registration might need only 10pooled databas

e c

onnections to serve the entirepopulation. Still, the RDBMS vendor willtypically require a license to support anunlimited number of users. On Unix systems,these licenses can run hundreds of thousands ofdollars. This pricing consideration is helpingdrive Web applications to Windows NT, and itwill dramatically affect the margins and platformconsiderations for RDBMS vendors in thecoming months and years.

In the open systems arena, BEA Systems’Tuxedo leads the TP monitor category. Spun outfrom Novell in February 1996, this robust andmature TP monitor product was used inapproximately 80 percent of the TPC-C resultsmentioned earlier. It was the 1997 DBMSReaders’ Choice winner for best TP monitor, andit’s also incorporated into major turnkeyapplication offerings such as PeopleSoft. Othersignificant TP monitor products include:

• Transarc Encina (1996 DBMS Readers’Choice winner)

• IBM Transaction Server products (includesCICS and Encina)

• Digital ACMSxp

• NCR (distributed by Entersoft)• Microsoft Transaction Server (MTS)

Object Integration

Some TP monitors deal effectively with objects.Microsoft Transaction Server is notable in thisrespect. It has strong integration with DCOM;essentially, any ActiveX object can be managedand cached by MTS. This makes applicationpartitioning much more straightforward becauseexisting components built with Visual Basic,C++, or J++ can be easily relocated to the server.MTS keeps the object “alive” for reuse,eliminating the need to re-create instancescontinually to service new requests. MTS is (forobvious reasons) bound tightly to Windows NT,but its robustness and low cost make it veryattractive. Microsoft has done an excellent job ofintegrating Java and ActiveX — all Java objectsare automatically exposed. This eases theintegration of MTS into a multiplatformenvironment.

On the Unix side, the Object Transaction Server(OTS) specification from the OMG is intendedto unify TP monitor functionality with objectrequest brokers. This extension of the CORBAprotocol is reflected in JavaSoft’s JavaTransaction Service specification, which madeits commercial debut in February with theSybase Jaguar Component Transaction Server.

Another emerging standard to be aware of whenevaluating TP monitors and application servers isthe Transaction Architecture (XA), aspecification developed by The Open Group(www.opengroup.org). XA defines the interfacebetween a transaction manager and the resourcesit uses, such as database systems andcommunication channels. Most major Unix TPmonitors and database systems support thisstandard. Windows NT support lags but isreported to be on the way for MTS.

You also should consider the underlyingcommunication protocol used by the applicationserver. Servers that are strictly tied to RPC (orDCOM in the case of MTS) may be limited bythe synchronous nature of the plumbing.Products that allow the use of queued messagesmay offer more flexibility, especially over aWAN. For example, Encina can use IBM’sMQSeries middleware. Microsoft has indicatedthat integration of MTS and its MessageQueuing Server will happen in later versions.

Application Servers

If TP monitors do all that, what’s left?

While TP monitors are effective tools for large-scale OLTP, they generally don’t have facilitiesfor:

• Hosting and managing application logic• Locating and instantiating objects (name

services)• Caching objects and controlling object

lifetimes.

Developing multitiered applications is all aboutpartitioning, which is the division of laborbetween the client and one or more specializedservers. Application servers facilitate partitioningby allowing the components of the application tobe moved to the architectural level and physicalplatform where they can work most efficiently.Need to run a forecast against a 10GB databasewithout having sales operations grind to a halt?Implement a component that runs in the middletier on a system with lots of CPU and memorybut not much disk. Need to turn the results intonice graphs? Let your hundreds of PCs do thatwork in a really distributed fashion, on eachuser’s desktop.

An application server supports the definition ofapplication logic. Some servers provide theirown development tools and languages for thispurpose. Others rely on object standards such asCORBA, COM, or JavaBeans. In almost allcases, the application logic needs to beencapsulated as one or more objects. Theseobjects expose their capabilities through methodsthat can be invoked by the application codedirectly or by other objects.

Given the flexibility of modern RDBMSs, it’stempting to put significant amounts ofapplication logic directly into the database in theform of stored procedures. Except for basicreferential and data integrity constraints, this isgenerally a bad idea. For most applications, thedatabase server throughput is the most preciousresource. If the server is performing anapplication-specific task for one resource-hungryuser, it’s unavailable to serve the needs of allother users. It’s better to partition this work sohardware resources can focus more accurately onthe neediest activities.

Until recently, most application servers weretightly bundled into enterprise applicationdevelopment platforms. Fort Software providesa leading example. The Fort product lineincludes complete GUI development tools,database connectivity components, anddeployment facilities. All of these are builtaround a robust application server. (See Figure 1,page 48.) The designer creates the application asthough it were to run all on one machine, andthen it uses Fort ’s partitioning tools to dividethe work between the client and applicationservers. Unify Corp.’s Vision also follows thismodel.

Until the end of 1995, this class of high-endenterprise tools was a fairly well-understood andmature category. Then the Web happened.

Plain Old Web Servers Aren’t SoPlain Anymore

Web servers are for Web sites, right? Yes, butincreasingly, they also serve a more general rolein the enterprise. The new generation ofapplication server products is heavily biasedtoward the Web. They leverage Web protocolssuch as HTML and HTTP, and they use the Webbrowser as the primary client environment.

The definition of the Web server platform haschanged dramatically in the last 18 months. Thisis being driven by the fierce growth of the Webas an information and commerce platform. Whilegood numbers are still hard to come by,anecdotal return on investment analysis ofintranets shows costs savings of many millionsof dollars, especially in areas such as sales andcustomer support. Many businesses expect Webcommerce to make up an increasing percentageof their overall sales. For example, JohnChambers, CEO of Cisco Systems, said that hiscompany’s Internet commerce and intranetsystems are saving the company more than $250million each year. Their Web site handlesapproximately 40 percent of their sales, for aprojected total of $3 billion in Web sales in1998. (Source: John Chambers at Comdexkeynote speech in November 1997.) SAPresponded to this trend by joining Intel in aventure (named Pandesic) to bring theirenterprise applications to the Web.

On the technical side, this growth is facilitatedby a critical mass of standards, such as HTTP,SSL, and Java. These standards are embodied inthe Web server, which acts as a focal point forthe integration of new tools and technologies.Table 1, shows this remarkable progression offunctionality.

These products are only examples. The range ofvendors and tools that enable the Web as anapplication platform increases daily, and theexisting products continue to improve. Alongwith this explosion on the server, the capabilitiesof the Web client have improved in parallel.With the growing maturity of client-sideJavaScript, Java run times, Dynamic HTML, andActiveX, Web applications need no longer sufferfrom the primitive, limited user interfacepresented by older HTML offerings.

The key players in this new space come at themarket from different angles. From the RDBMSvendors, we have database-centric applicationservers such as Oracle Web Application Serverand Sybase Jaguar CTS. From the Internet and e-commerce fields come servers focused onintegration with Web servers, EDI, andelectronic payment systems. Leading products inthis field include Kiva (recently acquired byNetscape), InterWorld Commerce Exchange,Dynamo from Art Technology Group, andNovera EPIC.

Some of the new offerings draw heavily on theFort xample, although none offers the samelevel of seamless partitioning support. They doincorporate their own development tools andproprietary technologies in an effort to present acomplete, fully integrated solution. ProgressSoftware’s WebSpeed (reviewed in theNovember 1997 issue of DBMS, page 33) offerstransaction services, tight integration with theProgress database, wizards and templates, and aproprietary scripting language. It opens the doorfor the use of Java for application componentsand access to any ODBC-compliant database.

SilverStream (reviewed in the March 1998 issueof DBMS, page 29) was developed by many ofthe same people who brought us PowerBuilder,but it is targeted squarely at Web applications. Itoffers a slick set of user interface, object, anddatabase design tools. The heart and soul ofPowerBuilder, the DataWindow, has beentranslated very well into the new environment.

The scripting language is Java, so the learningcurve should be short for most developers. Theapplication server manages the execution ofagents, which can run in response to databaseupdates, at scheduled times, or at the request ofapplication code. Agents can process data setsretrieved from the database on a row-by-rowbasis to provide procedural filtering.

Because it tries to do so much, the initial releaseof SilverStream comes up short in some areas.All its application components are stored in thedatabase in an opaque format, reducing theflexibility and openness of the environment.External Java class libraries aren’t easilyincorporated. The user interface class librariesdon’t conform to any of the AWT, AFC, or JFCstandards. The application server lacks fault-tolerance features, and the absence of a scriptdebugger is very problematic. GivenSilverStream’s depth of experience andmomentum, it’s reasonable to expect that theproduct will improve rapidly.

Upsides and Downsides

With all of these products, Java emerges as aclear winner. All products offer Javacompatibility at some level. Many, such asDynamo and Novera EPIC, are based on Javafrom the ground up. As noted earlier, evenMicrosoft has good Java support. If you’researching for the development language that willgo the farthest to span multiple platforms,promote reuse, and operate effectively on boththe client and server tiers of your architecture,Java is by far the best bet. Implementations arematuring rapidly, and early performanceproblems are quickly yielding to better run timesand faster CPUs.

Beans are to Java what ActiveX is to COM.They provide a model for components, includingevent handling. Until recently, the JavaBeansmodel has been most commonly used to packagevisual controls for client applications. But thenext major step in Java’s drive to become anenterprise standard comes with JavaSoft’sintroduction of Enterprise JavaBeans (EJB). Thisextension focuses on specialized, nonvisualBeans for the server. The Enterprise JavaBeanexecution environment provides thread poolingand implicit transaction management. (SeeFigure 2.) An impressive list of TP monitor and

application server vendors have indicatedsupport for this component model. Some willhave products ready to ship when the EJBspecification is finalized. Unfortunately,Microsoft is currently absent from the list. Still,the wide adoption of EJBs promises to enable thebroad reuse of application components.

What’s the downside to using a Web server as atier in an enterprise application architecture?There are several issues:

• HTTP isn’t ideally suited for client/serverapplications. It’s stateless, meaning thatthere’s no persistent connection to theserver. This means that state information hasto be included in every request, generally ata significant performance penalty.

• The frantic pace of development has led tosome shaky product releases withquestionable quality.

• The reliability and performance ofJavaScript and Java executing within theWeb browser are still poor. This has ledWeb application server vendors such asSilverStream to offer dedicated client runtimes for executing applications. Thissolution is reasonable, but it defeats onemajor promise of the Web platform, namely,not needing to install custom software on theclient.

• Dynamic HTML (DHTML) and the user-interface class libraries for Javadevelopment aren’t standard yet. If yourapplication requires any advanced userinterface features, you’ll probably need torestrict your users to a specific browservendor and version.

• Within the Web browser, Java is“sandboxed.” Without permission from theuser, downloaded Java can’t write to thePC’s disk or perform other potentiallydestructive actions.

Choose Your Weapons

For today’s enterprise applications, flexibleresource use is a key to success. Buildingcomponent-based applications will let you usethe latest application server technology to meetthese challenges. These products have finallymatured to the point that it’s no longer necessaryto build your own glue, transport mechanisms,communication protocols, or database

connectivity, even for very demandingapplications.

For the most resource-intensive applications,dedicated TP monitors offer the highestperformance. For applications involving morecomplex rules and logic, more generalapplication servers provide an excellentframework. In any case, the bulk of the newtechnology is converging around Web standards.Developing in Java will open a wide range ofchoices for partitioning and deploying yourapplications. In the Unix world, there is a rich setof products based around CORBA and Java. ForWindows NT, expect Microsoft’s MTS and itssupporting cast to dominate. Selecting a vendorwith a strong commitment to standards and openarchitecture is the best insurance in this time ofrapid change.

David Ritter is the principal of WebMine, aBoston-based consulting practice focused oninformation and technology solutions for Internetbusiness. He was previously the vice president ofengineering at Firefly Network and managed thedevelopment of OLAP client products for OracleCorp. He has spoken widely on topics rangingfrom data warehousing to Internet privacy. Youcan email David at dhr@webmine.com.

Web Platform Features CapabilitiesCommon Gateway Interface (CGI) Handles full requests with separate server processes;

slow and difficult to program; no built-in databasesupport.

Server APIs: Netscape NSAPI; Microsoft ISAPI Handles full requests with in-process libraries;much faster, but even more difficult to program; nobuilt-in database support.

First-generation scripting environments:Netscape LiveWire; Microsoft Active Server Pages(ASP); Apache with Java Servlets; ColdFusion;WebObjects

Integrated with HTML, allowing incrementalextensions to pages; high-level scripting inJavaScript, VB Script, or Java speeds development;some performance problems due to script execution;some object and database support; very limitedsecurity.

Second-generation application environments:LiveWire plus LiveConnect and Borland/VisigenicORB; ASP plus ADO and MTS; Apache withCORBA and JavaBeans; SilverStream 1.0; ProgressSoftware WebSpeed

More generalized object support; Java and CORBAintegration; database connection pooling; bettercaching and precompilation improves performance;better security with 40-bit SSL.

Third-generation enterprise and commerceenvironments: Netscape with Kiva ApplicationServer and Actra commerce servers; Microsoft SiteServer 3.0 with Active User Object, MTS 2.0, andMerchant Server; Open Market LiveCommerce andTransact

Sophisticated database resource pooling and objectcaching; integration with knowledge and contentservers; extends into more vertical application areas,such as user registration and profiling; high-enduser-to-business and business-to-businesscommerce functionality; integration with back-endpayment systems; more extensive security with 128-bit SSL and digital certificates.

Table 1. The progression of Web platform functionality.

Figure 1. The Fort WebEnterprise architecture. Courtesy of Fort Software Inc.

Figure 2. The Enterprise JavaBean executionenvironment. Courtesy of JavaSoft division of

Sun Microsystems Inc.