Service-Oriented Architecture
- In Turkish
- Servis Odaklı Mimari
In short
Service-oriented architecture builds enterprise software from reusable, network-accessible services that communicate with each other through standard contracts.
What is service-oriented architecture (SOA)?
Service-oriented architecture, or SOA, is a style of building software as a collection of services that other applications call over a network. It became popular in large organizations in the late 1990s and 2000s as a way to connect many separate systems, such as billing, customer records, and inventory, and to reuse their functions instead of rebuilding them in every application. Each service exposes a formal contract describing its operations and data.
Classic SOA implementations used SOAP web services described by WSDL documents, and often an enterprise service bus (ESB), a central piece of middleware that routes messages between services, transforms data formats, and coordinates multi-step processes. Services are typically large, cover a whole business capability, and share enterprise-wide data models so many applications can reuse them. Governance, meaning central rules for how services are designed, versioned, and secured, is a big part of SOA.
An analogy is a large company's shared departments: any team can send a request to payroll, legal, or IT through standard forms, instead of each team hiring its own accountant and lawyer. SOA is still common in banking, insurance, telecom, and government, where it wraps decades-old systems in services so newer applications can use them.
SOA is most often compared with microservices, which grew out of it. SOA aims at reuse and integration across a whole enterprise and often relies on a central bus with smart routing and shared data models, while microservices split a single application into small services that each own their data, deploy independently, and talk through simple protocols, an idea summed up as smart endpoints and dumb pipes. Both are service-based, so the difference lies mainly in scope, size, and how much is centralized.
Key takeaways
- SOA builds systems from reusable services that communicate over a network through contracts.
- Classic SOA used SOAP, WSDL, and a central enterprise service bus.
- Its main goals are enterprise-wide reuse and integration of existing systems.
- Microservices are smaller, own their data, and avoid a central bus.
- SOA remains common in large organizations with many legacy systems.
Example
<!-- A SOAP request to a shared CustomerService used by many applications -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cus="http://example.com/services/customer">
<soap:Body>
<cus:GetCustomer>
<cus:CustomerId>10452</cus:CustomerId>
</cus:GetCustomer>
</soap:Body>
</soap:Envelope>Readers ask
What is the difference between SOA and microservices?
SOA focuses on sharing large, reusable services across an entire organization, often through a central enterprise service bus. Microservices split one application into small, independently deployable services that each own their data and communicate over lightweight protocols such as HTTP or messaging.
What is an enterprise service bus?
An enterprise service bus (ESB) is middleware that sits between services and handles message routing, data transformation, and protocol translation. It simplifies integration but can become a central bottleneck and a single point of failure.
Is SOA outdated?
Its original tooling is less popular for new projects, but its core ideas, such as service contracts, loose coupling, and reuse, live on in microservices and API-based designs. Many large organizations still run and maintain SOA systems.
Often compared
See also
- MicroservicesSoftware Architecture, p. 27Microservices are an architectural style where an application is split into small, independently deployable services that communicate over a network.
- SOAPBackend & APIs, p. 44SOAP is an XML-based messaging protocol for web services that wraps each request and response in a strict envelope, usually defined by a formal WSDL contract.
- MonolithSoftware Architecture, p. 28A monolith is a software application built and deployed as a single unit, where all features share one codebase, one process, and usually one database.
- Loose CouplingSoftware Architecture, p. 26Loose coupling is a design principle in which components depend on each other as little as possible, so one can change without breaking the others.
- Message QueueBackend & APIs, p. 29A message queue is a component that stores messages from one service until another is ready to process them, so parts of a system can work asynchronously.
- API GatewayBackend & APIs, p. 3An API gateway is a server that sits in front of a group of backend services and acts as the single entry point that receives, checks, and routes API requests.
Spotted a mistake or something missing on this page?Suggest an edit