04/20/08 :: [SOA] Loose Coupling  [permalink]

|

A couple posts picked my interest today. "Does WOA bring anything new to SOA?" by Mike Meehan. Well, I have already expressed what I thought about WOA and REST so I won't do a repeat here. What I found surprising is that there is actually quite a few people agreeing with some of what I was saying.

If users perceive WOA to be outside the principles of SOA, it could prove an excellent vehicle for building Web-based stovepipes.

The article concludes:

[people] expressed an unequivocal desire to have no more than one something-oriented architecture in their lives

Well someone who is trying single-handedly to topple SOA with a "Something Else Oriented Architecture" is Jim Webber -the MEST guy. Mark Little points out this post by Jim: "Anemic Service Model". I am not sure why. I found his post being completely erroneous. I may be missing something, but Jim is looking at the relationship between Cohesion and Loose Coupling.

He defines Cohesion as follows:

"[Cohesion] measures of the extent to which related aspects of a system are kept together in the same module, and unrelated aspects are kept out."

For me cohesion sounds like a good engineering principle that looks a lot like "Dependency Structure Matrix". In fact Jim concludes:

In fact good software tends to be both loosely coupled and highly cohesive.

This is the part that I find completely bogus (again, unless I am missing something). The goal of loose coupling is precisely to mitigate cohesion as a good engineering principle. You can't be cohesive in a connected system. You can't be both cohesive and loosely coupled. Even in English, associating the two sounds really bad.

The goal of loose coupling is to make to pieces of code work together even though they may have been written at a different time, using different technologies, with a different security model, ...

SOA is about going away from cohesive systems to enable a wider range of reuse scenarios. Nested cohesive systems do provide a "nested" (library-style) reuse model: the upper layers can reuse the lower layers. Unfortunately, it forces us to create systems in a way that is incompatible with the way information systems should be architected. Cohesion is the problem, loose coupling is the solution. Jim, do you really think that people are trying to "keep stuff together in the same module"?

How can you say that when a system is loosely coupled,

even minor changes ripple through multiple components or systems

Have you considered this definition for "Loose coupling"?

The funny thing is that Jim thinks that other people think SOA is best built by "nesting" service invocation in a "Dependency Structure Matrix" style. Jim, I am sorry to say, but this view is what people where talking about in 2001-2002. You need a refresh. The very picture that you think people have of SOA is highly-cohesive.

Then you continue and recommend that people

build out a service that implements [a] process

Jim, what are you talking about a service implements an entire process? for sure that's going to be very cohesive. Now, how can you say that this is an instance of "MVC"? Precisely the fundamental problem with MVC is that is does not have natural boundaries for processes and human tasks. People using MVC keep creating "representations" (i.e. Model), views and controllers that cannot be associated easily to processes and human tasks. Your recommendations and analyses are completely bogus. I would really recommend that you spend more time understanding SOA and less time trying to create specs that are absolutely counter to SOA principles.

You know:

It might sound like a pretty dumb idea that my business stakeholders to become (inadvertent) IT architects.

is one of the dumbest recommendation you can make. You are no George Lucas, there is only one thing anemic about your post, it is your understanding of SOA.