The Human SOA
I’ve just read a great post by John Pither, a ThoughtWorks colleage of mine, that helps people think about an SOA through the pub/sub model of the physiological systems in the body. Like many middleware vendors, though, I think he’s missing some important facets of an SOA.
While loosely-coupled components interacting with messages using a (typically) asynchronous event-driven transfer mechanism are an important part of an SOA, it’s not the whole picture. At the least, we also have implementation substitution and recomposability to deal with.
So, perhaps the body’s redundancy of certain functions across organs, and artificial implants could be considered implementation substitution (and even dialysis as “outsourcing”?).
I’m struggling with recomposability – you don’t want the ingestion to occur after the excretion, but I’ve seen some automated systems that are equivalent 
. Perhaps when considering organs with long-defunct function, the Appendix of the SOA world will one day be bloatware adapters for systems that don’t use interoperable standards.
And on a slight tangent, if you really want to use an ESB – which may actually stand for “Expensive Spaghetti Box” – take a look at Mule first and give it a try ($0).