1.1 Client/Server Origins
Most developers are familiar with the basic concept of client/server computing: a central server handles requests from one or more clients. It's the foundation of the Web as described by HTTP and HTML: a web server sends pages to a browser client.
As shown in Figure 1-1, you can see that the client browser initiates the request, which is then processed and responded to by the web server.
Figure 1-1. Web concept of client server
Before the Web really took off, the term client/server was used to describe something slightly different?a central database server that was accessed by custom clients (often written in Visual Basic, C, Pascal, or other languages). Nobody really wanted to run around, constantly installing and reinstalling these custom clients every time there was a bug to be fixed, so people quickly started hooking up smarter, more sophisticated web servers to databases. In order to distinguish these smarter web servers from "dumb" web servers (that served mainly static files), the term application server become popular (in some circles, you'll hear the term web container used as well, usually when the server does a lot more than just handle web data).
As you can see in Figure 1-2, the notion of a client and a server becomes more complex in these systems, often called three-tier systems. The browser is clearly acting as a client of the application server, but the application server is a client of the database. In effect, the application server is acting both as a client of the database and a server for the client browser.
Figure 1-2. Three-tier web system
Consider the system shown in Figure 1-3: note the number of connections, and the number of different roles (client and server) being played by the different systems. These more complex systems are referred to as n-tier systems, because they can have any number of tiers.
Figure 1-3. An N-Tier system
As a mental exercise, consider the following:
How do you debug this system?
Each network connection implies a certain latency and bandwidth overhead. How many connections are appropriate? What happens to the rest of the system if one machine "starves" another by using all its bandwidth or available connections?
How are these connections secured?
What happens if one or more systems crash or otherwise become unavailable?
How do you roll out new applications?
These are tricky problems. When you're working with web services, you'll want to keep these potential pitfalls in mind.
