I was recently asked by a client if the SOA design principles of Service Autonomy and Loose Coupling amounted to the same thing. I thought it was an interesting question, so after some thought, I replied with the following, which I repeat here to help others that may be intrigued by the distinction:
The principle of Service Autonomy says that a service should be independent of external dependencies so that it is predictable in it's run-time behaviour, able to be maintained without disrupting other aspects of an organisation's systems landscape, and implementation decisions such as technology choice can be made in the best interests of delivering the service without affecting the usability of the service.
On the surface of it, Service Autonomy would seem to imply that there should be no coupling at all. That is to say, that coupling of any kind implies the introduction of a dependency. And this is where the distinction exists. Coupling and Autonomy are not the same thing, but they are very closely related. Coupling is about the way in which dependencies are introduced, and by doing so perfect autonomy is compromised. They feel like the same thing, because a balance must be reached between them and they go hand-in-hand.
Within a service boundary, there will naturally exist some tight couplings, and this is not always anathema to Service Orientation. Service Logic will be tightly bound to the service contract in order to implement the appropriate service behaviour, for example. However, it is when we introduce dependencies outside of the service boundary where we should pay careful attention to the manner of coupling.
In this context, loose coupling means that the services that are being coupled maintain as much autonomy as possible. This can be achieved by careful service contract design, and through the use of standards for contract implementation, including standardised schemas.
So, there is a strong relationship between Service Autonomy and Loose Coupling, they can be thought of as two sides of the same coin, but they are not the same thing.