\ In the client/server architecture, you need to determine if it will be the client or the server that handles the bulk of the workload. By client, we mean the application that runs on a personal computer or workstation and relies on a server to perform some operations. Thick or thin client architecture is actually quite similar. In both cases, you can consider it as being the client application running on a PC whose function is to send and receive data.. The server would normally communicate that information to the middle-tier software (the backend), which retrieves and stores that information from a database. While they share similarities, there are many differences between thick and thin clients. Thick and thin are the terms used to refer to the hardware, but the terms are also used to describe applications. While this article deals specifically with hardware issues, be sure to check back as we will continue our Thick and Thin discussion as related to applications.

18.3

1. The provision of a stub procedure with the same interface as the called component. 2. The middleware running on computer A accepts the call and discovers the location of the called component.
3. It translates the parameters into a standard format and sends these to computer B along with a request to call the required component.
4. The middleware on computer B converts the parameters into the appropriateformat for the language of the called component and then calls that component.
5. The result is transmitted to the middleware on computer A, which then translates that into the appropriate language format and returns it to the original calling component.

18.8- Application architecture designs exist as models, documents, and scenarios. However, applications must be deployed into a physical environment where infrastructure limitations may negate some of the architectural decisions.

Distributing components across tiers can reduce performance because of the cost of remote calls across physical boundaries. However, distributing components can improve scalability opportunities, improve manageability, and reduce costs over time

Choose communication paths and protocols between tiers to ensure that components can securely interact with minimum performance degradation
Consider separating long-running critical processes from other processes that might fail by using a separate physical cluster, and determine your failover strategy. Scaling up with additional processor power and increased memory can be a cost-effective solution.
This approach also avoids introducing the additional management cost associated with scaling out and using Web farms and clustering technology. You should look at scale up options first and conduct performance tests to see whether scaling up your solution meets your defined scalability criteria.
18.9
All software is hosted on a server and when e.g. upgrades are required, only the server (or servers) need be upgraded. There are no support problems with different computers in an organization running different software versions. The additional costs that can arise from this model are:

1. Network costs, as obviously there is a considerable increase in network traffic. Service providers (such as Amazon) may charge for data uploads and downloads. This is only applicable of the service is provided by a 3rd partyrather than in-house.

2. Server costs, as the servers are responsible for all computation and so must either be more powerful or more numerous.
3. There may in fact be additional support costs from this model in the shorttermif it requires users to change the software that they normally use.