Architectural Design Patterns 6 – Service-Oriented Architecture

Architectural Design Patterns 6 – Service-Oriented Architecture

Service-Oriented Architecture, often known simply as SOA, can be thought of as a city of services. In this city, each service is like a shop. Every shop provides a unique product or service but doesn’t worry about the other shops around it. Instead, it focuses on doing its own job really well. So, SOA is about creating independent services that work together in a large system.

Now, where would you find SOA being used? Imagine big companies with different departments, like finance, human resources, or sales. Each department uses different software. With SOA, these different pieces of software can communicate and share data more easily. So, if the sales department makes a sale, the finance software can quickly know about it and do its thing.

One of the great things about SOA is that each service can be updated or changed without messing up the whole system. This means companies can make improvements without shutting everything down. Also, since services are independent, it’s easier to test them separately. But it’s not all sunshine and rainbows. One big challenge is that when many services constantly chat with each other, things can slow down. And if one service breaks, it might cause problems for the services that depend on it.

There have been some strong opinions about SOA. Some folks say it’s too complex, especially when you have a ton of services talking to each other. Others argue that it’s tricky to manage and keep track of all these services.

Both SOA and Microservices emphasize on decentralization. They both push for a structure where individual components or services operate in a loosely coupled manner. However, while SOA often sees services as larger, encompassing multiple operations, Microservices aim for single functionality, making them finer-grained. This means that in the world of Microservices, every small function gets its own service. Further, while SOA services might share databases leading to potential interdependencies, every microservice manages its own database ensuring full autonomy.

But why is SOA not the go-to choice these days? Here’s the deal, there’s a new kid on the block called REST (Representational State Transfer). Unlike SOA, which is like calling a friend and waiting for them to pick up, REST is more like texting. You send a message (or request) and get a reply when the other side is ready. REST is simple and works really well on the web, making it a favourite for many modern apps and websites.

Back in the day, SOA was super popular because it allowed big, old software systems to talk to each other. But as the tech world moved more towards the internet and web apps, the simpler and web-friendly REST started taking the spotlight.

In the end, while SOA had its golden days and served its purpose well, the evolving needs of the tech world have seen newer architectures, like REST, take the lead. Still, understanding SOA is like appreciating a classic movie – it gives you an idea of how things were and how far we’ve come.

Suleyman Cabir Ataman, PhD

Architectural Design Patterns 1 – Layered (or Tiered) Pattern

Here in this first post of the blog, I want to also start with the first part of a series. Read more

Architectural Design Patterns 2 – Model-View-Controller (MVC)

When you're diving into the world of software design, you'll often hear about the Model-View-Controller, or MVC for short. It's Read more

Architectural Design Patterns 3 – Microservices

In this article, we will be talking about Microservices, a design pattern that has gained attraction for its approach to Read more

Architectural Design Patterns 4 – Event-Driven Architecture

Event-Driven Architecture is currently enjoying a lot of attention from businesses around the world due to the enhanced capabilities offered Read more

Sharing on social media:

Suleyman Cabir Ataman

Leave a Reply