Faughnan Home | FP Web Starter | Contact Info | Glossaries and Links | Site Contents
This page was first created in March of 1996. Corrections and minor revisions were made Aug. 30, 1996 and some minor formatting updates in Jan 2000. Special thanks to Richard Donkin for his comments and corrections. All errrors remain my own, like all papers of this sort the information here was obsolete when I first wrote it.
The figures referred to in the text are linked from the end of the text (attachments).
Modern client-server computing requires communication between client and server over heterogeneous networks and operating environments. Communication needs have gone beyond SQL statements to procedure transactions and object-traffic. Middleware software has evolved to serve this communications need, but solutions have been extremely complex, costly, and proprietary. The World Wide Web, the Common Gateway Interface and the Java environment, have become powerful alternatives to traditional middleware. Approaches to join Web and Distributed Object technologies are being developed.
In April of 1995 a review of client/server computer was published in BYTE magazine (Orfali, 1985). The authors described a dazzling range of technologies that would take computing into the "intergalactic" realm. Nowhere is the word "web" or "Internet" mentioned.
Precisely one year later an IBM Executive Overview, published on IBM's web-site, declared that "the web changes the client-server game" (Furey, 1996). In the same month BYTE declared "the Internet and the World Wide Web may be all the middleware you need" (Kador, 1996). Everywhere, Sun's Java programming language is widely proclaimed to be the ultimate solution to all client-server dilemmas.
Many things have changed in 12 months. Or have they? What were the problems with client-server solutions in the 90s? Has the web really solved everything? Can we really discuss Web applications using client-server concepts? What is client-server computing, anyway?
Client-server computing is roughly as old as the Internet; both came into their own in the early 1980s. At the time most business computing was done using mainframe systems. Mainframes centralized data and processes, sending information back to terminals for viewing. The terminals could interpret formatting commands and display data, but they had little processing power.
Microprocessors changed the economics of the mainframe world they made it possible to create workstations or personal computers that could do a great deal more than interpret formatting codes. Database and hardware vendors challenged the mainframe world with client-server solutions. Client software, running on a local computer, allowed a much greater range of local data representation and processing, and supported graphical interfaces. Server software ran on more powerful microprocessor systems, and responding to client queries with streams of data. Systems could be created by small groups without the need for centralized mainframes. SQL database management systems (DBMS), from vendors such as Oracle and Sybase, became widely used.
SQL database servers have been successful, but multivendor interoperability has been limited by proprietary solutions for transaction support and stored procedures. In the 1990s many complex client-server implementations have foundered. The costs of operating and maintaining a network of personal computers has exceeded traditional mainframe costs (Furey, 1996). Users are overwhelmed by complex architectures for next-generation client/server systems featuring transaction processing monitors, multimedia document repositories, and intricate standards for object interoperability (Orfali, 1996).
Much of the problem seems to lie in the domain of "middleware". "Middleware is software that allows elements of applications to interoperate across network links, despite differences in underlying communications protocols, systems architectures, [operating systems], databases, and other applications services (Rymer, 1996)". Rymer describes 10 applications models and 10 communications models that middleware can support. Orfali et al describe four categories of middleware: transport stacks, network operating system, distributed system management, and service-specific, and list several functions within each category (Orfali, 1995) (Figure 1). Software agents fall within many descriptions of the middleware domain. Middleware is complex. It's been called "muddleware" (Rymer, 1996).
The fundamental complexity underlying middleware is exacerbated by political factors. Dominant vendors have the ability to set proprietary standards. In today's world of computing there is only one such dominant vendor: Microsoft. Microsoft is setting its own standards for middleware for database access (ODBC), messaging (MAPI), groupware (Exchange), and object management (Common Object Model, distributed OLE). In each case Microsoft has confounded standards development by exercising its proprietary prerogative.
Extreme complexity, and the Microsoft factor, slowed the progress of client-server computing. Then came the web.
The web initially consisted of a messaging and transport protocol (http), an addressing scheme, a multimedia standard for document elements (MIME), and a human-readable markup language called HTML (see Glossary). All of these components worked under the TCP/IP transport stack. The connectionless transport protocol, and the ability to create hypertext links between documents, produced a relatively lightweight, flexible, environment for very low cost electronic publishing.
This publishing system alone was revolutionary, but the addition of the CGI (common gateway interface) added a new dimension the WWW, and made it legitimate middleware. CGI is a specification for passing encoded ascii character strings from a web server to a target application, and to pass HTML output back to the web server and thus on to the client browser (Figure 2). CGI applications conform to this standard.
Figure 2 illustrates the operation of a CGI/Web application on the Macintosh, using Netscape web browser, the WebSTAR web server, the Web FM CGI, and a FileMaker Pro database. The "server" in this application example is not the WebSTAR web server, but rather the FileMaker database. The client is a Netscape browser. The "middleware" is everything in between: the network and routers (TCP/IP), the web server (WebSTAR), and the CGI (WEB FM).
Identical techniques, often using Perl based CGI scripts, are used on large UNIX based multi-processor servers. In each case the Internet (or intranet), Web, and CGI application together provide some of the functionality of middleware: platform independence, file-based interoperability across heterogeneous domains, scalability, and data integrity (Kador, 1996). Compared to competing middleware solutions the process is simple, transparent to developers, and undemanding.
The incredibly rapid diffusion of this technology even overwhelmed the Microsoft factor, establishing a widely accepted standard (Microsoft, however, is pushing ActiveX as an alternative to the open CGI standard.)
There are several advantages to this unplanned middleware solution. The clients are "lightweight" compared to many SQL DBMS clients, and web browsers are becoming familiar tools to most computer users. Web-CGI systems are relatively easy to implement, and the connectionless protocol lessens the server burden. The absence of a central repository or directory allows rapid growth and evolution. Standards are open and relatively straightforward.
Have we then solved all of the middleware challenges? Not quite. The Web inherits the routing problems of the Internet, even on large intranets, including router overload and circuit congestion. The absence of central directory means that web links are routinely broken when machine addresses or directory structures change. High volume transactions will overwhelm a web server; transaction processing monitors may be needed just as in traditional middleware.
Most importantly, the Web-CGI solution does not permit the migration of objects and agents envisioned by the Object Management Group (Orfali and Harkey, 1995). Or does it? The Java environment, developed by Sun Microsystems, moves beyond CGI limitations (Sun, 1996). Java is an interpreted/compiled language, based on C++, with extensions for object communication and secure execution. Currently Java applets live on the web, on the same servers that provide web pages. When they are invoked they transfer to the user's web browser ,and they can enable that browser to interact with databases located on the web. This can be thought of "middleware on demand". Java's communication, security, and cross-platform features make this a big improvement on pre-existing middleware mechanisms. As of the fall of 1996 server-side Java execution was being developed, and the JDBC standard for Java to database communication is rapidly evolving. "Java promises to do for client/server software distribution what the Web has done for content distribution, by allowing dynamic movement of object oriented software components in the same way as content. As a result, it has the potential to greatly simplify building client/server systems, by allowing dynamic reconfiguration of client/server components as required by changing business needs..." (Donkin, 1996)
Java is being integrated into the Object Management Group's distributed object model of client-server computing. The Object Management Group (OMG) has specified a standard for interobject communication called IIOP: Internet Interoperable ORB Protocol. PostModern Computing has recently released Black Widow, a middleware object request broker which connects CORBA (common object request broker architecture) objects with the World Wide Web and Java applets. Black Widow allows a web browser to communicate with CORBA server objects implemented in Java or C++, either via CGI or the more powerful IIOP standard. (PostModern, 1996)
The early 1990s included some difficult years for client-server computing, but the combination of the Web, the CGI standard, and Java appear to have accelerated client-server implementation and sidestepped technical and political challenges. The next directions for client-server computing will include Java/Web to CORBA server integration, and deployment of active Agents and object-traffic over the Internet and corporate intranets.
Figure I: Client-Server Model Table
Figure 2: Web-Database Architecture