서비스 지향 아키텍처편집자 확인

서비스는 서비스 지향 아키텍처의 핵심 구성 요소이다. 이는 특정 비즈니스 기능을 수행하는 독립적인 소프트웨어 구성 요소로 정의된다. 각 서비스는 잘 정의된 인터페이스를 통해 다른 서비스나 애플리케이션과 통신하며, 내부 구현 세부 사항은 외부에 노출되지 않는다. 서비스는 일반적으로 비즈니스 프로세스에서 의미 있는 단위, 예를 들어 '고객 정보 조회', '주문 생성', '결제 처리'와 같은 기능을 캡슐화한다.

서비스는 자율적이고 재사용 가능한 단위로 설계된다. 자율성은 서비스가 다른 서비스에 대한 의존성을 최소화하고 스스로 제어할 수 있는 상태를 의미한다. 재사용성은 서비스를 다양한 비즈니스 컨텍스트에서 여러 번 활용할 수 있도록 설계하는 원칙이다. 이를 통해 새로운 애플리케이션을 구축할 때 기존 서비스를 조합하여 개발 시간과 비용을 절감할 수 있다.

서비스는 표준화된 프로토콜을 통해 접근된다. 초기 SOA 구현에서는 XML, SOAP, WSDL을 기반으로 한 웹 서비스가 널리 사용되었다. 이후에는 HTTP 프로토콜과 REST 원칙을 따르는 RESTful API가 대안으로 부상했다. 서비스의 특성은 다음과 같은 표로 요약할 수 있다.

이러한 서비스의 집합이 상호 연결되어 더 큰 비즈니스 애플리케이션이나 유연한 비즈니스 프로세스를 구성하는 것이 서비스 지향 아키텍처의 기본 아이디어이다.

느슨한 결합은 서비스 지향 아키텍처의 근본적인 설계 원칙 중 하나이다. 이는 시스템을 구성하는 개별 서비스들이 서로 최소한의 의존성을 가지며 독립적으로 운영될 수 있도록 하는 것을 의미한다. 느슨한 결합을 통해 한 서비스의 내부 구현이 변경되더라도 다른 서비스에 미치는 영향을 최소화할 수 있다. 이는 시스템 전체의 유연성과 유지보수성을 크게 향상시킨다.

느슨한 결합은 주로 잘 정의된 서비스 계약을 통해 달성된다. 서비스들은 공개된 인터페이스(계약)를 통해서만 상호작용하며, 상대방의 내부 데이터 구조, 구현 언어, 플랫폼 등에 대한 지식을 갖지 않는다. 예를 들어, 웹 서비스에서는 SOAP과 WSDL이, RESTful API에서는 HTTP 메서드와 JSON 또는 XML 형식이 이러한 계약의 역할을 수행한다.

이 원칙의 주요 이점은 다음과 같이 정리할 수 있다.

반대로, 서비스 간에 내부 데이터베이스를 직접 공유하거나 비공개 프로토콜로 통신하는 경우는 긴밀한 결합에 해당하며, SOA의 목표와 반대되는 설계로 간주된다. 느슨한 결합의 정도는 통신 프로토콜, 데이터 형식, 서비스 발견 메커니즘 등 여러 계층에서 조절될 수 있다.

서비스 계약은 서비스 지향 아키텍처에서 서비스와 그 소비자 간의 상호 작용을 정의하는 공식적인 규격이다. 이 계약은 서비스가 무엇을 수행하는지, 어떻게 접근하는지, 어떤 데이터를 교환하는지를 명확히 기술하여, 서비스의 외부 인터페이스를 규정한다. 서비스 계약은 서비스의 내부 구현을 완전히 숨기고, 오직 공개된 계약을 통해서만 상호작용이 이루어지도록 보장한다. 이는 느슨한 결합을 실현하는 핵심 메커니즘이다.

일반적으로 서비스 계약은 다음 세 가지 핵심 요소를 포함한다.

