Web Servers

Answers to Questions about...
Web Servers

9. How do I create internal web applications?

Intranets began as client/server networks but have evolved into multi-tier applications systems. An intranet application is software distributed between a web server and web browser, typically with additional functionality provided by such supplementary resources as application, database and directory servers.

All intranet applications are variations on three basic themes: server-side applications, client-side applications and partitioned applications, discussed below.

Server-side applications
... are programs launched on the web server when a browser requests a web page. An early and still useful method for launching server-side processes is the Common Gateway Interface (CGI). With this method, the executable application resides on the server as either an interpreted script (in Perl or Unix shell, for instance), or as a compiled program. The CGI specification allows for the exchange of data between the server application and calling browser. [More on CGI.]

CGI applications are inherently slow and non-scalable because each invocation launches a new server process. To get around this, some Web servers offer an optimized application programming interface (API); examples include ISAPI for Microsoft IIS, NSAPI for Netscape servers, and WSAPI for OReilly WebSite. [More on these APIs.]

There a other server-side application technologies as well, including FastCGI, application servers, Microsoft Active Server Pages (ASP), and server-side includes (SSI). [More on FastCGI, ASP, SSI.]

Client-side applications

...move system intelligence closer to the user. One problem with server-side programs is that they execute browser commands in batch mode. For example, data entered by the user cannot be validated on-the-fly by a server-side application, but must wait for a completed form to be submitted. This can feel awfully like a return to dumb terminal computing.

Early browsers coped with this limitation by enabling the user to set up helper applications: client-side programs associated with a specific content type. For instance, a browser could be configured to launch PKUNZIP (the helper app) when loading a file with the *.ZIP extension. A limitation of helper apps is that they require the full application for each new content type to be installed on on every client.

More efficient client-side solutions have emerged in the form of Java applets, ActiveX components and Dynamic HTML. Applets are chunks of code sent on demand from the server to a client, where they execute in the browser's Java Virtual Machine (JVM). Applets are a platform-neutral, language-specific technology. Their adoption has been hampered by Java's poor performance and differences between various vendors' JVM implementations.

ActiveX components are also chunks of code sent on demand from server to client, but they execute natively only in Microsoft's web browser. They can be programmed in any of several programming languages (e.g., VB, VC++, Java), making ActiveX a platform-specific, language-neutral technology. On the downside ActiveX components are prone to serious security problems because unlike Java, which executes in a protected memory space ("sandbox"), ActiveX has broad access to machine resources.

Dynamic HTML makes use of event-driven scripting languages such as JavaScript that add client-side functionality independent of platform or browser. For these reasons scripting is currenty the most prevalent client-side programming technique. [Resource: Client-Side Corner]

Partitioned web applications
... share the processing load between client and server. The partitioned model allows, for instance, scripts to validate input on the client before sending data to a back-end server where business logic resides. As with traditional client/server partitioning, distributing web applications between browser and server(s) lets developers optimize performance, client complexity, network traffic and reliability.

The future of Internet computing lies somewhere between the fat clients (PCs) and dumb terminals of the past. In particular, the rise of XML as a complementary markup language to HTML implies that client-side parsing and rendering functionality will continue to grow, while business logic and back-end repositories become increasingly accessible via HTTP, IIOP, LDAP, JDBC, OLE DB and other access protocols.