Every communication book I ever saw had a page of topology diagrams that showed the StarNetwork? as a starting point from which to generalize to truly interesting configurations. My peers and I have always looked down our noses at anything labeled client-server without actually realizing that the issue has nothing much to do with topology.
The real issue is division of responsibility in the presence of two masters. Consider business: The business put in the first computer and expected it to serve business needs. These were largely related to enterprise integrity. Now forward-looking businesses provide employees with personal computers. These computers serve their users by increasing personal productivity. It is important to understand this fine distinction. The client computer serves the user who serves the business. The client computer does not serve the business directly. With this distinction clearly in mind it becomes much easier to allocate responsibilities and design protocols in client-server systems.
JohnTibbits? first made this clear to me. -- WardCunningham
(Can someone generalize this argument for the unique client-server properties of the world wide web?)
I always considered "client/server" architecture to be FatClients with at least network/remote RDBMS access via queries instead of file-based table access (such as "LAN databases" that came before). Most of the business logic happend on the client, but "large-scale" processing was done on a database server using either queries or StoredProcedures. This differs from web-apps, which has most of the business logic on the server and uses web browsers. They had rich GUI's, but difficult deployability. --top