Service-Oriented Architecture (SOA) & ESB

1. Overview

서비스 지향 아키텍처 및 ESB(Service-Oriented Architecture & ESB, SOA)는 기업 내 산재한 다양한 정보 기술들을 '서비스'라는 표준 단위로 묶고, 이들을 유기적으로 연결하여 거대한 물리적 협업 망을 구축하는 전략적 아키텍처입니다.

학습자는 단순한 RPC 호출을 넘어, 비즈니스 기능을 추상화하고 재사용 가능하게 만드는 SOA 8대 원칙을 배웁니다. 특히, 흩어진 서비스 간의 메시지 라우팅, 프로토콜 변환, 데이터 포맷팅을 중앙에서 지휘하는 **엔터프라이즈 서비스 버스(ESB)**의 수리적 메커니즘과, 그로 인해 발생하는 중앙 집중형 병목 물리학을 익힙니다. 이를 통해 과거의 유산(Legacy)과 최신 시스템을 조화롭게 통합하고, 전사적 규모의 정보 자산을 관리하는 하이엔드 설계 능력을 확보합니다.

2. Scope & Boundaries

In-Scope

• SOA Core Principles: 서비스 계약(Contract), 느슨한 결합, 추상화, 재사용성 등 8대 원칙
• ESB Mechanics: 지능형 라우팅, 메시지 변환(Transformation), 프로토콜 중개(Mediation)
• Web Services Standards: XML, SOAP, WSDL 기반의 엄격한 물리 통신 규약
• Orchestration vs Choreography: 서비스 제어 주체에 따른 물리적 워크플로우 차이

Out-of-Scope

• RESTful API의 경량화 구현 상세 (07-06-XX 영역에서 분담)
• 마이크로서비스 아키텍처(MSA)의 분산 운영 상세 (07-01-01 영역에서 분담)

Boundaries

• SOA vs. Microservices: SOA가 '엔터프라이즈 전반의 공유와 통합'에 집중한다면, 마이크로서비스는 '개별 서비스의 독립성과 신속한 변화'에 집중하여 구분합니다.

3. Counterexample

• 단순히 "웹 서비스 쓰기"라 설명하는 것은 SOA 학습이 아닙니다. 왜 ESB가 모든 트래픽의 중심이 될 때 하드웨어가 겪는 '단일 장애점(SPOF)' 위험을 수리 물리적으로 증명할 수 있어야 하며, 서비스 간의 **강한 결합(Tight Coupling)**이 XML 스키마 변경 시 전체 시스템에 어떤 물리적 마비를 일으키는지 논증하지 못한다면 SOA의 교훈을 제대로 이해하지 못한 것입니다.

4. Prerequisites

• Network Layers & Protocols (Basic): HTTP, TCP/IP 기본 이해가 필수입니다. (08-01-02 기반 역량)
• Data Engineering Concepts (Recommended): XML, JSON 등 데이터 직렬화 이해가 권장됩니다. (06-03-02 DGS)

5. Learning Map

1. The Service Island: 파편화된 기업 자산을 서비스라는 표준 단위로 물리 캡슐화합니다.
2. The Backbone Bus: 흩어진 서비스들을 ESB라는 공통 통로에 물리 정착시킵니다.
3. Format Translation: 서로 다른 언어와 프로토콜로 말하는 서비스들 사이의 수리적 번역 체계를 구축합니다.
4. Enterprise Composability: 필요한 서비스를 조립하여 새로운 비즈무형을 즉시 만들어내는 공학을 완성합니다.

6. Learning Topics

Basic

Core: SOA의 근본 원칙과 서비스 정의 (SOA Core)

• Why to Learn: 기술이 아닌 '비즈니스 가치' 중심으로 시스템 경계를 획정하기 위해서입니다.
• What to Learn:
  • Service Contract: 서비스가 제공하는 기능과 데이터 형식의 물리적 명세
  • Loose Coupling: 서비스 간의 하드웨어/플랫폼 의존성 최소화 수리 모델
  • Autonomy: 서비스 내부의 자율적 통제권과 독립성
• How to Learn:
  • 기존 함수 호출 구조를 '서비스 계약'으로 변환했을 때, 수정 범위가 어떻게 물리적으로 줄어드는지 분석 실습
  • 표준화된 인터페이스(WSDL 등)를 통해 서비스의 가용 범위를 시각화
• Implement: 서비스의 기능과 입력/출력 형식을 정의한 기초 서비스 명세서 예시

Recommended

Core: 엔터프라이즈 서비스 버스의 물리 (ESB Mechanics)

