Trim And Fit Client

Pattern name: Trim And Fit Client

Aliases

Distribute Layers two by two, Presentation - Domain split

Context

Correctly distributing behavior in a client-server system is a difficult task. When PC’s were first introduced to major companies, they were most often used as terminal emulator front-ends to existing mainframe programs. These so-called "thin" clients did not take advantage of the capabilities or processing power of the new PC clients, and could not allow for complex user interaction to occur on the client side. In a response to this, the first generation of client-server systems often overloaded the client by placing all of the domain and display logic on the client. These so-called "fat" clients were often characterized by being big, slow, and inefficient at utilizing machine resources (network traffic, CPU horsepower, etc.). In a response to this, the "thin" client model is back in vogue. This time the client consists of a Web browser that accesses dynamically generated HTML pages from a central host. This "Web 3270" approach has the same problems as the original terminal-emulator approach in that all of the processing takes place on the server end, and complex user interaction is not allowed.

Problem

Having seen that both "fat" and "thin" clients are not appropriate, what is the proper, "healthy" division of behavior between client and server? How do you design a system such that the system is responsive on a client’s machine, and yet maintainable and architecturally sound?

Forces

The price of memory, hard-drive space and processor speed come down almost daily. However, it is apparent that the requirements placed on these resources by modern software is expanding at an even faster rate. It is not uncommon to see large-scale client-server programs that take up 15 or more megabytes of memory by themselves. At the same time, these same advances that make client machines more powerful are also making multiprocessor servers more cost-effective. However, most current client-server systems do not take full advantage of this processing power, as the server is most often used only as a data or file server. Therefore:

Solution

Break the system for distribution between the Application Model and Domain Model layers, or at some appropriate point inside the Application Model layer. The upper two layers will reside on the client. The lower two layers will reside on the application server. The application server will use this logic to connect to the storage and DB server. This split will allow the code that receives the most user interaction (the upper two layers) to handle these close to the user. On the other hand, the code that handles the business logic will reside on the server. This makes it easier to design the interaction between the objects in your system if you know ahead of time where in the network these objects will reside.

Consequences

This solution minimizes the amount of processing that must be done on a Client, and can reduce its need for memory and computational power. Note that once a system is broken up this way it does not require that the top two layer be implemented in the same language as the bottom two layers. A heterogeneous system will work if some type of object-to-object communication is provided. It would be perfectly acceptable to write the top two layers in Java, and the bottom two in C++ or Smalltalk, or have the entire system written from top to bottom in one language. So long as an object communication technology like CORBA can be used to provide intra-machine message passing, there should not be any restrictions put on the choice of language or platform.

Related Patterns:

FourLayerArchitecture demonstrates why systems should have clear layer boundaries and how that helps make systems more manageable. ThreeTierArchitecture discusses the choices that go into building your system as three tiers of computation. PhaseInTiers shows how applications can be built over time to take advantage of a three-tier architecture.

I'd need examples to really see how to do this ... but I'm a bear of very little brain. --RonJeffries

Some more explanation (and some later thoughts) are available at http://members.aol.com/kgb1001001/Articles/D-ICM/d-icm.htm -- KB