client/server

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 fulfills the request. Although the client/server idea can be used by programs within a single computer, 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 may 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 client/server model has become one of the central ideas of network computing. Most business applications being written today use the client/server model. So does the Internet's main program, TCP/IP. In marketing, the term has been used to distinguish distributed computing by smaller dispersed computers from the "monolithic" centralized computing of mainframe computers. But this distinction has largely disappeared as mainframes and their applications have also turned to the client/server model and become part of network computing. In the usual client/server model, one server, sometimes called a daemon, is activated and awaits client requests. Typically, multiple client programs share the services of a common server program. Both client programs and server programs are often part of a larger program or application. Relative to the Internet, your Web browser is a client program that requests services (the sending of Web pages or files) from a Web server (which technically is called a Hypertext Transport Protocol or HTTP server) in another computer somewhere on the Internet. Similarly, your computer with TCP/IP installed allows you to make client requests for files from File Transfer Protocol (FTP) servers in other computers on the Internet. Other program relationship models included master/slave, with one program being in charge of all other programs, and peer-to-peer, with either of two programs able to initiate a transaction.

Client/Server Architecture
client/server defined:
A description for applications that have a local (client) user interface but access data on a remote server. The application distributes the work between the local machine and the server, depending on the strengths of the frontend and back-end products. Microsoft SQL Server is designed to work effectively in a number of environments: As a two-tier or multitier client/server database system As a desktop database system Client/Server Database Systems Client/server systems are constructed so that the database can reside on a central computer, known as a server, and be shared among several users. Users access the server through a client or server application: In a two-tier client/server system, users run an application on their local computer, known as a client, that connects over a network to the server running SQL Server. The client application runs both business logic and the code to display output to the user, and is also known as a thick client. In a multitier client/server system, the client application logic is run in two locations: The thin client is run on the users local computer and is focused on displaying results to the user. The business logic is located in server applications running on a server. Thin clients request functions from the server application, which is itself a multithreaded application capable of working with many concurrent users. The server application is the one that opens connections to the database server and can be running on the same server as the database, or it can connect across the network to a separate server operating as a database server. This is a typical scenario for an Internet application. For example, a server application can run on a Microsoft Internet Information Services (IIS) and service thousands of thin clients running on the Internet or an intranet. The server application uses a pool of connections to communicate with a copy of SQL Server. SQL Server can be installed on the same computer as IIS, or it can be installed on a separate server in the network. Having data stored and managed in a central location offers several advantages: Each data item is stored in a central location where all users can work with it. Separate copies of the item are not stored on each client, which eliminates problems with users having to ensure they are all working with the same information. Business and security rules can be defined one time on the server and enforced equally among all users. This can be done in a database through the use of constraints, stored procedures, and triggers. It can also be done in a server application. A relational database server optimizes network traffic by returning only the data an application needs. For example, if an application working with a file server needs to display a list of the names of sales representatives in Oregon, it must retrieve the entire employee file. If the application is working with a relational database server, it sends this command: SELECT first_name, last_name FROM employees WHERE emp_title = 'Sales Representative' AND emp_state = 'OR'

The relational database sends back only the names of the sales representatives in Oregon, not all of the information about all employees. Hardware costs can be minimized. Because the data is not stored on each client, clients do not have to dedicate disk space to storing data. The clients also do not need the processing capacity to manage data locally, and the server does not need to dedicate processing power to displaying data. The server can be configured to optimize the disk I/O capacities needed to retrieve data, and clients can be configured to optimize the formatting and display of data retrieved from the server. The server can be stored in a relatively secure location and equipped with devices such as an Uninterruptable Power Supply (UPS) more economically than fully protecting each client. Maintenance tasks such as backing up and restoring data are simplified because they can focus on the central server.

In large client/server systems, thousands of users may be connected to a SQL Server installation at the same time. SQL Server has full protection for these environments, with safeguards that prevent problems such as having multiple users trying to update the same piece of data at the same time. SQL Server also allocates the available resources effectively, such as memory, network bandwidth, and disk I/O, among the multiple users. SQL Server applications can run on the same computer as SQL Server. The application connects to SQL Server using Windows Interprocess Communications (IPC) components, such as shared memory, instead of a network. This allows SQL Server to be used on small systems where an application needs to store its data locally.

Desktop Database Systems While SQL Server works effectively as a server, it can also be used in applications that need stand-alone databases stored locally on the client. SQL Server can configure itself dynamically to run efficiently with the resources available on a client, without the need to dedicate a database administrator to each client. Application vendors can also embed SQL Server as the data storage component of their applications. When clients use local SQL Server databases, one copy of the SQL Server database engine runs on the client and manages all the SQL Server databases on the client. Applications connect to the database engine in much the same way they connect across the network to a database engine running on a remote server. OLE DB Overview OLE DB, a set of interfaces for data access, is Microsoft's component database architecture that provides universal data integration over an enterprise's networkfrom mainframe to desktopregardless of the data type. Microsoft's Open Database Connectivity (ODBC) industry-standard data access interface continues to provide a unified way to access relational data as part of the OLE DB specification. Over time, OLE DB is expected to lead new database products that are assembled from best-in-class components rather than from the monolithic products available today. OLE DB provides a flexible and efficient database architecture that offers applications, compilers, and other database components efficient access to Microsoft and third-party data stores. OLE DB is the fundamental Component Object Model (COM) building block for storing and retrieving records and unifies Microsoft's strategy for database connectivity. It will be used throughout Microsoft's line of applications and data stores. OLE DB defines interfaces for accessing and manipulating all types of data. These interfaces will be used not just by data-consuming applications but also by database providers. By splitting databases apart, the resulting components can be used in an efficient manner. For example, components called service providers can be invoked to expose more sophisticated data manipulation and navigation interfaces on behalf of simple data providers.

OLE DB Overview OLE DB, a set of interfaces for data access, is Microsoft's component database architecture that provides universal data integration over an enterprise's networkfrom mainframe to desktopregardless of the data type. Microsoft's Open Database Connectivity (ODBC) industry-standard data access interface continues to provide a unified way to access relational data as part of the OLE DB specification. Over time, OLE DB is expected to lead new database products that are assembled from best-in-class components rather than from the monolithic products available today. OLE DB provides a flexible and efficient database architecture that offers applications, compilers, and other database components efficient access to Microsoft and third-party data stores. OLE DB is the fundamental Component Object Model (COM) building block for storing and retrieving records and unifies Microsoft's strategy for database connectivity. It will be used throughout Microsoft's line of applications and data stores. OLE DB defines interfaces for accessing and manipulating all types of data. These interfaces will be used not just by data-consuming applications but also by database providers. By splitting databases apart, the resulting components can be used in an efficient manner. For example, components called service providers can be invoked to expose more sophisticated data manipulation and navigation interfaces on behalf of simple data providers.