Let’s consider some possible server scenarios. Note as you consider these examples that the choices of WAN links are shown as examples only; any one of these servers could handle relatively high-speed or low-speed links.
Here are some scenarios of some typical server environments.
Here, the site has chosen the Interjet server appliance from a vendor called Whistle. The Interjet provides all of the server functions, both Web and ancillary, the site needs. The Interjet even includes routing functionality. This scenario would be very appealing to a library with little technical staff whose ISP is willing to support a server appliance.
Here we are running Windows NT Server as our operating system, with Microsoft’s Internet Information Server, or IIS, as our Web server software. We are also running Microsoft’s SiteServer, a collection of Web publishing tools that assist in managing large, complex sites. We rely on FrontPage for posting content to the server. This is a fairly typical Microsoft-oriented configuration. It would be easy to extend this server to run other Microsoft tools, such as Active Server Pages and a live database. Our DNS services are provided off-premises by our ISP. Our e-mail services are handled by a separate server at our site, which might or might not be a Microsoft-based server.
Here we’ve chosen a server from a traditional vendor of Unix hardware. We’re running Netscape’s FastTrack server. Our content providers publish to the server either via FTP or via Netscape’s “One Button Publish” extensions. We are relying on separate server boxes at the library to provide DNS and e-mail services.
Here we’ve chosen a Macintosh as our server. We’re running Apple’s conventional operating system at version 8.5 along with Appleshare IP extensions. Our Web server software is WebStar, which we’ve coupled with middleware from Lasso to offer live content managed by the popular FileMaker Pro database software, with the database software and Web server both on the same physical server.
This scenario exploits the most popular Web server package, Apache, and the Linux operating system, which is enjoying increasing popularity as an alternative to proprietary Unix systems (and Windows NT). This scenario is appealing because it relies on an operating system and on server software that are free.
Although in this example we show DNS and e-mail being provided by separate servers, Linux comes with built-in DNS and e-mail capabilities, so it would be just as easy to run those services on the same box as our Web content. Here we might choose not to do so for several possible reasons:
DNS and e-mail were already running on separate servers on site.
We don’t want any performance problems with our Web server.
We don’t want an outage in DNS or e-mail to force us to take down the Web server for service.
We want different staff to work on the Web server than the DNS and e-mail, and we don’t want to give “superuser” or “root” permission to other services for our Webmaster.
Interfacing to Databases
Besides the basic Web server software, you may need to install additional software to round out your server’s capabilities. For instance, if you are going to connect to a live database, you will need to install the database software, whether it be Oracle, Microsoft Access, Microsoft SQL Server, or some other database. Your scenario may call for the server software and database software to reside on a single piece of server hardware, or you may choose to run your database software on a separate box.
Whether your database resides on the same box or a separate one, you will need to be able to interface your Web server software with your database. Fortunately, a standard known as ODBC provides a standard way to interface with most popular databases. Database “middleware” tools such as Cold Fusion provide the glue to connect your Web server to any ODBC-compliant database. If you choose to run a Windows NT server with Active Server Pages under Microsoft’s IIS, you will be able to interface directly with an Access or SQL database. The Toolkit demonstration software assumes this model.
If your site grows to include a large number of pages, no matter how good a job you do of making the site navigable, navigation can be made easier with a local search engine. You may want to consider acquiring such a tool for your site. Here are your options:
Install a free tool, such as the ICE indexer and search engine. Written by Christian Neuss and made available to anyone at no charge, ICE is written in the language Perl and is suitable for use on servers with up to several thousand documents. For a tutorial on installing and using ICE, see:
Some Web server software packages may come bundled with their own search engine. For instance, Microsoft’s SiteServer includes a search engine capable of indexing content on your own server as well as crawling other servers you wish to index.
You could acquire a commercial search engine. For instance, Infoseek markets its search engine under the “Ultraseek” brand name, and Altavista markets its engine as well. Fees for using these engines vary with the size of the site. Both vendors’ products are available for Unix or Windows NT servers. Both vendors offer evaluation copies of their products for free download and use during a limited evaluation period. Altavista also offers free use of their product to index sites with up to 3000 documents. Note that these products can be rather expensive; be sure to pursue any non-profit, governmental, or library discounts. See www.infoseek.com and/or www.altavista.com.
You could use Excite for Web Servers, an older version of the search engine used on the Excite service and available for a variety of versions of Unix servers. This tool is available for free and offers much of the functionality users of the global Excite service are used to. See: www.excite.com/navigate/download.html.
An excellent general resource on picking a search engine for your site is:
There you will find information on the currently-available free and commercial alternatives, as well as case studies showing how some sites evaluated alternatives and chose their search engines.