Web Servers and Software

• you may choose from many different platforms for the server, including Macintosh, Windows NT, UNIX, VMS or MVS. The choice should reflect your administrators' expertise, your need for scalability and the availability of the necessary tools to access the data you may need. You want to make sure you adopt a platform that your IS group can administer. It makes little sense to add a UNIX machine if there is no UNIX expertise in the group
• when choosing an intranet platform, you will probably need much more horsepower than an external Web server. Not only are some of the database access tools hungry, your users will be attacking at speeds that are probably an order of magnitude faster than the external server
• if you are not going after sensitive information, security probably won't be a high priority. In those cases, there is free, quality Web server software available (and even free software to do SHTTP security). There is no standard API to those servers; you will have to work with CGIs and applications external to the HTTP server
• your Web server needs to have access to the information you want. For example, if you are using an Oracle database, you will probably avoid a lot of headaches by using Oracle's Web server and database tools.
  

Databases and Middleware

• more than likely, your company has oodles of information, which is most interesting to your users but is socked away in various databases. Web server-ready middleware can help you make that information available to the masses. Since your Web server becomes the client to your corporate database, it will need the right tools to get access
• on the back end, your server fetches data and plops it into a nice looking HTML sheet and ships it off you the client. Depending on the data, the client can also be given options to fetch more or different data. This gives your users a simple, browser-based interface to complex stores of information
  

CGI

• using CGI scripts and applications, data may be retrieved or posted from the users, creating a two-way path. Web browsers and servers support information passing in both directions.
• most CGI programming is quite complex. The means of passing data back and forth from the CGI is archaic and inflexible. For CGI development, you will need a working knowledge of the operating systems' scripting languages (PERL for most, AppleScript for Macs, etc.). CGI may also be designed using C or C++ on any platform. This also means that you must define every query, send the request, and parse the response, manually, by creating executables that access the network and kick that information back to the Web server which, in turn, passes a page back to the browser.
• PERL offers better portability and re-usability, but it does not scale as well as executables do. Since PERL is an interpreted language, it requires the PERL interpreter to load, eating up more CPU cycles and memory. Since these are run-time interpreted, you can break the problem down into various scripts that can be re-used on other projects.
  
  

Vendor-Supplied Server Programs

• if all you need to do is publish corporate information like HR data, consider using an complete product from the database vendor. These server side programs automatically generate HTML tables from your pre-defined data model and have the authentication engines included
• most database vendors have been supplying proprietary application development tools for quite some time. If you've already been using tools like PowerBuilder or PL/SQL, you can almost immediately deploy browser based applications by retargeting the compiled application. Instead of creating a proprietary workstation tool, you create a tool for the Web server that can be used by everyone.