Chapter 34

Intranet Tools

• Choosing Your Tools
  • Server-Side Includes (SSI)
  • Application Programming Interface (API)
  • Plug-Ins
  • The Common Gateway Interface (CGI)
  • Text Manipulation
  • Nontextual Data Handling
  • Database Interaction
• Languages
  • Content Tools
  • JavaScript
  • VBScript
  • VRML
  • Java
• Interface Tools: Perl
• Prewritten TCP/IP Applications
• Wayfarer QuickServer
• Summary

Now that you've examined some of the content and aesthetic concerns relating to intranet design, the next step is to become familiar with the various tools and resources that you and your staff will use to construct an intranet. Remember that although these tools offer powerful, enticing solutions to your design problems and challenges, you need to make careful and informed decisions when selecting the technologies that will support your intranet. Remember, the right tools and the right design plan will do wonders for your company, its productivity, and your reputation as an IS miracle worker. If you have a great intranet design but attempt to complete it with incorrect or inadequate intranet technology, you may soon be staring a pink slip straight in the face.

In this chapter, you will learn about some of the new technology that is available to make your intranet functional and efficient. You also will examine the steadfast technologies that have helped the Net emerge as the fastest growing and most powerful communications medium in history. After you finish this chapter, you should be familiar with many of the tools available to you as you build your intranet.

Choosing Your Tools

When you're evaluating your company's need for one or more of the many tools and resources available to you as intranet building blocks, you should realize that none of these languages, suites, or applications has been around very long on the intranet scene. In the development world, they're pretty much the new kids on the block, and although people may tout themselves as "Intranet Experts," "Java Gurus," or claim to have installed their first Web server on a Western Union telegraph wire, keep in mind that you're sailing in more or less uncharted waters. Webmasters, IS managers, and CIOs alike are all still learning the benefits and limitations of these new resources and are busily finding the most efficient and appropriate ways to integrate them into current and future intranet systems. Although you do need to put a good deal of thought into the design and development of your intranet, you also should feel free to explore new and creative applications for the emerging technologies and stretch the design limitations from time to time.

One thing that many people forget when they begin to develop an intranet architecture is that "intranet" does not equal "HTML." Although HTML is on many levels an integral part of a successful intranet, it is only one of a growing number of technologies that your development team will ultimately use. Nontechnical managers and end users may often ask why anything more than HTML (and the requisite HTTP server) is necessary for the successful implementation of a full-featured internal site; after all, they simply want to share information, and HTML does that just fine. You can explain that although HTML is indeed a useful tool for distributing text-based information, it isn't necessarily the answer for every information-distribution system. HTML, as a document-development language, is quite adept at simple markup and the presentation of reasonable amounts of static (unchanging) data. HTML, however, is limited in that it cannot (and was never intended to) provide any degree of interactivity whatsoever between the client and the server. The variety of tools that you will undoubtedly encounter during your research have been developed and have proliferated because of the widespread need to extend the basic capabilities of HTML to allow for data manipulation, advanced and dynamic generation of Web pages, and high-level interactivity.

You should address the following five central issues when selecting the tools and applications that you will include within the scope of your intranet:

• Portability: How well your intranet's technology will function across a range of hardware and software platforms (extremely important in a large, heterogeneous environment)
• Scalability: Your system's capacity to expand easily and incorporate large-scale installations
• Robustness: The stability of your software and hardware
• Ease-of-use: How easily both the designers and end users will be able to work with and understand the system
• Complexity: The extent to which your system is capable of handling a wide, ever-changing set of responsibilities or simply a few routine tasks

These factors are integral aspects that you must account for both in the definition of your intranet's functionality as well as in the selection of the tools with which you will build your intranet. By thinking these issues through beforehand, you'll end up saving yourself a lot of time, energy, and frustration. You'll also end up with a much better intranet for your organization.

In the next few sections, I cover some of the key resources you need to construct your intranet, including Server-Side Includes (SSI), the Common Gateway Interface (CGI), the Application Programming Interface (API), prevailing languages used for Web development, and some of the more popular third-party tools and applications used to build corporate and organizational intranets.

Server-Side Includes (SSI)

