Internet Systems - April 1997

Internet Systems, April 1997 Internet Systems Online: Net Developer By David S. Linthicum

Complexity Revisited

Why Web Development is Becoming More Complex than Client/Server

When I first began to look at the Internet and Intranet as the new platform for client/server development, two things were most attractive: the religious use of standards and simplicity of the architecture. All of the browsers were basically the same, and thus the Web was naturally multiplatform. HTML and CGI were the common programming environments, and HTTP was the common middleware layer. Moreover, the request-download-view-disconnect architecture was easy to understand and use. We were all on the same sheet of music.

Things are changing. As with the early days of client/server, we are moving quickly from the very simple to the very complex. Today there are many different ways to develop and deploy Web applications using all sorts of architectures and enabling technologies. The Web is being sold as an inexpensive and simplistic alternative to client/server, but it's actually becoming more complex. Let's find out why.

Open to Proprietary

Although Web technology such as HTML, HTTP, and CGI is open and nonproprietary, the applications we are building today are mostly tool-dependent. For example, once you build a VisualWave (ParcPlace-Digitalk Inc., Sunnyvale, Calif.) application, you can't run that application with WebObjects (NeXT Software Inc., now part of Apple Computer Inc., Redwood City, Calif.), even if the tools use the same enabling technology. The same problem applies to the client/server world: We are willing to tie an application to a particular tool in exchange for easy development and shortened time to market and deployment.

But the proprietary movement extends beyond the tools. APIs such as NSAPI and ISAPI are proprietary to particular Web servers. Microsoft Corp. (Redmond, Wash.) is building a new version of Java to support its own set of standards. In addition, Netscape Communications Corp. (Mountain View, Calif.) is looking to trade HTTP in for IIOP, and Microsoft is looking to trade it in for DCOM. We are moving further away from the rock-solid standards that drove the Web from the beginning. What's driving this shift?

Why Things Are Changing

There are two major reasons why we are moving from open simple standards to proprietary and complex technology. They are the two Ps: profit and performance. The profit motive is the same as it is in the world of client/server. Tool vendors understand that they will not make money in the Web revolution unless they offer unique value to developers. Such value comes in the form of a tool that does something that other tools can't do, thus making the application dependent on the tool. For example, although a tool may generate CGI scripts, Java source code and/or compiled apps and applets, and database connections to support a particular application, using a proprietary application-control mechanism you can't read most of that stuff into other tools for modification. What's more, many of these tools may also limit you to the brand of Web server and operating system you're able to deploy. Although Web development tool vendors may promote open standards, you're leveraging features found only in that particular tool.

The performance issue surrounds the fact that traditional Web technology was never designed to support interactive applications. HTTP and HTML, which create the infrastructure for most Web applications, were built using a request-download-view-disconnect architecture and cannot process applications interactively.

HTTP, for instance, is a simple protocol riding on top of TCP/IP and can only do one thing at a time on behalf of the Web client. This is a simple architecture, but HTTP is inefficient, establishing a new TCP connection for each request. Developers cannot create multiple requests at the same time over the same connection, nor can they support granular messaging. For example, it takes four connections just to request and download an HTML document. IIOP can support an interactive connection better -- as can Java and ActiveX -- but it does so by moving away from HTTP and CGI.

Common Links

Those who think the Web paradigm is replacing client/server have never worked with client/server. Web and client/server are clearly joined at the hip, sharing many common links including middleware, database connectivity, interface design, middle-tier technology, and especially tools. I can't name a single client/server tool vendor that does not offer a strategy or a tool to deploy its applications to the Web. To tool vendors, the Web is just another platform to support -- or another market. Clearly, Web support is on the critical list for most application development tool vendors.

The trouble comes in when you consider the number of enabling technologies that client/server tool vendors are using to deploy to the Web. For example, traditional Web development tools such as VisualWave are based on CGI, but newer tools use NSAPI or ISAPI or are attached to Java, ActiveX, JavaScript, or VBScript as both development languages and deployment mechanisms. They all have their own mechanisms to offer database connectivity and their own ways of distributing the process load.

Architecture

Another area of complexity is architecture. At first we only had one simple thin-client two-tier architecture, where a Web client would make a request to a Web server, which would serve up HTML and graphics. Pretty simple -- but although this provided a means of serving up static content, there was no means of becoming interactive with the end user.

The use of CGI changed all this. Using a three-tier architecture, developers could create a process on the Web server that was able to pump custom dynamic HTML down to the Web client, responding to the requests of the user. (See Figure 1.) Search engines are the best example of three-tier Internet applications. This was a step in the right direction, but developers were still dependent on the stateless development environments of HTTP and CGI.

Java and ActiveX brought true interactive application development to the Web by supporting the fat-client two-tier architecture. An applet is downloaded to the client, where it runs within the browser as an interactive application. The applet can then in turn link back to a database server using native API -- JDBC in the case of Java, or ODBC in the case of ActiveX.

If you think that's enough to worry about, you're wrong. In the past few months I've seen a rise in the use of additional Web application architectures such as four-tier and n-tier Web application development. When using four-tier, developers employ the traditional three-tier Web architecture but place a TP monitor between the CGI process (the Web server) and the database server. This provides all of the benefits of using a TP monitor, including load balancing and database multiplexing.

When using an n-tier architecture, developers generally layer a set of distributed objects between the CGI or Java processes and the database. With the advent of IIOP, distributed objects can even run on the browser, the Web server, the application server, or the database server. (See Figure 2.) There are also Web architectures that use applets at the browser to communicate with servlets (Java running on the Web server). The applets interact with the servlets, which interact with the database server and the Web server using the native API of the Web server. Of course, you can mix and match all of the architectures I just mentioned to create your own exciting combination of enabling technology that is even more complex than the ones I list. For instance, I've seen a number of projects using servlets to link to both TP monitors and distributed objects at the same time, as well as Java applets linking directly to legacy applications. I've been able to identify more than 10 different architectures in use for Web application development, whereas there are basically just three (with variations) in the world of client/server: two-tier, three-tier, and n-tier.

Normalizing the Industry

So what's the future of Web development? More complexity? More proprietary solutions? That's about the size of it for now -- that is, until the industry begins to normalize itself and a few architectures and enabling technology become commonplace. We also need to reconsider the use of standards; the Java vs. ActiveX conflict is a good example. When the dust settles, only one technology will own the Windows/browser desktop. I think we have another year or so before we can declare winners of this (and other) battles.

This whole concept is a tradeoff. It's disturbing to see developers move away from the standards that made the Internet great, but they are doing so to get around many of the limitations that traditional Web technology places upon them. We are once again moving toward the same "quick fix" for application development as we did with client/server, and this time with more complexity. History always seems to repeat itself.

Figure 1.

-- The three-tier architecture lets you create a process on the Web server that can pump custom dynamic HTML down to the Web client, responding to the requests of the user.

Figure 2.

-- With the advent of IIOP, distributed objects can even run on the browser, the Web server, the application server, or the database server.

David S. Linthicum is a widely published author, speaker, and senior manager with AT&T Solutions Systems Integration Practice in Chantilly, Virginia. You can email David at linthicum@worldnet.att.net.

Please send questions or comments to dbms@mfi.com