Intranets: How To Cut Through The Cob Webs of Internal Information Implementing Your Intranet We're also not going to rearchitect your existing network. We're going to assume you already have basic networking infrastructure items in place. Among them are file and print services, e-mail messaging, TCP/IP stacks on servers and clients, and routers and switches configured for IP routing. Although you could include e-mail as an intranet service, if you have an existing e-mail system it doesn't make sense to throw it out. If later on you decide you can benefit from integrating traditional Simple Mail Transfer Protocol (SMTP) systems then you can do it at that time. HTTP, SMTP, NNTP, FTP protocols, as well as custom applications, are the essential functions that you will be implementing on an intranet. HTTP is perhaps the most important as it has the greatest potential for information publishing and exchange. Among all of these services, a good set to sta rt with is a Web server (HTTP), an NNTP news server, and FTP. Since implementing a Web server has the greatest potential payoff, we'll discuss that here. If you're already using a proprietary form of groupware then a news server may not be necessary. The history of the Internet's protocol development means you have a great deal of freedom in building many portions of your intranet. With a little searching, you'll find free versions of nearly every component. It's not necessarily a good idea to build your own from free versions. By building these components yourself, you'll be forsaking support, accountability and in some cases quality. The trouble is, however, many commercial offerings aren't quite ready for prime time. Case in point -- a good commercial news server is hard to find. Netscape now offers one and it is about your only choice. Web Servers and Software. The basic component to your intranet service is the Web server. 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. Though many people will say that UNIX is the only solution for any Web implementation, database connectivity packages exist for any of the platforms we've listed here. 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. You will need to choose Web server software. 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 an d applications external to the HTTP server. Most importantly, 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, not to mention leveraging your group's existing PL/SQL knowledge. In addition, 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. 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. With a small shim here and there, you can add data from various databases across the enterprise. There are many ways to access data from databases. For a most in-depth look at the middleware solutions, you can check out our July 15 Workshop " Making The Right Web Connection ." 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. Be sure to choose a middleware solution that works well with your data stores. One common problem is that Web access is nearly stateless, which doesn't work well for databases that require a session to ensure security. Since the data access engine is really on the server, that server must keep the session open. You should take precautions to make sure the same browser user is still using that session. Usually, simple browser-server cookies are used to maintain the same session. Be sure that your middleware solution allows a time-out on that authentication caching. Info Publishing: Server-Side Development Options Many basic solutions to data access require the server to gather all the information before sending it to the client. CGI, or Common Gateway Interface, is a rather nebulous term that used to mean the scripts or applications run on the server to produce output. Now, it can also mean the functionality built into the server itself via server APIs. Choosing the right solution for you will depend on your needs for scalability and flexibility. CGI The first solution out of the door for making Web pages dynamic was CGI. Using scripts or executables, the server performs some calculation or queries some data source and formats the output to agree with your Web browsers. Simple examples may simply insert the date or tell how may users have visited the page. Using more complex 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. Using some ingenuity (or canned applications), data can be posted to the server for addition to some user accessible pages such as want ads. 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 wel l 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. The API Parade: NSAPI , ISAPI , W*API And BGI Most HTTP servers currently shipping have Application Programming Interfaces (APIs) to allow you to hook into the server. APIs allow direct access to server-side applications that run as part of the Web server. In most cases, this leads to faster and more compact memory-wise equivalents of CGI programs, though no longer portable. In addition, the same programming requirements as CGI still hold. This is not 4GL data access. Netscape offers NSAPI for their servers; Microsoft has ISAPI for the Internet Information Server; Spry has BGI and Quarterdeck just announced W*API for WebStar. These are customer specific augmentations to the behavior of the Web server. By adding your own code to the server, you can allow functions, such as database queries or external authentication, to become part of the Web server itself. Writing directly to a server API will allow that code to be executed in the server's memory space. In addition to saving on memory, that functionality will already be there when a client requests it. CGI requires an external application to be launched, adding to the delay in passing information to the client. CGI resource use is linear with the number of users accessing that function. Functions written to the server's API can be multi-threaded, so one process can service many requests, keeping the memory requirement reasonable. Most organizations will find the API approach server dependent and very coding intensive. These APIs exist mostly for third-party developers. Look for database access tools that are written to the server's API, thereby increasing its scalablility. Vendor-Suppli ed 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. However, most database vendors offer solutions that will only work with their database. The product is actually an application for the Web server that is implemented using the same methods mentioned above, such as CGI, server API, etc. The beauty is the canned solution can speed your delivery time significantly. These tools are much easier to implement than re-inventing the wheel with your own CGI or API programs; however, you will be stuck with the tools they give you and the performance may not meet your requirements. Make sure to test these tools for flexibility and scalability before you implement them. 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. Designing Your Intranet . Client-Side Development Options . Return to Intranets: How To Cut Through The Cob Webs of Internal Information. Rob Kohlhepp , is Technology Editor at Network Computing. He can be reached at rkohlhepp@nwc.com. Anthony Frey , is Associate Technology Editor at Network Computing. He can be reached at afrey@nwc.com. Updated July 15, 1996 Print This Page E-mail this URL