:: What does architecture simplicity mean in an SOA space? ::

"There are going to be complexities in any SOA initiative because SOA, if being a simple basic idea, is complex to realize. As with anything, you have to choose where you want to hide complexity and where you want to show simplicity.

If you want simplicity at design and development time or run time, you will probably have complexity at modification time or use (or reuse) time. You can play with any of these axis, you always end up with one that has to give.

You have to make the choice of where you want to show simplicity and deal with the other parameters. So, here are the choices of what a simple SOA architecture should be:

a) derived from business architecture with a strict functional normalization of services (separation of concerns) to eliminate logic gaps and duplication;

b) based on standardized service contracts and a solid common data architecture, all of which promotes intrinsic interoperability and lower integration requirements;

Of course, this is not simple to design, build, run and evolve and this is where governance is critical: design time governance, development time governance, deployment time governance, change time governance, etc. The organisational structure and retribution should ultimately be designed to weave these concepts in the very culture of the SOA team (but that is another subject).

The reward is a set of stable services positionned as real enterprise assets, that are simple to use and readily available for reuse, composition and swift recomposition whithin many different processes, as business changes dictate."

Jacques Ledoux
Senior Consultant at CGI

::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".