• TCP/IP
• Domain names and IP Addresses
• Domain name registration and DNS servers
• Ports and services
• Other TCP/IP services
• Web Servers
• Web Server software
• Web sites and HTML Pages
• DHTML
• ActiveX / Java Applets
• Web Server Extensions
• CGI
• Win-CGI
• ISAPI / NSAPI
• ASP
• CGI and ISAPI
• Differences
• Advantages / disadvantages
• Browser based applications
• Internet enabled applications

Web sites on the Internet are known by their Domain Names, such as www.Microsoft.com / www.Datasourceinc.com. Domain names actually resolve to an IP address such as 207.176.25.218. So actually, to get to the DataSource web site one could actually type in http://205.177.16.151 and the browser will take you to the site. But remembering numbers such as these is not easy and so Domain Names were introduced. Domain Names (that end in - .com or .org) have to be registered with an organization called INTERNIC. There is an annual charge of $35 for this registration and the Domain Name has to be unique! When one types in a domain name, the browser actually goes to Internic’s DNS (Domain Name Service) server, that resolves the Domain name to an IP address from a lookup database and gives the browser the IP address of the web site in question. The browser then goes to the IP Address. The IP address is also a unique Address. No two servers on the same network can have the same IP address. The WWW can bee looked at as one big network. Each server on the Internet can be uniquely identified by its IP address. So it follows that typing in the IP address will be a lot faster than using the domain name.

Transfer Control Protocol / Internet Protocol. This is the protocol used by the WWW. For this protocol to work we have what are called clients and servers. These are software applications that can "talk" to each other. The server application has to be up and running and "listening" on a certain port number (just a number from 1 to 65535). The client application that wants to talk to the server application must use the same port number and must know the IP address of the server application. Once a connection is established between the client and server, the two can communicate.

Services such as HTTP, FTP, POP, SMTP are what are called "known services" and therefore use a fixed port.

HTTP: Port 80

FTP: Port 21

POP: Port 110

SMTP: Port 25

Again, the names of the service can be used instead of the port No., such as http://www.datasourceinc.com actually resolves to http://205.177.16.151:80. This really tells the browser and the server to use the HTTP protocol on port 80. Since port 80 is the default port, one need not specify it (and so one normally does not). One is free to use any port for "unknown services". On any one server machine/PC one can have one and only one server application listening on a port. So for a given IP address (that uniquely identifies a PC), you can only one server application listening on a given port.

Web servers are both a physical machine as well as a software application that is listening on port 80. An FTP server is another application (also called service or more accurately TCP/IP service) listening on port 21. So you could have both, an HTTP server (Web server) and an FTP server on one single machine, since they use different ports.

Also one can build ones own TCP/IP applications that "talk" across the Internet using a certain port. The server application needs to be listening on a certain port and the client application needs to know the IP address and the port to use. Only clients can connect to servers. Servers can not initiate a connection by themselves. Servers typically "service" multiple clients and so the name - Server. To learn more about TCP/IP and protocols take a look at th eTCP/IP tutorials in the Tutorials section on my web site.

One can have multiple web site on a single machine. The web server (application) has a way of understanding which site is required by which HTTP request it receives. Web servers have what is known as the "root" folder. The root folder is the equivalent of the "C:\" folder of the hard drive. This root folder can be any subfolder on the HDD but the server needs to be informed of it’s root folder. The web server in turn can not "see" anything before this root folder. This is to provide for some form of security. The root folder is the starting point for the web server. It can "see" all the folders and subfolders in its tree. Most folders are read access only but some are read/write/execute access. Normally, one of the subfolders of the web server is /scripts (or /cgi-bin) and it is only this folder that has read/write/execute access.

