What Makes SOA Different from Microservices? Services, ESB, and Legacy Explained

2000s Enterprise Integration Problem

Enterprises typically ran five independent systems—SAP for finance, PeopleSoft for HR, a legacy COBOL supply‑chain system, a .NET CRM, and a Java e‑commerce front‑end. Each used different data formats and protocols, so cross‑system business processes (e.g., order → inventory → finance → logistics) could not be executed.

SOA was created to connect many heterogeneous systems, not to split a monolithic one.

Core Abstraction: Service

A service is defined by a service contract that specifies inputs, outputs, pre‑conditions and post‑conditions. The contract must remain backward compatible, allowing a COBOL system and a Java system to interoperate without sharing implementation details.

Service discovery lets a consumer locate a provider at runtime; the SOA era used UDDI (Universal Description, Discovery, and Integration) for this purpose.

Service reuse enables a single service (e.g., “customer‑info query”) to be invoked by order, CRM, and reporting subsystems, eliminating duplicate code and guaranteeing data consistency.

ESB is not the soul of SOA; the service contract is.

Enterprise Service Bus (ESB): A Means, Not the Goal

The ESB supplies four capabilities:

Message transformation (e.g., COBOL EBCDIC → XML)

Protocol conversion (e.g., HTTP → JMS, SOAP → REST)

Routing to the appropriate service instance

Orchestration—combining multiple services into a business process

Because all communication passes through the ESB, it can become a performance bottleneck and a political hotspot when multiple teams compete for control.

ESB is an integration infrastructure, not the essence of SOA.

Orchestration vs. Choreography

Orchestration uses a central coordinator (e.g., BPEL) that invokes services step‑by‑step, providing full visibility and easier debugging but creating a single point of failure.

Choreography lets each participant follow predefined rules and react to messages autonomously; it is decentralized and resilient but harder to trace.

Orchestration is like a conductor directing an orchestra; choreography is like dancers following a shared rhythm.

Core Value: Service Reuse and Integration

Service reuse avoids duplicated development. In the 2000s, the “customer‑info query” service was called by order, CRM, and reporting systems, ensuring a single source of truth for customer data.

Service integration lets heterogeneous systems communicate. The ESB performed protocol conversion so a Java service could call a COBOL system, a .NET component could consume a SAP service, and no legacy code needed to be rewritten—only a service contract wrapper was added.

WS‑* Stack as Technical Implementation

WSDL (Web Services Description Language) – describes service interfaces and message formats.

SOAP (Simple Object Access Protocol) – defines the envelope and transport rules for messages.

UDDI – registers and discovers services.

BPEL (Business Process Execution Language) – specifies orchestration logic.

WS‑* technologies are implementations of SOA, not the architecture itself.

Why SOA Chose Centralization

In the 2000s, integration required:

Protocol conversion (Java used HTTP, COBOL used CICS, SAP used RFC). Without an ESB, the systems could not converse.

Legacy adaptation – a 20‑year‑old COBOL system could not be rewritten; a service contract layer made it callable.

Cross‑department workflow coordination – order processing involved inventory, finance, and logistics, needing a central orchestrator.

Microservices, emerging in the 2010s, targeted independent deployment of homogeneous services (HTTP + JSON). Because all services shared the same protocol, protocol conversion was unnecessary, and rapid, decoupled releases were more valuable than a central orchestrator.

SOA centralized because the problem was integration; Microservices decentralized because the problem was independent deployment.

Common Misunderstandings

“SOA is ESB” – ESB is one possible implementation; SOA can also use point‑to‑point calls, message queues, or API gateways.

“SOA is Web Services” – Web Services (WSDL, SOAP, UDDI) are a specific technology stack; REST or messaging can also realize SOA.

“SOA is dead” – Service contracts, discovery, and messaging remain essential in Microservices.

“SOA and Microservices are the same” – SOA focuses on integrating many heterogeneous systems; Microservices emphasize independent deployment of homogeneous services.

“SOA is outdated” – The principles of contract‑first design, loose coupling, and reuse are still fundamental for cross‑system integration.

SOA’s Legacy in Modern Architectures

Service contracts → API‑first design (OpenAPI/Swagger)

Service discovery → Registries such as Consul, Eureka, Nacos

Message middleware → Event‑driven architectures using Kafka or RabbitMQ

Service reuse → Business‑capability decomposition

ESB is a means; service reuse is the purpose. First determine whether integration is required, then choose the appropriate integration method.

Choosing Between SOA and Microservices

If the problem is integrating legacy, heterogeneous systems across departments, the contract‑first approach and ESB‑style mediation of SOA remain valuable. If the goal is building new, homogeneous services that need rapid, independent deployment, a Microservices style is a better fit.