Skip to content
Docs
Enterprise Architecture (EA) & Design
SOA (Service-Oriented Architecture)

SOA (Service-Oriented Architecture)

SOA

Service-Oriented Architecture

1. Overview: SOA, an enterprise architecture that separates business functions into reusable, standardized services 

    flowchart LR
    A["Siloed, monolithic systems —<br/>hard to integrate and reuse"] --"Split into services<br/>with standard interfaces"--> B["A set of reusable services,<br/>integrated via an ESB"] --"Business agility,<br/>IT-business alignment"--> C["Flexible, integrated<br/>enterprise IT"]

    style A fill:#FFEBEE,stroke:#D32F2F,color:#000
    style B fill:#E3F2FD,stroke:#1976D2,color:#000
    style C fill:#E8F5E9,stroke:#388E3C,color:#000

Definition: An enterprise architecture paradigm that separates business functions into independently deployable services callable through standard interfaces, loosely coupling them via an Enterprise Service Bus (ESB) so IT assets can be shared and reused across the organization.

Characteristics: (Service contract) Defines the communication contract between services through standard interfaces such as WSDL and OpenAPI. (Loose coupling) Consumers and providers can communicate without knowing each other’s implementation details. (Stepping stone to MSA) The mainstream enterprise integration approach of the 2000s, and an intermediate stage in the architectural evolution toward MSA.

2. Core Structure of SOA

A. Service Sharing and Reuse 

    flowchart TD
    subgraph R1["　"]
        direction LR
        SC["Service Contract<br/>WSDL / OpenAPI<br/>defines the calling convention<br/>and interface"]
        LC["Loose Coupling<br/>implementation independence,<br/>easy replacement,<br/>consumer/provider separation"]
        AB["Abstraction<br/>hides internal implementation,<br/>exposes only the interface"]
        RU["Reusability<br/>multiple consumers<br/>share the same service"]
    end

    style SC fill:#E3F2FD,stroke:#1976D2,color:#000
    style LC fill:#F3E5F5,stroke:#7B1FA2,color:#000
    style AB fill:#FFF3E0,stroke:#F57C00,color:#000
    style RU fill:#E8F5E9,stroke:#388E3C,color:#000
    style R1 fill:none,stroke:none

The 8 SOA Design Principles

PrincipleDescription
Service contractSpecifies a service’s function and I/O via a standard interface document (WSDL, OpenAPI)
Loose couplingMinimizes inter-service dependency — implementation changes don’t affect consumers
AbstractionHides internal logic and exposes only the interface
ReusabilityA single service is shared and used by multiple consumers/processes
AutonomyA service controls its own logic independently
StatelessnessNo state retained between service calls, enabling scalability
DiscoverabilityServices can be discovered via a service registry (UDDI)
ComposabilityMultiple services can be composed into a compound service or process

B. The ESB (Enterprise Service Bus) and Evolution to MSA 

    flowchart LR
    subgraph CONSUMERS["Service Consumers"]
        direction TB
        C1["Web Application"]
        C2["Mobile App"]
        C3["B2B Partner"]
    end

    subgraph ESB_BOX["ESB (Enterprise Service Bus)"]
        direction TB
        E1["Message routing"]
        E2["Protocol conversion<br/>SOAP / REST / JMS"]
        E3["Orchestration<br/>BPM / BPEL"]
        E4["Security and monitoring"]
    end

    subgraph SERVICES["Service Providers"]
        direction TB
        S1["Order Service"]
        S2["Customer Service"]
        S3["Inventory Service"]
        S4["Payment Service"]
    end

    CONSUMERS --> ESB_BOX --> SERVICES

    style CONSUMERS fill:#E3F2FD,stroke:#1976D2,color:#1E3A5F
    style ESB_BOX   fill:#1E3A5F,stroke:#1E3A5F,color:#fff
    style SERVICES  fill:#E8F5E9,stroke:#388E3C,color:#1B5E20

SOA vs. MSA

ComparisonSOAMSA
Service sizeRelatively large service units (enterprise functions)Very small service units (single responsibility)
Communication styleCentralized integration via ESBDirect communication via REST/message queues
Data managementShared databases allowedIndependent DB per service (Database per Service)
Deployment unitService unit (relatively large)Independent container/service unit
CouplingCentralized control via ESB (relatively tighter coupling)Maximized loose coupling between services
Suitable environmentLarge enterprise legacy integrationCloud-native, rapid-deployment environments

Architecture Evolution Path

    flowchart LR
    MONO["Monolithic"] -->|"Split into services"| SOA2["SOA<br/>ESB-based integration"]
    SOA2 -->|"Decompose, lighten"| MSA2["MSA<br/>independent deployment, containers"]
    MSA2 -->|"Go event-driven"| EDA2["EDA + MSA<br/>event-driven microservices"]

    style MONO fill:#f5f5f5,stroke:#ccc,color:#333
    style SOA2 fill:#E3F2FD,stroke:#1976D2,color:#000
    style MSA2 fill:#FFF3E0,stroke:#F57C00,color:#000
    style EDA2 fill:#E8F5E9,stroke:#388E3C,color:#000

3. Expected Benefits and Application of SOA

CategoryKey Expected BenefitApplication and Practical Use
Legacy integrationIntegrates heterogeneous systems through standard interfaces via an ESBBuild a data-integration hub linking ERP, CRM, and SCM
Maximized reuseCommon services shared across multiple channelsOffer authentication, payment, and customer services as shared services
Business agilityQuickly compose new business processes from existing servicesImplement new business processes as service compositions using BPEL/BPM
Foundation for MSA transitionGradually decompose SOA services to migrate toward MSAUse the Strangler Fig pattern to progressively migrate legacy SOA to MSA
Hexagonal ArchitectureEDA (Event-Driven Architecture)