응답 메시지를 요청 애플리케이션에 로컬인 큐 위치로 제한
JMS 큐가 서비스 큐를 응답 큐로 식별하고 해당 서비스 통합 버스 큐에 여러 큐 위치가 있는 경우, JMS 큐를 참조한 애플리케이션에 로컬인 큐 위치로 메시지를 제한하도록 JMS 큐를 구성할 수 있습니다. 이를 사용하여 클러스터 버스 멤버의 적절한 큐 위치로 응답 메시지를 전송할 수 있습니다.
여러 메시징 엔진이 있는 클러스터 버스 멤버에 서비스 통합 버스 큐가 있는 경우 여러 큐 위치를 보유합니다. 로컬 큐 위치는 애플리케이션이 연결된 메시징 엔진의 큐 위치입니다.
예제: "응답"이라는 JMS 큐가 응답 큐로 사용할 서비스 통합 버스 큐를 식별하도록 구성됩니다. JMS 큐는 메시지를 로컬 큐 위치로 제한하도록 구성되었습니다(자세한 내용은 관련 태스크 참조).

버스 멤버는 또한 응답 큐로 사용되는 서비스 통합 버스 큐를 소유하므로 각 메시징 엔진에는 응답 큐의 큐 위치가 구성되어 있습니다.
요청 애플리케이션이 JMS 메시지를 작성하고 JMSReplyTo 대상을 JMS 큐 "응답"으로 설정합니다. 요청 애플리케이션은 "서비스"라는 다른 JMS 큐를 사용하여 서비스의 큐에 요청 메시지를 전송합니다. ("서비스"에는 특수 구성이 필요하지 않습니다.) 이 메시지는 일반적으로 로컬 큐 위치로 이동하지만 기본적으로 "서비스"에 속하는 모든 큐 위치로 전달할 수 있습니다. 그러나 이 예제를 완전하게 설명하기 위해 시스템은 다른 큐 위치로 메시지를 전송합니다.
요청 메시지를 전송한 애플리케이션은 기본 서비스 통합 버스 응답 큐의 큐 위치가 구성되어 있는 메시징 엔진에 연결되어 있고 옵션이 사용 가능한 경우, 응답 큐의 해당 단일 큐 위치 ID가 메시지의 JMSReplyTo 큐에 있는 정보에 추가됩니다.

요청 메시지가 서비스의 큐 "서비스"에 전달되고 서비스에 의해 처리됩니다. 완료 시 서비스가 요청 메시지(JMS Message.getJMSReplyTo 메소드를 사용하여 확보됨)에서 식별된 응답 큐에 JMS 메시지를 전송합니다. 이때 메시징 시스템은 기본적으로 "응답"의 큐 중 하나에 응답 메시지를 전송하지만 요청자가 응답 큐의 범위를 해당 로컬 큐 위치로 지정했으므로, 응답은 요청자가 연결된 메시징 엔진의 단일 큐 위치로 전송됩니다.

시스템은 서비스 통합 버스 큐에 하나의 큐 위치만 있는 것처럼 작동합니다. 응답의 범위로 지정된 큐 위치를 사용할 수 없는 경우, 메시지는 다른 큐 위치로 전송되지 않습니다.
- 응답 메시지가 항상 요청 애플리케이션에 로컬인 큐 위치로 다시 전송됩니다. 이는 메시지 라우트를 줄입니다.
- 버스 멤버의 여러 메시징 엔진에 연결된 요청 애플리케이션이 동일한 JMS 큐 정의를 사용할 수 있습니다. 이는 클러스터 전체에서 동적 워크로드 밸런싱을 허용합니다.
- 요청 애플리케이션이 응답 메시지를 수신하기 전에 연결을 끊은 다음 다시 연결하려는 경우, 해당 애플리케이션은 연결 중인 메시징 엔진을 알고 다시 연결할 때 동일한 메시징 엔진에 연결해야 합니다. 이는 JMS 연결 팩토리에서 메시징 엔진을 대상으로 지정하고 JMS 연결 팩토리를 다시 연결하는 데 사용하여 달성됩니다. 이 구성은 워크로드 밸런싱을 제외시킵니다.
- 요청 애플리케이션을 서비스 통합 버스 응답 큐를 소유하는 버스의 메시징 엔진에 연결해야 합니다. 그렇지 않은 경우, 응답 메시지의 범위를 지정할 로컬 큐 위치가 없고 시스템은 기본 메시지 라우팅 동작을 따릅니다.
세분화
- 여러 연결 팩토리가 각각 다른 메시징 엔진을 대상으로 지정함
- 요청 애플리케이션이 연결 팩토리 전체에 보급됨