by Tom Henderson
The next time you visit your favorite home pages on the Web, there's a good chance you'll wind up filling in forms, performing searches or sending queries. You might not realize it, but during this process, your browser takes on a new role, acting as a client in a client/server operation. Of course, client/server apps have been around for quite a while, but this new Web-enabled variant is not without its own lingo. In case you haven't heard, the latest catchphrase in enterprise computing is browser/server.
Several software industry heavyweights, including Borland International, Microsoft and Sybase, are vying to deliver application programming interfaces and software tools to ease browser/ server application development. For the desktop, vendors are striving to transform browsers into increasingly intelligent database clients. And in the back office, Web servers are becoming agents that fetch information from relational databases and reformat it for delivery to browsers. Some vendors will even try to sell all three of the components-browser, Web server and database server-needed for a typical browser/server installation.
To focus clearly on the browser/server picture, you should understand its progenitor, client/server. Traditional client/server applications are divided into client-side software and rela-
tional database management systems (RDBMS) running on servers. The client-side application can be "skinny" or "fat." Fat applications are typically sophisticated packages, containing code for internal checking and rules for how server data is to be manipulated, queried or reported. Skinny client applications are often based on forms and have little sophistication. The skinniest client applications may soon run on the so-called network computers being developed by IBM, Oracle and Sun Microsystems, or on products based on Microsoft's Windows CE palmtop operating system (see related article in this issue's Reviews section).
World Wide Web browsers are among the skinniest of clients because they have little native application intelligence. Instead, they are increasingly clever user interfaces. Browsers bulk up by downloading applications from a server. They can also retrieve data by using a Web server as an intermediary to a back-end RDBMS or other data sources.
Browsers communicate with servers via the hypertext transfer protocol (HTTP). HTTP is stateless, meaning that HTTP-driven Web servers are totally reactive to browsers. When you point a browser to a Web site using a universal resource locator (URL), a Web server responds by transmitting its default page (unless the URL points to a specific page). The Web server then goes to sleep until the next browser request.
Many of the Web pages you fetch will likely contain HTML forms for you to fill in. For example, some forms request your name and e-mail address
so you can be placed on an electronic mailing list. When you're filling out a form, you're not yet interacting with a Web server. Once the form is filled in, you're typically prompted to click on an action button. When pressed, the action button activates the HTML code that sends the data from your form to the appropriate Web server. The Web server then typically passes the data to a common gateway interface (CGI) application, a Windows dynamic link library (DLL) application or other types of server applications (described later in this article).
CGI applications have their roots in UNIX and the Perl scripting language. Think of CGI as the middleware in a browser/server architecture. Like client/ server middleware, CGI is part application and part database activity handler. When a CGI application receives data from a form, it usually checks the data's validity, then performs operations based on that data. These operations can be as varied as the programmer's imagination. In browser/ server applications, a typical CGI request may reformat the data, log into a database server and pass a query to it. Rules may be imposed on the query to limit the possible results.
The query results-if any-will be reformatted for presentation to the user. For instance, the results can be embedded into an HTML document, or fed directly to a Java application. The Java app, in turn, uses or reformats the data for presentation. Finally, the reformatted data is sent to the user's browser, and the CGI script de-allocates any resources it used and terminates until called again. This entire process-from submitting form data to receiving a result-may take a matter of seconds.
Properly written CGI applications play a critical role in ensuring fast response times. Each time a user submits a query form, an independent CGI application or script is called to perform the action. In other words, each user's query launches a dedicated CGI script. This lets CGI processes wake up, work and terminate very quickly.
There are alternatives to CGI. Although Microsoft's own Internet Information Server (IIS) supports CGI, the software titan is pushing programmers to turn their CGI code into DLLs with Microsoft's Internet Server API (ISAPI). These libraries continually reside in memory (rather than being called ad hoc like CGI applications) and are called by a Web server to process forms data.
ISAPI DLLs share a common address space with the Web server application. If the DLLs haven't been used after a predefined amount of time, they are released from the application. According to Microsoft, this speeds reaction time. It also allows the DLL application to use common memory pools, instead of the concurrent resources needed by multiple CGI application instances.
There is one big potential downside to ISAPI DLLs: They're proprietary to 16- and 32-bit Windows. By contrast, CGI scripts and applications are supported across a number of platforms, including Microsoft's IIS. Browsers running on different operating systems can, however, use back-end Web server applications that call DLLs.
Borland International is another player in the browser/server arena. You can use Borland's IntraBuilder tools to develop the client, middleware and server connectivity components needed for a browser/server network. IntraBuilder is a server-side data access product that's based on the foundation used in Borland's popular Delphi rapid application development (RAD) platform.
Another browser/server development option comes from Sybase, which is known for competing with Oracle, Informix and IBM in the enterprise database market. Sybase's approach to browser/server is less comprehensive than Borland's, however.
Sybase is offering web.sql, a database connectivity tool for the creation of dynamic Web pages. It supports in-line SQL and Perl scripting, and works with any Web server.
The Sybase web.sql product currently runs on Silicon Graphics IRIX and Sun Solaris. Windows NT and Hewlett Packard HP-UX versions are in beta as of this writing, and are expected to ship in early 1997.
On the desktop, however, Sybase's tools can't match the features of Borland's IntraBuilder. Sybase's PowerBuilder development tool, for instance, lacks the client-side development capability that enables browser/server. Although Sybase is working on several Java initiatives, these efforts have yet to bear fruit.
If you can't wait for Sybase to fill out its browser/server product line, Microsoft will gladly sell you alternative browser/server development tools for both the desktop and server.
On the server, Microsoft includes IIS 2.0 with Windows NT Server 4.0 ($1,129 for 10 users; $539 for a 10-user upgrade from NT Server 3.51). Also included with the NT Server 4.0 license is Microsoft's Index Server and ODBC/IDC connectivity link. Index Server can index and query HTML, text and Microsoft Office documents. After Index Server digests such documents, it can be queried based on keywords with simple or moderately complex Boolean search techniques. The IDC (Internet Database Connector) uses ODBC (open database connectivity) to query a database and can reformat the query results into HTML for presentation to the user.
NT Server also includes several different example applications that use the Index Server, as well as other apps that demonstrate how to use IDC/ODBC with server applications.
The included ODBC drivers can connect IIS to virtually any ODBC-compatible database, such as relational databases from Oracle, Sybase, IBM, Informix and Microsoft, or flat-file databases such as Microsoft Access, Visual FoxPro, dBASE or Btrieve. Visigenic Software (http://www.visigenic.com/info/prod.html) makes enhanced, 32-bit drivers for an impressive number of data sources that aren't in the Microsoft box.
Microsoft offers two other products for server database applications development. They are the OLEdb SDK and an IIS-specific product called dbWeb 1.1. The OLEdb SDK is expected to lead to new databases that are assembled from best-of-class components, but it isn't specifically Internet/intranet targeted. In contrast, dbWeb is a database publishing utility.
The dbWeb software installs on an existing IIS system. From there, dbWeb Administrator software invokes a Wizard (dbWeb Schema) to select an ODBC data source such as Access, Oracle or Microsoft SQL Server. The Schema Wizard allows programmers to select tables from a database source. The wizard also records access and validation rules for data coming from HTML or user access.
Once the ODBC data source and validation rules have been written, dbWeb is linked to an HTML page by a URL that points to the desired schema. Multiple database sources can be "AutoLinked" together.
The upside to dbWeb is that it's free, and requires no real knowledge of SQL, HTML or programming.
The downsides are that Microsoft does not offer technical support for dbWeb, the software works only on IIS, and it produces very simple results. The dbWeb server can run alongside IDC if desired.
Each of the aforementioned tools provides enough to get you started with browser/server. But the best is yet to come. Browser/server applications will become more sophisticated when Java and other "coffee" software starts to mature. Many of the back-end components, meanwhile, have already become rich and are quite popular for building intranets.
Still, large browser/server applications that connect to the Internet remain problematic because access times can vary widely. One of the more popular curses these days is "May your Web site be on the HotWired Top 10." Indeed, sudden popularity can bring even the healthiest Web site to a near halt. Of course, you'll never know how healthy your own browser/server network is until you deploy one. Isn't it time to get started?
Contributing Editor Tom Henderson is vice president of engineering for Indianapolis-based Unitel. Contact Tom in the "Enterprise Administrator" topic of WINDOWS Magazine's areas on America Online and CompuServe, or care of the Features and Columns Editors.