Designing around the constraints of external services in a client-server architecture

Question

Suppose you have a client that interfaces with a server which in turn invokes an external service to fulfill some of the client's requests. I'm designing the client and server and need to accommodate the limitations of the external service. I have these options:

1. Encapsulate (as much as possible) all code dealing with the service's limitations inside the server application.
2. Encapsulate (as much as possible) all code dealing with the service's limitations inside the client application.
3. Design both the client and server applications around the external service's limitations.

I had chosen option #1 because the server application was 'closer' to the external service and I didn't want to have to redesign the client if and when the external service was improved. However, now I'm being asked to choose option #3 by the server-side team so we can deal with the external service limitations in the API instead of by handling exceptions. Is there a design pattern I can reference to convince them (or myself) that one option is preferred? (Separation of concerns looks promising, but I haven't convinced myself that it's sufficient because it could also argue for option #2)

Answer 1

#1 is clearly the correct solution.

The client should know nothing about the implementation details of the server. Adding knowledge of the server's internal topology (that it talks to an "external" service) violates the Single Responsibility Principle and Separation of Concerns and couples your client to the particular current internal implementation details of the server.

From the client's perspective, there is only one "external service": the server. Whatever the server does to compute its response for the client, it is "internal" to the server from the perspective of the client. That is, the client must treat the server is a black box. The client makes requests and gets responses according to whatever protocol is implemented between the two. It should know nothing at all about how the server creates those responses.

Answer 2

IMHO both options 1 and 3 will probably end up looking the same way in the end, unless the server application actually has business logic that can handle limitations of the external service. In other words, the limits of external web service will likely influence the server application interface with the client, so the end result MIGHT be the same.

On that note pursuing 1 is what SHOULD be done. The client in no way needs to directly communicate with the external web service, the only client for the external web service is the server application.

The scenario you describe is where most componentized software applications go awry and develop design smells. The server application team is refusing to acknowledge that business logic integrating with the external web service is their responsibility.

I have been in this situation before and a number of things cause this:

• Server application team being ignorant of componentized software development.

• Server application team is overworked and has a tight schedule, trying to push work back onto other teams

• Selfish manager trying to weasel out of further responsibilities for himself and his/her team.

• Server application team is just being lazy and wants to be a hollow middleman between the external web service and their client.