* 기능적 정의: 서비스가 제공하는 작업 또는 기능을 명시한다. 예를 들어, '주문 생성', '고객 정보 조회'와 같은 작업 목록을 정의한다.

* 데이터 정의: 각 작업의 입력 매개변수와 출력 결과의 데이터 형식을 규정한다. 이는 XML 스키마나 JSON 스키마와 같은 표준 형식으로 기술된다.

* 비기능적 정의: 서비스의 품질 속성을 기술한다. 여기에는 성능(응답 시간, 처리량), 가용성, 보안 프로토콜, 트랜잭션 지원 여부 등이 포함될 수 있다.

서비스 계약은 기술 중립적인 형태로 정의되는 것이 이상적이다. 이를 구현하는 대표적인 기술 표준으로는 웹 서비스 기반의 WSDL(Web Services Description Language)과 SOAP 프로토콜이 있다. WSDL은 서비스의 기능적, 데이터적 정의를 XML로 기술하는 데 사용된다. 최근에는 RESTful API의 경우 OpenAPI 명세서가 사실상의 표준 계약 정의 도구로 널리 사용된다. 서비스 계약은 한 번 정의되면 변경하지 않는 것이 원칙이며, 변경이 불가피할 경우는 하위 호환성을 유지하는 새로운 버전을 발행하는 전략을 따른다[2].

표준화된 서비스 계약은 서비스 지향 아키텍처의 기본 원칙 중 하나로, 서비스와 그 소비자 간의 상호작용을 명확히 정의하는 공식적 인터페이스를 의미한다. 이 계약은 서비스가 무엇을 수행하는지, 어떻게 호출되는지, 어떤 데이터를 교환하는지에 대한 모든 세부사항을 포함한다. 계약은 서비스의 공개된 기능을 정의하는 동시에 내부 구현 세부사항은 숨기는 서비스 추상화의 기초가 된다.

이 원칙의 핵심은 계약의 표준화에 있다. 서비스 간의 통신은 WSDL, OpenAPI(Swagger), gRPC 인터페이스 정의 언어(IDL)와 같이 널리 알려진 표준 형식을 사용하여 정의된다. 이를 통해 서로 다른 플랫폼이나 프로그래밍 언어로 개발된 서비스들도 표준화된 계약을 통해 원활하게 상호작용할 수 있다. 예를 들어, 자바로 작성된 서비스 제공자와 .NET으로 작성된 서비스 소비자는 XML 기반의 SOAP 프로토콜과 WSDL 계약을 공유함으로써 통신이 가능해진다.

표준화된 서비스 계약은 느슨한 결합을 실현하는 데 필수적이다. 서비스 소비자는 서비스의 내부 로직이나 구현 기술에 의존하지 않고, 오직 공개된 계약만을 바탕으로 서비스를 호출한다. 이로 인해 서비스 제공자는 내부 구현을 변경하거나 업그레이드하더라도, 공개 계약을 유지하는 한 소비자에게 영향을 미치지 않는다. 결과적으로 시스템의 유연성과 유지보수성이 크게 향상된다.

서비스 추상화는 서비스 지향 아키텍처의 기본 원칙 중 하나로, 서비스의 내부 구현 세부 사항을 숨기고 필요한 기능만을 명확한 서비스 계약을 통해 외부에 노출하는 것을 의미한다. 이 원칙은 서비스의 복잡성을 관리하고, 서비스 간의 느슨한 결합을 강화하며, 시스템의 유연성과 유지보수성을 높이는 데 핵심적인 역할을 한다.

서비스 추상화는 일반적으로 여러 수준에서 적용된다. 가장 기본적인 수준은 기술적 추상화로, 서비스가 특정 프로그래밍 언어, 운영 체제, 데이터베이스 시스템과 같은 기술 플랫폼에 종속되지 않도록 한다. 다음으로 기능적 추상화는 서비스가 제공하는 비즈니스 기능이나 작업을 논리적인 단위로 정의하고, 내부의 복잡한 처리 로직이나 데이터 구조를 캡슐화한다. 예를 들어, '고객 정보 조회' 서비스는 내부적으로 여러 데이터베이스 테이블을 조인하거나 복잡한 검증 로직을 수행할 수 있지만, 소비자에게는 단순히 고객 ID를 입력받아 관련 정보를 반환하는 인터페이스만을 제공한다.

