Tuesday, January 27, 2009

What is SOA?

SOA - Service Oriented Architecture ... what exactly does that mean?

Its an unfortunate fact within the IT industry that there is no single, definitive definition of 'Service Oriented Architecture'. In the early days it was often conflated with Web Services, which is not unreasonable as many resources on the web invariably include Web Services somewhere within their definition of SOA. However, today there are few who still adhere to that view, and some are even amenable to the use of REST.

I'm not going to define SOA here - there's plenty of definitions out there already. Instead, I'm going to take a different tack and consider what we're trying to achieve with SOA. Why are companies attempting to re-engineer their IT infrastructures to be coherent with this vision of 'SOA'?

System Design Principles

System Design is closely related to Systems Theory, being the application of Systems Theory to the development of systems. System Design is a complex subject; however, in its application to software-based System Design it fundamentally comes down to the following principles when defining individual components:
  • High Cohesion
  • Low Coupling
Incredibly, that's about it. No magic bullet. Of course, these two principles have very big implications (such as data abstraction and information hiding, impacts on interface design, contract specification, etc.). But in a nutshell, that's it.

A perfect example of a high-cohesion, low-coupling component is a lego brick. It has high-cohesion by the mere fact that it doesn't tend to spread itself around (unlike, say, air), so you won't find bits of it in places where they don't belong doing things they shouldn't be doing. It has low coupling due to the fact that it physically only has two interfaces that interact with other lego blocks - one that you can plug lego blocks into, and one that can accept lego blocks. Due to this exquisite combination of simplicity and utility, it is capable of being used to construct an infinite number of designs in conjunction with other lego blocks.

However, due to the fact that it has a well-defined set of capabilities (a result of its high-cohesion), this simplicity also imposes limits. A lego block cannot, for example, be used to construct electrical circuits. To build electrical circuits you need resistors, diodes, transistors, capacitors, conductors, and inductors - not lego blocks.

High cohesion and low coupling of components appears to be common in the construction of complex systems, whether they be software systems, computing systems, biological systems, or manufacturing systems. For example, object-oriented design heuristics have high-cohesion and low-coupling as two important properties for well-specified classes, modules and subsystems. In biological systems such as the human body, cells are specialised towards specific functions and predominantly localized to certain organs. The organs, have specialised functions and interface with the remaining body using well-defined interfaces (how else could a surgeon simply replace one heart with another?).

Are high cohesion and low coupling the only principles needed? Not quite ...

No comments: