Plenty of enterprises run applications that were never built to work together, and SOA is the usual way of getting them to share business functions. Each function is exposed as a loosely coupled service with a standardized interface. The service provider publishes a contract, and any service consumer can call it over a network and combine it with other services as needed.
A standard definition only arrived when OASIS approved its Reference Model for Service Oriented Architecture on 12 October 2006. The model ties the style to no protocol or technology, which is why SOA isn’t limited to SOAP or web services.
What Is Service-Oriented Architecture?
The standards body behind the main reference model is OASIS, and its definition rests on matching needs with capabilities. A consumer has a need, a provider holds a capability, and the architecture is what connects the two.
Among styles of software architecture, SOA stands out because a formal reference model defines it, and not only vendor documentation.
What counts as a service
OASIS defines a service as a mechanism that gives access to one or more capabilities through a prescribed interface, under the constraints and policies stated in the service description.
In practice, that’s a unit of functionality with a contract and an owner, with the internals kept out of sight. Checking an order status is a typical case.
What SOA is not
SaaS is a delivery model for cloud applications. Services inside an SOA can be delivered that way (Red Hat’s SOA overview), but the two ideas answer different questions. Client-server is a separate thing too, since it divides workload between client applications and server applications, while SOA structures software as loosely coupled, interoperable services (OutSystems glossary).
Web services aren’t a synonym for SOA either. They’re one way to implement it, and the OASIS model names no protocol.
Where the term and the OASIS definition come from
Because no standard definition of SOA existed yet, OASIS chartered its SOA Reference Model Technical Committee in February 2005. The Reference Model was approved as an OASIS Standard on 12 October 2006.
The model is deliberately abstract. According to the OASIS SOA-RM FAQ, architects use it as a template for composing concrete architectures, and it can’t be implemented directly. A companion document, the Reference Architecture Foundation for SOA, followed it.
How Does Service-Oriented Architecture Work?
A service provider publishes a contract to a registry. A consumer finds it there, binds to the provider, and invokes the service by exchanging messages. The consumer works only from the contract and never sees how the provider does the job.
- The provider registers the service and its contract in the service registry.
- The consumer queries the registry for a service that matches its need.
- The consumer binds to the provider, using the endpoint and protocol the contract names.
- The consumer sends a request message over the network.
- The provider responds by returning information or changing the state of a shared resource.
The provider builds and owns the service. Contracts and locations sit in the registry, which some sources call the broker, and the consumer is whoever finds a service there and calls it.
What the OASIS model adds
OASIS describes the dynamic side of a service through visibility, interaction, and real world effect.
Visibility is about whether consumer and provider can find each other. Interaction is the exchange of messages between them. The real world effect is whatever comes out of that exchange, which is either information returned or a change in state.
In classic web services designs, the registry carries the visibility burden.
Core Principles of Service-Oriented Architecture
Thomas Erl’s service-orientation catalog has eight design principles, and they split fairly cleanly between what a contract looks like and how a service behaves while running.
Principles that shape the contract
Standardized service contract means services in one inventory follow the same contract design standards. Loose coupling asks that contracts place few demands on consumers and stay independent of the environment around them. Abstraction keeps the contract to what the service does and hides how it does it.
Discoverability is a little different, since it depends on published metadata that lets consumers find and interpret the service. In web services that usually runs through a registry such as UDDI.
Principles that shape runtime behavior
Reusability, so that one service serves many consumers, is the point of most SOA budgets. Autonomy means a service controls its own logic and runtime environment, and statelessness has services defer state management, which uses fewer resources. Composability is about recombining services into new solutions.
Amazon is the best-documented case of autonomy at scale. Its architecture began about ten years before the 2006 ACM Queue interview as a monolithic application on a web server talking to a database, and CTO Werner Vogels said in that interview that SOA gave the isolation needed to build components rapidly and independently.
For Amazon, service orientation meant encapsulating data with the business logic that operates on it, with a published service interface as the only way in.
Reuse is the main justification for SOA, and also the source of its sharpest failure mode. Speaking at the 2007 Enterprise Architect Summit, Lipton warned (ADT Magazine, May 2007) that as more users share a service, unexpected bottlenecks and organization-wide single points of failure appear.
Protocols and Standards in Service-Oriented Architecture
The classic SOA stack runs on XML. SOAP carries the messages and WSDL describes the contract, UDDI lists the services, WS-Security protects the messages, and WS-BPEL chains services into processes.
| Standard | Job in the stack | Steward and milestone |
|---|---|---|
| SOAP 1.2 | Message envelope, processing model, protocol bindings | W3C Recommendation, 24 June 2003 |
| WSDL 2.0 | Service contract: interface, binding, location | W3C Recommendation, 26 June 2007 |
| UDDI 3.0.2 | Registry for publishing and finding services | OASIS Standard, February 2005 |
| WS-Security 1.1 | Tokens, integrity, and confidentiality in SOAP messages | OASIS Standard, February 2006 |
| WS-BPEL 2.0 | Executable and abstract business processes | OASIS Standard, 11 April 2007 |
Before SOAP 1.2 became a Recommendation, W3C tracked seven implementations from member organizations and independent developers (W3C news release, June 2003).
SOA without SOAP
SOA does not mandate SOAP. The OASIS model is independent of vendors, products, and technologies, so a service can just as well be exposed as a RESTful API over HTTP.
Some vendor explainers equate SOA with the SOAP, WSDL, and UDDI trio. The reference model doesn’t, because it prescribes no protocol.
Where the standards stack shows its limits
UDDI got a lukewarm reception even at its approval. In February 2005, John Davies of JPMorgan Chase said it suited some uses but not an investment bank (eWeek, 2005). WS-Security comes with a caveat too. OASIS states that its mechanisms for security tokens, message integrity, and message confidentiality do not form a complete security solution on their own.
The version gap is a stranger problem. WS-BPEL 2.0 was finalized on 11 April 2007 on top of WSDL 1.1, and WSDL 2.0 followed about eleven weeks later. The process layer and the contract layer were not finished against the same WSDL version.
Service Types, Layers, and Orchestration
Erl’s service models sort services by the logic they hold. A service that wraps a business entity is an entity service, one that wraps shared technical functions is a utility service, and the ones built around a business process are task services.
Sources classify services in different ways, so this section sticks to the models published on Erl’s SOA Patterns site (Arcitura).
Entity services carry reusable logic tied to a business entity such as an invoice, customer, or claim. The standard example is an Invoice service with an Add capability.
Utility services hold shared technical logic that has no business meaning, like data format transformation or address checking. Some sources call these application, infrastructure, or technology services.
A task service ties its logic to one business process and usually controls a composition of other services. A billing consolidation that pulls invoice and purchase order records is a typical case.
How layers combine
Grouping services by type produces service layers, and the SOA Patterns guidance puts the rule of thumb at two layers minimum.
An inventory built only from utility and entity layers is not recommended, because nothing then abstracts the process-specific logic that will not be reused.
Orchestration versus choreography
Orchestration puts one controller in charge of the process. Choreography has no controller at all. Participating services share control, and the interaction is described from a global viewpoint.
OASIS standardized orchestration as WS-BPEL 2.0 on 11 April 2007. The W3C counterpart, WS-CDL 1.0, reached Candidate Recommendation on 9 November 2005, the Web Services Choreography Working Group closed on 10 July 2009, and the group’s page still lists that 2005 stage.
Burton Group analyst Chris Howard argued, before WS-BPEL 2.0 was final, that it still orchestrates from the perspective of a single service. That limits it for interactions spanning several services.
What Role Does the Enterprise Service Bus Play in SOA?
Every message between services passes through the enterprise service bus (ESB), a central middleware component that routes, transforms, and mediates those messages. Each service connects to the bus instead of to every other service.
IBM describes it as the shared communication mechanism of an SOA. Lewis and Fowler’s 2014 microservices article lists message routing, choreography, transformation, and business rules among the functions ESB products carry.
Why teams adopt one
Mostly it cuts down on connection work. Each service needs one link to the bus instead of point-to-point links with all the others. Data format translation also happens in one place, and mixed messaging protocols such as SOAP, AMQP, and MSMQ are supported.
Where the bus fails
Every message crosses the bus, so an outage there reaches the whole enterprise (IBM, 2024). Celent’s 2009 report adds processing overhead and more complex audit trails to the list.
There’s no standard to lean on, either. At the 2007 Enterprise Architect Summit, Lipton pointed out that standards groups such as OASIS publish no ESB standard, and that each product writes its own log format (ADT Magazine).
Because every message crosses it, the bus needs its own high availability setup. That is more infrastructure to run and monitor.
Is an ESB required?
No. In its 2009 report “To ESB or Not to ESB?”, Celent analyst Bart Narter argued that a bank could get more value from SOA without a bus.
The catch is coordination. Without a bus, the organization needs more discipline across teams, and the same report notes that the vast majority of large banks run one anyway.
IBM’s guidance gives a workable decision rule. Large, diverse environments with mixed applications and protocols lean toward a bus-based SOA, while smaller web and mobile estates do not need that communication layer.
Benefits and Drawbacks of Service-Oriented Architecture
SOA pays off where many heterogeneous systems must share business functions. The costs show up in governance overhead, speed, and dependence on shared infrastructure.
What SOA gains
IBM’s 2024 comparison of SOA and microservices gives SOA credit in a few areas.
- A service published once is reused across applications in the enterprise, which saves development time.
- Fewer point-to-point integrations. Before SOA, connecting a monolith to another system’s data or functions meant integration work that developers re-created for every project.
- Shared resources allow common data governance standards across all services.
- SOA is more open to heterogeneous messaging protocols such as SOAP, AMQP, and MSMQ.
What SOA costs
- The bus becomes a single point of failure, and one slow service can drag down the rest (IBM, 2024)
- A shared architecture tends to run slower than microservices, which minimize sharing (IBM, 2024)
- Audit trails get more complex (Celent, 2009), and Lipton questioned how service level agreements can be measured across distributed services (ADT Magazine, 2007)
- Lewis and Fowler list centralised governance models that actively inhibit change, and failed multi-year initiatives that delivered no value, among the botched SOA implementations they have seen
Governance turns up as both a benefit and a cost. IBM counts common data governance standards as a benefit of shared resources, while Lewis and Fowler blame centralised governance for slowing change.
The two positions describe the same mechanism from opposite ends. Standards that keep services consistent also put approval steps between a team and its release.
How Does SOA Differ From Microservices and Monolithic Architecture?
What separates SOA from microservices is scope. SOA has an enterprise scope, microservices an application scope (IBM, 2024). A monolith differs from both because it ships as a single deployable unit.
| Attribute | Monolith | SOA | Microservices |
|---|---|---|---|
| Scope | One application | Enterprise-wide | One application |
| Deployment unit | Whole application | Individual services | Independent services |
| Data | Single logical database | Shared storage layer | Database per service |
| Communication | In-process calls | Shared ESB | Lightweight APIs or messaging |
| Reuse | Shared code in one process | Runtime reuse of shared services | Copied code, duplicated data |
The monolith baseline
Lewis and Fowler describe the monolithic architecture as a single logical executable, where any change means rebuilding and redeploying the whole application.
Scaling means scaling everything, not only the part under load. They still note that monoliths can be successful.
Where the sources disagree
Whether microservices are a different style or a form of SOA depends on which source defines SOA.
IBM treats the two as complementary approaches separated by scope. Lewis and Fowler note that some people consider microservices one form of SOA, perhaps “service orientation done right”, and that Netflix referred to its style as fine-grained SOA until recently. The same article then says most things labeled SOA centered on ESBs integrating monolithic applications, which is not the style they describe.
How the microservices term emerged
A workshop of software architects near Venice discussed the style in May 2011. The same group settled on the name in May 2012, and Lewis and Fowler completed the article that defines it on 25 March 2014.
The term surfaced six years after OASIS chartered its SOA Reference Model committee in February 2005.
That gap explains why SOA has a formal reference model while the microservices architecture has only a list of common characteristics.
When Service-Oriented Architecture Does Not Fit
A single application owned by one team doesn’t need SOA. Latency-sensitive paths suffer from it, and so do teams whose testing and deployment tooling can’t handle many services at once.
| Condition | Lean toward | Evidence |
|---|---|---|
| Many heterogeneous systems and protocols across departments | SOA, usually with an ESB | IBM, 2024 |
| One application, one team, web or mobile | Microservices or a modular monolith | IBM, 2024; Lewis and Fowler, 2014 |
| Latency-sensitive paths | Fewer network hops, in-process calls | IBM, 2024; Lewis and Fowler, 2014 |
| Immature testing and deployment tooling | Fewer, larger deployable units | Twilio Segment, 2018 |
A documented reversal
Twilio Segment, whose own blog calls microservices a service-oriented software architecture, reported in July 2018 that it had folded more than 140 services into one. Operational overhead had grown with every destination it added.
Improvements to its shared libraries rose from 32 under the old design to 46 in the following year. The price was fault isolation, which got harder because one bad destination could now crash the whole service.
The lesson carries to any service-based style. Service count is a cost, and testing and deployment tooling has to scale with it.
Is SOA still in use?
The sources disagree. TechTarget’s SOA tutorial says SOA itself has been largely displaced, though its service concept lives on in cloud computing and microservices.
The CMS Technical Reference Architecture (2026 Release 1) still lists SOA and microservices as reuse strategies. It cites the Medicaid Information Technology Architecture (MITA) as an SOA framework for CMS and state Medicaid organizations.
Both can be true. SOA fits where reusable services already span departments under an enterprise architecture function that owns contracts and ownership, and it is a poor starting point elsewhere.
Service-Oriented Architecture FAQ
How is security handled across services in SOA?
It gets applied at each component, in the identity and authentication procedures around it, and on the connections between components, according to TechTarget’s SOA tutorial.
For SOAP services, WS-Security adds tokens, integrity, and confidentiality at the message level. OASIS states it does not form a complete solution on its own.
How do you test a service-oriented system?
Test each service against its contract, then trace transactions across services at runtime. Lewis and Fowler describe running consumer-driven contracts in the build, so a provider change that breaks a consumer fails fast.
Lipton argued in 2007 that SOA also needs transaction tracing to follow a request through every service it touches.
Do SOA services have to be completely stateless?
No. Erl’s statelessness principle asks services to defer state management to cut resource use.
He treats full statelessness as a target measured against what the surrounding technology architecture can support.
How do you change a shared service without breaking its consumers?
Control the contract. Arcitura’s SOA Patterns guidance warns that an incompatible change to a widely reused entity service contract can have widespread consequences for consumers.
Lewis and Fowler advise designing consumers to tolerate supplier changes, with explicit versioning as a last resort.
Which industries use SOA?
Banking and government are the best documented. Celent’s 2009 report found the vast majority of large banks run an ESB.
The CMS Technical Reference Architecture names SOA as a reuse strategy and cites MITA as an SOA framework for state Medicaid organizations.
Who publishes the standards behind SOA?
Mostly OASIS and W3C. OASIS publishes the Reference Model, UDDI, WS-Security, and WS-BPEL, while W3C publishes SOAP, WSDL, and WS-CDL.
Lipton noted in 2007 that neither body publishes a standard for the ESB.
Modernizing a Service-Oriented Architecture Without a Rewrite
A service-oriented architecture is modernized in increments, starting with the services that carry the most traffic through the enterprise service bus. A full rebuild is unnecessary.
IBM names DevOps as the means of moving from SOA toward microservices, and the order below is a workable one.
- Map services that change together or bottleneck on the bus
- Move routing logic into service endpoints, one service at a time
- Automate testing and deployment before splitting any further
Mapping comes first because Lewis and Fowler advise merging services that are repeatedly changed together, which removes calls before any new ones are added.
The cost is governance. Moving logic out of the bus gives up the common data governance standards that IBM credits to shared resources.
- What Communications Teams Should Ask Before Commissioning a Mobile App - November 12, 2026
- How to Install Node JS in VS Code and Run Your First Script - November 11, 2026
- Protecting Users and Brand Standards Across Image-Driven Platforms - November 10, 2026
