Client-Server computing is the logical extension of modular programming. Modular programming has as its fundamental assumption that separation of a large piece of software into its constituent parts ("modules") creates the possibility of easier development and better maintainability. Client/Server takes this a step further by recognizing that those modules need not all be executed within the same memory space. With this architect, the calling module becomes the "client" (that which request the service), and the called module becomes the "server" (that which provides the service).
The logical extension to this is to have clients and servers running on the appropriate hardware and software platforms for their functions. For example, database management system servers running on platforms specially designed and configured to perform quarries, or file servers running on platforms with special elements for managing files.
It is the latter perspective that has created the widely-believed myth that client-server has something to do with PCs or Unix machines.
The client is a process (program) that sends a message to a server process (program), requesting that the server perform a task (service). Client programs usually manage the user-interface portion of the application, validate data entered by the user, dispatch requests to server programs, and sometimes execute business logic. The client-based process is the front- end of the application that the user sees and interacts with. The client process contains solution-specific logic and provides the interface between the user and the rest of the application system. The client process also manages the local resources that the user interacts with such as the monitor, keyboard, workstation CPU and peripherals. One of the key elements of a client workstation is the graphical user interface (GUI). Normally a part of operating system i.e. the window manager detects user actions, manages the windows on the display and displays the data in the windows.
A server process (program) fulfills the client request by performing the task requested. Server programs generally receive requests from client programs, execute database retrieval and updates, manage data integrity and dispatch responses to client requests. Sometimes server programs execute common or complex business logic. The server-based process "may" run on another machine on the network. This server could be the host operating system or network file server; the server is then provided both file system services and application services. Or in some cases, another desktop machine provides the application services. The server process acts as a software engine that manages shared resources such as databases, printers, communication links, or high powered-processors. The server process performs the back-end tasks that are common to similar applications.
Characteristics of the Client-Server Architecture
The basic characteristics of client-server architectures are:
1) combination of a client or front-end portion that interacts with the user, and a server or back-end portion that interacts with the shared resource. The client process contains solution-specific logic and provides the interface between the user and the rest of the application system. The server process acts as a software engine that manages shared resources such as databases, printers, modems, or high powered processors.
2) the front-end task and back-end task have fundamentally different requirements for computing resources such as processor speeds, memory, disk speeds and capacities, and input/output devices.
3) the environment is typically heterogeneous and multivendor. The hardware platform and operating system of client and server are not usually the same. Client and server processes communicate through a well-defined set of standard application program interfaces (API's) and RPC's.
4) An important characteristic of client-server systems is scaling ability. They can be scaled horizontally or vertically. Horizontal scaling means adding or removing client workstations with only a slight performance impact. Vertical scaling means migrating to a larger and faster server machine or multi-servers.
The Client-server Model
The client-server achitectural model is a distrbuted system msdel which shows how data and processing is distributed across a range of processors. The major compoents of this model are:
(1) A set of stand-alone servers which offer services to other sub-systems. Examples of servers are print servers which offer printing services, file servers which offer file management services and a compile server which offers language translation services.
(2) A set of clients that call on the services offered by servers. There are normally sub-systems in their own right. There may be several instances of a client program executing concurrently.
(3) A network which allows these clients to access these services. In principle, this is not really necessary as both the clients and the servers could run on a single machine. In practice, however, this model would not be use in such a situation. Clients must know the names of the available servers and the services that they provide. However, servers need not know either the identity or how many clients there are. Clients access the services provided by a server through remote procedure calls.
Advantages of Client-Server
Client-server is an open system. The advantages of this environment include:
Interportability - key components (client/network/server) work together
Scaling ability - any of the key elements may be replaced when the need to either grow or reduce processing for that element dictates, without major impact on the other elements.
Adaptability - new technology (i.e., multi-media, broad band networks, distributed database, pen computing, etc.) may be incorporated into the system.
Afford Ability - cost effectiveness is insured by using less expensive MIPs available on each platform.
Data Integrity - entity, domain and referential integrity are maintained on the database server.
Accessibility - data may be accessed from WANs and multiple client applications.
The Relationship of the Waterfall Model to the Client/Server Architecture
The Waterfall Model lifecycle would not be the perfect development tool for the Client/Server Architecture, unless you and the customer have a real understanding what needs to be done.
In the Requirement phase is when the developer and the customer decided what the customer wants and if the developer can develop the system. If they don't get in sync. in this phase then what is given to the customer in the end is not what the customer wants. In the client/server system it is really two systems connected together. The client provides the Graphic User Interface (GUI) or Object-Oriented User Interface (OOUI) element and some form of DSM. In order to give the customer an excellent user interface then it must be spelled out here and if the customer changes his mind or thinks of something more he wants then he has to decide before the requirement phase is signed off. The waterfall model is not a good model to use if there are any kind of GUI or OOUI.
The design phase can only work if the requirement phase is done properly and it is what the customer wants. The design phase is created of the Requirement s Definition and Specification that the developer and customer agreed upon. After entering the design phase there is not any going back and what was decided on at the requirement phase is what the customer will get.
The coding is done after they have done the design phase. If the design phase is done right then this phase should be easy.
Finally at the time when the client reviews the product he can not readily change his mind unless they must start the process all over again and it will be costly. Minor changes will not be a problem because apart of the Maintenance phase they take into account for minor changes. If the client part of the system is not right then the server will be wrong too. The waterfall model is hard to develop a two system at the same time.
The Relationship of the Prototyping Model to the Client/Server Architecture
The Prototyping Model lifecycle is a good method for testing the Client/Server application and locating bottlenecks. It would quickly get a working system up and running, and verify that the overall structure is viable.
Prototyping, the creation and enacting of models based on operational scenarios, has been advocated as useful software engineering paradigm because it lends itself to intense interaction between customers, users, and developers, resulting in early validation of specifications and designs. The prototype goes through the acceptance process with the users and designers. Once the design gets user approval, the application will go through the development lifecycle. After the application leaves the development lifecycle, the customer uses it. The customer will evaluate the functionality of the application. This is an iterative cycle that will result in upgrades and changes to the application and its hardware based on the customer's input.
A two-tier architecture is where a client talks
directly to a server, with no intervening server. It is typically
used in small environments (less than 50 users). A common error in
client/server development is to prototype an application in a small, two-tier
environment, and then scale up by result in an ineffective system, as the
server becomes overwhelmed. To necessary to move to a three-tire
architecture. A three-tier architecture introduces a server between
the client and the server. The role of the server is many fold.
It can provide translation services (as in adapting a legacy application
on a mainframe to a client/server environment), metering services (as in
acting as a transaction monitor to limit the number of simultaneous requests
to a given server), or intelligent agent services (as in mapping a request
to a number of different servers, collating the results, and returning
a single response to the client).
Appropriate use of Client/Server architecture
Universities of companies database systems are appropriate use of client/server architecture. Many people can process data in a current time. The advantages, data integrity, adaptability, and afford ability this would be a great solution for this kind of situation. A specific example would be many terminals connect to the library database system, not each terminal connects to unique system. More information can be found, and it does not take too much time and too many processes to get information. These systems can work more effectively if we use client/server model.
Inappropriate use of Client/Server Architecture
In client/server applications, the server or
servers must have more complex code designs. For this reason, small
type systems or the systems do not need to use database are not good for
client/server design. For these systems, we should design them by
other more simple ways. For example, the window 3xx operating
If the users just only do the edit or some other simple works, those works
do not need too large disk space even they may use the internet to help
them get the information. It means, some of the systems may need
the internet, but they would be inappropriate to use the client/server