SOA : RPC : : Object Oriented Design : Procedural Programming

Back in 2008, I attended SDBest Practices in Boston. I had recently read Jimmy Nilsson's Domain Driven Design book. One of the contributors to the book was Udi Dahan, so when I say that he was talking at the conference, I was excited to attend his session: How to Avoid a Failed SOA. At that point, I didn't know much about Service Oriented Architecture, but what he described as a failure mode sounded like an architecture I had discussed and planned with coworkers. That session was the start of a journey into learning about SOA.

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."


  1. I also learned tonight that my mental model of cellular communication was incomplete and caused me to make some in appropriate analogies in the past.

    "Cells communicate with each other via direct contact (juxtacrine signaling), over short distances (paracrine signaling), or over large distances and/or scales (endocrine signaling)." - Wikipedia

    I was not aware of juxtacrine signaling and considered paracrine and endocrine signaling to be the same thing. That's what I get for dropping out of college. On the other hand, I did get an A in my only required biology class, so sticking around wouldn't have helped here anyway.

  2. LOL, thanks for the rick roll. :)

  3. I will openly admit that I have a bias against Enterprise Architects. I am working on it, but for now, that was the nicest way I could handle it. ;-)
    Also, I picked the HD version, cause if you're going to do it, do it right, right?


Post a Comment

Popular posts from this blog

Architecture at different levels of abstraction

TFS to SVN Conversion with History