Intranets: How To Cut Through The Cob Webs of Internal Information by Robert J. Kohlhepp and Anthony Frey Welcome To The Intranet What is this "intranet?" The latest buzzword surrounding the Web may turn out to be one of the most fundamental shifts in information storage. But in other ways, intranets are nothing new; building an intranet is simply deploying Internet applications on the local network to disseminate information within the organization's boundaries. Most users have become familiar with Web browsers, and intranets bring a wealth of information to their desks via that common interface. As with their Internet Web brethren, adding graphics, interactive methods and continuously updated information to the intranet Web servers can make the best use of computing and people resources. In fact, internal Web servers can be configured to allow users with average computer skills to up date information, such as their address, tax status, and retirement contributions, or to post simple announcements such as for company events. Using one of the various Web-based groupware packages, discussion groups can help employees discuss business issues or collaborate on projects and documents. In this chapter of Network Computing's Interactive Network Design Manual , we discuss the issues of deploying internal Web servers to give your employees universal access to information, including topics such as choosing a Web server software platform, securing your information and getting that information to the users. Consider the Web browser a universal tool for giving your employees up-to-date information from heterogeneous sources. Cross-Platform At Last The primary advantage in using standard Internet types of servers, such as Hypertext Transfer Protocol (HTTP), Network News Transfer Protocol (NNTP), and Post Office Protocol/Simple Mail Transport Protocol (POP/SMTP), is the ubiquity of the browser component. Since your organization's users are probably already using Netscape or another Web browser, they are familiar with that interface and that way of working. Deploying access to internal information in a way everyone can use only makes sense. Most Web browsers are available on a variety of platforms. Whether you have PCs, Macs, or UNIX workstations, a browser exists that can get your users the information they need. In addition, many browsers have incorporated support for NNTP and POP. These protocols give you threaded discussions and e-mail, andcover a majority of groupware functionality. Furthermore, by using the browser, you've eliminated almost all of the GUI development issues. This is no small accomplishment. With an intranet, a three-tier architecture is used. This means that the client asks for information from a central server (an HTTP server in this case), and the server in turn gathers the necessary information from a variety of sources, such as databases. In the custom client/server application scenario, the client does the data requests itself, and so it must be customized to the data being requested. Using a three-tier intranet architecture offers the possibility of easier upgrades, since only the second- and third-tier software needs to be updated, while in a traditional client/server application, when the application needs to be updated so does desktop and file server software--all when no one is using them. If you have specific needs for constantly updated information at the desktop, client-side solutions are available. Java and JavaScript offer a full-featured execution container in Netscape's browser, and other browser vendors are starting to license the technology as well. Rapid Development Most companies would like to make corporate information, such as human resource data, available to their employees at the desktop. In the past this has meant client/server development, which the industry has found hasn't met expectations. With server-based data querying and tools designed to mine that information for HTML use, data is not only easier to get, but also it is formatted for use on any Web browser. Using a three-tier model, we have a client, a server and a data store. Since the client is simply a Web browser, data access development only happens on the server. Clients talk to the server, where they are authenticated and to which they submit requests. The server, if authentication warrants, passes the query to the data store, retrieves the proper information, formats it and sends it back to the user. Development cycles are limited to server-based development. In addition, code can be reused on the server. In the past, applications were standalone, client-side querying devices. Now the server holds all the logic, allowing modules to interoperate a nd to make more complex queries and decisions. You must contend with a few bandwidth issues here. In the old model, clients are very intelligent, requesting only data structures. In a three-tier architecture, the server must collect all the data and then send a fully formatted version to the Web browser. In most cases, this will add more overhead to the transaction. Client-based forms software via plug-ins or Java can help reduce that network traffic. Designing Your Intranet . Implementing Your Intranet . Client-Side Development Options . Updated July 15, 1996 Print This Page E-mail this URL