Dealing with Client/Server

Issues in Purchasing and Implementation

The Next-Generation Web Site

Databases contain the kinds of information that can add functionality and personalize your Web site.

By Sally Atkins

As Web sites evolve into their second and third generations, they often change from publishing and simple interaction into more sophisticated, dynamic front ends for electronic commerce and associated distributed applications. These cutting-edge Web applications are enabling channels for content programming and electronic commerce. They cover functions such as electronic data interchange (EDI), sales, marketing, customer service and order fulfillment for soft goods.

To provide this new level of functionality for next-generation Web sites, IS professionals must invent architectures for integrating both new and legacy databases with the Web. Whether it be an intranet or the Internet, if you have not been faced with it yet, chances are you soon will be. A new class of software which I call "Web middleware" has emerged to help architect this intersection between back-end databases and Web pages. Here are a few preliminary steps for evaluating Web database middleware for your organization's sites.

Finding the Right Middleware

First, take a look at your existing Web infrastructure. Is it sound or is it a mish-mash of various servers, content management and development tools? Maybe this is the time to bring some corporate buying guidelines to bear. Uniformity in Web servers and toolkits will enable you to better ensure future interoperability between Web databases. Especially with conflicting Internet standards being pushed by Microsoft and Netscape, this is a year in which to choose your buying strategy--whether based on Microsoft or traditional Unix and Internet open protocols defined through the Internet Request for Comments and Engineering Task Force process--and stick by your vendor philosophy as much as possible.

Second, look at the database side of things for the applications at hand. Figure out the scope of the database you will need, and determine each front-end application's complexity and size. Ask what information you will be collecting or disseminating and why. Do a data model. Decide whether this is an extension to an existing database (that is, a Web facelift) or a new collection.

Next, figure out what kind of transactions will be processed, and whether they will be in realtime or near realtime, as in the FedEx and UPS package tracking Web sites. Your choice of database management system should depend on the size of the database, the number of people expected to access it simultaneously and the type of work to be performed. This is common sense for selecting any database, not just a Web back end. Yet people often forget to start here. They start with middleware and find themselves trying to put a 500-pound gorilla of a database into a gazelle of a tool because the middleware works only with lightweight PC databases.

Then think about maintenance. Will this database be maintained by your own staff or outsourced to a customer service company or perhaps an Internet service provider (ISP)? The choices of database and middleware may be dictated by the environments of your vendors. How will you keep the information current and restructure the database if it is not housed in your shop? Who will do the reporting? Watch out for hidden charges from ISPs and Web design firms. Often they forget to build in the costs of reporting when estimating the cost of building or hosting a Web database.

Picking the Platform

Assuming you have the luxury of deciding what platforms your vendor or your IS department will use, how do you choose? Generally, for database servers you will choose between Unix for Intel or RISC, NT for Intel or RISC, and Apple (which has some robust Web sites running on its servers). The choice depends on how scalable and portable you need the database to be. Some businesses today are hosting their Web sites on Unix with links to the NT server where the database resides. This will be necessary, for example, if your ISP only offers Unix hosting and you wish to use a Web middleware tool which runs only on NT.

The choice of platform depends on who will maintain the database and where it will be hosted. Internet service providers today, with few exceptions, do not offer NT server hosting. I researched this issue and found that UUNet plans to begin offering the service, as do a few others. Microsoft told me to look to a small ISP in Olympia, WA. (Hardly a valid choice for my East Coast and Fortune 500 customers!) For the time being, you will be hosted on Unix if you outsource your Web server hosting to an ISP. As you plan your Web database, you need to determine whether you are better off linking to an NT database server offsite from the ISP or going with a Unix database server. Make the choice based on the ease of maintenance of the application. This is where the costs can build up and spin out of control.

The future is bright for new tools in the Web middleware arena. An important step in evaluating Web middleware is to keep your eye on the marketplace. Today, leading vendors include Bluestone, Microsoft, O'Reilly and Spider on the lower end; on the high end, BroadVision is worth a look. Coming forward in the midrange are Oracle and Sybase with exciting tools for database integration with the Web. The future belongs to channels on the Net, and to the applications and databases that enable them.

Sally Atkins is president of IST Consulting, an affiliate of NetSource, Inc., based in Boston. She can be reached at Sally@kins.com.