Loose coupling defined by SOA

In that debate about whether cohesion is important to SOA, Carlos Perez expressed his views on coupling in Software Construction and Its Evolution in the SOA field. He first gave the principles of parallelism (principles of modularity) of Bertrand Meyer, and then extended it to his own set of service-oriented principles.

Carlos first cited the attention principle of Bertrand Meyer:

1. Modullar Decomposability) -- if a software constructor can resolve a software problem into several simple sub-problems, connect these sub-problems with a simple structure, and independently further decomposition of sub-problems, this method satisfies the module factorization.
2. Modular Composability-if a method is used to produce software elements, in the future, a new system can be generated in a way that is freely combined with each other in a different development environment. This method can meet the requirements of Modular Combination.
3. Modular Understandability-if a method is used to produce software from it, human readers do not need to understand other modules (or at most need to study a few other modules) every module can be understood, so this method is conducive to module comprehensibility.
4. Modular Continuity-if a method is used in the software architecture it obtains, minor changes to the Function Specification will only cause changes to one (or a small number) module, this method satisfies the module continuity.
5. Modular Protection-if a method is used in the architecture obtained by it, when a module encounters an exception during operation, it does not affect the module (or only a few peripheral modules can be spread at most). This method meets the protection requirements of the module.

Then, he examined and commented on the service-oriented principles expressed by various thought leaders in the field (such as Thomas Erl, Don Box, Stefan Tilkov, and David Orchard.

...... Thomas Erl's principles are a bad set of principles because they mix up the concerns.

...... The principles of David Orchard reflect a good balance. Of course, I must question why we have included WS.

Then, according to his service definition, he summarized the following service-oriented principles,

1. Decomposability) -- if a method can be used to resolve a software problem into several simple subproblems, connect these subproblems with a simple structure, and independently address each subproblem for further decomposition, this method can be decomposed.
2. Composability-if a method is used to produce software elements, in the future, a new system can be generated in a way that is freely combined with each other in a different environment than the one originally developed. This method can meet the requirements of combination.
3. Understandability-if a method is used to produce software from it, human readers can understand each module without having to understand other modules (or at most, by looking at a few other modules, this method is helpful for understanding.
4. Continuity-if a method is used in the software architecture it obtains, minor changes to the Function Specification will only cause changes to one (or a small number) module, this method satisfies the continuity.
5. Protection-if a method is used in the architecture obtained by it, when a module encounters an exception during operation, it does not affect the module (or only a few peripheral modules can be spread at most). This method is protective.
6. Introspection-if a method provides a mechanism for "querying and checking the module structure and inter-module communication structure at runtime, this method is suitable for self-check.
7. Remoteability-if a method is used, the architecture provided by it provides a mechanism to allow different modules hosted in different physical environments to communicate with them, this method is remote.
8. Asynchronicity-if a method, the architecture obtained by it does not assume that the module call will be immediately responded, the method will satisfy Asynchronization. In other words, it assumes that there is a delay in the network or the called module.
9. Document Orientedness-if a method is in the structure obtained by it, communication messages between internal modules are clearly defined and mutually known, and there is no implicit state sharing between calls, so this method is document-oriented.
10. Standardized Protocol Envelope (Standardized Protocol Envelope)-if a method is developed, the architecture requires that all module communications share a common Envelope message format, this method meets the standard protocol envelope.
11. Decentralized Administration-if a method does not require centralized management of all modules in the architecture it obtains, this method is in line with Distributed Management.

Finally, he said, "As for the all-encompassing 'loose coupling ', many of the above features can be obtained as long as you wish! In short, SOA is just a loosely coupled API ."

What do you think? How many of Bertrand Meyer's software quality principles can be used in the service-oriented field? You must read the original article of Carlos Perez.