이 원칙을 효과적으로 적용하기 위해서는 서비스 계약이 내부 구현이 아닌 필수적인 기능과 데이터에만 집중해야 한다. 계약에는 서비스의 엔드포인트, 작업, 입력/출력 메시지 형식, 사전/사후 조건, 오류 처리 방식 등이 명시되지만, 이러한 기능이 어떻게 구현되는지는 포함되지 않는다. 결과적으로 서비스 제공자는 성능 최적화, 기술 스택 변경, 알고리즘 개선 등 내부 구현을 자유롭게 변경할 수 있으며, 이러한 변경이 서비스 소비자에게 영향을 미치지 않게 된다. 이는 시스템의 진화와 기술 부채 관리에 매우 유리한 환경을 조성한다.

서비스 재사용성은 서비스 지향 아키텍처의 근본적인 목표 중 하나이다. 이 원칙은 특정 비즈니스 기능을 수행하는 서비스를 설계할 때, 여러 다른 애플리케이션이나 비즈니스 프로세스에서 재사용될 수 있도록 만드는 것을 강조한다. 단일 목적을 위한 애플리케이션을 구축하는 대신, 범용적으로 활용 가능한 서비스 컴포넌트를 개발함으로써 시스템 전체의 효율성을 높인다.

재사용 가능한 서비스는 일반적으로 특정 비즈니스 엔터티(예: 고객, 주문)나 잘 정의된 비즈니스 작업(예: 신용 조회, 가격 계산)을 중심으로 설계된다. 이러한 서비스는 느슨한 결합과 명확한 서비스 계약을 통해 구현되며, 내부 구현의 복잡성은 숨기고 표준화된 인터페이스만을 외부에 노출한다. 결과적으로 새로운 애플리케이션을 구축할 때 기존 서비스를 조합하여 빠르게 개발할 수 있으며, 이는 개발 시간과 비용을 절감하는 효과를 가져온다.

서비스 재사용성을 성공적으로 달성하기 위해서는 초기 설계 단계부터 재사용 가능성을 고려해야 한다. 이는 서비스의 범위를 적절하게 정의하고, 너무 구체적이거나 너무 포괄적이지 않은 수준의 추상화를 유지하는 것을 포함한다. 또한 서비스의 존재와 기능을 쉽게 찾고 이해할 수 있도록 서비스 레지스트리와 같은 메커니즘을 통해 서비스를 잘 문서화하고 게시하는 것이 중요하다.

재사용성은 단순한 코드의 재사용을 넘어, 비즈니스 로직, 데이터 모델, 그리고 통합 노력 자체의 재사용을 의미한다. 잘 설계된 재사용 가능 서비스는 기업의 IT 자산 가치를 높이고, 시스템의 유지보수성을 개선하며, 비즈니스 변화에 더 민첩하게 대응할 수 있는 기반을 제공한다.

서비스 자율성은 각 서비스가 설계, 개발, 배포, 운영, 진화 과정에서 다른 서비스나 외부 시스템에 대한 의존성을 최소화하여 독립적으로 기능할 수 있는 능력을 의미한다. 이는 느슨한 결합을 실현하는 핵심 원칙 중 하나이다. 자율적인 서비스는 자신의 비즈니스 로직과 데이터를 캡슐화하며, 내부 구현을 변경하더라도 외부에 공개된 서비스 계약을 훼손하지 않는 한 다른 서비스에 영향을 주지 않는다.

