E-commerce success hinges on fast, scalable access to big databases. The question is, which key is best suited to unlock this door - proprietary APIs or FastCGI? Elwood P. Dodd and Matthew JC. Powell help you pick your way through this problem, and have a look at some of the new database products on offerAs the Web rapidly evolves from a platform for timely communications to a platform for timely transactions, corporate customers increasingly expect integrators to build or select solutions for fast, Web-based access to databases. Unfortunately, while the Web is perfectly suited to this task on a physical level, the internal structures of Web tools haven't been brought up to speed.
For electronic-commerce applications, including extranet apps, the problem rests with the twin beasts of volume and speed. When using the Web to sell, for example, your e-commerce clients can die a thousand times a minute if their customers are kept waiting to enter a credit-card number or if they endure any other lags in processing an order.
The solution, of course, is to provide new Web-based database-access methods that offer higher performance, serve as many customers or business partners who care to call, and provide simulta-neous security for all highly sensitive information.
Naturally, intense competition among software vendors to deliver this solution has given integrators a range of choices, each with its particular trade-offs. Here we examine the database-access-tool offerings of three leading vendors - Microsoft, Netscape, and Oracle - and compare the diametric strategies of app building with proprietary APIs versus FastCGI, the next-generation common gateway interface (CGI) standard for running programs on a server from a Web page.
From the database out
With the largest installed base of industrial-strength SQL databases worldwide, the Oracle Call Interface (OCI) v7.3 carries a fair amount of market clout. This tool lets apps written in third-generation programming languages such as C, Cobol, or Fortran to issue SQL statements to one or more Oracle servers.
As such, OCI is positioned to sell well into back-end mainframe and midrange computer environments, as well as for micro-based servers. Oracle claims that OCI gives programs the capability to perform the full range of operations possible with Oracle Server v7.3.
Oracle is getting into Web-based technology in other ways as well. It recently added Web extensions to an older product, Forms v4.5, a standard in the client/server environment for some time.
The Netscape Server API (NSAPI) lets you build interfaces between the http server and back-end database applications, on both Unix and Windows systems. Netscape offers an olive branch to older Web apps, promising that Netscape Server products can take advantage of CGI in addition to NSAPI.
Windows Web to database
As you'd expect, Garth Fort, a product manager for Microsoft Visual InterDev, approaches Web access to databases from a different direction - namely, Microsoft's proprietary APIs. "For simple access, we have facilities built into Access 97," he says. "Stepping up in complexity, FrontPage 97 supports a database range up to, for example, a marketing Web site."
But for serious e-commerce apps, you must get to know Microsoft's Internet Server API (ISAPI). "Where you'd build with ISAPI components," explains Fort, "is when you want credit-card-approval processing, for example, built into your app. It's a small component but one that must be very secure, very scalable, and very fast."
He notes that ISAPI applications are complex - written in C++ - but provide the benefit of high speed and high security. According to Fort, Visual InterDev comes into play at the very high end. "It's a complete programming environment, more like Visual Basic for the Web," he notes. "It's all about having a set of visual tools for constructing Web pages."
These tools include a wysiwyg HTML editor and a source editor, as well as a set of database tools that let software integrators build Web sites that are able to communicate with and expose the tables and relationships in any back-end database.
As far as choosing between a Web tool for database access from Microsoft or Netscape versus a tool from a database vendor, Fort recommends the former, but his argument does have merit. "Database-vendor tools are extremely powerful, but they're also limited to one type of back-end," he observes. "For most of the world, data is actually scattered through multiple databases."
Heterogeneous data storage requires open-database connectivity that enables access and integration of all the data. That's where the benefit of having a database-application tool, as opposed to a simple database-publishing tool, becomes obvious.
An open possibility
But the question of where open-database connectivity actually begins is with your choice of programming interfaces. Assuming limited time and resources, you basically have two development paths to choose from: FastCGI or vendor-specific APIs.
FastCGI works in much the same way as APIs. A FastCGI application library simplifies the migration of existing CGI applications to the newer interface, and applications built with the application library can run as CGI programs - making FastCGI backward-compatible with older Web servers.
FastCGI is also language-independent and employs process isolation to keep buggy or malicious apps from messing with the Web server. It is not tied to a particular server architecture, and it uses common TCP packets to communicate between the server and the app.
APIs are vendor-specific, which can make them hard or impossible to implement in any environment but the vendor's own. If you and your customers don't mind being committed to that vendor's Web-server package, however, a big benefit of APIs is their specificity. The API and the server are designed to work together for maximum efficiency.
FastCGI is an open standard that has been designed to be broadly applicable with the widest possible range of servers. API supporters feel that by trying to be all things to all people, FastCGI must sacrifice some performance. Meanwhile, promoters of FastCGI deride APIs as complex, language-dependent, difficult to maintain, prone to security risks, and inherently unstable.
What's your platform commitment?
It comes down to speed versus expense. APIs are zippy and work well with spe-cific servers, but there are all those nasty disadvantages cited above.
FastCGI is also quite quick but reportedly not as fast as an API when volume on a server gets heavy. Still, FastCGI is simpler and works over a broad range of servers.
Which development road you choose, or recommend to your customers, may depend on how committed either party is to a particular vendor's server. If you've thrown your lot in with Netscape or Microsoft and have no desire to use anything but one of the Netscape Enterprise Server platforms, NSAPI makes a strong argument. This applies equally for integrators implementing Microsoft's Internet Information Server or Oracle Server.
On the other hand, if you are a multiline integrator and prefer to maintain a broader range of server offerings, FastCGI promises more flexibility and lower maintenance costs, albeit at the expense of speed and scalability.
Look before leaping onto API path
Vendor-specific APIs deliver many performance perks - but at a price. For many integrators, VARs and service providers building e-commerce solutions, linking the application code to the Web server via a proprietary API will be very attractive. They'll like the idea of increased speed and traffic-handling capability. But experts warn that using an API to solve traffic-load problems is no easy development path. Some widely reported disadvantages include:
Lack of process isolation. APIs link application code into the core Web server, so that a bug in one API-based app can corrupt the core server or another application.
Vendor specificity. An API reflects the internal architecture of a specific Web server. If the vendor changes the server's architecture, the APIs must also change.
Complexity. Vendor-specific APIs are reported to require a steep learning curve, which means customer implementation and maintenance costs go up.
Language dependence. Apps must be written in whatever language the vendor's API wants them to use. Most often, this is C or C++. This adds expense, since most existing Web-based database-access mechanisms are designed for CGI, which means that they were probably written in Perl. No vendor APIs support Perl.
The speed bumps to FastCGI
Platform independence may be too high a price for the demands of large-scale e-commerce. The beauty of an e-commerce application written to the FastCGI standard is the "write once, run anywhere" promise familiar to Java developers. That is, because the app adheres to a standard gateway interface, it will run on any Web server that supports FastCGI. If you're developing an application and don't know what server your customers may use, your only viable option today is FastCGI.
The standard provides cross-platform compatibility, but it cannot offer the platform-specific enhancements of such tools as Microsoft's ISAPI or Netscape's NSAPI. You're essentially trading server performance for platform independence. And the performance trade off, according to some experts, is big. Vendor-specific APIs such as ISAPI or NSAPI, for instance, offer architectures that run in process with the Web server to accommodate heavy traffic.
Functionality such as connection pooling, in which hundreds of concurrent connections may be opened and kept open regardless of individual user activity, provides enterprise-class scalability FastCGI apparently cannot match. With some vendor research showing that 90 per cent of developers know what specific servers their apps are targeted for, the scales seem tipped toward server-specific APIs.