Do you get only what you pay for with Microsoft's free NT-based Internet applications?
Tom Yager
What's the biggest growth area in network services? The Internet, which is no surprise. IS people are feeling the pressure to make more impressive Web services available to both employees and to people outside the company.
While Unix has so far dominated Web development, Microsoft is now laying claim to providing all the software needed to build and deliver complex applications over the Internet, starting with Windows NT. Microsoft also offers the Web server (Internet Information Server, or IIS), the database server (SQL Server), the
development tools (Visual Basic and Visual C++), and even the glue (Open Database Connectivity [ODBC], Internet Server API [ISAPI], Windows Sockets, and OLE).
Therefore, you pay for NT, the development tools, and, optionally, the database server. However, Microsoft will give away its Web server, its Internet Explorer client, and all the software and documentation needed to crank out custom Internet applications. This not only helps you maximize your limited resources, but the Internet components let technology-shy organizations experiment with distributed applications.
Fine: A single-source vendor is good, and free is even better. But what about technology? Traditionally, Unix has ruled in hosting networked applications, and with good reason. It's mature and highly scalable. Also, all the protocols Internet users take for granted first dawned within Unix. Why develop under NT?
Tables Are Turning
That the Unix world remains splintered and discouraging for cross-platform development is old news. While Unix vendors fiddle, Microsoft is craftily infiltrating Unix strongholds with stable, multiplatform, natively g
raphical NT. Two years ago, Unix might have been the automatic choice for anyone deploying Internet services. Now the tables are turning in NT's favor.
The differences between NT and Unix are common knowledge (see "Which Side Are You On?," May BYTE). What's not as well understood, however, is that NT is, on paper, the perfect Internet application server: It's lean, it's relatively scalable (see "NT Server's Growing Pains"), it's affordable, it has a complete array of standard network services, and its standard file system supports such essentials as striping and mirroring.
It also installs fast, boots and shuts down in a hurry, and has strong security. Unix still can't approach NT's ease of installation and use. Unix does offer an administration advantage: Telnet lets you remotely manage Unix machines over the Internet from any terminal, as long as you have the proper access rights. NT still falls short in remote administration.
The reasons to implement under Unix instead of NT boil down
to one: If you have a significant investment in Unix hardware or applications, stick with it. Yet, even if Unix is what you have, that does not mean that you have to specify Unix forever. NT plays nicely with Unix workstations and servers in the same enterprise. Admittedly, what NT still won't give you are NFS (which you can add) and X Window System. Still, if you are creating Internet applications for use outside your enterprise, these shortcomings hardly matter.
Web Server, Cheap
Microsoft's Web server, IIS, is downloadable for free from Microsoft's Web site (
http://www.microsoft.com
). This is no crippled application or limited-time free trial. Microsoft is giving away a fully functional commercial-quality Web server. It's no surprise that IIS works hand in glove with NT and is
an integral part of Microsoft's Internet applications-development strategy. IIS is a server that answers HTTP, gopher, and FTP requests from clients. IIS takes full advantage of NT's built-in security, even supporting encrypted password exchange for those clients (such as--no coincidence--Microsoft's own Internet Explorer) that support it.
This server is no slouch on other features. Multihoming lets a machine running IIS appear to the Internet as several distinct Web sites.
Virtual directories
hide your system's true directory structure from browsers, improving security and making configuration changes easier to endure. Remote administration lets you manage all the servers in your enterprise from one console.
Microsoft would deserve credit just for building these laudable features into IIS1.0, but the company's vision extends beyond basic services. A key feature for applications development is that IIS is remarkably extensible. A skilled developer can build custom Internet
applications that use IIS to deliver data in a number of ways.
IIS isn't the only Internet server for NT. Among Microsoft's competitors is Netscape, whose cross-platform Netscape Enterprise Server 2.0 runs on both NT and a variety of Unix variants.
NT vs. CGI
Web authors well understand the Common Gateway Interface (CGI) method of extending Web-server functionality. You simply include a uniform resource locator (URL) in your document that points to an executable file on a server. The server will then launch that program, with any required arguments coming from a search request, a form, or the URL itself. The Web server sets environment variables (e.g., information about the client and the connection) before launching the CGI program. A CGI program outputs its results, usually in Hypertext Markup Language (HTML) format.
Because most Web servers have run on Unix systems, CGI programs are normally Unix shell scripts or Perl scripts. NT offers both those language cho
ices, and you can use them with IIS the same way you would if you were running under Unix. The exception, of course, is that many Unix external commands are not standard under NT. The MKS Toolkit from Mortice Kern Systems fixes that and provides a true Korn shell for CGI programming.
Advancing past mere Unix emulation, NT lets you reach beyond basic scripting languages for your CGI executable files. Visual Basic 4.0 runs under NT and is an excellent, more powerful alternative to shell and Perl scripts. It's still an interpreted language, so don't expect light-speed computations.
On the plus side, you can use ODBC and MAPI to bulk up your Internet applications with database access and multiprotocol e-mail. You could use the multimedia features so that the system makes sounds when certain conditions exist or present formatted text and graphics in response to Web users' actions.
Microsoft is making noise now about a leaner--and less capable--BASIC called VBScript. Like Sun's JavaScript, you
could embed VBScript in your Web pages to create active documents. Text-entry validation is one example of a function VBScript could handle. The server wouldn't even see the document until all the required fields were filled and they passed the VBScripted validation tests. You could also embed OLE objects in Web documents that, when activated, would launch VBScript applications on the client side.
There's one serious drawback to using interpreted server-side scripts: Each call to a CGI executable file incurs heavy overhead. The server has to load a sizable interpreter that must load, parse, and run the script file. All this takes time and resources, and it's repeated for every page that includes CGI references.
DLLs Aren't Dull
You can partially solve performance problems by using Visual C++ or another tool that produces stand-alone executable files. These files do not need a run-time interpreter, so they load much faster. Of course, they
run
faster than interp
reted code. However, it's still an imperfect solution: The server must reload that executable file every time a browser activates its CGI link. Microsoft's IIS includes a more efficient mechanism: DLLs.
Microsoft ingeniously allows authors to specify DLLs as CGI executable files. NT will first check to see if the requested DLL is now loaded (presumably by another request for a similar link). If it is already loaded, there's no overhead. IIS just calls the DLL. However, if NT has to load the DLL, it loads into the same process as the Web server itself. IIS can also preload commonly used DLLs and automatically unload them after a specified time.
Because a DLL has no concept of standard input and output (the mechanism through which IIS communicates with other CGI programs), Microsoft uses an API for passing arguments and data between the server and its helper DLL. Part of the broader ISAPI, this procedure sets up communications among client, server, and DLL.
The server calls the entry point
GetExtensionVersion
when the DLL loads and then calls
HttpExtensionProc
for each client request.
ReadClient
,
WriteClient
, and
GetServerVariable
are among the functions that let the DLL communicate with the remote client and IIS. It's a blissfully simple API. Any programmer used to writing C or C++ code won't see a problem with building server extensions as DLLs.
IIS also includes an ISAPI DLL that provides access to databases. You can embed queries and other manipulations of ODBC-compatible databases in your HTML documents. If you run BackOffice on your IIS system, BackOffice's SQL Server component provides efficient and capable database
services to IIS
.
Pure, Filtered HTTP
ISAPI DLLs aren't just for
replacing CGI
programs. You can also create filters using ISAPI. You have the power to intercept every client request, analyze them, and do something clever with them. Maybe you want to
create a customized log program that keeps detailed records of the transactions you care about. You might use an ISAPI filter to watch for hackers who attempt to coax your server into sending files outside your HTML source tree. With matching plug-ins on the client side, you could implement encryption, authentication, or secure traffic. One use might be to prevent underage users from accessing material intended for adults.
You can install as many ISAPI filters as you like by making entries in the registry. Each filter has its own priority level and event mask. The priority determines the execution order for multiple filters. Each filter's event mask tells IIS which client events should pass to that filter. Client requests trigger some events. For example,
SF_NOTIFY_READ_RAW_DATA
lets the filter look at each byte of data before it goes to the client.
Your filter can analyze the data and pass it unmodified. Or, it can modify the data to, say, remove profanities and pointers to GIF images.
Your filter can also tell the server this particular event should fail, in which case the client gets an error message from the server.
Your filter can also find out when a session starts and ends. You can choose notification at the start of secure sessions, nonsecure sessions, or both. If you want to watch the URLs being accessed at your site, the server can feed you the client's URL requests before it maps them to physical locations. With this, you can intercept URLs, even new types, and process them in your DLL.
The combination of the usual CGI and filter DLLs makes it possible to add almost anything to IIS. The ISAPI specification is simple, with easy-to-follow policies for entry points and data structures. You're protected from having to understand anything about sockets and ports. As you write your applications, you can be oblivious to the fact that the user is probably hundreds of miles away.
Sure, you still have the limitation that your responses need to be in HTML format, but mo
re advanced browsers like Microsoft's Internet Explorer and Netscape's Navigator support plug-ins. With custom code on the client side, and Microsoft's ability to support OLE and ActiveX objects in HTML documents, you're able to create complex Internet applications. Those applications can speak whatever language they like to each other, using IIS as a conduit.
Before you conclude that Microsoft is giving away the store, remember its motives: Microsoft is betting that you'll want to buy BackOffice, Visual C++, and Visual Basic to tie all the goodies together. Keep an eye on the Microsoft Web site to see what new browser plug-ins, ISAPI DLLs, and other useful tidbits magically appear. At this writing, Microsoft announced VBScript and its intent to give it away (with a compiler) on its Web site. VBScript has not, however, appeared yet. Until it does, you still have plenty of options for deploying custom Internet applications under NT.
Where to Find
Mortice Kern Systems
Waterloo, Ontario, Canada
Phone: (519) 884-2251
Internet:
http://www.mks.com/
HotBYTEs
- information on products covered or advertised in BYTE
illustration_link (19 Kbytes)
ISAPI sets up communications among the client, server, and DLLs.
screen_link (51 Kbytes)
In IIS's virtual-directory facility, long paths collapse, and hidden drive letters make storage configuration changes easier to manage.
screen_link (40 Kbytes)
You can send IIS log data to an ordinary file or store it in a special table in a SQL or compatible database.
Tom Yager is a freelance writer who operates a research facility in Texas. You can reach him at
tyager@maxx.net
.
NT and the Net