서비스 자율성의 수준은 구현 방식에 따라 달라질 수 있다. 가장 높은 수준의 자율성은 서비스가 자신의 데이터를 독립적으로 소유하고 관리하는 것을 포함한다. 이는 데이터 중복을 허용하더라도 다른 서비스의 데이터베이스에 직접 접근하는 강한 의존성을 피하기 위한 전략이다. 자율성은 서비스의 변경과 배포 주기를 독립적으로 관리할 수 있게 하여, 시스템 전체의 민첩성과 유지보수성을 크게 향상시킨다.

서비스 자율성을 달성하기 위한 주요 접근 방식은 아래와 같다.

이러한 자율성은 시스템의 복잡성을 관리하고, 장애 격리와 확장성을 개선하는 데 기여한다. 그러나 지나치게 높은 자율성은 데이터 일관성 유지와 분산 트랜잭션 처리와 같은 새로운 도전 과제를 야기할 수 있다.

서비스 발견 가능성은 서비스 지향 아키텍처의 기본 원칙 중 하나로, 서비스가 명확하게 정의되고 설명되어, 필요할 때 쉽게 찾아서 사용할 수 있어야 한다는 원칙이다. 이는 서비스의 존재와 기능, 접근 방법을 서비스 소비자에게 효과적으로 알리는 메커니즘을 포함한다.

이 원칙을 구현하기 위해 서비스 레지스트리나 디렉터리와 같은 중앙 저장소가 자주 사용된다. 서비스 제공자는 새 서비스를 개발하거나 기존 서비스를 변경할 때, 해당 서비스의 기술적 인터페이스(WSDL), 위치(URL), 비즈니스 기능 설명 등을 이 저장소에 등록한다. 서비스 소비자는 필요한 기능을 검색하여 적합한 서비스를 발견하고, 그 정보를 바탕으로 서비스를 호출할 수 있다. 이 과정은 수동으로 이루어질 수도 있고, 런타임에 자동으로 이루어지는 동적 발견 방식으로 구현될 수도 있다.

서비스 발견 가능성을 보장하기 위해서는 서비스에 대한 명확한 메타데이터가 필수적이다. 이 메타데이터는 서비스의 기능, 사용 방법, 품질 속성(성능, 가용성 등), 비즈니스 규칙 등을 설명한다. 잘 구성된 메타데이터는 서비스의 재사용성을 극대화하고, 시스템 통합의 복잡성을 줄이며, 서비스 포트폴리오의 관리 효율성을 높인다.

웹 서비스는 서비스 지향 아키텍처를 구현하는 데 널리 사용되는 기술 표준 모음이다. 특히 SOAP과 WSDL은 초기 웹 서비스의 핵심 프로토콜과 언어로, 플랫폼과 프로그래밍 언어에 독립적인 상호 운용성을 보장하는 것을 목표로 했다.

SOAP은 구조화된 정보를 교환하기 위한 XML 기반의 프로토콜이다. 주로 HTTP나 SMTP 같은 인터넷 프로토콜을 전송 수단으로 사용하며, 메시지의 헤더와 바디를 정의하는 엄격한 XML 스키마를 따른다. 이는 서비스 간에 전송되는 데이터와 명령을 표준화된 형식으로 포장하여, 서로 다른 기술 스택을 가진 시스템 간 통신을 가능하게 한다.

서비스의 인터페이스를 기술적으로 정의하기 위해 WSDL이 사용된다. WSDL 문서는 특정 웹 서비스가 제공하는 기능(작업), 해당 기능을 호출하는 데 필요한 메시지 형식, 메시지를 전송할 프로토콜(예: SOAP over HTTP), 그리고 서비스가 위치한 네트워크 주소(엔드포인트)를 XML 형식으로 상세히 기술한다. 이는 서비스 제공자와 소비자 사이의 명확한 계약 역할을 하며, 개발 도구가 이를 자동으로 파싱하여 클라이언트 코드를 생성하는 데 활용된다.