The home page is an HTML page in the root folder by the name default.htm. So when a surfer types in the URL (Uniform Resource Locator) for your web site, the web server (application) looks for a file in its root folder by the name default.htm and sends it back, to the surfer’s browser via TCP/IP or more accurately the HTTP protocol which is nothing but a layer over the TCP/IP protocol. The most common and the easiest way to have a web site is to have numerous HTML pages as physical files on the server that are hyper-linked to help navigate through the web site. This kind of site is also called a static web site. Each time you want to make a change to the web site, you have to edit/change/add the HTML pages you want. For large sites this can be a nightmare to manage. Most sites are a mix between dynamic pages and static pages. If some of your web site's information needs to come from a database of some kind, these pages need to be generated dynamically (on request) by some form of script (application programs). Examples are CGI, ISAPI, ASP etc. For your information, the contents of this page are stored in a database. When you linked to this page, an ISAPI application extracted the information for this particular page from a database and dynamically converted the information into HTML format and sent it back to you, for you to see in your browser. In fact this web site is 100% dynamic, which means there are no static HTML pages on the server's hard disk. All content resides in a database and is servered to you dynamically.

Since HTML is very "static" and does not "respond" to the surfer of your web page, Dynamic HTML was introduced. DHTML is a combination of HTML and JavaScript or VBScript. Combining HTML with a scripting language allows for a more dynamic or active web page. Due to scripts embedded within the HTML document the browser is able to respond to certain events, similar to normal event driven programming tools. Events such as mouse moves, mouse clicks etc. are exposed by the browser to your HTML page and the HTML page can in turn "react" to these events. In this way, the HTML pages produced seem to be more responsive or alive than regular static (HTML) pages.

One needs to know one of the scripting languages in order to create DHTML pages. Further, DHTML is supported only by version 4.0 of both IE and Netscape. JavaScript is supported by IE and Netscape while VBScript is supported only by IE. The level of support differs between these browsers. This means that certain DHTML pages may not "work" on all browsers unlike pure HTML (HTML version 3.0 is supported by most browsers in the market today).

ActiveX is Microsoft’s answer to Java applets. Once again ActiveX is supported only by IE version 3.02 onwards, and not by Netscape. Java applets are supported by both IE (3.02 and above) and Netscape versions 3 and is also Windows platform dependent. Besides the incompatibility issue there is a big security risk with ActiveX on a web page. The ActiveX control or document is fully capable. In that, it can access any resource on the PC. It has full access to the Win32API and all of the drives and folders. Ironically, it’s these "benefits" that are the downfall of ActiveX. ActiveX is better implemented in an Intranet environment where the platform is the same, the browser versions are compatible and the ActiveX document comes from a trusted source (such as the internal IT department).

Java applets on the other hand are platform independent. But once again, it due to it’s benefits that it has limitations. The fact that these applets are platform independent means that these applets can not make use of certain functions (API or the UI capabilities) of the operating system. The moment an applet tries to use platform specific features it looses its platform independence. For a Java applet to run in the browser the target machine needs to have the JVM (Java Virtual Machine) installed on it to be able to interpret the Java byte code in the applet. The JVM comes in many flavors and versions and is most times the cause for applet misbehavior on certain machines. Once again, Java Applets are best suited in an Intranet environment where the environment can be better controlled. Java Applets that are very basic in functionality and made for earlier versions of the JVM are and can be used in Internet applications provided of course that the browsers’ version understands them.

Seeing that static HTML is very limited in what it can do, web server developers designed a way to allow programmers to extend their capabilities by providing server extensions. Server extensions in their simplest form a scripts that are executed on the server side with the help of interpreters. Examples of these are Perl and Rexx and later came JavaScript and VB script. Scripts allow for server side processing and return HTML pages. Scripts allowed for data access on the server side as well. So with the help of a script, one could query a database local to the server and in return, send back the result set in the form of HTML that the web server sends back to the requester. CGI (Common Gateway Interface) is the interface that most web servers understand. This interface allows web pages to send parameters to the script via the URL and the script processes these parameters and sends back the information via the standard I/O.

Win-CGI is specific to the Windows platform and Microsoft’s Internet Information Server (IIS) and other compatible web server software. Here, the parameters are sent to the CGI application (normally a .exe file) via an .ini file. The script in turn writes data (the result) in this same .ini file which the web server reads and send back to the requester.

ISAPI (Internet Server Application Programming Interface) is specific to IIS and other IIS compatible web server software. Microsoft, went a step further (after Netscape introduced NSAPI – Netscape Server API) to provide more functionality and faster response by introducing the Internet Server API. Using this API, one has access to the web server’s functionality. ISAPI application can be written with any tool that produces a compiled native machine code output. The compiled code is generated in the form of a DLL (Dynamic Link Library). This DLL is loaded into memory by the web server upon the first request (by a web page) and is kept in memory until the HTTP service is stopped or the machine is re-booted. ISAPI applications have no limitations on the number of parameters that can be passed to them (CGI applications have a limit of 255 bytes). Further, the way the data is transferred or handed to the ISAPI is much faster than the way CGI applications are pass information to and fro.

