The standard today is moving away from rich clients (often called fat clients) towards thin clients to access a server application. These thin clients are often implemented in a Web-based application working with a Web server. Obviously the reason is not because they supply a richer user interface/experience, but because it costs less to maintain thin clients than rich client installations, which reside on the user's computer.
This is due to client dependence on many different files. A centralized application (Web-based) is easier to maintain, because it consists of only one server or Web server farm (as discussed in Chapter 3) to update when new patches are released. Another benefit of a Web-based application is that the client often only needs a Web browser to be able to connect and run the application. No specific configuration on the client's machine is necessary. You can let Linux-based, UNIX-based, and Windows-based clients connect to your application, as long as they can communicate via HTTP.
The traditional rich client often uses the Distributed Common Object Model (DCOM) to communicate with the server. This is quite tricky to set up, and many different ports need to be opened if the communication is to pass through a firewall. A nice solution to this problem is to use HTTP as a transport protocol instead of using DCOM. The familiar HTTP protocol port 80 is normally open through a firewall by default, and communication with the server is easier to maintain.
Today, the use of fat clients is seeing a renaissance, but this does not change the value of Web services. The use of Web services will be important even for fat clients, because you can create rich clients that access business functions remotely without problems with firewalls and the like. The update and installation process is also managed via Web services for a rich client, installed on the client's computer, which eases the burden on system administrators when installing patches and updates to your applications.