Using Server-Side Includes (SSI), one of the easiest methods for incorporating semi-dynamic HTML creation into your intranet, is an excellent way to introduce short-term or small-scale functionality into your system. Table 34.1 illustrates the ease with which you can add SSI. SSI is a great tool-especially if you're not a programmer-because it allows you to specify, via HTML-like tags, various points within a Web page that should be generated on-the-fly (such as date/time, the inclusion of standard header/footer files, or HTTP environment variables) when a specific page is requested by the client. It's also great for "quick fixes," intended to be remedied later by full-featured CGIs, because little development time is required to implement SSI. Open your HTML file, specify the type and location of the included information, and off you go.

If you've ever written your own Web page or worked on a Web site, you should feel confident in using SSI after only a brief review of the steps involved. Because SSI is so simple, however, its functionality also is limited to basic, straightforward tasks, and utilizing it for anything other than the most routine, simple operations is usually beyond the scope of what SSI was intended to facilitate. This is mildly compensated by the fact that due to its inherent simplicity, you can easily update and modify your SSI tags to account for changes in your intranet's information delivery requirement.

A good example of SSI would be to include a standard header and footer file reference tag for each page of HTML on your site. If for any reason your header or footer needs to change, you have one point of contact to make a global change instead of changing every page of HTML individually.

Finally, you should note that because of the manner in which Web servers deal with SSI functionality, you experience moderate delays when serving SSI-enabled documents because the server must first read in the HTML file, find the locations within the document requiring SSI data, and then complete the client request by building the full HTML page and transmitting it back to the client. If your data-serving needs are conservative, using SSIs can be a great way to increase your intranet's value. If, however, you need to serve more than small amounts of data, you should seriously consider one of the options discussed in the following sections.

Application Programming Interface (API)

