Client - Server Model

Client/server describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server, which fulfils the request. Although programs within a single computer can use the client/server idea, it is a more important idea in a network. In a network, the client/server model provides a convenient way to interconnect programs that are distributed efficiently across different locations. Computer transactions using the client/server model are very common.

For example, to check your bank account from your computer, a client program in your computer forwards your request to a server program at the bank. That program might in turn forward the request to its own client program that sends a request to a database server at another bank computer to retrieve your account balance. The balance is returned back to the bank data client, which in turn serves it back to the client in your personal computer, which displays the information for you.

The communications method in computing includes Local procedure calls and Remote procedure calls.

In a two tier architecture the workload is divided between the server (which hosts the database) and the client (which hosts the user interface).In reality these are normally located on separate physical machines but there is no absolute requirement for this to be the case.

The distribution of application logic and processing in this model was, and is, problematic. if the client is 'smart' and hosts the main application processing then there are issues associated with distributing, installing and maintaining the application because each client needs its own local copy of the software. If the client is 'dumb' the application logic and processing must be implemented in the database and then becomes totally dependent on the specific DBMS being used. in either scenario, each client must also have a log-in to the database and the necessary rights to carry out whatever functions are required by the application. However, the two tier client/server architecture proved to be a good solution when the user population work is relatively small (up to about 100 concurrent users) but it rapidly proved to have a number of limitations.

Performance: as the user population grows, performance begins to deteriorate. this is the direct result of each user having their own connection to the server which means that the server has to keep all these connections live (using "keep-alive" messages) even when no work is being done.

Security: Each user must have their own individual access to the database, and be granted whatever rights may be required in order to run the application. Apart from the security issues that this raises, maintaining users rapidly becomes a major task in its own right. This is especially problematic when new features/functionality have to be added to the application and users rights need to be updated

Capability: No matter what type of client is used, much of the data processing has to be located in the database, which means that it is totally dependent upon the capabilities, and implementation, provided by the database manufacturer. This can seriously limit application functionality because different databases support different functionality, use different programming languages and even implement such basic tools as triggers differently

Portability: Since the two-tier architecture is so dependent upon the specific database implementation, porting an existing application to a different DBMS becomes a major issue. This is especially apparent in the case of vertical market applications where the choice of DBMS is not determined by the vendor having said that, this architecture found a new lease of life in the internet age. It can work well in a disconnected environment where the ui is essentially dumb (i.e. a browser). however, in many ways this implementation harks back to the original mainframe architecture and indeed, a browser