Does Service-Oriented Architecture require the robustness principle?

Question

I try to migrate more and more of our IT infrastructure to a Service-Oriented Architecture (SOA), that means separation of independent tasks and implementation of this tasks as decoupled services, simply accesible via HTTP. If you don't like the term SOA, just put in another - the basic idea is to put functionality in little modules and expose them by well-defined interfaces.

It also means a lot of documentation and communication, because people tend to think in integrated systems. When I combine multiple services to a new component, I always take care to catch errors: if one service fails, the rest of the system should keep on running as best as possible. You probably know the Chaos Monkey, which I keep in mind. However, if other people use services, they tend to think in reliable parts. Does good SOA require the robustness principle? In short, if you use a service, you should not expect to much quality: be aware of any kinds of errors: the service response may not contain all information (missing fields), it may include additional, unknown parts, it may respond very slow, or it may not work at all. Is this a property of loose coupling or am I just to lazy to guaranteeing strict service quality? ;-)

Answer 1

I think you're confusing the Robustness Principle and Robustness in Distributed Systems.

The Robustness Principle says:

Be liberal in what you accept, and conservative in what you send.

If you apply the Robustness Principle, it's very difficult to provide a clear and accurate description of what input your application will accept. In other words, it will harder, and your application more complicated and more difficult to maintain. Even worse is when clients start assuming that "bad but accepted" input is "good" input. I think a good example of the Robustness Principle gone wrong is early versions of HTML and its interpretation by web browsers. I would not recommend applying this principle unless you really know what you're doing.

However, robustness in distributed systems, as discussed in Jeff's article and the comments below, means that you expect failure and design accordingly, doing things like:

• providing multiple servers in case one goes down
• as services fail, other services which depend on them experience only graceful degradation

To answer the original question: yes, I think this kind of robustness is (or should be) required in service-oriented systems.

Answer 2

I think you have to err on the side of robustness.

Consider this: at this time all the developers involved can remember the system as an integrated whole. However, if the SOA approach is actually worth doing, you should end up with several services that can be used in new ways. Used by new users who don't know the history, or even better by external users, who would be very disappointed if they didn't get reasonable service, clear error messages, and easily parsed responses. The principle of least astonishment should guide you here.

Note my caveat - some companies do SOA to be buzzword compliant. Or perhaps only one component needs to be exposed and scale. Or they read that Amazon does it this way. Building each component as a robust, standalone service may be a waste of time.

There will always be components that require sub-services x, y, and z to do useful work. You may not be doing anyone any favors if it tries to soldier on with missing dependencies. Sometimes failing is better than catching everything at the service boundary and hiding the issues.