• Why to Learn: 수백 개의 서비스가 직접 연결되어 얽히는 '스파게티 아키텍처'를 물리적으로 방지하기 위함입니다.
• What to Learn:
  • Content-based Routing: 메시지 안의 데이터를 보고 도착지를 결정하는 물리 엔진
  • Transformation: XML을 JSON으로, 혹은 그 반대로 바꾸는 수리적 변환기
  • Protocol Mediation: HTTP 요청을 JMS나 SFTP로 연결해 주는 하드웨어 중개
• How to Learn:
  • 서비스 A와 B 사이에 ESB를 두고, 메시지 포맷을 실시간으로 변환하여 전달하는 물리적 연동 실습
  • ESB에 트래픽이 몰릴 때 처리 지연 시간($Latency$)이 어떻게 기하급수적으로 늘어나는지 관찰
• Implement: 입력 메시지의 특정 필드 값에 따라 다른 대상 서비스로 토스하는 가상 BusRouter

Practical

Core: 오케스트레이션과 비즈니스 프로세스 (BPEL & Workflow)

• Why to Learn: 여러 서비스를 엮어 복잡한 비즈니스 시나리오를 자동화하기 위해서입니다.
• What to Learn:
  • Service Composability: 원자 서비스를 조합하여 복합(Composite) 서비스를 만드는 물리학
  • BPEL (Business Process Execution Language): 서비스 실행 순서를 제어하는 수리 언어
  • Transaction Bridge: 서로 다른 서비스 간의 분산 트랜잭션 관리(WS-AtomicTransaction)
• How to Learn:
  • 휴가 신청-승인-로그 기록의 3단계를 BPEL 모델로 그려보고, 각 단계의 물리적 응답 대기 시간 산출 실습
  • 중간 단계 실패 시 이전 작업을 되돌리는 '보상 트랜잭션'의 수리적 설계
• Implement: 순차적 서비스 호출 흐름을 정의한 워크플로우 다이어그램 및 설정 파일

Advanced

Core: 거버넌스와 레거시 통합 전략 (Governance & Legacy)

• Why to Learn: 수십 년 된 메인프레임과 최신 클라우드 서비스를 물리적으로 공존시키기 위함입니다.
• What to Learn:
  • Service Registry: 승인된 서비스의 위치와 버전을 관리하는 물리 저장소
  • Service Invalidation: 낡은 서비스를 시스템 망에서 물리적으로 퇴출시키는 절차
  • Policy Enforcement: 보안 및 성능 정책을 서비스 전체에 일괄 적용하는 기제
• How to Learn:
  • 신규 서비스 등록 시 거버넌스 체크리스트를 통과하지 못하면 버스 진입을 차단하는 시뮬레이션 실습
  • 레거시 시스템을 '서비스 래퍼(Wrapper)'로 감싸 SOA망에 이식할 때의 하드웨어 부하 분산 분석
• Implement: 전사 서비스 일람과 각 서비스의 상태를 모니터링하는 ServiceCatalog 관리툴 기획

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Design / Architecture Styles (Service-oriented) — Structural context.
• [P1] CS2023 - NC/Networking and Communication (Application layer protocols) — Transport context.

Secondary

• [Service-Oriented Architecture: Concepts, Technology, and Design] Thomas Erl — The definitive SOA series.
• [Enterprise Integration Patterns] Gregor Hohpe — Patterns for ESB and messaging.

Industry

• [IBM: What is Service-Oriented Architecture?] — Enterprise perspective.
• [Oracle: Enterprise Service Bus Architecture Guide] — Implementation standard.

9. Final Checklist

Primary

• 'SOA'의 핵심 원칙 중 '서비스 계약(Service Contract)'이 왜 하드웨어 플랫폼에 무관한 호출을 가능케 하는지 설명 가능한가? (P2)
• 'XML/SOAP' 방식이 'JSON/REST'에 비해 네트워크 전송 및 처리(Parsing) 측면에서 유발하는 물리적 부하를 기술할 수 있는 가? (P1)

Secondary

• 'ESB'를 통한 중앙 집중형 통합이 시스템의 '확장성'에는 유리하지만 '응답 지연'에는 불리한 수리적 이유를 소통 가능한가?
• 오케스트레이션(Orchestration) 방식에서 중앙 제어기가 정지했을 때 전체 비즈니스 프로세스가 겪는 물리적 치명타를 입증할 수 있는 가?

Industry

• 기업의 기존 레거시 시스템을 SOA망에 통합하기 위해 '어댑터 패턴'을 적용한 물리적 중개 시나리오를 제안할 수 있는 가? (SFIA)
• 수천 개의 서비스가 연동되는 환경에서 '서비스 저장소(Registry)'의 동기화 배포 주기가 시스템 전체 가용성에 미치는 영향을 분석할 수 있는 가?