일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 컴포넌트 주도
- 리덕스 공식문서
- 자료구조
- AWS
- 리덕스
- exiting abnormally
- $emit()
- 공식문서
- 도커빌드
- rabbitmq 에러
- 애그리거트
- Java Reflextion API
- ACCESS_REFUSED
- forNmae()
- paraller
- EBS
- react
- 커스텀 로그인
- VUE
- 리액트
- vue.js
- .getClass()
- 오라클
- redux
- 오라클 병렬처리
- Express
- REDIS
- 자바
- 네임드 뷰
- quert
- Today
- Total
개발정리
스프링 STOMP - 메세지 흐름 본문
일단 한번 STOMP 엔드포인트가 드러나면 , 스프링 애플리케이션이 STOMP 브로커가 됩니다.
이장은 서버단의 메세지 흐름에 대해 설명합니다.
spring-messaging 모듈은 메세지 애플리케이션을 위한 기본적인 기능을 제공합니다.
여기에서 메세지 애플리케이션은 스프링 통합 에서 비롯되었으며
나중에 스프링 프레임워크로 추출되어 통합되었습니다.
다음은 사용가능한 메세징 추상을 설명합니다.
- Message:메세지의 간단한 표현,헤더와 페이로드를 포함
- MessageHandler:메세지를 다루기 위한 핸들러
- MessageChannel:프로듀서와 컨슈머 사이의 느슨한 결합을 가능케 하는 메세지를 전달하는 채널
- SubscribableChannel:MessageHandler 구독자가 있는 MessageChannel
- ExecutorSubscribableChannel:메세지를 전달하기 위해 Executor를 사용하는 subscribablechannel
@EnableWebSocketMessageBroker 와 <websocket:message-broker>는 메세지 workflow를 조합하기 위해 앞서 설명한 컴포넌트들을 사용합니다.
다음은 simple built-in message broker를 사용했을 때의 컴포넌트들을 보여줍니다.
앞선 다이어그램은 세가지 메세지 채널을 보여줍니다.
- clientInboundChannel:웹소켓 클라이언트로 부터 받은 메세지를 보내기위한 채널
- clientOutboundChannel:서버 메세지를 웹소켓 클라이언트로 보내기위한 채널
- brokerChannel:서버사이드 애플리케이션 코드의 메세지 브로커로 메세지를 보내기위한 채널
다음의 다이어그램은 외부의 메세지 브로커를 사용했을때 입니다.
메세지 브로커는 메세지의 구독과 브로드캐스팅을 관리하기위해 설정 되었습니다.
앞선 두 다이어그램의 차이점은 "broker relay"의 사용입니다.
"broker relay"는 TCP위에서 외부의 STOMP브로커로 메세지를 전달하고 구독한 클라이언트로 전달하기 위해 사용합니다.
웹소켓 연결로 부터 메세지들을 받았을때,메세지들은 STOMP 프레임들로 해독되어 스프링 Message 표현으로 바뀝니다.
그리고 추가적인 처리를 위해 clientInboundChannel 로 보내집니다.
예를들어, 헤더가 /app으로 시작되는 STOMP메세지들은 @MessageMapping 메소드가 붙은 컨트롤러로 라우팅 될 것 입니다.
반면에 /topic 과 /queue가 붙은 메세지들은 직접 메세지 브로커로 라우팅 될 것 입니다.
클라이언트로 부터 온 STOMP 메세지를 다루는 @Controller 는 brokerChannel을 통해 메세지 브로커로 메세지를 보낼 것 입니다.그리고 브로커는 clientOutboundChannel을 통해 매칭되는 구독자 들에게 브로드 캐스팅 할 것 입니다.
동일한 컨트롤러는 Http 요청의 응답으로 동일한 일을 할 수 있습니다.
그러므로 클라이언트는 HTTP POST를 수행할 수 있습니다.
그리고 @PostMapping 메소드가 구독자들에게 브로드 캐스팅하기 위하여 메세지브로커로 메세지를 보낼 수 있습니다,
다음은 간단한 예제입니다.
@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {
@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
registry.addEndpoint("/portfolio");
}
@Override
public void configureMessageBroker(MessageBrokerRegistry registry) {
registry.setApplicationDestinationPrefixes("/app");
registry.enableSimpleBroker("/topic");
}
}
@Controller
public class GreetingController {
@MessageMapping("/greeting")
public String handle(String greeting) {
return "[" + getTimestamp() + ": " + greeting;
}
}
앞선 예제는 다음과 같은 흐름을 지원합니다.
- 클라이언트가 localhost:8080/portfolio 로 연결됩니다.그리고 웹소켓 커넥션이 설정되면 STOMP프레임들의 흐름이 시작됩니다.
- 클라이언트가 /topic/greeting destination 헤더를 가진 subscribe 프레임을 보냅니다.한번 받은 후에 해독이 되면,메세지는 clientInboundChannel 로 보내지고 클라이언트 구독자 들을 저장한 메세지 브로커로 라우팅 됩니다.
- 클라이언트가 /app/greeting으로 프레임을 보냅니다./app 접두어는 컨트롤러로 라우팅 되는것을 돕습니다./app접두어가 제거되면 남아있는 /greeting 부분이 greeting컨트롤러의 @MessageMapping으로 매핑됩니다.
- greetingcontroller의 리턴값은 스프링 메세지로 변환됩니다.리턴값은 payload에 저장되며 destination은 /topic/greeting으로 설정됩니다.(/app이 /topic으로 대체됨)메세지는 brokerchannel로 보내지고 메세지 브로커에 의해 다뤄어집니다.
- 메세지 브로커는 clientOutboundChannel을 통해 각각의 구독자들에게 전달합니다.
참조
https://docs.spring.io/spring-framework/reference/web/websocket/stomp/message-flow.html
'스프링 > 스프링 프레임워크' 카테고리의 다른 글
스프링 트랜잭션 모델의 장점 (0) | 2024.02.15 |
---|---|
스프링-트랜잭션 management (0) | 2024.02.15 |
스프링 STOPM -개요 (1) | 2024.02.12 |
스프링 웹소켓 문서읽기 (0) | 2024.02.09 |
AOP(Aspect Oriented Programming) (0) | 2023.12.01 |