SOA : RPC : : Object Oriented Design : Procedural Programming
I spend my spare time reading about SOA. I read Udi's blog. I read Thomas Erl's book Service Oriented Architecture. I read SOA in Practice. I played with various ESBs and Message Brokers. I built a pretty sweet prototype of my company's systems using NServiceBus. I even attended the SOA World 2009 conference in NYC and a full week immersion course on SOA taught by Jean-Jacques Dubray. In the end, I never took any of it to production because it didn't align with the Enterprise Architect's vision.
What I learned is that the naive implementation of SOA is to distribute workload in a system by making Remote Procedure Calls to (web) services running on other systems. Unfortunately, this style of architecture runs into the fallacies of distributed computing. Put simply, you can't take a remote call to a database server from your web server that takes X ms and introduce a web service call in the middle and expect it to take less than X ms.
Taking into account things like the CAP Theorem, eventual consistency, CQRS, etc leads to a different strategy. In this implementation of SOA, one focuses on Domain Events and the Messages exchanged by the Services rather than emphasizing the Services themselves. I have often contemplated these types of systems and how they lead to simple, autonomous, easily-redundant, horizontally-scalable Services.
The similarities to OO are striking. Object orientation is also about message passing. In languages such as Smalltalk, we talk about "sending messages to objects" or "objects receiving messages" rather than talking about "calling methods on objects." The characteristics of these OO systems are similar to the what we desire in SOA. They are (or can be) loosely coupled and focus on performing actions rather than requesting at-rest data to be operated on externally.
So when building software, whether a single application or a collection of inter-operating applications that form a complex network with high availability and scalability requirements, remember to focus on the messages, not the Objects/Services. This is what I was thinking about the other day when I tweeted, "I never understood OO until I studied SOA. It's not the object/services that matter. It's the messages."