SOA. Let’s remove some of the confusion.

Before you can talk about what Service Oriented Architecture (SOA) is, you need to understand the difference between an architecture and an architectural style.

Udi Dahan defines an architectural style as the, “Do’s and the Don’ts. The Rules. Thou shalt do this, thou shalt not do that in your architecture. But it’s not meant to be a complete form of your architecture. It’s a subset.” (Dahan, ADS Course).

The architecture of your project, your application, or your system will and should be comprised of multiple architectural styles.

For example, in the typical n-tier style application you might make use of MVC on the front-end, layers and onion architecture in the back end, etc.

You have probably used many different architectural styles before and didn’t know it. That’s because many of the things we call architectures are really architectural styles. Layered architecture, onion architecture, hexagonal architecture; these are all really styles and not all inclusive architectures unto themselves. Sometimes we aren’t even lucky enough to have the word architecture to identify it; for example, MVC, bus, and pipes and filters.

So I like to think of architectural styles as the ways we can go about implementing something and an architecture as the actual implementation of those styles we chose to work with.

The idea of styles doesn’t mesh well with most people, “[we] prefer cookie-cutters. Just do everything this way and everything will be ok. Unfortunately, we are building systems that are more complex than that so we have to get [deeper] into the details.” (Dahan, ADS Course)

The Do’s and Don’ts of SOA

So back in the day a bloke named Don Box at Microsoft came up with the four tenets of Service Orientation and they are:

1) Services are autonomous.
2) Services have explicit boundaries.
3) Services share contract & schema, not class or type or databases.1
4) Service interaction is controlled by policy.

So there you go. That’s it. That’s the do’s and don’ts of service oriented architecture. It’s really quite simple… almost too simple. And therein lies one of the issues with its adoption. It is so wide open you are left to interpret a lot of things. Like Udi said we as developers really want that cookie cutter recipe or formula to follow. When we start having to spend brain cycles on something other than coding we start to lose interest.

The simplicity of SOA is its greatest strength; it’s also its reason for low adoption and inappropriate implementations. It sucks that we don’t have much to go on as far as instructions on implementing it. Yet it’s not a bunch of rules binding our hands so we have a lot of freedom to build our system the way it needs to be built. One thing that helps to here is to reiterate that SOA is an architectural style. So when we apply SOA we will most definitely need to apply other architectural styles to create a full architecture for our systems and or applications.

What SOA is NOT

Now that we recognize the service oriented architectural style for what it is we can start taking a look at how it’s being misrepresented and remove some of the confusion about what it is.

1) SOA is not web services (building web services != SOA).

First let’s define what a Web Service is:

Any service whose functions can be invoked via a web call. – The Real Justin Self

An HTTP API call that allows one computer to talk to another computer. (Me: does it have to be over HTTP?). Yes, because when we say web we mean HTTP. – Jeffrey Palermo

A web service linguistically sounds like it should be a type of service. But when you think of a web Service as a “thing” and then compare that “thing” to the tenets of SOA it falls short of items 1 and 2. Especially because web services have a strong inclination to be a request/response communication. This means we will more often than not end up with temporal coupling when we communicate to and from a web service. If we boil this down to the nitty gritty we end up with:

What happens in service A effects service B.

When the functionality or resources of one service effect the functionality or resources of another service the boundaries are no longer explicit and the services are no longer autonomous. (Dahan)

2) SOA is not WSDL.

WSDL is more or less an XML file used to describe a web service endpoint. One blog describes SOA as being “generally based upon WSDLs for defining interfaces.”3 I suppose you could make it a part of your architecture but it is not a requirement (see tenet 4) nor is it the defining foundation of service oriented architecture. SOA is actually more likely to have been based on messaging which is the preferred form of communication in SOA. We also shouldn’t forget that the WS in WSDL stands for web service which we already determined wasn’t SOA either.

In reality it’s just plain inappropriate to compare WSDL to SOA. WSDL is an implementation technique and SOA is an architectural style (you know that already though).

3) SOA is not an Enterprise Service Bus.

Sometimes SOA gets mixed up with the notion of an Enterprise Service Bus (ESB). Most ESB’s are actually not a bus. They are really brokers. The broker pattern like SOA is based on messaging. And when you get into the 4th tenet of SOA you start talking about communication implementations and brokers are one of the possible architectural styles you can apply. The original intent of the ESB was to provide a way to integrate several applications together in a way that would allow inter-application communication. In terms of SOA it’s easy to correlate the idea of hooking several different applications together in a way that would allow them to communicate with hooking up several services in a way that would allow them to communicate.

Again we are back to this idea of how to make services talk to each other. This is another driving point of confusion about what SOA is. The next time you find yourself thinking about how services communicate just go back to tenet #1. Communication between services undermines and breaks autonomy. So in SOA we actually want to AVOID all communications between services. That’s right we want none! So if you read a blog about SOA and they start jabbering away about REST API’s, WSDL, SOAP, JSON over HTTP, or ESB’s then something is wrong with the authors understanding of service oriented architecture.

Ok So what is SOA?
Ahh. That is a great question. And the answer is…….you will have to wait until my next blog to find out. This one is already long enough.

References and Notes:

1 The 3rd tenet of SOA was modified by Udi Dahan to include “or databases” explicitly. Previously it was implied implicitly through tenets 1 and 2 but its importance is often overlooked.

2 Dahan, Udi – Advanced Distributed Systems Course (ADS), http://particular.net/adsd

3 Pool, Kevin – The Great Debate: Microservices vs SOA, http://www.tibco.com/blog/2015/07/24/the-great-debate-microservices-vs-soa/

2 thoughts on “SOA. Let’s remove some of the confusion.”

  1. I am laying some ground work for a post I plan to write on SOA vs Microservices. That one may be more of what you are expecting. Thanks for my first comment!

Leave a Reply