Corporate.Net
internetRx

By AnthonyFrey Q: Our intranet Web server accesses a database--an ODBC (Open Database Connectivity) data source setup for an xBase (like FoxPro) flat file--on the same machine as the Web server. We use both scripts and third-party serverside processors (like ColdFusion) to access the data. Can we extend this to a three-tier architecture?

A: Yes. This is a frequent migration path on Windows-based systems where flat file databases have predominated. By using the Web browser client and HTML strictly for data presentation, the Web server for application logic and an RDBMS for data storage, you will have a rough, Internet-ready, three-tier design. This will let you more easily scale your Web server load across multiple machines because they can each access a single database.

You can add database client functionality to your Web server by doing the following:

· If your RDBMS uses a protocol other than TCP/IP for its transport layer, you'll need to configure your Web server to use that transport. (Your Web server should already be configured with TCP/IP to run the HTTP protocol.) You can use any network protocol that is supported by both the RDBMS and the Web server. We still recommend using TCP/IP because it's efficient and simplifies configurations.

· Configure the RDBMS middleware's naming service on the Web server. No standard naming service for looking up database systems exists. Of course, a DNS query will resolve the host name where an RDBMS resides, but that only gets you halfway because many RDBMSes require that you specify the desired "logical" database. Fortunately, most data access middleware lets you specify host name, network transport and logical database all within the definition of the data source name.

· Use the vendor's standalo ne client tools to verify the connection. Any tool, such as SQL Server's ISQLw, Oracle SQL*NET's "tnsping" or Oracle's SQL*PLUS, will suffice.

· Install the ODBC driver for that RDBMS vendor's middleware and redefine the ODBC DSN (Data Source Name) to use the database connect string. If the new DSN name is identical to the previous DSN name, your Web server application should be able to access the new database without any modifications.

Finally, you'll want to set up RDBMS connection caching if your Web server CGI (Common Gateway Interface) application supports it. How you do this varies in CGI packages, but most only let you cache a RDBMS session if the RDBMS user name does not change. In this case, you need to use a single RDBMS account for intranet users.

Anthony Frey can be reached at afrey@nwc.com.

H.323: Videoconferencing Approches the Millennium
By Jeff Newman with Dave Brown

Updated November 10, 1997