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? ;-)
Does Service-Oriented Architecture require the robustness principle?
web services;soa
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 downas services fail, other services which depend on them experience only graceful degradationTo answer the original question:  yes, I think this kind of robustness is (or should be) required in service-oriented systems.