I came across this article on ZDNet: The bigger the system, the greater the chance of failure
Now, I am all for “bite-size chunks” and Roger Sessions does make a lot of sense. However, simply breaking a system into smaller parts is only part of the solution. The greater problem is the degree of coupling within the system. A monolithic system is inevitably highly coupled. This makes the system fragile and complex. The fragility becomes apparent when a “simple” change in one part of the system has high ramifications in another part. The complexity stems from the number of states within the system that increases exponentially since they are all coupled.
If we simply break the system down into smaller components without removing the high coupling we end up with the exact same problems. This is typically what happens when folks implement JBOWS.
What is required is to break down the system into components and remove the coupling. One option is to make use of a service bus to facilitate sending messages between the components asynchronously. In this way the different components rely only on the message structures in the same way that an interface (as in class interface) abstracts the contract between classes. So in a way it is a form of dependency inversion since the components no longer depend on the concrete component implementation but rather on the message structures (the data contracts).
Coupling comes in two forms: temporal and behavioural. Web services are a classic case of high temporal coupling. Since a service bus is asynchronous it results in low temporal coupling. Behavioural coupling is tricky either way.
