A variety of products can connect Web clients to data and application services over the Internet and Intranets.
In all but the most homogeneous computing environments, system architects use middleware products to enable interoperability between products that otherwise would have no common lingua franca. Ironically, however, in so-called open systems environments, frequently the only glue enabling these heterogeneous components to communicate is itself sometimes a proprietary product. These proprietary solutions can present the architect with a Hobson's choice between proprietary solution with optimized performance and an "industry standard" solution with possible lowest-common-denominator performance. In this article I focus on transactional middleware for Web database applications and consider the tradeoffs each solution imposes.
Defining middleware is not unlike defining obscenity: I may not be able to define it precisely, but I know it when I see it. Thus, one of the best ways to define middleware is by example, and that is what I will do in this article: I'll provide some examples of middleware products and show how they can solve certain classes of interoperability problems, especially those that involve the Internet or an Intranet.
Although it's difficult to provide an all-encompassing functional definition of middleware, it's relatively easy to define middleware in abstract terms. Generally, middleware sits between clients and servers, and it communicates with both using an application programming interface (API), which programmers on both ends use for requesting or receiving services and data. Thus, to enable Client A to talk to Server Z, an enterprise architect may install Middleware M and provide the API to programmers supporting both A and Z. A can now talk to Z, with M mediating the conversation between them. But why not just rewrite A so that it speaks Z's language, or add an A interface to Z? The answer is that as the number of disparate client and server types grow arithmetically, the number of interfaces grows exponentially. Middleware then becomes not a nicety but a necessity.
Middleware addresses two basic interoperability needs: services and data. Service-oriented middleware such as CORBA addresses the system architect's need to enable message communication between systems which would otherwise have no common language. By using an object request broker (the central technology of CORBA), a system can request object services from another without knowing anything about messaging other than what the ORB requires. Data-oriented middleware, by contrast, is designed to make life simpler for database administrators who need to make a given DBMS server, or several such servers, interoperable with a variety of clients. By using ODBC, arguably the most prevalent form of data middleware, system architects can have developers working on clients and database administrators working on servers use the common ODBC API to transparently resolve any differences among the data formats and commands expected by each vendor.
Middleware is not a panacea, however. Whenever you introduce data translation of any kind, you are introducing a bottleneck that can - depending upon the product and the environment - significantly impact performance. The specifications of a product might make it read like it's the greatest thing since sliced bread, but that's no guarantee that it will perform so well in your environment. Just as with database benchmarks, the numbers are meaningless until validated by your experiences in your environment. With those requisite caveats established, let's look at some interesting middleware products for Web architects.
The JAM/WEB server can be configured to access a wide variety of DBMSs, including Oracle, Informix, Sybase, and Microsoft SQL Server, and transactions can be spanned across multiple databases from different vendors. Of course, JAM/WEB does not itself serve as a transaction-processing monitor, so applications that span multiple DBMSs cannot be rolled back as one transactional unit. For application developers seeking true two-phase commit capability spanning multiple databases, Jyacc offers an interface to Tuxedo. Tuxedo, a transaction-processing monitor originally developed by AT&T's Unix System Laboratories and then sold to Novell, is now marketed and developed by BEA Systems Inc.
VMark Software, a database vendor that markets the Unix database UniVerse, also offers a middleware product - HyperStar - and application development tool, the Web Developer's Kit (WDK). You can use the WDK to develop applications that query not only UniVerse databases but also Unix databases from Oracle, Informix, Sybase, and CA-OpenIngres. Prior to the release of the WDK, you could develop HyperStar client applications only using Excel, Visual Basic or other products that support ODBC. With the WDK, developers can now access supported databases via Web browsers.
As with JAM/WEB, both ODBC and HTML HyperStar clients access the supported databases through central servers, but unlike JAM/WEB, HyperStar requires a separate server product for accessing each vendor's database. VMark optimizes communication between HyperStar database servers and their clients using what the vendor refers to as object messaging technology, which supports caching, pipelining, and message packing, but CORBA compliance is not specified.
Another tool that incorporates direct access to database structures is the NetDynamics Application Server from NetDynamics Inc. (formerly Spider Technologies Inc.), which offers lightweight (not message-based) middleware capabilities for Web developers, including cached database connections and an optimized interface to Netscape NSAPI, Microsoft ISAPI, or any standard CGI. The NetDynamics Application Server also offers automatic load balancing for multiple connections to Informix, Sybase, Oracle, and ODBC-compliant databases. In addition to load balancing, NetDynamics applications can be written to provide continuous connections to target databases, which lets programmers bypass the ordinary stateless nature of CGI applications. NetDynamics server applications are built using a Java-based visual development tool, and they run on Windows NT as well as Sun Solaris, SGI Irix, and HP-UX. Applications may be built using any HTML editor and are compatible with any Web browser.
Other ODBC products attack middleware needs from other directions. Ensodex's HotSockets and DataRamp Inc.'s DataRamp enable ODBC client applications to access database servers over any TCP/IP network - including, of course, the Internet. XDB's JETConnect provides an API to a set of Java classes that you can use to build ODBC-compliant applications. Intersolv offers a similar ODBC-enabling product, JDBC/ODBC DataDirect Bridge. As the name implies, the Intersolv product brings the company's extensive experience in writing the DataDirect ODBC driver products to Java application developers.
For those developing Macintosh-based Web servers, EveryWare Development Corp. offers Tango, a tool that provides ODBC connectivity. As with several other tools mentioned in this article, Tango consists of a form-building environment for editing HTML pages and a CGI server that provides interfaces to databases such as Oracle, Informix, and Sybase that are ODBC-compliant. Unlike some of the more active middleware products discussed in this article, however, Tango does not provide load balancing, nor does it maintain state information.
The popularity of Java has piqued the interest of several CORBA-compliant vendors as well, and as a result these vendors have developed products that make it possible for developers to build CORBA-based transaction-processing systems using Java. For example, Iona Technologies' Orbix for Java provides services that let Java applets downloaded to a user's Web browser participate in complex CORBA-compliant back-end processes. Because the Java applets are CORBA-aware, the Java-enabled HTML applications can maintain the state information required for complex transactions.
Another CORBA vendor, PostModern Computing Technologies (which has merged with ODBC-driver vendor Visigenic Software Inc.) provides a similar architecture for marrying CORBA and Java. The major difference between the Iona and PostModern products is that PostModern, because of its merger with Visigenic, incorporates Visigenic's JDBC drivers into Visigenic's VisiBroker for Java (formerly named PostModern's Black Widow), whereas Iona focuses exclusively on providing a CORBA-compliant Object Request Broker (ORB).
SunSoft, the company that created Java, has been busy building other service-oriented middleware products that leverage the astounding success of Java in the Web marketplace. One such middleware product, Joe, which is written in Java, lets developers build interactive applications that communicate with the rest of the enterprise using SunSoft's own ORB, Solaris NEO. As with all other CORBA-compliant products mentioned here, Sun includes a downloadable ORB and an OMG-compliant Interface Definition Language (IDL) compiler. And - like the other CORBA-compliant products discussed here - Sun's ORB supports communication with any other vendor's object request broker written to be compliant with the CORBA 2.0 Internet Inter-ORB Protocol specification.
Corporate developers seeking painless interoperability between ODBC and HTML may be interested in Fulcrum Technologies's SurfBoard. This product utilizes the company's core SearchServer technology to dynamically and automatically convert a wide variety of information sources, including ODBC, into HTML. Unlike some of the other ODBC-compliant products mentioned here, Fulcrum distinguishes itself from the competition by supporting searching and HTML conversion of a variety of data sources other than ODBC, such as structured RDBMS, WAIS-compatible databases, Adobe Acrobat PDF files, SGML, HTML, and NetNews. If you have a disorganized data warehouse or need to create a virtual data warehouse, Fulcrum's SurfBoard may meet your wide-ranging browsing needs. SurfBoard runs with any CGIbin-compatible WWW server, including Netscape's Communications and Commerce Servers, Microsoft Internet Information Server, O'Reilly & Associates' WebSite, and Process Software's Purveyor.
The economies resulting from using HTML browsers for lightweight transaction clients, along with cheap Internet terminals, are forging a natural alliance with those developing data warehouses. It's not surprising, then, that we find specialized products for optimizing Web access to data warehouses. One such product is NetScheme's InterMart Toolkit. The InterMart Toolkit consists of two major components: the Modeler and the Navigation Server. The Modeler offers a wizard that inspects the target database and transforms the schema into a navigation model with which the user requests information from the warehouse. The Navigation Server translates requests made against the Modeler into SQL queries that the target database will understand. As with Spider Technologies' NetDynamics product, the NetScheme Navigation Server maintains state information for user queries, thus enabling users to bypass the normal limitations of stateless standard CGI interactions against a database. The NetScheme Navigation Server runs on Microsoft Windows NT Server; the preferred target database is Microsoft SQL Server, but it will also work with any database compliant with ODBC.
Developers faced with making legacy applications Web-accessible will find that products such as Simware's Salvo and CEL Corp.'s Legacy Link may offer yet another middleware solution. Salvo bidirectionally translates 3270 datastreams and HTML. Legacy Link provides a CGI product that links HTML servers to data residing on mainframes and other legacy platforms.
The middleware approach offers natural advantages for developers interested in Web access to IBM mainframe CICS legacy applications. One such product comes from UniKix Technologies, a subsidiary of Bull HN Information Systems. The UniKix Server performs only one middleware function: acting as glue between CGI and legacy applications written using IBM's CICS transaction system. UniKix Technologies claims that its product is the fastest CICS-compatible transaction system on Unix and that in customer benchmarks on IBM mainframes, UniKix has outperformed a 3090-600J and has equaled an ES/9000-720.
Unix was originally designed with the philosophy of providing many small tools that can be linked in unique and innovative ways. In many ways, the single-purpose UniKix product represents the essence of Unix middleware. In contrast to the focused UniKix product strategy, Open Horizon's "one-stop" solution attempts to address all of an organization's middleware needs. Open Horizon's Connection product provides a proprietary "universal plug" into which virtually any existing system may be inserted to connect it with the rest of the enterprise. Connection provides many of the services DCE offers, such as user authentication and data encryption, but it goes beyond those operating-system-level services to provide ODBC driver access as well. With the release of Connection for Java, Open Horizon gives developers the ability to write applications in Java that can access all resources connected by Connection. In the process, Open Horizon leaves no stone unturned in ensuring that not only are all enterprise connectivity buzzwords addressed but that the hottest language buzzword - Java - is used as well.