Loose Coupling in SOA Defined

In the debate on whether cohesion is important for SOA, Carlos Perez expressed his views on coupling in software construction, and how it has evolved in the context of an SOA. He starts out with Bertrand Meyer's principles of modularity and extends it to his own set of principles for service orientation.

Carlos first quotes Bertrand Meyer’s original principles of modularity:

1. Modular Decomposability - A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.
2. Modular Composability - A method satisfies Modular Composability if it favors the products of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.
3. Modular Understandability - A method favors Modular Understandability if it helps produce software in which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.
4. Modular Continuity - A method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.
5. Modular Protection - A method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

He then examines and critiques the tenets of service orientation as expressed by various thought leaders in this space like Thomas Erl, Don Box, Stefan Tilkov, and David Orchard.

... [Thomas Erl's principles] is a terrible set of principles because they are overlapping concerns.

... [David Orchard] whose list shows better balance, of course I do have to question the WS-* inclusion.

Based on his own definition of services, he then boils it down to the following principles of service orientation,

1. Decomposability - A method satisfies Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed independently on each item.
2. Composability - A method satisfies Composability if it favors the products of software elements which may then be freely combined with each other and produce new systems, possibly in an environment quite different from the one in which they were initially developed.
3. Understandability - A method favors Understandability if it helps produce software in which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.
4. Continuity - A method satisfies Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.
5. Protection - A method satisfies Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.
6. Introspection - A method satisfies Introspection if it yields architectures that support a mechanism that enables the structure of modules and the structure of their communication to be queried and examined at runtime.
7. Remoteability - A method satisfies Remoteability if it yields architectures that support a mechanism that enables module communication by other modules that are hosted in separate physical environments.
8. Asynchronicity - A method satisfies Asynchronicity if it yields architectures that do not assume an immediate response from a module invocation. In other words, it assumes that latency exists in either the network or the invoked module.
9. Document Orientedness - A method satisfies Document Orientedness if it yields architectures where the messages of inter module to module communication are explicitly defined, shared and that there is no implicit state sharing between invocations.
10. Standardized Protocol Envelope² - A method satisfies a Standard Protocol Envelope if it yields an architecture that requires the sharing of a common Envelope message format across all module communications.
11. Decentralized Administration - A method satisfies Decentralized Administration if it yields an architecture that does not require a single administrator for all modules.

and concludes with a parting shot saying "... that [the] all encompassing term of "loose coupling"; one could essentially derive many of the above properties from it! To summarize, SOA is all and nothing but Loosely Coupled APIs".

What do you think? How much do Bertrand Meyer's principles of software quality apply in the context of service orientation? Be sure to check out Carlos Perez's original post.