SOA: Real Meat, and Potatoes too
James Gosling's recent blog asks the question: "SOA: Buzzworld Whiplash or Real Meat?"
The answer probably requires a change of perspective. Jame's falls into the same trap that I fell in... SOA isn't really about a programming paradigm, it's about a product paradigm.
Let me rush to explain....
To programmers SOA looks a lot like OOP (especially a lot like OOP as promoted by the SmallTalk language). Clearly defined interfaces, message oriented invocation, etc. What's the difference?
To product managers SOA looks only vaguely like OOP. SOA is about composing solutions from mostly pre-existing business services (Pay attention to the business services part).
SOA is about Meat and Potatoes programming (programming to pay the bills). It's not really sexy, and it's not really about anything new.
Most companies already have a lot of legacy assets. They are not very interested in developing a wonderful new object hierarchy. They are very interested in squeezing every last bit of value out of a system that they've already paid for. To a product manager, SOA is the lure that a magic "connector" between a legacy asset and a new-fangled ESB (Enterprise Service Bus) will let the company squeeze five more years out of that old COBOL application.
It's the connectors that make the immediate business case for SOA.
Nobody (well, almost nobody) is creating SOA solutions from scratch. Instead, we're figuring our how to duct tape a snazzy JBI connector onto our 20th century legacy code.
I can't blame you if you're still confused. The sometimes mundane reality isn't much like the hype.
Not wishing to end on a down note, I've got to say that once the messy SOA-enabling slogging of today is behind us, SOA should actually be fun to work with. I just hope that I live that long ;-)
Update: January 9th, 2006
Humphrey Sheil has written a good article examining SOA from a JEE perspective: Can't we just keep it simple? Use SOAs to add real value, not complexity, to Java enterprise applications