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