Skip to content
Software Architecture Guide

Service-Oriented Architecture

Explanation

Section titled “Explanation”

Service-Oriented Architecture (SOA) is a paradigm, or way of thinking, for organizing and using distributed capabilities. Distributed means the capabilities are spread across different systems.

Services. A service brings together what a consumer needs and what a provider can do. The consumer asks. The provider delivers.

Interface and contract. The service interface is the way to reach a service’s underlying capabilities. Callers use the interface and never touch the implementation behind it. A contract is an agreement between two or more parties. Together they define what a service offers and what callers can expect.

Description and discovery. A service description holds the information needed to use a service, or to decide whether to use it. Consumers usually become aware of services through discovery mechanisms such as registries. A registry is a directory of available services.

Different owners. SOA is motivated by ownership boundaries. A provider and its consumers may belong to different organizations. That is why clear interfaces, contracts and descriptions matter.

Central hubs. Some SOA systems send all messages through one central message broker. This is called the hub-and-spoke style, and it is an architecture-level pattern. The Broker Pattern article covers it.

A loose term. Martin Fowler notes that SOA means many different things. For some people it means exposing software through web services. For others it means asynchronous document messaging. In practice it often meant enterprise service buses (ESBs, central middleware) joining monolithic applications. So check which meaning a document intends.

Contrast with microservices. The microservice community prefers smart endpoints and dumb pipes. That is the opposite of putting intelligence into ESB middleware.

Example

Section titled “Example”

A city’s permit office offers a “check application status” service. Other organizations, such as a bank or a law firm, call it through a published interface. The description says how to call it. A registry lists it. The office can replace its internal systems, and callers notice nothing as long as the interface stays the same.

Trade-offs

Section titled “Trade-offs”

Routing every message through one central broker is simple to reason about. But it can turn that broker into a serious bottleneck. Hub-style middleware also concentrates intelligence in the middle, which the microservice community avoids by choosing smart endpoints and dumb pipes. Because “SOA” has many meanings, teams may think they agree when they do not.

A consumer finds a service through a registry, then calls it through its interface.

Diagram source 
flowchart LR
  P[Provider] -->|publishes description| R[(Registry)]
  C[Consumer] -->|discovers| R
  C -->|calls| I[Service interface]
  I --> M[Implementation]

Checks

Section titled “Checks”
  • Each service has a documented interface that is separate from its implementation.
  • Each service has a description with the information needed to use it.
  • The document states how consumers discover services, for example through a registry.
  • If a central broker is used, the document addresses the bottleneck risk.
  • The document states which meaning of SOA it uses.
Section titled “Related”

Sources

Section titled “Sources”