Client/server ads are proliferating in professional literature and vendors' sales representatives are claiming their product has been client/server for years. One problem in sorting out all of the representations is that there is no agreement on what client/server is. After several months of research in preparation for a monograph-length article on client/server for libraries in Library Technology Reports, the contributing editor has adopted the following definition:
Client/server is a computer architecture which divides functions into client (requestor) and server (provider) subsystems, with standard communication methods (such as TCP/IP and Z39.50) to facilitate the sharing of in format ion between them.Among the characteristics of client! server architecture (as defined above) are 1) the client and server may operate on different computer platforms, 2) either the client or server may be upgraded without affecting the other, 3) clients may connect to one or more servers, 4) servers may connect to multiple clients concurrently, and 5) clients always initiate the dialogue by requesting a service.
Client/server is most easily differentiated from hierarchical processing—which uses a host and slave—by the way in which a PC functions within a system. In client/server the PC-based client communicates with the server as a computer; in hierarchical processing the PC emulates a “dumb” terminal to communicate with the host. In client/server the client controls some part of the activity, but in hierarchical processing the host controls it all. A client PC in a client/server environment almost always does the screen handling, menu or command interpretation, data entry, help processing, and error recovery.
While a client usually is configured on a 386 or 486-based PC (and a server on a Pentium, supermicro, mini, or mainframe), a single machine can act as both client and server on a network. For example, an automated library system in one library linked to another library's system for resource sharing functions as a client when requesting information, and as a server when providing information.
In a typical client/server system, a library staff member or patron formulates a request in the query language of his/her PC or x-terminal (the client). This then is translated into an information request either in standard format (e.g., z39.50) or in a proprietary format understood by the information source (the server). The link between the client and the server may be a Local Area Network within a building, an organization-wide LAN, a Wide Area Network (which links several LANs together using telco circuits), or a specific dial-up telco circuit. Upon receiving a request, the information source (server) retrieves the appropriate data, packages it into a standard form, and ships it back to the PC or x-terminal (client). The server does not need to know the query language of the client to respond to the request. That is why a client can be used to access many different servers.
A GUI (graphical user interface)—a presentation of information to a user via icons and other graphics—is often called client/server, but unless information moves from the server to the client in machine-readable (raw) form, and the client re-formats the data so that it is human-readable, the GUI is not a true client/ server design. Further, there is nothing inherent in the client/server architecture that requires a GUI.
The two major applications for client/ server in a library environment are: 1) as the architecture for an automated library system, and 2) as an approach to linking heterogeneous systems. In the first, a vendor designs a system using client/server architecture to (a) facilitate that system's accessing of multiple servers within an organizational environment that has clients already in use, (b) to facilitate bringing together multiple product lines (DRA and Geac, for example), and/or (c) to improve staff/patron productivity. In the second, a vendor designs the client to facilitate transparent access to systems of other vendors, and the server to facilitate transparent access to its own system from others. While the underlying principles are the same, a vendor has considerable latitude in the design of its client/ server system, but must conform rigorously to standards when using client/server design to link its system with those of other libraries.
An extensive discussion of client/server architecture for libraries along with descriptions of currently available products has recently been published by Library Technology Reports, Volume 30 Number 6 (November/December 1994).