클러스터 버스 멤버에서의 JMS 요청 및 응답 메시징
일반적인 JMS 메시징 패턴에는 메시징 서비스(예: 메시지 구동 Bean)로 처리하기 위해 메시지를 JMS 큐로 전송하는 요청 애플리케이션이 포함됩니다.
요청 애플리케이션이 요청 메시지를 전송할 때 메시지는 서비스가 응답 메시지를 전송해야 하는 다른 JMS 큐를 식별합니다. 요청 메시지를 전송한 후 요청 애플리케이션은 응답 메시지가 도달하기를 대기하거나 나중에 다시 연결하여 응답 메시지를 검색합니다.
그림 1. 일반 JMS 메시징 패턴

요청 및 응답 패턴에는 다음 조건이 필요합니다.
- 요청 애플리케이션은 요청 메시지에서 서비스가 응답 메시지를 전송해야 하는 위치를 식별할 수 있습니다.
- 요청 애플리케이션은 응답 위치에서 응답 메시지를 이용할 수 있습니다.
JMS 큐는 서버 버스 멤버 또는 클러스터 버스 멤버에 정의된 서비스 통합 버스 대상을 참조할 수 있습니다.
- 버스 멤버는 서버(하나의 메시징 엔진만 있을 수 있음) 또는 단일 메시징 엔진이 있는 클러스터인 경우 JMS 큐는 단일 서비스 통합 버스 큐 위치를 식별합니다.
- 버스 멤버가 여러 메시징 엔진이 있는 클러스터인 경우(워크로드 공유 또는 확장성 제공) JMS 큐는 여러 큐 위치(버스 멤버의 각 메시징 엔진에 있는 큐 위치)를 식별합니다.
그림 2. 애플리케이션 서버 버스 멤버에 정의된 서비스 통합 버스 큐 대상

기본적으로, 다음 동작이 발생합니다.
- 애플리케이션이 메시지를 전송하거나 메시지를 수신하는 큐 위치는 메시징 시스템에 의해 판별됩니다.
- 지속 시간 중에 이용자(이 경우에는 JMS 메시지 이용자)는 하나의 큐 위치에서만 이용합니다.
이 요청 및 응답 동작을 통해 요청자가 대기 중인 큐 위치에서 다른 큐 위치로 응답 메시지를 전송할 수 있습니다. 그 결과 응답 메시지가 수신되지 않을 수 있습니다.
그림 3. 두 개의 메시징 엔진이 있는 클러스터 버스 멤버에 정의된 서비스 통합 버스 큐 대상

이 상황을 해결하기 위해 서비스 통합 버스 시스템 또는 JMS 애플리케이션을 구성할 때 여러 옵션이 제공됩니다.
접근 방법을 선택하기 전에 각 옵션의 장점과 단점 및 애플리케이션의 요구사항을 고려하십시오.
요약
요청/응답 시나리오의 요구사항을 충족하는 가장 간단한 해결책을
사용하십시오. 예를 들면, 다음과 같습니다.
- 요청 애플리케이션이 처음 연결된 동안에만 응답 메시지가 필요한 경우, 비지속적 메시지 및 임시 큐를 사용하십시오. 또한 요청 애플리케이션이 한정된 시간 동안에만 응답을 대기할 경우 초기 요청 메시지의 timeToLive 설정을 고려하십시오.
- 큐 위치(및 해당 메시징 엔진)가 요청 애플리케이션의 모든 응답 메시지 통신량을 처리할 수 있지만 다른 메시징 통신량(예: 요청 메시지)에 복수 메시징 엔진이 있는 클러스터 버스 멤버가 필요한 경우, 서비스 통합 버스 별명 대상을 사용하여 메시지의 범위를 해당 단일 큐 위치로 지정하십시오.
필요한 경우, 이러한 옵션을 결합하여 애플리케이션의 요구사항을 충족시키고 최상의 성능과 확장성을 갖는 해결책을 확보할 수 있습니다.
예를 들어, 요청 애플리케이션이 일반적으로 초기 연결 중에 흔하지 않은 특정 조건(예:
실패) 아래에서 응답 메시지를 수신하는 경우, 응답을 수신하기 위해 다시 연결해야 하며
다음 접근 방식이 적당할 수 있습니다.
- JMS 큐의 scopeToLocalQP 옵션을 사용 가능하게 하고 요청 애플리케이션이 클러스터 버스 멤버의 모든 메시징 엔진에 연결할 수 있도록 허용하십시오(즉, 버스 멤버의 JMS 연결 팩토리를 대상으로 지정). 이를 통해 연결의 워크로드 균형을 맞출 수 있지만 응답 메시지는 로컬 큐 위치로 제한됩니다. 그 결과 요청을 전송하는 데 사용된 것과 동일한 연결을 사용하여 응답을 수신하는 중에 응답 메시지를 찾을 수 있습니다.
- 실패 후 다시 연결할 때 JMS 큐의 메시지 수집 옵션을 사용 가능하게 하여 응답 메시지를 보유한 모든 위치에서 응답 메시지를 수신할 수 있도록 하십시오.
이 접근 방식을 사용하면 실패 시나리오에 메시지 수집을 적게 사용하여 메시지 수집이 성능에 미치는 영향을 최소화하고 요청 애플리케이션의 워크로드 밸런싱을 동적으로 수행할 수 있습니다.