이 기술 스택의 일반적인 구현 흐름은 다음과 같다. 서비스 제공자는 기능을 구현하고, 그 인터페이스를 WSDL 문서로 공개한다. 서비스 소비자는 이 WSDL 문서를 참조하여 SOAP 메시지를 구성하고, 정의된 엔드포인트로 요청을 전송한다. 서비스 제공자는 SOAP 메시지를 처리하고, 결과를 다시 SOAP 응답 메시지로 포장하여 반환한다. 이 접근 방식은 높은 표준화와 강력한 타입 안전성을 제공하지만, XML의 상대적 복잡성과 오버헤드로 인해 경량의 RESTful API에 비해 더 무겁다는 평가를 받기도 한다.

RESTful API는 REST 아키텍처 스타일의 제약 조건을 따르는 API이다. 서비스 지향 아키텍처의 구현 기술 중 하나로, 웹 서비스의 복잡성을 줄이고 경량화된 통신을 지향한다. HTTP 프로토콜을 기반으로 하며, 자원을 URI로 식별하고 HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 해당 자원에 대한 조작을 정의한다.

RESTful API의 핵심 설계 원칙은 다음과 같다.

* 자원 지향 아키텍처: 모든 데이터나 서비스를 자원으로 간주하고 고유한 URI를 부여한다.

* 통일된 인터페이스: HTTP 메서드라는 표준화된 동사 집합을 사용하여 자원을 조작한다.

* 무상태성: 각 요청은 필요한 모든 정보를 포함해야 하며, 서버는 세션 상태를 저장하지 않는다.

* 캐시 가능성: 응답은 명시적으로 캐시 가능 또는 불가능으로 표시되어야 하며, 이는 성능 향상에 기여한다.

* 계층화 시스템: 클라이언트는 서버와 직접 연결되었는지 중간 계층을 거쳤는지 알 필요 없이 통신할 수 있다.

SOAP 기반의 전통적인 웹 서비스와 비교할 때, RESTful API는 다음과 같은 특징을 보인다.

이러한 특성 덕분에 RESTful API는 모바일 애플리케이션, 단일 페이지 애플리케이션(SPA), 그리고 마이크로서비스 아키텍처와 같은 현대적 분산 시스템에서 널리 채택되었다. JSON 형식의 경량 데이터 교환과 HTTP의 보편성 덕분에 구현과 통합이 상대적으로 쉽다. 그러나 공식적인 서비스 계약 표준(예: WSDL)이 없어, OpenAPI와 같은 별도의 명세 도구를 사용하여 API 문서화와 계약 관리를 보완하는 경우가 많다.

서비스 지향 아키텍처에서 메시징은 서비스 간 통신을 위한 비동기적이고 신뢰할 수 있는 패턴을 제공하는 핵심 기술이다. 이는 웹 서비스나 RESTful API와 같은 동기식 요청-응답 방식과 대비되는 방식으로, 메시지 브로커라는 중간 매개체를 통해 메시지를 주고받는다. 발신자(생산자)는 메시지를 브로커에 전송하면 즉시 자신의 작업을 계속할 수 있으며, 수신자(소비자)는 준비가 되었을 때 브로커에서 메시지를 가져와 처리한다. 이 방식은 시스템 구성 요소 간의 느슨한 결합을 극대화하고, 서비스의 가용성과 확장성을 높이는 데 기여한다.

주요 메시징 표준과 구현체로는 JMS와 AMQP가 널리 사용된다. JMS는 자바 플랫폼을 위한 메시징 API 표준으로, 특정 프로토콜이 아닌 인터페이스를 정의한다. 따라서 ActiveMQ, IBM MQ 등과 같은 다양한 메시징 벤더가 JMS API를 구현하여 제공한다. 반면, AMQP는 플랫폼 중립적인 이진 프로토콜 표준으로, 서로 다른 언어와 시스템 간의 상호 운용성을 보장한다. RabbitMQ는 AMQP 프로토콜의 대표적인 구현체이다.

