Service-Oriented Architecture (SOA) in System Design

Service-Oriented Architecture (SOA) is a way of building software as a collection of reusable services that communicate over a network through well-defined contracts. Instead of each application containing its own copy of features such as customer lookup, payments or notifications, those features are offered once as shared services that many applications can use.

This tutorial explains why SOA was created, its core principles, its building blocks such as the service registry and the Enterprise Service Bus (ESB), the main types of services, how SOAP and REST services are built in Java, and how SOA compares with monoliths and microservices. It ends with advantages, drawbacks and guidance on when SOA still makes sense today.

1. What Is Service-Oriented Architecture?

Picture a large city. Every house does not dig its own well, run its own power plant and hire its own postman. Instead, the city provides shared services: a water utility, an electricity company and a postal service. Each has a clear way to use it (a tap, a socket, a post box) and hides how it works inside. Houses simply use the services they need.

SOA applies this idea to enterprise software. A service is a self-contained unit of business functionality, such as "check a customer's credit" or "create an invoice", that:

• exposes a contract describing what it does, what inputs it needs and what it returns,
• hides how it is implemented (language, database, platform),
• can be called over a network by any authorised application,
• is designed to be reused across many business processes.

Applications are then built by composing services, much like assembling a process from building blocks. SOA became popular in large organisations in the early 2000s, often using SOAP web services and an Enterprise Service Bus.

2. Why SOA Was Created

Large companies typically run dozens of systems bought or built over many years: a CRM for customers, an ERP for finance, a warehouse system, an HR system and more. Each was built with different technology, and each kept its own copy of shared data such as customer details.

When these systems needed to talk to each other, teams built custom point-to-point integrations between each pair. With a handful of systems, the number of connections exploded, every change broke something, and the same logic was duplicated everywhere.

SOA addressed these problems by:

• Reusing business functions as shared services instead of duplicating them.
• Standardising how systems communicate, using common protocols and message formats.
• Decoupling systems so one can be replaced without rewriting all the others.
• Aligning IT with business processes, so a process like "open a bank account" is modelled as a composition of services.

3. Core Principles of SOA

4. Components of SOA

A classic SOA has three roles connected in a triangle, plus supporting infrastructure:

• Service provider: implements the service and publishes its contract.
• Service consumer: any application or service that calls a service.
• Service registry/repository: a catalogue of available services, their contracts, versions and owners. Historically UDDI registries; today often an API catalogue or developer portal.
• Service contract: the formal interface, traditionally a WSDL file for SOAP services, or an OpenAPI document for REST services.
• Enterprise Service Bus (ESB): middleware that connects services, routes and transforms messages and applies shared policies (explained next).
• Governance: the rules and processes for designing, versioning, securing and retiring services across the organisation.

5. The Enterprise Service Bus (ESB)

The ESB is the communication backbone of many SOA implementations. Rather than calling each other directly, services send messages through the bus, which provides:

• Routing: deciding which service receives a message, for example based on its content.
• Transformation: converting between formats, such as XML from an old system to the format a newer service expects.
• Protocol mediation: letting a service that speaks SOAP over HTTP talk to one that reads from a JMS queue or a file drop.
• Orchestration: running multi-step business processes that call several services in order.
• Cross-cutting policies: security, logging, monitoring and reliable delivery in one place.

Well-known ESB products include MuleSoft, IBM Integration Bus (App Connect), Oracle Service Bus, WSO2, and open-source integration frameworks such as Apache Camel and Apache ServiceMix.

The ESB is also SOA's biggest weakness. When too much business logic moves into the bus, it becomes a central, complex component that every team depends on, a bottleneck for changes and a single point of failure. This "smart pipes" problem is one of the main reasons the microservices movement later preferred "smart endpoints and dumb pipes".

6. How SOA Works: A Loan Application Example

A bank wants to let customers apply for loans through a web portal. In an SOA design, the process is built from existing shared services:

1. The customer submits an application on the portal.
2. The Loan Application process service asks the Customer Service for the customer's verified details.
3. It calls the Credit Check Service, which in turn talks to an external credit bureau.
4. It stores the uploaded salary slips through the Document Service.
5. Based on the credit score, it approves or rejects the loan and asks the Notification Service to email the customer.

