Client/Server Computing

The expression client-server has become one of the biggest buzzwords of the 90's...

The basic idea:

An application, which would previously have been hosted on a mainframe system using terminal access, is split into separate parts.
A server system provides the data management and storage aspects of the application. The server could be a traditional mainframe, a medium sized business system, a Unix system or (more rarely) a high-end PC running a proprietory network server OS.
A client system provides the user interface, and may formulate queries and transactions which are sent to the server for execution. Clients are commonly PCs, but can also be Macs, Unix workstations or even X terminals.
One distinguishing feature of client-server systems is the existence of co-operative processing. Both the client and the server participate in the information processing functions of the overall system.

Reasons For Client Server

Many opinions exist as to why client/server computing is attracting so much interest. The following seem important to your lecturer�

The emergence of the end user desktop computer system during the 1980's, typified by the IBM-PC and the Mac. These are characterised by:
- "User friendly" interfaces
- Cheap, and increasingly very powerful.
- It quickly became obvious that, whilst users of such systems could throw togther quite sophisicated software applications, such solutions would not scale to the enterprise level.
The increasingly outdated mainframe-centric big-bang, data centre and terminal-based EDP departments were faced with justifying their very (expensive) existence. The solution, it seems, is to re-invent the data centre as the server in a new client/server world.
The trend to downsizing, outsourcing and all the other economic rationalist evils of modern management...

More Definitions

The conventional "network file server" architecture used in many PC systems (eg Novell, Appletalk) is not, of itself, a client/server relationship in the modern sense. For example, just because you can "word process" a shared document stored on the server does not imply co-operative processing.
The client-side software is usually carefully designed to have the "look and feel" of existing PC (or Mac, or whatever) software. This software is usually developed using high-level, object oriented software development systems.
One of the early applications of client/server has been in the database market, with companies such as Oracle, Ingres, etc, positioning themselves as ideal choices for the server side.
The LAN is fundamental to the emergence of client/server. Not so obvious is the choice of protocol architecture to support its operation: TCP/IP, Novell, LANmanager, etc.

Middle-Ware

A moderately mis-used term, in general this means any software which eases the integration of desktop systems with traditional big-iron database applications. For example:

A user interface builder can provide a set of libraries which allow a single user interface to be built for various platforms, complying with their respective "look and feel" rules, from the same source code.
A vendor may provide a standard set of SQL functions which can be used with any DBMS system. An early example of this was Apple's "Data Access Language" server, which runs on most mainfame servers and interoperates with most DBMS's.

A key phrase in middle-ware is the API (Application Programming Interface) which it provides: programmers can "write to the API" regardless of the final OS on which the software will run, or the DBMS with which it will interact.

Communications Architecture

As stated previously, the LAN is the underlying basis of client/server.

Atop the LAN, two communications models are common:

Connection-oriented

the comms subsystem guarantees reliable transfer, and messages are sent and received as �encoded byte streams�. This is the type of service provided by TCP in the Internet protocol architecture. Most other network architectures have an equivalent transport layer service.

Remote Procedure Calls

this is an alternative way of thinking about the transport layer (or, more correctly, the session layer!) as a means of data transfer.

two different machines interact using a proedure call/return model, just as within a program.
the procedure which is invoked may be local, or remote, with complete transparency.

TCP-based Client/Server

Recall that in TCP, the terms client and server already have well-defined meanings. This makes discussion of client/server computing somewhat problematic in this context :-)

A typical TCP-based client/server system relies on a database "front end" on the server system, which acts as a TCP server process, accepting connections from client systems at some port number. Some interesting aspects of this include:

How is authentication managed? For example, should the front end require a user password before granting access to the database? Or will a simple reverse-lookup of the client's IP address suffice? If a password is required, is it stored or entered for every session?
What does the application-level protocol look like? For example, are the queries which cross the TCP connection simply SQL, or are they encoded in some way? And if encoded, does the encoding follow any standard?

Nevertheless, such connection-oriented systems are very popular for client/server.

Remote Procedure Calls in TCP/IP

The Internet standard RPC system was developed by Sun Microsystems as part of their NFS (Network File System) specification. Other architectures may provide an RPC system, but the Internet RPC is now pretty well standard.

RPC is based on the conventional programmer's view that a procedure call contains the name of the procedure, and a parameter string, thus:

call thatProc(x, y, z);

This call does not return until the procedure has completed execution. The return value(s) are read from the parameter string upon return.

A key problem is the representation of parameters. If the client and server are not identical machines running identical software, then internal representations may be different. In Sun RPC, this is solved by running every RPC call/return through the XDR (eXternal Data Representation) libraries.

Note that XDR is another approach to the problem that ASN.1/BER also solves.

Other Client/Server Applications

Whilst the majority of "real world" (ie, commercial) applications of client/server are in database applications, there are some other nice examples on the Internet:

The World Wide Web (WWW) information system is an excellent example of client server "done right". A server system supplies multimedia documents (pages), and runs some application programs (HTML forms and CGI programs, for example) on behalf of the client. The client takes complete responsibility for displaying the hypertext document, and for the user's response to it. This will be expanded upon in the next lecture.
The POP-based electronic mail system used by most staff within the Department of Information Technology at Bendigo, using Eudora as the client software, is a very good client/server application.

This lecture is also available in PostScript format. The tutorial for this lecture is Tutorial #20.

Phil Scott