Contrasting SOA Philosophies
You probably use SOA in your organisation as a measure to provide enhanced business value. Logically, then, the better you understand the diversity of SOA the more value you can provide.
So in this post I’ll contrast the style I’ve seen from a few dev teams here in London, with the drastically different philosophy I learned from Udi Dahan’s advanced distributed systems design/SOA course (really enjoyed and learned from it — thanks 7digital for paying for it).
My goal is to show that knowing about the different SOA philosophies adds a few shiny new spanners to your tool belt, and subsequently your ability to deliver.
Synchronous HTTP SOA
Mostly when talking about SOA I’ll see teams who are using synchronous XML /HTTP to communicate between their services. The main benefit is that their services are free to change internally as long as they conform to their agreed-upon XML/HTTP contract.
This decoupling is desirable because it allows the individual systems and thus individual business capabilities to evolve independently — SRP at the service level, if you will.
In all of the cases, the designers have also been aware of the fallacies of distributed computing and the tenets of service orientation, often being explicit about how they’ve addressed them.
Let’s take a look at an example of what this style of architecture could look like for taking a customer’s order:
As per the synchronous style of SOA, when a request comes in from a user to place an order, some number of tasks are immediately carried out. The user then waits for their synchronous response until all of those tasks have completed.
This system looks free of coupling, and, in-line with the tenets of service orientation looks to have autonomous services (they share no code or databases) with explicit boundaries (routing service is boundary between services).Be aware of temporal coupling
Can you spot the risks in this design? Firstly, what if the external payment provider goes down? In many systems like this the transaction fails and the business loses the ability to take money from customers.
What is the root cause of this problem? Temporal coupling — the fact that all events have to occur immediately in a synchronous manner.
It’s easier to identify further source of problems along the sequence of 9 HTTP requests (and internal database calls they might make) before a user’s order can be confirmed. Even if the unreliable third party is briefly reliable, what if another service goes down, or develops some kind of fault preventing it behaving as intended?
Take the inbox for example. If it goes down, would the payment be rolled back; how would the subsequent services be used? It’s looking like more opportunity for lost business, upset customers who paid for a product and didn’t get it, or some hard-to-debug data inconsistencies and the un-desired side-effects that manifest from them.
It’s also useful to go back and re-evaluate fallacies of distributed computing — 1: The network is reliable. This architecture relies on the succession of web request to all succeed. Unfortunately, there is no fault-tolerance of a network issue anywhere in the pipeline, mainly because of temporal coupling (though there could be infrastructure measures to mitigate this, and that might be enough).Watch out for logical coupling too
If we further analyse this design against the tenets of service orientation, is the purchasing service really autonomous if it contains code to defend against errors or unavailability of other services? The problem in this case is a logical coupling to other services — logic in the purchasing service is dependent upon logic in other services.
As well we can question if the boundary is clearly defined, when services beyond the boundary can have an impact on the way it behaves.
Think about also adding a new, un-related service to this workflow? The purchasing, or another service, will have to change to call it. There’s definitely some coupling, and questions about autonomy.
In my opinion, you should at least be asking these questions about your services with respect to the impact temporal and logical coupling are having on your ability to provide business value.Udi’s asynchronous pub/sub SOA
Udi explicitly tries to solve the problems of temporal and logical coupling by using a pub/sub event-based architecture; at all times relating this back to the fallacies of distributed computing, the tenets of service orientation, and ultimately how you can provide value for the business.
Moving to the pub/sub, event-based architecture, we might achieve something similar to this:
Firstly, as soon as user intent to place an order is captured the order is secure. There’s then a messaging-gateway (a queue with re-try logic wrapping a HTTP request) between the purchasing service and the unreliable third-party to provide fault-tolerance.
When the payment is finally confirmed the order-placed event is fired allowing the other services to carry out their job when it suits them — free of temporal coupling.
Now ponder a service going down.
Messages will be on a queue waiting for it to come back up. Suddenly, the opportunity for losing business has dramatically decreased to a very short time-frame, with massively-reduced opportunity for crippling errors. Losing temporal coupling was the enabler.
Also re-imagine the case when a new business capability needs to be added. This time we don’t change the payments service, instead the new fraud detection service just subscribes to the existing event — services don’t even know other services exist now. Using events to remove logical coupling was the enabler.
If we’re using SOA as a way to let individual parts of our business work and change independently by reducing coupling, then it makes sense for us to be challenging our designs against the benefits of a pub/sub alternative.Async has other benefits as well
Udi takes a very business-centric view to SOA. Using the bus architectural style, you can often align technical infrastructure with business needs…
Do you want payments to be processed faster so clients get their product quicker? Put more processing resource there. Maybe speed of calculating customer satisfaction isn’t so important to the business — we can allow messages to be processed at a slower rate here, so no need to splash out on hardware.
It’s not really possible to provide these more granular levels of processing priority when temporal coupling exists.
This leads us to being able to measure the rate of message processing, and enabling us to track our SLAs. If this important to you, and proving tricky with the XML/HTTP style of SOA, Udi’s bus-based architecture might be just what you need.But let’s keep things in check
Blind faith in any principle, process or theory can be a very dangerous mindset. By understanding the different styles of SOA out there, though, you have more resources to call upon when making an informed decision about what’s right for the business.
As with other principles and methodologies in software development, it seems sensible to look beyond the ambiguous wording (e.g. autonomy, boundary, service) and try to understand the intent and how it applies to your situation. So even when you have identified what might be a boundary or an autonomous service, keep looking for coupling and other factors that can hurt you …..
… just remember to apply critical evaluation to messaging or any other solution before you decide you need it because there will be massive trade-offs.
Should you have the opportunity, then I would definitely recommend you attend or watch Udi’s course to broaden your knowledge of SOA…. there’s a lot more to the course than I have alluded to in this post