Overview

STOMP (Simple Text Oriented Messaging Protocol)은 원래 엔터프라이즈 메시지 브로커에 연결하기 위해 Ruby, Python, Perl과 같은 스크립팅 언어를 위해 만들어졌습니다. 이는 일반적으로 사용되는 메시징 패턴의 최소 부분 집합을 다루도록 설계되었습니다. STOMP는 TCP와 WebSocket과 같은 신뢰할 수 있는 양방향 스트리밍 네트워크 프로토콜 위에서 사용할 수 있습니다. STOMP는 텍스트 지향 프로토콜이지만, 메시지 페이로드는 텍스트 또는 바이너리일 수 있습니다.

STOMP는 프레임 기반 프로토콜이며, 이 프레임은 HTTP를 모델로 합니다. 다음 목록은 STOMP 프레임의 구조를 보여줍니다:

1COMMAND
2header1:value1
3header2:value2
4
5Body^@

클라이언트는 SEND 또는 SUBSCRIBE 커맨드를 사용하여 메시지를 보내거나 구독할 수 있으며, 이때 메시지가 무엇에 관한 것인지와 누가 이를 수신해야 하는지를 설명하는 destination 헤더를 함께 사용할 수 있습니다. 이것은 브로커를 통해 다른 연결된 클라이언트로 메시지를 보내거나 서버로 메시지를 보내 작업 수행을 요청하는 데 사용할 수 있는 간단한 퍼블리시-서브스크라이브 메커니즘을 가능하게 합니다.

Spring의 STOMP 지원을 사용하면, Spring WebSocket 애플리케이션은 클라이언트에 대한 STOMP 브로커 역할을 합니다. 메시지는 @Controller 메시지 처리 메서드나 subscription을 추적하고 구독된 사용자에게 메시지를 브로드캐스트하는 간단한 인메모리 브로커로 라우팅됩니다. 또한 실제 메시지 브로드캐스팅을 위해 RabbitMQ, ActiveMQ와 같은 전용 STOMP 브로커와 함께 작동하도록 Spring을 구성할 수도 있습니다. 이 경우 Spring은 브로커에 대한 TCP 연결을 유지하고, 메시지를 브로커로 릴레이하며, 브로커로부터의 메시지를 연결된 WebSocket 클라이언트로 전달합니다.

따라서 Spring 웹 애플리케이션은 메시지 처리를 위해 통합된 HTTP 기반 시큐리티, 공통 검증, 익숙한 프로그래밍 모델에 의존할 수 있습니다.

다음 예시는 클라이언트가 주식 시세를 수신하도록 구독하는 것을 보여주며, 서버는 주기적으로(예를 들어, 브로커로 메시지를 보내는 스케줄링된 태스크를 통해) 이를 발행할 수 있습니다:

1SUBSCRIBE
2id:sub-1
3destination:/topic/price.stock.*
4
5^@

다음 예시는 클라이언트가 트레이드 요청을 보내는 것을 보여주며, 서버는 @MessageMapping 메서드를 통해 이를 처리할 수 있습니다:

1SEND
2destination:/queue/trade
3content-type:application/json
4content-length:44
5
6{"action":"BUY","ticker":"MMM","shares",44}^@

실행 후, 서버는 트레이드 확인 메시지와 세부 정보를 클라이언트로 브로드캐스트할 수 있습니다.

destination의 의미는 의도적으로 STOMP 명세에서 불투명하게 남겨져 있습니다. 이는 어떤 문자열이든 될 수 있으며, 지원하는 destination의 의미론과 구문을 정의하는 것은 전적으로 STOMP 서버에 달려 있습니다. 그러나 일반적으로 destination은 /topic/..이 퍼블리시-서브스크라이브 (one-to-many)를 의미하고 /queue/가 포인트-투-포인트 (one-to-one) 메시지 교환을 의미하는 경로와 유사한 문자열입니다.

STOMP 서버는 MESSAGE 커맨드를 사용하여 모든 subscriber에게 메시지를 브로드캐스트할 수 있습니다. 다음 예시는 서버가 구독된 클라이언트에게 주식 시세를 보내는 것을 보여줍니다:

1MESSAGE
2message-id:nxahklf6-1
3subscription:sub-1
4destination:/topic/price.stock.MMM
5
6{"ticker":"MMM","price":129.45}^@

서버는 원치 않은 비요청 메시지를 보낼 수 없습니다. 서버로부터의 모든 메시지는 특정 클라이언트 subscription에 대한 응답이어야 하며, 서버 메시지의 subscription 헤더는 클라이언트 subscription의 id 헤더와 일치해야 합니다.

앞선 개요는 STOMP 프로토콜에 대한 가장 기본적인 이해를 제공하기 위한 것입니다. 전체 프로토콜 명세을 검토하는 것을 권장합니다.