지금까지는 메시지 지향 미들웨어의 요소에 대해 설명하고 JMS를 사용하여 MOM 응용 프로그램에 이식성을 추가하는 방식에 대해 설명했습니다. 이제 Message Queue에서 JMS 사양을 구현하는 방법과 안정적이고 안전하며 확장 가능한 메시징 서비스를 제공하기 위해 사용하는 기능과 도구에 대해 설명하겠습니다.
우선 많은 JMS 공급자와 마찬가지로 Message Queue를 독립 실행형 제품으로 사용하거나, 비동기식 메시징을 제공하기 위해 J2EE 응용 프로그램 서버에 내장된 활성화 기술로 사용할 수 있습니다. Message Queue가 J2EE에서 수행하는 역할에 대한 자세한 내용은 5 장, Message Queue와 J2EE를 참조하십시오. 다른 JMS 공급자와 다르게, Message Queue는 JMS 참조 구현으로 지정되었습니다. 이러한 지정은 Message Queue가 올바르고 완벽한 JMS 구현임을 입증합니다. 또한 Message Queue 제품이 향후의 JMS 개정 및 확장을 통해 최신 상태로 유지됨을 보장합니다.
JMS 공급자로서 Message Queue는 JMS 인터페이스를 구현하고 관리 서비스와 제어를 수행하는 메시징 서비스를 제공합니다. 지금까지 메시지 전달에서 브로커의 역할을 중심으로 JMS 공급자에 대해 설명했습니다. 그러나 JMS 공급자는 브로커 이외에 안정적이고 안전하며 확장 가능한 메시징을 제공하기 위한 많은 요소를 포함해야 합니다. 그림 1–6에서는 Message Queue 메시지 서비스를 구성하는 요소를 보여 줍니다. 그 중에는 다양한 연결 서비스(각기 다른 프로토콜 지원), 관리 도구를 비롯하여 메시징, 모니터링 및 사용자 정보용 데이터 저장소도 있습니다. Message Queue 서비스는 그림에 회색으로 표시된 모든 요소를 포함하고 있습니다.
위와 같이, 전 기능 JMS 공급자는 기본 JMS 모델보다 더 복잡합니다. 다음 절에서는 위에서 보여준 Message Queue 서비스 요소에 대해 설명합니다. 이러한 요소는 브로커, 클라이언트 런타임 지원 및 관리라는 세 가지 범주로 분류될 수 있습니다.
그림 1–6에 표시된 것처럼 응용 프로그램 클라이언트와 관리 클라이언트 모두 브로커에 연결할 수 있습니다. JMS 사양에서는 공급자가 특정 와이어 프로토콜을 구현하도록 규정하지 않습니다. 응용 프로그램 클라이언트와 관리 클라이언트가 브로커에 연결하는 데 사용하는 Message Queue 서비스는 현재 TCP, TLS, HTTP 또는 HTTPS 프로토콜의 상위 계층에 있습니다. HTTP의 상위 계층에 있는 서비스를 사용하면 방화벽을 통해 메시지를 전달할 수 있습니다.
JMS 지원을 제공하며 클라이언트와 브로커와의 연결을 가능하게 해 주는 서비스(jms, ssljms, http 또는 https)는 NORMAL 서비스 유형이며 TCP, TLS, HTTP 또는 HTTPS 프로토콜의 상위 계층에 있습니다.
관리자를 브로커에 연결하는 데 사용하는 서비스(admin, ssladmin)는 ADMIN 서비스 유형이며 TCP 또는 TLS 프로토콜의 상위 계층에 있습니다.
기본적으로 브로커를 시작하면 jms와 admin 서비스가 실행됩니다. 또한 이러한 연결 서비스 중 어느 것이라도 또는 전부 실행하도록 브로커를 구성할 수 있습니다. 각 서비스는 특정 인증 및 권한 부여(액세스 제어) 기능을 지원하며 다중 스레드 방식으로서 다중 연결을 지원합니다.
연결이 실패할 경우 Message Queue 서비스는 동일한 브로커 또는 다른 브로커(이 기능이 사용 가능하도록 설정된 경우)에 대한 클라이언트 연결을 자동으로 다시 시도할 수 있습니다. 자세한 내용은 부록 B, Message Queue 기능의 자동 재연결 기능에 대한 설명을 참조하십시오.
클라이언트는 연결을 가져오는 연결 팩토리를 만들 때 연결 런타임 지원을 구성할 수 있습니다. 옵션을 사용하여 연결할 브로커, 재연결 처리 방법, 메시지 흐름 제어 등을 지정할 수 있습니다. 연결을 구성하는 방법에 대한 자세한 내용은 연결 팩토리 및 연결을 참조하십시오.
메시지 서비스의 핵심은 안정적으로 메시지를 라우팅, 전달하고 사용자를 인증하며 성능 모니터링을 위한 데이터를 수집하는 브로커입니다.
메시지를 라우팅하고 전달하기 위해 브로커는 들어오는 메시지를 각각의 대상에 배치하고 이 대상을 드나드는 메시지 흐름을 관리합니다.
안정적인 전달을 위해 브로커는 영구 저장소를 사용하여 상태 정보와 영구 메시지를 수신 시점까지 저장합니다. 브로커 또는 연결이 실패할 경우 브로커는 저장된 정보를 사용하여 브로커의 상태를 복원한 다음 작업을 다시 시도할 수 있습니다.
교환되는 데이터의 보안을 위해 브로커는 인증된 연결을 사용합니다. SSL과 같은 보안 프로토콜을 통해 데이터를 암호화할 수도 있습니다. 또한 브로커는 사용자 그리고 사용자가 액세스할 수 있는 데이터 또는 작업에 대한 정보를 보관하는 저장소를 사용하고 관리합니다. 브로커는 서비스를 요청하는 사용자를 인증하고 이 저장소에서 정보를 조회하여 사용자가 수행할 작업에 대한 권한을 부여합니다.
브로커는 시스템을 모니터링하기 위해 관리자가 액세스하여 성능을 측정하고 브로커를 조정할 수 있는 메트릭 및 진단 정보를 생성합니다. 메트릭 정보를 프로그래밍 방식으로 사용하여 응용 프로그램이 메시지 흐름과 패턴을 조정하여 성능을 향상시키게 할 수도 있습니다.
Message Queue 서비스는 관리자가 브로커 지원을 구성하는 데 사용할 수 있는 다양한 관리 도구를 제공합니다. 자세한 내용은 관리를 참조하십시오.
클라이언트 런타임 지원은 Message Queue 클라이언트를 구축할 때 연결되는 라이브러리에 제공됩니다. 클라이언트 런타임은 클라이언트의 일부가 되는 Message Queue 서비스 비트로 간주할 수 있습니다. 예를 들어 클라이언트 코드에서 메시지를 보내는 API 호출을 만들 경우, 이 라이브러리에서 호출되는 코드는 브로커의 물리적 대상으로 메시지를 전달할 때 사용될 프로토콜에 적합한 메시지 비트를 패키지화합니다.
JMS 공급자는 Java 클라이언트만 지원해야 합니다. 그러나 그림 1–6에 표시된 것처럼 Message Queue 클라이언트는 Java 또는 공급자별 C API를 사용하여 메시지를 보내거나 받을 수 있습니다. 이러한 인터페이스는 Java 또는 C 런타임 라이브러리에 구현되는데, 브로커와의 연결을 만들고 요청된 연결 서비스에 적절하게 비트를 패키지화하는 실제 작업을 담당합니다.
Java 클라이언트 런타임은 Java 클라이언트에 브로커와의 상호 작용에 필요한 객체를 제공합니다. 이러한 객체에는 연결, 세션, 메시지, 메시지 제작자 및 메시지 소비자가 포함됩니다.
C 클라이언트 런타임은 C 클라이언트에 브로커와의 상호 작용에 필요한 기능과 구조를 제공합니다. C 클라이언트 런타임은 JMS 프로그래밍 모델의 절차상 버전을 지원합니다. C 클라이언트는 JNDI를 사용하여 관리 대상 객체에 액세스할 수 없지만, 연결 팩토리와 대상을 프로그래밍 방식으로 만들 수 있습니다.
Message Queue 서비스는 레거시 C 및 C++ 응용 프로그램이 JMS 기반 메시징에 참여할 수 있도록 C API를 제공합니다. 이러한 두 API에서 제공하는 기능에는 많은 차이가 있으며, 그에 대한 자세한 내용은 Java 및 C 클라이언트를 참조하십시오.
JMS 사양이 Java 클라이언트 전용 표준이라는 점을 명심하십시오. C 지원은 Message Queue 공급자에만 해당되며 다른 공급자에게 연결할 클라이언트 응용 프로그램에서는 사용할 수 없습니다.
Message Queue Java 클라이언트는 JMS 메시지로 래핑된 SOAP 메시지를 보내고 받을 수도 있습니다. SOAP(Simple Object Access Protocol)를 사용하면 분산 환경의 두 피어 간에 구조화된 데이터를 교환할 수 있습니다. 교환되는 데이터는 XML 스키마를 통해 지정됩니다.
Sun SOAP 처리는 현재 지점 간 모델 사용으로 제한되었으며, 안정성이 보장되지 않습니다. SOAP 메시지를 JMS 메시지로 래핑한 다음 브로커를 사용하여 라우팅하면 안정적인 전달을 보장하고 주제 및 지점 간 도메인 사용이 모두 가능한 전 기능 Message Queue 메시징을 이용할 수 있습니다. Message Queue는 메시지 제작자가 SOAP 메시지를 JMS 메시지로 래핑하고 메시지 소비자가 JMS 메시지에서 SOAP 메시지를 추출하는 데 사용할 수 있는 유틸리티 루틴을 제공합니다.
SOAP 메시지 처리에 대한 자세한 내용은 SOAP 메시지 작업을 참조하십시오.
Message Queue 서비스는 다음 작업을 수행하는 데 사용할 수 있는 명령줄 도구를 제공합니다.
브로커 시작 및 구성
대상 만들기 및 관리, 브로커 연결 관리, 브로커 자원 관리
JNDI 객체 저장소에서 관리 대상 객체 추가, 나열, 업데이트 및 삭제
파일 기반 사용자 저장소 채우기 및 관리
영구 저장소 용도로 JDBC 호환 데이터베이스 만들기 및 관리
GUI 기반 관리 콘솔을 사용하여 다음 명령줄 기능을 수행할 수도 있습니다.
브로커에 연결하여 관리
물리적 대상 만들기 및 관리
객체 저장소에 연결, 저장소에 객체 추가 및 객체 관리
클라이언트 수 또는 연결 수가 증가하면 병목 현상 해소 또는 성능 향상을 위해 메시지 서비스 확장이 필요할 수 있습니다. Message Queue 메시지 서비스는 사용자의 필요에 따라 많은 확장 옵션을 제공합니다. 이러한 옵션은 편의상 다음과 같은 범주로 정렬될 수 있습니다.
수직 확장은 처리 능력을 늘리고 사용 가능한 자원을 확장하는 것입니다. 프로세서 또는 메모리를 추가하거나, 공유 스레드 모델로 전환하거나, Java VM을 64비트 모드로 실행하여 수직 확장을 할 수 있습니다.
지점 간 도메인을 사용하는 경우에는 여러 소비자가 하나의 대기열에 액세스하도록 허용하여 소비자 측면을 확장할 수 있습니다. 이 방법을 사용할 경우 최대 활성 및 백업 소비자 수를 지정할 수 있습니다. 또한 로드 균형 조정 메커니즘에서는 소비자의 현재 용량과 메시지 처리 속도를 고려합니다. 이는 Message Queue의 기능입니다. (JMS 사양은 단일 소비자가 대기열에 액세스할 때의 메시징 동작을 정의합니다. 여러 소비자의 액세스가 허용되는 대기열에 대한 동작은 공급자별로 다릅니다. 이 확장 옵션에 대한 자세한 내용은 Message Queue 개발 안내서를 참조하십시오.)
상태 없는 수평 확장은 브로커를 추가한 다음 해당 브로커에 기존 클라이언트를 재배포하여 이루어집니다. 이 방법은 쉽게 구현할 수 있지만, 메시징 작업이 독립 작업 그룹으로 분류될 수 있는 경우에만 적합합니다.
상태 있는 수평 확장은 브로커를 클러스터에 연결하여 이루어집니다. 브로커 클러스터에서 각 브로커는 로컬 응용 프로그램 클라이언트뿐만 아니라 클러스터에 있는 모든 다른 브로커에도 연결됩니다. 브로커는 동일한 호스트에 있거나 네트워크에 분산될 수 있습니다. 대상 및 소비자에 대한 정보가 클러스터에 있는 모든 브로커에 복제됩니다. 대상 또는 가입자에 대한 업데이트가 함께 전파되므로, 각 브로커는 직접 연결된 제작자로부터 클러스터의 다른 브로커에 연결된 소비자로 메시지를 라우팅할 수 있습니다. 백업 소비자가 사용되는 환경에서 하나의 브로커나 연결이 실패할 경우, 액세스할 수 없는 소비자에게 보낸 메시지를 다른 브로커의 백업 소비자에게 전달할 수 있습니다.
브로커 또는 연결이 실패할 경우 영구 항목(대상 및 영구 가입)에 대한 상태 정보가 동기화되지 않을 수 있습니다. 예를 들어 클러스터된 브로커가 중단되어 대상이 클러스터에 있는 다른 브로커에 생성되고 첫 번째 브로커가 다시 시작될 경우, 해당 브로커는 새 대상에 대해 알 수 없습니다. 이 문제를 사전에 방지하기 위해 클러스터의 한 브로커를 마스터 브로커로 지정할 수 있습니다. 이 브로커는 마스터 구성 파일에서 대상 및 영구 가입에 대한 모든 변경을 추적하고, 클러스터에서 일시적으로 오프라인 상태인 브로커를 업데이트합니다. 자세한 내용은 4 장, 브로커 클러스터를 참조하십시오.
마스터 브로커를 사용하더라도 Message Queue는 브로커 또는 연결이 실패할 경우 서비스 가용성만 제공하며 데이터 가용성은 제공하지 않습니다. 예를 들어 클러스터된 브로커를 사용할 수 없는 경우, 해당 브로커에 보관된 모든 영구 메시지는 브로커가 복구될 때까지 사용할 수 없습니다. 현재는 SunCluster Message Queue 에이전트를 통해서만 데이터 가용성이 제공됩니다. 이 경우 영구 저장소는 공유 파일 시스템에 유지됩니다. 브로커가 실패할 경우 두 번째 노드의 Message Queue 에이전트가 공유 저장소를 인계할 브로커를 시작합니다. 클라이언트가 해당 브로커에 다시 연결되므로 영구 데이터에 대한 액세스와 서비스가 지속됩니다.