응답 메시지를 요청 애플리케이션에 로컬인 큐 위치로 제한

JMS 큐가 서비스 큐를 응답 큐로 식별하고 해당 서비스 통합 버스 큐에 여러 큐 위치가 있는 경우, JMS 큐를 참조한 애플리케이션에 로컬인 큐 위치로 메시지를 제한하도록 JMS 큐를 구성할 수 있습니다. 이를 사용하여 클러스터 버스 멤버의 적절한 큐 위치로 응답 메시지를 전송할 수 있습니다.

여러 메시징 엔진이 있는 클러스터 버스 멤버에 서비스 통합 버스 큐가 있는 경우 여러 큐 위치를 보유합니다. 로컬 큐 위치는 애플리케이션이 연결된 메시징 엔진의 큐 위치입니다.

예제: "응답"이라는 JMS 큐가 응답 큐로 사용할 서비스 통합 버스 큐를 식별하도록 구성됩니다. JMS 큐는 메시지를 로컬 큐 위치로 제한하도록 구성되었습니다(자세한 내용은 관련 태스크 참조).

그림 1. 요청 JMS 애플리케이션이 클러스터 버스 멤버의 메시징 엔진 중 하나에 연결됨
요청
JMS 애플리케이션이 클러스터 버스 멤버의 메시징 엔진 중
하나에 연결됩니다.

버스 멤버는 또한 응답 큐로 사용되는 서비스 통합 버스 큐를 소유하므로 각 메시징 엔진에는 응답 큐의 큐 위치가 구성되어 있습니다.

요청 애플리케이션이 JMS 메시지를 작성하고 JMSReplyTo 대상을 JMS 큐 "응답"으로 설정합니다. 요청 애플리케이션은 "서비스"라는 다른 JMS 큐를 사용하여 서비스의 큐에 요청 메시지를 전송합니다. ("서비스"에는 특수 구성이 필요하지 않습니다.) 이 메시지는 일반적으로 로컬 큐 위치로 이동하지만 기본적으로 "서비스"에 속하는 모든 큐 위치로 전달할 수 있습니다. 그러나 이 예제를 완전하게 설명하기 위해 시스템은 다른 큐 위치로 메시지를 전송합니다.

요청 메시지를 전송한 애플리케이션은 기본 서비스 통합 버스 응답 큐의 큐 위치가 구성되어 있는 메시징 엔진에 연결되어 있고 옵션이 사용 가능한 경우, 응답 큐의 해당 단일 큐 위치 ID가 메시지의 JMSReplyTo 큐에 있는 정보에 추가됩니다.

그림 2. 요청 애플리케이션이 다른 JMS 큐를 사용하여 서비스의 큐에 요청 메시지를 전송함
요청
애플리케이션이 다른 JMS 큐를 사용하여 서비스의 큐에
요청 메시지를 전송합니다.

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

그림 3. 응답 애플리케이션에 응답 큐에 대한 로컬 큐 위치가 있는 경우에도 메시지가 요청 애플리케이션의 로컬 큐 위치에 전송됨
응답
애플리케이션에 응답 큐에 대한 로컬 큐 위치가 있는 경우에도
메시지가 요청 애플리케이션의 로컬 큐 위치에 전송됩니다.

시스템은 서비스 통합 버스 큐에 하나의 큐 위치만 있는 것처럼 작동합니다. 응답의 범위로 지정된 큐 위치를 사용할 수 없는 경우, 메시지는 다른 큐 위치로 전송되지 않습니다.

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

세분화

애플리케이션이 연결을 끊은 후 다시 연결할 수 있는 동안 버스 멤버의 모든 메시징 엔진 사이에서 여러 요청 애플리케이션의 워크로드 밸런싱을 확보하려면 다음 구성이 필요합니다.
  • 여러 연결 팩토리가 각각 다른 메시징 엔진을 대상으로 지정함
  • 요청 애플리케이션이 연결 팩토리 전체에 보급됨

주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjt0023_
파일 이름:cjt0023_.html