Service Oriented Architecture: A Dead Simple Explanation

Service-oriented architecture (SOA) has been with us for a long time. The term first appeared in 1998, and since then it’s grown in popularity. It’s also branched into several variants, including microservice architecture. While microservices dominate the landscape, reports of SOA’s death have been greatly exaggerated. So, let’s go over what SOA is. We’ll cover why it’s an architectural pattern that isn’t going anywhere. Then we’ll see how you can apply its design concepts to your work.

What Is Service-Oriented Architecture?

Service-oriented architecture’s definition has always been a moving target. It evolved for several years before The Open Group published a white paper in 2007. Later, that paper grew into the SOA Source Book. Due to its fragmented past, SOA has more than one definition.

SOA According to Hoyle

The Open Group’s definition of SOA is almost a tautology. One reason for that is service-oriented architecture’s apt name. Another might be a shortage of thesauri at The Open Group headquarters.

Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation.

Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.

This definition originated in the department of redundancy department.

The Open Group says that a service:

• Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports).
• Is self-contained.
• May be composed of other services (emphasis is theirs).
• Is a “black box” to consumers of the service.

So, SOA separates business processes into discrete operations. Then, it creates services that perform those operations.

The services perform business tasks. They are self-contained, but you can combine services into larger ones. Consumers shouldn’t need to know anything about the services.

The Open Group goes a bit further in their definition. The design should “mirror real-world business activities.” You design its operations after the business processes it replaces. The service names should be business processes, rules, or policies.

In SOA, services communicate with each other. They do this over an enterprise service bus (ESB). SOA employs something called Boundaryless Information Flow. Business messages flow over the bus so services can communicate and collaborate. This requires significant coordination and, according to The Open Group, governance.

SOA is an architecture that works for large enterprises. It models applications after business processes. Then, it connects them to a message-exchanging system where they can collaborate. It’s a model for getting many development groups to work together.

SOA According to Everyone Else

That’s what the closest thing to a standard for SOA looks like. So, what does it look like in the wild?

Well, it depends.

In 2005, before The Open Group published its Source Book, Martin Fowler called SOA “ServiceOrientedAmbiguity.”

I’ve heard people say the nice thing about SOA is that it separates data from process, that it combines data and process, that it uses web standards, that it’s independent of web standards, that it’s asynchronous, that it’s synchronous, that the synchronicity doesn’t matter…

Service-oriented architecture is different things to different people. In its early days, one of its defining characteristics was what it wasn’t. SOA is an alternative to the application server pattern that dominated much of the 1990s. Beyond that, as Fowler hints, SOA was in the eye of the beholder.

What About Microservice Architecture?

So, what about microservices? Is a microservice architecture a type of SOA? Or, is it something completely different? The answer depends on who you ask.

Both architectures center around the concept of decomposing business problems into services. This makes the two styles seem similar, but if you dig a little deeper, there are critical differences.

SOA’s concept of Boundaryless Information Flow encourages sharing between services. Services share as much information as possible. They share software components to maintain consistency and reduce development effort. This is where The Open Group’s idea of strong centralized governance comes from.

Bounded vs. Unbounded Data Flows

Microservice-based systems are (hopefully) built with the concept of the bounded context. We covered bounded context earlier in a post about domain driven design.

Let’s take a look at how we defined it there:

First, bounded contexts are meant to contain complexity. In other words, we can create a bounded context for some specific complex business logic. The bounded context connects to other contexts through adapters. And, those adapters protect against change. When those complexities contained within the context change, the rest of our system doesn’t also have to change. (Emphasis added)

Bounded contexts exist to contain complexity. They protect services outside the context from change. It’s the opposite of Boundaryless Information Flow.

The relationships between services and clients are explicitly defined. At the same time, services communicate with each other as little as possible. Services rarely, if ever, share components in a microservice architecture.

This difference goes beyond design. Microservices manage collaboration between development teams by isolating concerns. SOA does it by exposing them. The Open Group requires strong governance for SOA systems. If you design an enterprise system that shares data between departments, you need it. Microservices avoid this with the bounded context. Development teams can work within their defined interfaces, without centralized control.

Key Characteristics of an SOA Architecture

So that’s what SOA isn’t. What is it, and how can you use it?

Service Composition

Let’s circle back to where we started. Service-oriented architecture is about solving business problems with services. So, imagine a vast e-commerce store. It sells several product lines consisting of thousands of products each.

Twenty years ago, you might build it as a single application server. The application server would connect to a relational database. Then, you would place most of the business logic in stored procedures in that database. You would deploy it on clusters for reliability. Any changes to the system would mean updating the servers, the databases, or both. Applications servers are rigid and need a lot of hardware.

With SOA, you break the system down into services. For example:

• Point-of-sale (POS).
• Payment processing.
• Inventory.
• Order fulfillment.
• Shipping.

There might be different inventory services for each product line. But, there is a significant opportunity for code reuse. The point-of-sale service might be a composite service. It might have a web server for communicating with clients. It could also have a specialized interface for taking phone orders. The shipping service might be made up of services for UPS, USPS, FedEx, and private shippers for unique products.

Instead of using expensive clustering, you run more than one instance of each service. We’ll discuss how the ESB makes this possible below.

So far, this sounds a lot like how you would solve this problem with microservices. But, there is a big difference.

The Enterprise Bus

The services communicate with each other over an enterprise service bus (ESB.) An ESB is often a messaging system, such as JMS, RabbitMQ, or Kafka. The bus implements the Boundaryless Information Flow. It’s where SOA and microservices part ways.

So, in our example, the POS service talks to fulfillment and payment processing systems during a sale. The fulfillment system communicates with the inventory and shipping services, and so forth. This requires coordination. The services have to agree on how to represent products, sales, and clients. This is where the strong governance comes in. Or does it?

A message bus is an effective decoupling mechanism. Coordinating messages between services is still better than tightly coupled or monolithic services. Service developers write to the agreed message formats. Does this need strong governance? Why can’t the messages act like the RESTful APIs used in microservices?

As mentioned above, a message bus supports fault tolerance. You can run more than one instance of each service and use orchestration to share the load. Or, if it suits your application model better, you can run the services in a hot standby mode.

An Architecture for Enterprises

Service-oriented architecture has survived for a long time for good reason. The model of breaking processes into services is sound and led to microservices. The notion of a message bus is good for enterprises that need to share data between departments.

The call for strong governance can be off-putting to some, but you don’t need it. Rather than using the enterprise bus as a coupling mechanism, use it as a demarcation point. SOA’s message bus can be a valuable addition to systems that need to exchange data between services.