메시징은 특히 이벤트 주도 아키텍처, 배치 처리, 시스템 통합 시나리오에서 강점을 발휘한다. 서비스가 일시적으로 다운되더라도 메시지는 브로커에 안전하게 보관되어 복구 시 처리될 수 있어 신뢰성을 보장한다. 또한, 트래픽이 급증하는 경우에도 메시지 큐가 버퍼 역할을 하여 시스템이 과부하에 빠지는 것을 방지할 수 있다.

서비스 제공자는 서비스 지향 아키텍처 생태계에서 실제 비즈니스 기능을 구현하고 노출하는 주체이다. 이는 특정 작업이나 작업 집합을 수행하는 소프트웨어 구성 요소로, 정의된 서비스 계약을 통해 그 기능을 외부에 제공한다. 서비스 제공자는 서비스를 구현하고 호스팅하며, 서비스 레지스트리에 자신의 존재와 위치를 등록하여 서비스 소비자가 이를 발견하고 사용할 수 있도록 한다.

서비스 제공자의 주요 책임은 비즈니스 로직의 캡슐화, 신뢰할 수 있는 서비스 운영, 그리고 계약 준수이다. 제공자는 요청을 수신하고, 필요한 처리를 수행한 후, 적절한 응답을 반환한다. 서비스의 구현 세부 사항은 서비스 추상화 원칙에 따라 외부로부터 완전히 숨겨진다. 소비자는 서비스가 어떻게 구현되었는지 알 필요 없이, 공개된 계약(인터페이스)을 통해서만 상호작용한다.

서비스 제공자는 종종 다음과 같은 특성을 가진다.

서비스 제공자는 웹 서비스의 경우 SOAP 엔드포인트를, RESTful API의 경우 URI를 통해 자신의 기능을 노출한다. 서비스 버스 (ESB)가 존재하는 환경에서는 ESB를 통해 서비스를 간접적으로 제공하기도 한다. 이는 서비스 제공자와 소비자 간의 직접적인 연결을 제거하여 느슨한 결합을 더욱 강화하는 효과가 있다.

서비스 소비자는 서비스 지향 아키텍처에서 서비스 제공자가 노출한 기능을 호출하여 비즈니스 요구를 충족시키는 애플리케이션 또는 시스템 구성 요소이다. 소비자는 서비스의 최종 사용자 역할을 하며, 서비스 계약에 정의된 인터페이스를 통해 필요한 작업을 요청한다. 소비자는 서비스의 내부 구현 로직이나 위치에 대해 알 필요 없이, 공개된 계약만을 통해 상호작용한다.

서비스 소비자는 일반적으로 서비스 레지스트리를 조회하여 필요한 서비스의 엔드포인트 정보를 획득한다. 이후 서비스 계약에 명시된 통신 프로토콜(예: SOAP, HTTP/RESTful API)과 데이터 형식을 준수하여 요청을 전송한다. 이 과정에서 서비스 버스 (ESB)를 경유할 수도 있다. 소비자는 하나의 서비스에 의존할 수도 있고, 여러 서비스를 조합(오케스트레이션)하여 복잡한 업무 흐름을 구성할 수도 있다.

서비스 소비자의 주요 책임은 다음과 같다.

이러한 역할 분리는 시스템 전체의 느슨한 결합을 실현하는 데 기여한다. 서비스 소비자는 서비스 제공자의 변경(예: 기술 스택 변경, 물리적 위치 이동)으로부터 격리될 수 있으며, 표준화된 인터페이스를 통해 유연하게 통신한다.

서비스 레지스트리는 서비스 지향 아키텍처에서 서비스의 메타데이터를 저장하고 관리하는 중앙 저장소 역할을 한다. 이는 서비스의 위치(URL 또는 엔드포인트), 제공하는 기능, 사용 가능한 버전, 서비스 계약 정보 등을 포함한 디렉터리이다. 서비스 소비자는 필요한 기능을 수행하는 서비스를 찾을 때 이 레지스트리를 조회하여 서비스 제공자의 정확한 위치와 접근 방법을 얻는다.

