Just when you think that all the good meataphors for SO applications and SOA have been coined, along comes another one. A collegue of mine recently compared component oriented design (heretofore SOA) to stereo equipment, citing that when purchasing a new system, you have 2 main choices:
1. You can buy a solid-state system with the CD player, AM/FM tuner, cassette deck, turntable etc "baked" right in.
In this case, all of these components are tightly coupled. You can't swap out the CD player for a multi-disc player, or upgrade the turntable to a better, higher quality one. You are pretty much stuck indefinetely with the purchase decision you made the day you forked over the cash to the teenager working the Best Buy counter. Darn! I wish I would have bought the product protection scam, I mean plan!
Essentially, you are stuck with with a monolithic system.
Sure, you might be able to add to it, but now you are adding redundant components. How odd it would be to have, for instance, a single disc CD player and a 6 disc changer. Can the system even support an auxillary player? How many auxillary devices (if any does it support)? Does the device that it came with have to somehow be disabled to add a different device, and is this even supported?
If one of the internal components breaks, what do you do? If anyone has ever had this happen to them, you probably know the answer. The money you may have saved in buying this all-in-one wonder has just been diminished by the exorbatant repair cost that some hole in the wall "authorized" repair shop is going to charge you. First, you will most likely have to pay for them just to take a look. Next, the estimate is going to come in just short (or perhaps in excess) of what a new system would cost.
2. You buy a modular system, starting out with a reciever that supports pluggable, optional components.
Granted, there is a good chance you are going to pay more up front, as even the less expensive, lower end receivers are going to cost you about as much as those all in one packages, but from there, your options are endless. Want to add a 50 disc CD changer? No problem. Ready to move past AM radio to XM satellite? Just plug in the right cable.Think you bought the wrong turntable to play your parent's old 33s? Return it and get one that better meets your needs. Its all about flexibility!
This flexiblity cannot be underestimated and serves as a great metaphor for SOA. Looking back at option 1, why is the cost of repair so high? The reason is that to repair the solid state, monolithic blob of a system requires very specialized expertise. Chances are there is going to be esoteric part ordering and soldering involved. Even if that is not the case, the cost of just having to open up the case is prohibitive because no one want to do it. The labor costs are just too high.
See the connection? How many times have you had to debug a big procedural blob, or, perhaps worse, an object oriented hiearchical mess? I've seen coding horrors consisting of inheritence levels that are 4, 5 and 6 levels deep. To fix something at level 4, you have to understand what's happening at level 3, which means you are going to have to get your hands dirty at level 2 and more than likely in the base class. Who wants to do all this when the bug is at level 4?! This is the problem with traditional OOP and design- any reuse you do get is completely white box because you have to know the internals of each generalizing class.
Sevice orientation, on the other hand is all about black box reuse, achieved through contract-first interaction. If a method is broken, fix the method. Its implementation is out in the open and transparent. Inheritance isn't forbidden, but it should be used judiciously favoring interfaces over abstract classes. This keeps the voodo factor to a mminimum and helps make the system easier to support, understand and maintain.
As I mentioned in the Windows Communication Foundation talk I did at Desert Code Camp II a few weeks ago, each significant innovation in software engineering introduces a reduction of coupling between interdependant parts, and future advancements will be based on this recurring theme.
As my collegue reminded me today, it turns out this doesn't only apply to software engineering.