CGI applications are generally .exe files. This means that each time a request is made via the web server, an instance of the exe is loaded into memory and the data passed to it. This exe file is later unloaded once its job is done. So, if you had 100 surfers hitting your site simultaneously and making the same request, you’ll actually have 100 instances of the CGI application, all loaded in memory at the same time. The system resources required for such a feat are phenomenal. Besides that, the time it takes for an instance of a CGI application to load and initialize causes a performance hit.

ISAPI applications on the other hand are DLL files. A DLL is run in the process of the calling application (in this case the web server application) and only one instance is loaded. The ISAPI DLL has to be built in such a way as to incorporate safe multi-threading. For each request, the web server spawns a new thread and does not need to load and initialize the ISAPI application. Since there is no load time involved and multi-threading is employed instead of multi-instancing, the system resources required are at a minimum and the response times are far less than those with CGI applications.

On the other hand CGI applications, by virtue of the fact that they are .exe files and don’t need to cater for multi-threading are far simpler to build than ISAPI applications. Also, since an ISAPI runs in the process space of its calling application has the capability of crashing the calling application if errors are not handled internal to the DLL. Basically, this means that if an ISAPI DLL crashes, it takes the web server application down with it. This means all web-sites hosted by that web server will not be accessible until the machine is re-booted. This is one of the primary reasons ISPs (Internet Service providers such as AOL, Erols etc.) do not allow ISAPI applications.

Web applications or browser based applications use the browser as the front end with some form of web server extension application (CGI/ISAPI/NSAPI/ASP) running at the back end. Ideally these applications are a very powerful technology. They are zero configuration thin clients. Which means, the surfer has to do nothing on his/her PC to be able to use these applications. They are platform independent as well as browser and browser version independent. But in reality, these applications are never zero-configuration. Due to the speed with which technology is moving and the inability of individuals to keep upgrading their machines, operating systems and browsers, the zero configuration thin client can not use the new and emerging technologies. Thus browser- based applications will always have to built to conform to earlier versions of operating systems as well as browsers.

Besides the compatibility issues stated above, browsers, by their very nature are isolated from the PC, such that they can not access the resources of the machine they are running on. Therefore they are very limited in their capability to integrate/interface with existing systems or use the Os’s API or GUI capability for better and more functional/feature rich UIs. Even in corporate environments, where operating system versions and browser versions can be controlled, these kinds of applications are not the best suited for such a need as 9 times out of 10, these applications will need to interface/integrate with existing systems in the corporate environment.

Browser based application therefore tend to be used for very simple needs.

These are applications built as normal PC based applications but access data over the Internet. Effectively, these applications use the Internet infrastructure as their network. This allows for remote connectivity to data from anywhere in the world. Similar to browser based applications. With the advantage of being able to access the resources of the machine on which they are executed and thereby allowing for integration with other existing corporate systems.

On the GUI side, these applications are fully capable, thus allowing for "standard" features such as drag/drop, tree-views and list-views (like in windows Explorer [not Internet Explorer]). This not only gives the user of the application an interface s/he is familiar with but also saves on training needs. The UI is not limited in any way.

Advantages and Disadvantages of Web based and Internet based Applications

Each technology has its place. Where a simple data entry, data view and reporting capability is required, browser based applications are very well suited. On the other hand, if you require the full functionality and capability of a standard PC application as the front end, but need the "remote" connectivity as well, then Internet enabled applications are ideal. In most corporate scenarios, you will find a combination of browser based and Internet enabled applications. For the simple user or "on off" user (surfer) you’ll find a web interface and for the power/corporate user you’ll find Internet enabled applications.

When the user/surfer is unknown, that is the browser type, platform etc. in not known or controllable, a browser-based application has its advantages. On the other hand, if cross-platform is not an issue and the environment can be controlled to a high degree, then Internet enabled applications are the right choice, due to their interfacing/integrating capability and UI capability.