Service-Oriented Architecture
Instead of taking one part out of an application when it causes a problem, we can design the system as services from the start. Before we build anything, we look at what the system does for the business, and we divide the system into services that match those things. The system is made up of these services and the calls between them.
Something a system does for the business, named in the business’s own words, is a business capability. For a shop, keeping the catalog is a capability, and so is taking orders.
Designing a system as a set of services, each offering one or more business capabilities to the rest of the system, is called service-oriented architecture (SOA).
Designing a system this way involves three decisions:
- What the capabilities are.
- Which capabilities share a service: which ones go together in one service, and which get a service of their own. This decision sets the boundaries between the services.
- How the services communicate.
SOA in the 2000s
The term service-oriented architecture came into wide use in large companies in the early 2000s. Those companies had many separate systems, such as billing, customer records, and shipping, and they wanted each system to use the others’ capabilities. The services were often described in WSDL (Web Services Description Language) and exchanged XML messages using a protocol called SOAP. They were often connected through a central product called an enterprise service bus (ESB). Most systems built today do not use those tools. Many of them are still designed as services that each offer a business capability.