서비스 레지스트리의 주요 기능은 서비스 등록, 서비스 발견, 서비스 상태 관리이다. 서비스 제공자는 자신의 서비스를 레지스트리에 등록하고, 서비스 소비자는 레지스트리를 쿼리하여 필요한 서비스를 발견한다. 레지스트리는 서비스의 가용성을 지속적으로 모니터링하기 위해 헬스 체크를 수행하거나, 서비스 제공자로부터 주기적인 하트비트 신호를 받기도 한다. 이를 통해 레지스트리는 오래되거나 사용 불가능한 서비스 항목을 자동으로 제거할 수 있다.

서비스 레지스트리의 구현 방식은 다양하다. 전통적인 웹 서비스 환경에서는 UDDI가 표준 레지스트리 프로토콜로 사용되었다. 현대의 마이크로서비스 아키텍처와 RESTful API 기반 시스템에서는 유레카, 콘설, 주키퍼, etcd와 같은 도구들이 널리 사용된다. 이러한 도구들은 서비스 발견을 자동화하고, 서비스 간의 동적 연결을 가능하게 하여 시스템의 탄력성과 확장성을 높인다.

서비스 레지스트리를 효과적으로 운영하기 위해서는 몇 가지 고려사항이 있다. 레지스트리 자체의 고가용성과 내결함성을 보장해야 하며, 서비스 정보의 일관성을 유지해야 한다. 또한, 서비스 등록 및 조회에 대한 보안 정책과 접근 제어 메커니즘이 필요하다. 레지스트리가 단일 장애점이 되는 것을 방지하기 위해 클러스터링이나 분산 아키텍처로 구성하는 것이 일반적이다.

서비스 버스는 서비스 지향 아키텍처의 핵심 인프라 구성 요소 중 하나로, 분산된 서비스 간의 통신을 중앙에서 관리하고 조정하는 미들웨어 플랫폼이다. 이는 서비스 제공자와 서비스 소비자 사이에 위치하여, 서비스 간의 직접적인 연결 대신 버스를 통한 간접적인 통신을 가능하게 한다. 주요 목적은 시스템의 느슨한 결합을 강화하고, 서비스의 상호 운용성을 보장하며, 통합 로직을 중앙 집중화하여 관리 복잡성을 낮추는 것이다.

서비스 버스는 일반적으로 메시지 라우팅, 프로토콜 변환, 데이터 형식 변환, 보안 적용, 모니터링, 트랜잭션 관리 등 다양한 기능을 제공한다. 예를 들어, SOAP 기반의 웹 서비스와 RESTful API를 사용하는 서비스가 서로 통신해야 할 때, ESB는 메시지 형식과 프로토콜을 자동으로 변환해준다. 또한, 서비스의 위치가 변경되거나 특정 서비스가 다운되었을 때 대체 경로로 메시지를 라우팅하는 기능도 담당한다.

ESB(Enterprise Service Bus)는 서비스 버스의 가장 대표적인 구현체로, 기업 수준의 통합을 위해 설계되었다. ESB는 서비스 레지스트리와 긴밀하게 연동되어 서비스의 위치를 동적으로 발견하고, 서비스 간의 의존성을 관리한다. 이를 통해 애플리케이션은 네트워크 상의 서비스 정확한 위치를 알 필요 없이, 논리적인 서비스 이름만으로 호출할 수 있다.

그러나 서비스 버스, 특히 전통적인 ESB는 단일 장애 지점이 될 수 있고, 구성이 복잡해질 수 있으며, 성능 병목 현상을 초래할 가능성이 있다는 비판도 존재한다. 이러한 이유로, 더 가볍고 분산된 접근 방식을 선호하는 마이크로서비스 아키텍처에서는 API 게이트웨이 패턴이 ESB의 일부 역할을 대체하는 경우가 많다.