What is a Service in Service Oriented Architecture (SOA)

Services in SOA need to fit within the 4 tenets of SOA:

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

This means that services should not rely on each other. They should be able to operate alone without any assistance from other services or other outside sources. There should be a clear border around a service defining the business logic, data, classes, types, etc. that belong to it. No other service should have a say or influence over the resources of another service. When services do share something it should only be the schemas and contracts necessary for sending communications. It should never share any of its resources. And services should have a strict policy in place for how each service will physically move communications from one service to another.

Communication is important in Service Oriented architecture
For a service to be autonomous and have explicit boundaries we need to pay really close attention to how they communicate with other services. If the logic or data in one service can influence the resources and/or behavior in another service it will undermine the autonomy and boundaries.

So how do they communicate? Never! Absolutely never ever. We want to strive to have no communication between our services. That being said we will never be able to reach absolute zero communication and nor would we want to. Doing so would diminish the usefulness or our system. So when we do need to communicate it should be in a very controlled fashion and indirectly. The best architectural style that can help us to achieve that is the Bus pattern. In short it provides dumb pipes for sending messages in the form of events. Each service can then make use of pub/sub to subscribe to events from other services. This allows for services to remain autonomous and retain their explicit boundaries by avoiding temporal coupling. But we still have to be extremely careful that we are not using the messages to transfer/duplicate data across services.

We achieve tenets 3 and 4 through messaging. The messages in our system become the contracts and schemas we share between our services and then our physical transport and formatting of those messages becomes our policy.

Autonomy and Boundaries are also important in SOA
Udi Dahan, one of the world’s foremost experts on Service-Oriented Architecture, defines services a little further with this definition:

  1. A service is the technical authority for a specific business capability
  2. All data and business rules reside within the service
  3. Nothing is “left over” after identifying services
  4. Everything must be in some service

These rules drive home the idea that a service has a boundary and everything inside of the boundary belongs solely to that service. To be autonomous you can’t have outside influences affecting what you control. And to define what you control you need to have a boundary.

On a bit of a side note…. I often come across comments that associate autonomy with being independently deployable. When we think about how to deploy a service it puts us in the wrong frame of mind. Autonomy is more about encapsulation and being self governing. Mr. Dahan tells us that services are artifacts of the logical view. So when we start talking about services being independently deployable we are no longer in the realm of talking about how we logically organize things (see the 4+1 architectural view model for more information).

Services stretch across systems and processes
It’s very easy to see services as these things that live somewhere in the back-end our systems. The truth however is that the autonomy and boundaries of a service expand beyond processes and into whatever parts of our system they need to be in. So as we said before if a service is autonomous and in control of its own resources then how would you share the data of your service with a front-end HTML/Javascript UI so you could display content to the users? The not-so-obvious conclusion is that the Javascript code I would need for retrieving data from a service would also have to be owned by the service.

So are you saying that Javascript code belongs in the back-end with my service logic and data? No! A service isn’t a back-end thing. It’s a logical view of how we group stuff together. How we deploy the parts of our service and where they actually live are part of the deployment view and the physical view.

We need a special IT/Ops Service
I briefly want to touch upon the fact that we will inevitably need a way for our services to do something that may violate one of our tenets. For example we may need to communicate with third parties outside of our control or services in different systems who have a different policy for communication. To avoid coupling our services directly to these outside systems we make use of the IT/Ops Service. This abstracts away any of the coupling or dirty deeds we have to do. The IT/Ops Service can be useful in other situations as well and it is meant to handle all of the odd jobs that don’t fit in exactly with other services that are aligned with business capabilities.

View of SOA
So without further ado lets take a look at a generic view of services in SOA. I have tried to capture the ideas we have discussed as well as included some we have not. Try to keep in mind this is more of a logical view and that it doesnt fully represent how we might deploy the services.

SOA Logical View

Things that services are not
I don’t want to go to far down the rabbit trail but I thought it would be worth mentioning that Mr. Dahan has a few examples of what services are not and you can learn a little more about them in his talk he gave at the London NDC titled “Finding Service Boundaries – illustrated in healthcare.” Fast forward to about 14:28 to see what they are. In fact I recommend going back and watching the whole video (or at least the first 40 minutes) after reading this blog post to get Mr. Dahans high level on SOA in general.

For more reading on services check out Udi Dahans article, The Known Unknowns of SOA.

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/