Web Servers

Web Servers started out traditionally serving documents up (with the occasional diagram) much like the stuff you are reading right now. With the introduction of forms, interaction became possible and the limitations of the original design became apparent. Now Web Servers seem destined to reinvent the wheel with the introduction of scaling and Transactions.

Traditional Shortcomings

When you fetched this document you did so using the Hyper Text Transfer Protocol (HTTP). This involved making a TCP/IP connection (possibly through intermediaries), getting the text and then closing the connection. This is fine as far as it goes, but consider what would happen if everybody wanted this page, at once. There is a significant overhead in making a TCP connection and then breaking it and a TCP connection consumes a small portion of a finite resource on the computer which is serving up the page.

Forms have similar problems. Not only is the interaction over a single TCP/IP connection that is made and closed for each form, but also forms invoke programs through the Common Gateway Interface (CGI) mechanism. These individual programs are started, service the request and then exited. Each request has an individual operating system process going through these motions.

Re-inventing the Block Mode Terminal

One of the things that make the Web interesting to TP people is the invention of Forms. At once they can see the advantages of the Block Mode Terminal being re-established on a new platform. Block Mode Terminals, and perhaps the most famous is the IBM 3270 used extensively in TP. They allow messages to be displayed and data to be gathered without recourse to a central computer. This is unlike the character mode terminal this article was written on, for example. There the computer had to process each individual character and key press. Block Mode Terminals also have some intelligence and both the pretty display of information and a bit of data validation can be performed. The model with which these terminals work is one of a Form. So it is no surprise to see the adoption of Forms in Hyper Text Mark-up Language (HTML) being greeted like an old friend.

More recently, with the advent of Java, and to be neutral, shall we also say ActiveX, further tricks can be performed in the display department and a bit or appropriately compartmentalised business logic can be shipped up to the terminal. The same tricks can be performed using a programming language actually embedded within the HTML. The language normally found doing this work is known as JavaScript (which looks like Java, but isn't and is more correctly termed ECMAScript).

Re-inventing the Terminal Concentrator

The Web browser has enormous advantages going for it. It fits over an open and almost certainly existing infrastructure. Notwithstanding the Java Wars, the Department of Justice and Microsoft's attempt at leveraged hegemony it is also platform independent. It can be retrofitted to all manner of displays (even character based ones).

With the ability to serve up forms and to collate the answers, Web Servers make interesting machines, but because of their traditional shortcomings somewhat unscalable beasts. This is of no great importance to the Traditional TP person. The Web Server shall be a terminal concentrator. To understand the reasoning behind this one must understand how traditional TP terminal environments operate. They are almost always connection oriented and hierarchical in nature. The Block Mode terminals are constantly connected to a terminal concentrator which is permanently connected to other network gubbins and so on to the Big Computer in the Centre.

The Web Server itself can be a client to your favourite TP System, through the CGI mechanism and this will allow the solution to scale. The Web Server will not have to scale too much in its own right since the real scaling work will be done for it by the TP Monitor. Further, the machine the Web Server resides on can do other server type things, like printing and file storage.

So Web Browsers are the Terminals of the Future and Web Servers the Terminal Concentrators of the Future. Everything is neat, open and, importantly, cheap.

Big, Big Servers

Neat for shops and banks and the like, but what about the Big Wide World of Internet Shopping. In this scenario we'll have huge Servers serving their forms up to a very large population of Browsers. The fundamental problems associated with the Servers must now themselves be overcome.

There seems to a number of mechanisms that have been proposed or are coming into place which allow Web Servers to scale for this business. On the connection to browsers front Richard Stevens, author of a number of very good books on TCP/IP, had proposed a lighter version of TCP which would be more suited to this kind of work (TCP for Transactions (T/TCP)). The other solution seems to be Web Farms. Web Farms are collections of Web Servers masquerading as one large Server, usually through the mechanism of Address Translation, see RFC1631 The IP Network Address Translator.

Meanwhile, on the back end, the Server needs some way of bypassing the CGI bottle neck. Individual Server suppliers have produced different mechanisms. Netscape and Microsoft have produced two Application programming Interfaces (APIs) for their servers. Needless to say they are mutually incompatible (NSAPI and ISAPI respectively). Apache which is the most widespread of Servers (and is also free, please note) has Apache Modules. All of these mechanisms allow the programmer more direct and tightly coupled access to the Server.

Scripting and Java Serverlets

When the HTML page is served by the HTTP server it is possible to have that server act on programs embedded within the HTML either as a scripting language (like Java Script) or as a Java program. This approach was pioneered by Microsoft with Active Server Pages (ASP). In the Apache world PHP Hypertext Preprocessor (PHP) is the scripting language of choice. Both these mechanisms are interpreted, so performance is not brilliant but they do perform better than CGI. The scripting languages can access databases (via SQL) and can therefore construct content of the fly. The final steps are to use Java to provide that dynamic element by incorporating a Java Virtual Machine (JVM).

Holding the Web Farm with its direct API, the database and the business logical all together however will still require a TP Monitor. The various TP Monitor vendors have proposed various proprietary solutions to this, often incorporating Java and the production of HTML to display results on the fly. There are standards emerging based on the Common Object Request Broker Architecture (CORBA), the Internet Inter-ORB Protocol (IIOP) and Enterprise Java Beans. Find out more about these things by reading our pages on Object Transactions Services (OTS) and Enterprise Java Beans (EJB). Enterprise Java Beans is an important technology and has many big companies and organisations behind it such as Netscape, Oracle, Sun, BEA and most importantly of all, for they own the Enterprise TP market, IBM.

Microsoft are pitching their proprietary TPM, Viper, at this market from day one. There is more on this in an article from Byte, Microsoft's Efficient Transactions.

$Date: 2008/07/03 12:36:10 $