October 24, 2007

...Learn TDD with Codemanship

SOA Design Metric - Lack of Cohesion of Services

To be sure, so-called Service-oriented Architecture is a load of old codswallop.

I can remember when we used to called it distributed component-based architecture. Sadly, managers have really bought into the SOA hype, and web services abound - often in places where there have no real business being.

But the idea of different systems or subsystems (or components) collaborating to achieve a business goal is real enough, and it carries design implications that we need to consider. So, just to avoid any unnecessary unpleasentness in the boardroom, let's humour them and call it "SOA" while we ponder the reality of service-oriented design principles.

First, let's break this problem down into two distinct areas of concern:

1. Logical Service-oriented Design, and
2. Physical SOA implementation

I do this because I want to distinguish between the design problems associated with two logical systems talking to each other to achieve some logical goal, and the problems involved in physically getting those two logical systems connected and communicating with each other. They are seperate concerns: and one thing we should strive for in any kind of software design is to achieve a clean separation of concerns.

Today, I'm pondering whether we can take the same principles of dependency management that we use to package code into methods, methods into classes and classes into packages (units of release), and apply them to the problem of packaging services into systems.

Take this example where a package tour operator (along the lines of lastminute.com) needs to collaborate with other systems in order to book hotel rooms and reserve seats on scheduled flights. Each system involved in this business scenario "owns" a set of data - in the form of business objects. The services manipulate this data, transforming the state of these business objects in the course of the booking process.



It looks to me a little reminiscent of the problem of class cohesion - where classes have methods that manipulate attributes. The theory is that things that change together belong together. Packaging behaviour and the data it acts on in the same class helps to localise the propagation of change within that class, which helps prevent changes rippling out to other parts of the system - making change easier and cheaper.

A typical metric used to help us gauge how not-cohesive our classes are - when we define cohesion in this way - is Lack of Cohesion of Methods. The Brian Henderson-Sellers version of this metric is given as:



If every method accesses every attribute, then LCOM-HS would be zero, meaing total cohesion. If none of the methods accessed any of the attributes, LCOM-HS would be greater than 1. Actually, the megric design has some weaknesses - such as tending towards 1 as the number of methods increases and the average number of methods accessing each attribute decreases - think of the extreme case where no method accesses any attributes and there are an inifnite number of methods => LCOM-HS = (0 - infinity) / (1 - infinity) = 1. If M were, say, 2, then LCOM-HS would be 2. I'm not convinced that cohesion increases as the number of methods increases inthat extreme set of cases of apparantly total non-cohesion. But such cases are exceptions, and - as a rough guide - it's a workable indicator of class cohesion.

Could we adapt the formula for SOA? I think so. Just replace "class" with "system" (or "subsystem", or "component"), "method" with "service" and "attribute" with "business object type", and - hey presto! A working metric for Lack of Cohesion of Services (the Gorman-Henderson-Sellers version, of course!).



Now, this is just me thinking out loud, so don't go out and expect to see this metric in the next release of NDepend or anything like that. But, if our goal is to limit the propagation of change across systems in a service-oriented architecture, it seems to make some kind of sense. (Well, as much sense as I usually make, at any rate.)

Now, business data does tend to get duplicated across systems in workflow-type situations. So we would have to be careful here not to attribute "ownership" of objects that are really only only copies of objects stored in another system. How we do that still needs some thought. But as a first attempt, I think we might have the statr of something here that might help us scale our theories about dpendency management up to the enterprise/SOA level. And that is a useful first step towards addressing scalability in feedback-driven approaches to architecture and design.

Which means this could be a step on the way to scaling Agile and evolutionary approaches. (Tomorrow, the world! Ha ha ha ha ha ha ha ha ha ha ha ha ha - pauses for breath - ha ha ha ha ha ha etc...)


Posted 13 years, 2 months ago on October 24, 2007