Netscape legs out Web win We take a detailed look at five servers and pronounce Netscape's the best. Plus, a database lets you sort through offerings from 19 vendors. Network World, 4/7/97. Snyder is a senior partner at Opus One, a consulting firm in Tucson, Ariz. He can be reached by phone at (520) 324-0494 or via the Internet at jms@ opus1.com.

By Joel Snyder
IntraNet, 6/23/97

Intranet servers may bear the same names, run on like operating systems and share stylesheets and graphics with their World Wide Web counterparts, but the similarities end there. From an architectural standpoint, public and private Web servers should be worlds apart.

For example, if you're establishing an Internet presence, you want a Web server capable of tracking visitors and logging what they do. That's because information such as how people get to the site and how long they stay there can be vital to external marketing and education efforts.

This same information, however, is largely meaningless when it comes to an intranet site created for employees. A Web server loaded with powerful logging and tracking capabilities is probably overkill.

Architecturally, then, what should an intranet server offer? To meet the demands of an intranet, look for built-in, easily accessible protection schemes; the ability to customize and easily modify a server's configuration; the availability of intranet-specific tool kits; a fault-tolerant configuration; ease of installation and management; and simple database access.

Of course, you'll find it difficult to buy one Web server that excels in all of these areas. So depending on the particular needs of your intranet, you might opt for the Web server that's easy to manage rather than the one that easily links to database systems. This buyer's guide will help you sort through the intranet-related purchasing decisions and identify the best-of-breed products in each category.

Security

But in an intranet, things are not that simple. Access privileges can be based on who you are, where you're located, what department you work for, what your title is and who you supervise. For security, intranet servers need to be flexible.

This is especially the case if a corporate Web spreads across multiple servers and departments, which most do. Web servers are inherently lonely and solitary beasts - they seldom, if ever, share security and authentication data among themselves without a great deal of application-level programming.

Even within a single Web server, authentication information is usually poorly partitioned. The normal Web server security model calls for one authentication file for each access realm. The authentication files list users and passwords, while the server configuration file links users to permitted areas.

This means a user may have to use multiple user names and passwords to reach different areas of the intranet and would have no convenient way of synchronizing those different access schemes. The traditional user-level security object in a Web server is subatomic indeed.

The exception to this rule is Microsoft Corp.'s Internet Information Server (IIS), which extends Windows NT security - user name, password and, most importantly, access control list features - into the world of the Web. Users authenticate themselves to IIS servers using their Windows NT user name and password. IIS then uses this information to restrict what the users see based on the Windows NT protection model.

At the same time, some of the authentication and security features of public Web servers have little use on an intranet. Traditionally, high-end security for public services such as online banking has depended on a combination of encrypted communications and application-level security, such as an account number or user name and associated password.

In an intranet, this is usually overkill. Server-level authentication is much simpler to add to an intranet than true application-level security. By emphasizing high-end server authentication to meet those needs, products like IIS free the designer of the burden of reimplementing application-level security.

Customization and modification

One area where the flexibility issue pops up often is in preprocessing text. A preprocessor is beneficial because it gives the HTML author the power to build dynamic Web pages without having to write real application code. This lowers development cost and eases maintenance. While all servers have preprocessors of varying power, the nature of highly customized Web-based applications is that out-of-the-box preprocessor capabilities will seldom be strong enough.

Solving this problem usually means either diving into the world of CGI (and API) scripts or changing the preprocessor. The trade-offs either way are significant. Many CGI/API scripts will heavily impact the performance of Web servers. On the other hand, changing the preprocessor commits you to retrofitting those changes every time the vendor releases a significant version of the server.

At times, special applications may require changes in the way the server itself operates. Some of these can be accommodated by CGI or API scripts, while others may mandate changes to the basic server.

If you choose to modify the server, you'll want Apache, a freeware product maintained by Apache Group. Apache is nothing if not popular: It dominates the public Web server space, serving more than 450,000 domains. That's more than Microsoft, Netscape Communications Corp. and O'Reilly & Associates, Inc. combined.

Apache has two advantages: It comes with complete source code, and it is designed to be modified. Apache Group has fitted a plug-in framework to the Apache server that makes changing the server simple. Although changing server source code sounds dangerous, Apache removes much of the danger and uncertainty with its development framework.

Intranet tool kit

Programming Web applications is no easier than programming any other application - it's just that the graphical user interface (GUI) is simpler, or so it seems. In fact, intranet applications may be more difficult to build as distributed systems, groupware, e-mail and data warehousing projects migrate to the corporate Web.

Intranets have to deliver what large mainframes offered without having the advantages of a single processing domain and a secure local file system. Developers need an intranet-specific tool kit to help build these applications.

One simple example of this is in transaction-oriented applications, such as a benefits program. Since the Web is stateless, maintaining state information across screens in a transaction-oriented application is harder on an intranet than in a standard client/server system. Every screen is a separate transaction; there is no smooth flow from screen to screen. Unlike an application with its own GUI, a Web application cannot depend on an unbroken, continuous link to the user.

The HTTP world offers several mechanisms for maintaining state information. The most controversial is cookies, which provide an insecure way for the server to store state information on the client and to retrieve that information as the client moves through the application. Controversy surrounds cookies because of misplaced ideas of how anonymity works on the Web and the tracking that can happen using cookies.

In any case, intranet applications normally don't have the same privacy issues as their public Web counterparts. But there is a security problem, in that the content of cookies is directly under control of the user and the server cannot depend on cookies staying un-corrupted during a transaction's lifetime.