The Application Programming Interface, or API for short, is another of the primary ways to extend a Web site's (or, more specifically, a Web server's) functionality. Table 34.2 illustrates the benefits of using APIs. By loading extension code (offered by many companies such as O'Reilly, Netscape, Microsoft, and so on) onto a machine equipped with an HTTP server that has a defined API, you can extend that particular server's capacity to deal with information, requests, and so on, based entirely on what that particular API has been designed to accomplish. As powerful as standard CGI programs and much more so than SSI, APIs allow your design team to increase your intranet's capabilities significantly.

Because APIs run in the same process as the server and are preloaded at runtime, they are faster than the CGI. Here are some popular APIs and their corresponding HTTP servers:

NSAPI (Netscape API) from Netscape
http://home.netscape.com/comprod/server_central/server_add_ons.html

ISAPI (Internet Server API) from Microsoft
http://www.microsoft.com/win32dev/apiext/isaphome.htm

WSAPI (WebSite API) from O'Reilly and Associates
http://software.ora.com/wspro/wsapi/html/

It should be noted that APIs are not for everyone. Some HTTP servers don't support any API. Generally, APIs are very server-specific. There are no current standards, so don't expect to bring API code with you if you change server platforms. Microsoft implemented the Internet Server API (ISAPI), which they hope will become the industry standard.

The benefits gained from using APIs, however, do not come without a significant cost, in this case an increased risk of having your server die as a result of inappropriate or poorly designed API code. Additionally, the level of technical know-how required to implement an API is well beyond the realm of most system administrators and most likely outside the skills held by many in-house programmers. Therefore, you probably will need to contract with an outside company or programmer to develop, test, and integrate a specific API that will address your needs and concerns.

As with CGI technology, APIs are implemented using standard programming languages such as C or C++ and as such offer a significant level of server-extension capabilities that should not be ignored. Due to the complexity involved in using APIs, however, and the fact that your intranet may be dependent on a high-priced, external source for its API development and troubleshooting, you'll want to consider carefully how strongly you want to embrace this option.

Plug-Ins

If your company currently uses (or plans to use) Netscape Communication's browser as a client for your information services, you'll be more than pleased to learn about plug-ins, a new family of software products that will enable your users to accomplish any number of tasks more easily than you ever imagined. Microsoft's Internet Explorer plans to support the Netscape Navigator Plug-In format. From playing any number of different audio formats to viewing hundreds of different formats of word processing documents, plug-ins provide for an ever-increasing array of possibilities. By virtue of how they work, a plug-in could be written to handle any file type the user could ever dream of. The HTTP server handles requests for files, and files have types. Plug-ins are just extension code that handles new or nonstandard file types.

Using Netscape Navigator as the foundation, the plug-in is installed on the client machine and resides in a directory that the browser knows to look in for plug-ins. Functioning whenever it is called upon (based on requests for a file type it has been written to handle-called MIME in Internet lingo), the plug-in software processes a given set of information and then presents it to the user in-line. This resource is fabulous whether you're considering the in-house creation of specialty software to enhance your intranet or would prefer to purchase prebuilt systems that are ready to go. A great example of this functionality is the Real Audio plug-in (http://www.realaudio.com). Netscape Navigator can't handle a Real Audio MIME type (.RAM) straight out of the box, so the user must install the Real Audio plug-in. Then, when the user requests a Real Audio clip (http://www.realaudio.com/products/server/hpeval/overview.ram), the Real Audio plug-in says, "Hey-I can handle that!" and takes over.

Additionally, as these plug-ins are built by a variety of companies all competing for market share, you will see no end (assuming no huge shifts in browser preference) for the short- to mid-term of publicly available and affordable third-party solutions for your intranet needs. For a list of plug-ins that you can use to extend the capabilities of the Netscape Navigator browser, visit

http://home.netscape.com/comprod/products/navigator/version_2.0/plugins/index.html

The Common Gateway Interface (CGI)

The Common Gateway Interface is a standard for connecting client-based forms with HTTP servers and other tools on the server side. Table 34.3 illustrates the benefits of using CGIs. Unlike standard HTML documents, which are static (unchanging) in nature and content, a CGI-compliant application is executed in real time, allowing for the dynamic generation of complete HTML files, the manipulation of data within a database, or any number of other complex tasks.

One of the most beneficial uses of the CGI, for example, is to create dynamic, or "on-the-fly," Web pages in response to user queries. The CGI receives the query from the client and passes it to the database engine or other specific application, which then completes the requested action. After the request has been processed, the CGI receives the answer from the server-side application and transmits the resulting data back to the client for display. This is a prime example of a CGI database-gateway.

Although CGI seems like a straightforward concept, implementing CGIs on anything more than a basic scale is often extremely difficult, due to the fact that databases, Web servers, and back-end programs often have complex and divergent needs that must be thoroughly addressed. CGIs are also difficult to debug. Additionally, enabling a CGI program on your system is equivalent to allowing a total stranger to run an application on your hardware without your supervision, which has some rather serious security ramifications if your CGIs are sloppy or are designed by inexperienced programmers not familiar with possible security issues. When and if you decide that CGIs are essential to your intranet, keep in mind the following points to create winning CGIs:

• Remember that all CGIs must reside in special CGI directories.
• Be sure to limit access to these directories so that only authorized personnel can write and enable CGIs. (This way, a hacker or inexperienced programmer cannot severely injure your site.)
• Craft your code with speed in mind. If users have to wait, they'll often just leave, never to return.
• Test, test, test. Make absolutely certain that your programs do what they are supposed to do-no more, no less.

Your team can build CGIs for your intranet in a number of different ways. You can select from among C/C++, Perl, UNIX Shells, Visual Basic, FORTRAN, TCL, REXX, and others, which gives you a good deal of flexibility in your design strategy and allows you to benefit from your employees' skills in the particular languages. Keep in mind, however, that each of these tools is different from the next in complexity as well as function, so be sure to evaluate them in the context of your specific project. You would be wise to invest some time researching the specifics of the environments prior to embracing a particular language, especially considering that the platform-language combination that you choose will have an enormous impact on the quality of your intranet. (For more background on programming, see Chapter 22, "Creating a Functional Site.")

Before finalizing your system's development needs, you have to make many choices. To help you get a handle on some of them, review the following sections in relation to what you anticipate as your system's central requirements.

Text Manipulation

In recent years, if your site depended heavily on text searches and large-scale text manipulation, UNIX would have been your first (and probably only) choice. As Windows NT has expanded into a widely-embraced and versatile server platform, however, the power, speed, and graphical interface sported by Windows NT seem to have reduced the UNIX lead, except in the most demanding of environments.

Nontextual Data Handling

Another area in which the Windows platform excels is in dealing with word processing, spreadsheet, and database manipulation. Because of the built-in capacity for Windows applications to share data by virtue of OLE and DDE, writing CGI scripts for this platform provides for a comprehensive and extremely versatile information-processing system.

Database Interaction

Here's a short list of preferred tools for database connectivity-in no particular order:

C++
C
PL/SQL
Perl
Visual Basic
Java

Although a number of competing database systems run under UNIX or Windows, UNIX is the preeminent choice when you're using an extremely high-end data system such as Oracle, Sybase, or Informix because many different gateways have already been created to facilitate their connection to your system. If your data-handling needs are less than legendary, however, you'll probably find the Windows options to your liking, as you can utilize tools like Visual Basic to write interfaces to ODBC-compliant data sources-for example, Microsoft Access, SQL Server, and so on.

The Relative Power of Popular Database Options
High

Oracle
Sybase

Medium

Microsoft SQL Server
Microsoft Access
Paradox

Low

Flat file

Languages

When designing customized software for your intranet, you can utilize a number of different languages. As with any aspect of information systems design, you need to have a thorough grasp of the features each product offers as well as the relative benefits and drawbacks of implementing a particular language. In the following sections, I cover the more popular languages that are prevalent on current intranets. I also cover a few emerging technologies that will soon offer your intranet some exciting options for new and improved data-serving roles.

Content Tools

Some of the easiest and relatively simple languages to work with for intranet design (aside from HTML), content tools work as enhancements to the base functionality inherent to HTML. Generally, you use them to provide error checking for data input through forms (masks), to change various features of the browser, or to perform other easily definable tasks for which the higher-level languages are ill-suited. Working hand-in-hand with the technology underlying HTML and HTTP, content tools are essentially useless without these complementary technologies because the instructions that are created with these content tools reside within the HTML of a particular page and depend on the HTTP server to transmit them to the client.

JavaScript

JavaScript, a compact, object-based scripting language, is one of the latest and increasingly popular ways to create "smarter" HTML pages for your intranet as well as the Internet. Currently, various browser and operating system platforms support different degrees of JavaScript functionality. So, if you decide that JavaScript is the answer to your needs, be sure to find out whether your client workstations are equipped to process your JavaScript code. In general, you'll find that newer versions of Netscape Navigator (and forthcoming browsers from America Online, Microsoft, and Spry) will be ready to take on the task of enabling JavaScript on your intranet.

As a content tool, JavaScript is an excellent choice to make "dumb" Web pages into data-processing geniuses. Well, maybe not geniuses, but by combining JavaScript with standard HTML forms, you can do a good deal of preprocessing to save time, bandwidth, and frustration when your intranet goes online. Because JavaScript statements are included directly (embedded) within an HTML document and are interpreted directly from a browser (requiring no compiler or other traditional programming tools), JavaScript is fairly simple to implement and maintain. It is readable to humans, can be changed almost instantly by an administrator, and requires no supporting software other than the client's browser. One of the most valuable features of JavaScript is its ability to "sense" a user's actions (such as mouse clicks, form input [masks], or page navigation) on the client side and respond to them via a predetermined script.

You can develop a JavaScript function, for example, to verify that users have entered appropriate information within a form field, such as a telephone, Social Security number, or zip code. Without any outbound transmission from the client once the Web page has been loaded into memory, the embedded JavaScript can evaluate the user-provided text and alert the user through an alert dialog box if the input is invalid or otherwise unacceptable for processing. This capability is extremely important if you are considering a database-to-intranet connectivity plan, as you'll want to reduce processing overhead on the server as much as possible and keep bandwidth usage to a minimum so that priority traffic can get through.

You also can use JavaScript to perform certain actions (such as play an audio file, execute an applet, or communicate with a plug-in) in response to a user's actions. Depending on your intranet's needs, or perhaps to enable additional resources for the hearing or visually impaired, JavaScript's sensing capabilities may prove useful.

Resembling Java in many ways, JavaScript lacks Java's static typing and strong type checking, which can be an important consideration if your system needs to perform complex mathematical calculations. JavaScript supports most of Java's expression syntax and basic flow constructs, so if you've got some in-house talent in Java, using JavaScript shouldn't be much of a stretch for you. In contrast to the compile-time system of classes built by declarations that is employed by both Java and C++, however, JavaScript has implemented a runtime system based on a small number of data types representing numeric, Boolean, and string values, which ease development burdens significantly but decrease flexibility. JavaScript also provides a relatively straightforward instance-based object model that still provides significant capabilities despite the fact that it is quite limited in comparison to Java.

As a descendant of smaller, dynamically typed languages, such as HyperTalk and dBASE, JavaScript is accessible to a wider audience than its big-brother counterpart (Java) because of its easier syntax, specialized built-in functionality, and minimal requirements for object creation. Although not a replacement for Java as a Web development tool, JavaScript serves a complementary role by allowing script authors to include limited amounts of Java functionality, including changing the properties and performance of applets, plug-ins, or even certain aspects of the browser itself, including shape, color, and orientation. Table 34.4 outlines some of the more technical differences between Java and JavaScript. These differences are commonly questioned on Internet newsgroups.

You can embed JavaScript in HTML in one of two ways, and depending on how you plan to utilize JavaScript, you should examine both possibilities. Your first option is to include JavaScript statements and functions within your HTML using the <SCRIPT> tag, using the following format:

<SCRIPT LANGUAGE="JavaScript">
Your Wonderful JavaScript Code Functions
\</SCRIPT>

http://home.netscape.com/comprod/products/navigator/version_2.0/script/script
info/index.html

<TAG eventHandler="command1;command2;command3">

<SCRIPT LANGUAGE="VBS">
Sub BtnAlert_OnClick
MsgBox "I no need hall pass!!!"
End Sub
</SCRIPT>

//(Copyright Notice: This source code is (c) Copyright 1995-96, EarthWeb LLC.)
package eweb.awt;
import java.awt.*;
public class Thingy extends Canvas
{int mx, my;
public Thingy()
{mx = my = 50;}
public void paint(Graphics g)
{for (int i=0;
i<size().width-1; i+=8)
{g.drawLine( mx, my, i, 0 );
{g.drawLine( mx, my, i, size().width-1 );
{for (int i=0; i<size().height-1; i+=8)
{g.drawLine( mx, my, 0, i );}
g.drawLine( mx, my, size().width-1, i );}
g.drawRect(0, 0, size().width-1, size().height-1);}
public void Action( int x, int y )
{mx = x; my = y;
repaint();}
public boolean mouseDown(java.awt.Event evt, int x, int y)
{Action( x, y );
return true;}
public boolean mouseDrag(java.awt.Event evt, int x, int y)
{Action( x, y );
return true;}}

http://www.gamelan.com

http://www.sun.com/sunsoft/Products/Developer-products/java/Workshop/index.html

$CRLF = "\n";
$method=$ENV{"REQUEST_METHOD"};
print "Content-type: text/plain",$CRLF,$CRLF;
print "CGI/1.2 report:",$CRLF;
print "              ^^^^^^^^^", $CRLF;
if($#ARGV eq '-1')
{
print "No command args";
} else
{
print "ARGC=",($#ARGV+1),", ARGV: ";
for (@ARGV) { print; print " "; };
}
print $CRLF,$CRLF;
print "Environment variables:",$CRLF;
print "REQUEST_METHOD:  ",$method,$CRLF;
print "SCRIPT_NAME:     ",$ENV{"SCRIPT_NAME"},$CRLF;
print "QUERY_STRING:    ",$ENV{"QUERY_STRING"},$CRLF;
print "PATH_INFO:       ",$ENV{"PATH_INFO"},$CRLF;
print "PATH_TRANSLATED: ",$ENV{"PATH_TRANSLATED"},$CRLF;
if($method eq "POST")
{
$cfile= $ENV{"CONTENT_FILE"};
print "CONTENT_TYPE:    ",$ENV{"CONTENT_TYPE"},$CRLF;
print "CONTENT_FILE:    ",$cfile,$CRLF;
print "CONTENT_LENGTH:  ",$ENV{"CONTENT_LENGTH"},$CRLF;
print "---- begin content ----",$CRLF;
print while <STDIN>;
print $CRLF,"---- end content ----",$CRLF;
}
print $CRLF,"end of report",$CRLF;