::Coupling::

Coupling refers to the degree of knowledge that provider or consumer has of the other.

Tight coupling occurs when a consumer directly points the provider. This is what request / response messaging styles offered you like CORBA.  You should implement some design patterns or you should have a provider which only maps a request to a different provider from a provider list for achieving a better coupling. However, in request / response messaging styles you have “who, what, where, when” coupling. It is not an easy task to get rid of all these.  Maybe the best way is to have an Enterprise Service Bus (ESB). Anyway, you have to keep in mind that ESB alone does not make you to achieve SOA.

Loose coupling is your design goal to have the minimal interdependency between your providers and consumers. If you modify a provider or consumer, you do not want to modify any other one because of unnecessary dependencies. The easy way to get rid of tight coupling is to choose a reasonable messaging style like publish / subscribe.  You have only “What” coupling by being data-centric. Publishers and subscribers do not point each other.  They only share the same message definition which does not make them coupled. Because you can swap a provider with another one which publishes the same data and consumer cannot understand this swap.  This is a good example of loose coupling. Loose coupling is subject to discussion here. Here, producer and consumers can change implementation without have to modify the contract between them. So that level of coupling can be seen as "not coupling".