The key benefit is reuse. The Customer Service is also used by the account-opening process, the Credit Check Service by the credit card process, and the Notification Service by almost everything. Each service is built once and maintained by one team.

7. Types of Services in SOA

8. SOAP Web Services and WSDL

Many SOA systems use SOAP (originally "Simple Object Access Protocol"), an XML-based messaging protocol. Every message is an XML envelope with an optional header (for security tokens, transaction IDs and so on) and a body containing the actual request or response. The service's operations and data types are described in a WSDL (Web Services Description Language) file, from which client code can be generated automatically.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:cr="http://javabytechie.com/credit">
    <soap:Header/>
    <soap:Body>
        <cr:checkCredit>
            <customerId>C-1042</customerId>
            <loanAmount>500000</loanAmount>
        </cr:checkCredit>
    </soap:Body>
</soap:Envelope>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:cr="http://javabytechie.com/credit">
    <soap:Body>
        <cr:checkCreditResponse>
            <score>742</score>
            <decision>APPROVED</decision>
        </cr:checkCreditResponse>
    </soap:Body>
</soap:Envelope>

SOAP comes with a family of WS-* standards for security (WS-Security), reliable messaging and transactions, which is why it remains common in banking, insurance, telecoms and government integrations. Its downsides are verbose XML and heavier tooling. SOA itself does not require SOAP; many modern service-oriented systems use REST with JSON and OpenAPI contracts instead.

9. Building a SOAP Service in Java

Jakarta XML Web Services (JAX-WS) lets you turn a plain Java class into a SOAP service with annotations. Since Java 11, the implementation is a separate dependency, such as com.sun.xml.ws:jaxws-rt.

package com.javabytechie.soa;

import jakarta.jws.WebMethod;
import jakarta.jws.WebParam;
import jakarta.jws.WebService;

@WebService(serviceName = "CreditCheckService", targetNamespace = "http://javabytechie.com/credit")
public class CreditCheckService {

    @WebMethod
    public CreditResult checkCredit(@WebParam(name = "customerId") String customerId,
                                    @WebParam(name = "loanAmount") long loanAmount) {
        int score = lookUpScore(customerId);
        String decision = (score >= 700 && loanAmount <= 1_000_000) ? "APPROVED" : "REVIEW";
        return new CreditResult(score, decision);
    }

    private int lookUpScore(String customerId) {
        // In a real system this would call the credit bureau
        return customerId.endsWith("2") ? 742 : 655;
    }
}

package com.javabytechie.soa;

public class CreditResult {

    private int score;
    private String decision;

    public CreditResult() { }                    // required by JAXB for XML mapping

    public CreditResult(int score, String decision) {
        this.score = score;
        this.decision = decision;
    }

    public int getScore() { return score; }
    public void setScore(int score) { this.score = score; }
    public String getDecision() { return decision; }
    public void setDecision(String decision) { this.decision = decision; }
}

package com.javabytechie.soa;

import jakarta.xml.ws.Endpoint;

public class CreditServicePublisher {

    public static void main(String[] args) {
        String address = "http://localhost:8085/credit";
        Endpoint.publish(address, new CreditCheckService());
        System.out.println("Credit Check Service running. WSDL: " + address + "?wsdl");
    }
}

Credit Check Service running. WSDL: http://localhost:8085/credit?wsdl

Opening the WSDL URL shows the generated contract. Any consumer, written in Java, C#, Python or another language, can generate a client from it. In Spring applications, Spring Web Services offers a contract-first alternative where you write the XML schema first and generate Java classes from it.

10. Composing REST Services in Java

Modern service-oriented systems often use REST and JSON. The process service below composes three shared services into the loan workflow using Spring's RestClient:

package com.javabytechie.soa;

import java.math.BigDecimal;

import org.springframework.stereotype.Service;
import org.springframework.web.client.RestClient;

@Service
public class LoanApplicationService {

    public record LoanRequest(String customerId, BigDecimal amount) { }
    public record Customer(String id, String name, String email) { }
    public record CreditCheckRequest(String customerId, BigDecimal amount) { }
    public record CreditReport(int score) { }
    public record Notification(String to, String message) { }
    public record LoanDecision(boolean approved, String message) { }

    private final RestClient customerService;
    private final RestClient creditService;
    private final RestClient notificationService;