Another common technique for tracking a single client across multiple screens involves stateful URLs, where every URL is modified to have some state information stashed into it. This is guaranteed to work - until the user bookmarks a page with one of these stateful URLs and tries to go back to it long after the transaction has been closed out. The URL will fail, and the user won't know where to go next.

Cookies and stateful URLs can be useful, but when it comes to building robust applications that have more than a screen's worth of persistence, they're not enough. This is especially true when programmers have to take into account issues such as transaction re-covery, integration with authentication systems and database links.

Unfortunately, Web servers take a flat approach to programming: The librar-ies are there, go ahead and use them.

For many Web developers, site construction begins with a question: ''What code can I use as a model?'' Intranet programmers benefit from the availability of good tool kits of sample applications along with the associated application source code.

Good examples in this area are Net-scape's Enterprise Server, which has dozens of samples in its AppFoundry, and StarNine Technologies, Inc.'s Web-Star, which includes more than 100 example applications. Both servers provide fertile ground for the imaginations of Web developers to grow new applications and modify existing ones.

Fault tolerance

Business-critical applications require fault-tolerant servers that also have fail-over capabilities or, preferably, load sharing. All of these characteristics contrast with the rough-and-ready world of the Internet and, consequently, most of the Web servers available.

Microsoft, Netscape and a few other Web vendors promise they can bring ''big business'' style software to the in-tranet. However, they have failed to capture the trust of those IT managers who are used to the cradles that traditional computer system vendors such as Digital Equipment Corp., Hewlett-Packard Co. and IBM built for them.

In this case, the server choice isn't as significant as operating system. Win-dows NT, while popular as a workgroup operating system, does not offer the fault-tolerant and load-sharing features that older operating systems have had for years. NT also has gotten black eyes from defects in its network applications and TCP/IP implementation.

So IT managers charged with building mission-critical intranet applications are turning to their old, solid standbys - Unix and Digital's OpenVMS. (If a good Web server were available for IBM's MVS operating system, they'd likely build intranets on it, as well.)

OpenVMS, which offers built-in clustering technology, is an excellent choice as an intranet platform when rock-solid reliability, failover capabilities and load sharing are required. Net-scape's Commerce Server, Process Soft-ware Corp.'s Purveyor and Ohio State University's (OSU) Web server run on OpenVMS. The OSU Web server leads in the number of installations.

Digital's back-office operating system also brings another benefit: security. Windows NT has suffered from several deadly network-launched denial-of-service attacks; popular Unix platforms have dozens of published stack-overflow attacks. In light of all this, OpenVMS seems almost miraculously unscathed.

As an alternative to built-in load sharing and fault tolerance, companies such as Cisco Systems, Inc., IBM and Reson-ate, Inc. offer products that sit in front of a Web server farm directing queries among a set of Web servers and keeping tabs on server availability and load level. With these types of products, a farm of Windows NT servers can appear as reliable as Unix or OpenVMS - although at substantially higher cost.

Easy installation, management

In this environment, ease of installation, management and tuning are critical success factors.

One approach to meeting this need is picking a single server that is supported across a wide variety of platforms. If a ''corporate standard'' can be established, then the help desk can support the Web in the same way it supports word processors and spreadsheets.

Few Web servers run across multiple platforms. The obvious exception is Netscape's family, which offers a relatively unchanged interface across OpenVMS, Unix and Windows NT.

Netscape has a second advantage: Its management interface, done via a Web browser, is the strongest and most flexible among Web servers. Because Netscape's server is managed via HTTP, remote control of a Netscape server is easy. For those who prefer to edit configuration files, Netscape also supports that interface and provides documentation on how to maintain the configuration manually.

A second approach is to simply find the easiest and simplest servers to manage and offer them to users. One un-likely contender for this approach is, surprisingly, the Macintosh. As a computing platform, the Macintosh's legendary ease of use makes it an interesting - if not unorthodox - choice for small departmental servers.

The most popular Macintosh Web server, StarNine's WebStar, shares the idea of a Web-based management interface with Netscape, although direct management from the server console also is possible.

O'Reilly also offers a well-documented and fairly easy-to-manage Web server in WebSite Professional. Although the Windows 95 and NT platforms don't have the hands-off management and tuning style upon which the Macintosh builds, the idea of putting workgroup Web servers on commonly used platforms may be comforting.

No matter what operating system platform or server is chosen, departmental server managers will need ad-vice on tuning and cleaning the server. Because Web designers are loathe to give up precious hit logs, procedures for removing and archiving old logs are key to long-term health of the server. Where the platform supports it, automated procedures to roll over log files will be a great help.

Database access

Easy access to databases can be the key to building powerful intranet applications. A simple way to blend HTML and SQL into Web pages is vital.

The goal is to be able to let a Web page display the results of a query accurate at the moment the page is loaded. Similarly, integrating HTML forms and SQL queries without requiring scripts brings the intranet designer additional power at low cost.

The big three Web commercial server vendors - Microsoft, Netscape and O'Reilly - include tools in their servers that make the link back to SQL databases with little or no effort. These servers depend on a robust SQL interface.

Unfortunately, some legacy databases won't have such an interface, or won't work with these Web servers. In this case, the specter of middleware looms large, with high-priced products de-signed to push out true legacy data to the Web browser. These range from the useful to the truly sublime, such as Teubner & Associates' 3270-to-HTML converter.

The bottom line