    public LoanApplicationService(RestClient.Builder builder) {
        this.customerService = builder.clone().baseUrl("http://customer-service/api").build();
        this.creditService = builder.clone().baseUrl("http://credit-service/api").build();
        this.notificationService = builder.clone().baseUrl("http://notification-service/api").build();
    }

    public LoanDecision apply(LoanRequest request) {
        Customer customer = customerService.get()
                .uri("/customers/{id}", request.customerId())
                .retrieve()
                .body(Customer.class);

        CreditReport report = creditService.post()
                .uri("/credit-checks")
                .body(new CreditCheckRequest(customer.id(), request.amount()))
                .retrieve()
                .body(CreditReport.class);

        LoanDecision decision = report.score() >= 700
                ? new LoanDecision(true, "Dear " + customer.name() + ", your loan is approved.")
                : new LoanDecision(false, "Dear " + customer.name() + ", your application needs review.");

        notificationService.post()
                .uri("/notifications")
                .body(new Notification(customer.email(), decision.message()))
                .retrieve()
                .toBodilessEntity();

        return decision;
    }
}

Each called service is owned by a different team and reused elsewhere. The process service knows only their contracts. In production you would add timeouts, retries, circuit breakers and security tokens to these calls.

11. Monolith vs SOA vs Microservices

SOA sits between a single monolithic application and fine-grained microservices. Microservices are often described as an evolution of SOA ideas, with smaller services and lighter communication.

See Monolithic vs Microservices Architecture for more on the other two styles.

12. Advantages of SOA

• Reusability: a service built once is used by many applications, reducing duplicate code and cost.
• Easier integration: standard contracts let very different systems, including legacy mainframes and packaged software, work together.
• Loose coupling: services can be modified or replaced behind a stable contract.
• Technology independence: each service can use the platform that suits it best.
• Business alignment: services map to business capabilities, making processes easier to understand and change.
• Parallel development: different teams can build different services at the same time.
• Centralised policies: security, auditing and monitoring can be enforced consistently, often in the ESB.

13. Disadvantages of SOA

• Complex middleware: ESBs and governance tools are expensive and need specialised skills.
• ESB bottleneck: putting too much logic in the bus creates a central component that slows every change and can fail for everyone.
• Performance overhead: network calls, XML processing and message transformation add latency.
• Heavy governance: enterprise-wide standards and approval processes can slow teams down.
• Shared data coupling: services sharing large enterprise databases are harder to change independently.
• Upfront investment: designing reusable services requires significant analysis before benefits appear.

14. When to Use SOA Today

SOA is still a good fit when:

• You must integrate many existing systems, such as ERP, CRM, mainframes and partner systems, that cannot be rewritten.
• You work in a regulated industry (banking, insurance, healthcare, government) where SOAP and WS-Security are expected by partners.
• Many applications need the same business capabilities, and central reuse is more valuable than independent speed.
• The organisation already has integration middleware and skills in place.

For new cloud-native products built by autonomous teams, microservices or a well-structured modular monolith are usually better starting points. Many large organisations run a hybrid: SOA-style integration for core and legacy systems, with microservices for new customer-facing products.

15. Best Practices

• Design services around business capabilities, not database tables or technical layers.
• Write contracts first and treat them as public APIs: version them and avoid breaking changes.
• Keep the ESB focused on routing, transformation and protocol bridging; keep business rules inside services.
• Make services stateless and idempotent where possible, so retries are safe.
• Maintain a searchable service catalogue with owners, documentation and versions.
• Secure every service call with authentication, authorisation and encryption.
• Monitor each service and trace requests across service calls with correlation IDs.
• Keep governance lightweight enough that it guides teams without blocking them.

16. Summary

• SOA builds systems from reusable, network-accessible services with standard contracts.
• Its core principles are standard contracts, loose coupling, abstraction, reuse, autonomy, statelessness, discoverability and composability.
• Key components are service providers, consumers, a registry and often an Enterprise Service Bus for routing, transformation and orchestration.
• Services can be built with SOAP and WSDL or with REST and OpenAPI; SOA is an architectural style, not a single technology.
• Compared with microservices, SOA uses larger services, more central governance and smarter middleware, and focuses on enterprise-wide reuse and integration.

Understanding SOA explains where many microservices ideas came from and why certain trade-offs were made. Open the FAQ tab for answers to common questions about Service-Oriented Architecture.

Frequently Asked Questions (FAQ)