Sun Java 로고     이전      목차      색인      다음     

Sun 로고
Sun Java System Message Queue 3.5 SP1 관리 설명서 

1장
개요

이 장에서는 Sun Java™ System Message Queue를 소개하며 관리자와 프로그래머가 관심을 가질 내용으로 구성됩니다.

Sun Java System Message Queue 소개

Message Queue 제품은 분산 응용 프로그램의 안정적인 비동기 메시징을 위한 표준 기반 솔루션입니다. Message Queue는 JMS (Java™ Message Service) 개방형 표준을 구현하는 엔터프라이즈 메시징 시스템이며 JMS 참조 구현 역할을 합니다. 하지만 Message Queue는 엔터프라이즈급 기능을 제공하는 완벽한 기능의 JMS 공급자이기도 합니다.

JMS 사양은 분산 환경에서 Java 언어 응용 프로그램으로 메시지를 작성하고, 전송하고, 수신하며 읽을 수 있는 공통된 방식을 제공하는 메시징 의미와 동작 및 응용 프로그램 프로그래밍 인터페이스(API)의 집합을 설명합니다("JMS 프로그래밍 모델" 참조). Java 메시징 응용 프로그램 지원 외에 Message Queue는 Message Queue 서비스에 C 언어 인터페이스(Message Queue C-API)도 제공합니다.

Sun Java System Message Queue 소프트웨어를 사용하면 서로 다른 플랫폼과 운영 체제에서 실행되는 프로세스들이 공통의 Message Queue 메시지 서비스("메시지 서비스 구조" 참조)에 연결하여 정보를 보내고 받을 수 있습니다. 응용 프로그램 개발자들은 네트워크를 통한 응용 프로그램의 안정적인 통신 방식과 관련된 하위 수준의 세부 사항보다는 응용 프로그램의 비즈니스 논리에 좀 더 집중할 수 있습니다.

Message Queue에는 JMS 사양의 최소 요구 사항을 능가하는 기능이 있습니다. 다음은 그러한 기능의 예입니다.

중앙 집중식 관리     Message Queue 서비스 관리와 대상, 트랜잭션, 영구 가입, 보안 등과 응용 프로그램 종속 항목의 관리를 위한 명령줄 도구와 GUI 도구를 제공합니다. Message Queue는 Message Queue 서비스의 원격 모니터링도 지원합니다.

확장 가능한 메시지 서비스     탠덤으로 작동하는 많은 Message Queue 메시지 서버 구성 요소(브로커), 즉 멀티 브로커 클러스터 간에 로드 균형을 조정하여 더 많은 수의 Message Queue 클라이언트(구성 요소 또는 응용 프로그램) 서비스를 제공할 수 있습니다.

클라이언트 연결 페일오버     Message Queue 메시지 서버에 대한 실패한 클라이언트 연결을 자동으로 복원합니다.

조정 가능한 성능     전달 안정성을 더 낮출 수 있는 경우 Message Queue 서비스의 성능을 높일 수 있습니다.

다중 전송     TCP와 HTTP 등의 다양한 전송 방식을 통해 그리고 보안(SSL) 연결을 사용하여 Message Queue 메시지 서버와 통신이 가능한 Message Queue 클라이언트의 기능을 지원합니다.

JNDI 지원     JNDI (Java Naming and Directory Interface)를 객체 저장소 및 사용자 저장소로 구현하는 파일 기반 및 LDAP 방식을 모두 지원합니다.

SOAP 메시징 지원     JMS 메시징을 통해 SOAP 메시지, 즉 SOAP (Simple Object Access Protocol) 사양에 일치하는 메시지의 생성 및 전달을 지원합니다. SOAP을 사용하면 분산 환경에서 피어 간에 구조화된 XML 데이터를 교환할 수 있습니다. 자세한 내용은 Message Queue Java Client Developer's Guide를 참조하십시오.

JMS 호환성에 대한 정보는 부록 G, "선택적 JMS 기능의 Message Queue 구현"을 참조하십시오.

제품 판

Sun Java System Message Queue는 플랫폼판과 엔터프라이즈판의 두 버전으로 제공되며, 이 버전들은 다음과 같이 기능과 사용권 용량이 서로 다릅니다(Message Queue를 다른 판으로 업그레이드하는 방법은 Message Queue 설치 설명서 참조).

플랫폼판

이 버전은 Sun 웹 사이트에서 무료로 다운로드할 수 있으며 Sun Java System Application Server 플랫폼과 함께 제공됩니다. 플랫폼판의 경우 Message Queue 메시지 서비스가 지원하는 클라이언트 연결의 수에 제한이 없습니다. 여기에는 다음과 같은 두 가지 사용권이 제공됩니다.

엔터프라이즈판

이 판은 생산 환경에서 메시징 응용 프로그램을 배포 및 실행할 때 사용됩니다. 여기에는 멀티 브로커 메시지 서비스 지원, HTTP/HTTPS 연결, 보안 연결 서비스, 확장 가능한 연결 기능, 클라이언트 연결 페일오버, 다중 사용자로의 대기열 전달, 원격 메시지 기반 모니터링, C-API 등에 대한 지원이 포함됩니다. 엔터프라이즈판은 메시징 응용 프로그램과 구성 요소의 개발, 디버깅, 로드 테스트에도 사용할 수 있습니다. 엔터프라이즈판에는 멀티 브로커 메시지 서비스의 브로커 수는 제한하지 않지만 사용되는 CPU의 수를 기반으로 하는 무기한 사용권이 있습니다.

엔터프라이즈 메시징 시스템

엔터프라이즈 메시징 시스템에서 독립 분산 응용 프로그램이나 응용 프로그램 구성 요소는 메시지를 통해 상호 작용할 수 있습니다. 동일한 호스트나 네트워크에 있거나 또는 인터넷을 통해 느슨하게 연결되어 있는 이 구성 요소들은 메시징을 사용하여 데이터를 전달하고 각자의 기능을 조정합니다.

엔터프라이즈 메시징 시스템의 요구 사항

일반적으로 엔터프라이즈 응용 프로그램 시스템은 24시간 미션 크리티컬 작업으로 무수히 많은 메시지를 교환하는 많은 수의 분산 구성 요소로 구성됩니다. 그러한 시스템을 지원하기 위해 엔터프라이즈 메시징 시스템은 일반적으로 다음 요구 사항을 만족시켜야 합니다.

안정적인 전달     구성 요소 간에 전달되는 메시지는 네트워크나 시스템 오류로 인해 손실되지 않아야 합니다. 즉 시스템은 메시지가 성공적으로 전달되도록 보장할 수 있어야 합니다.

비동기식 전달     많은 수의 구성 요소가 동시에 메시지를 교환하고 고용량의 처리량을 지원하기 위해서는 메시지 발신이 사용자의 즉시 수신 가능 여부에 따라 결정되어서는 안 됩니다. 사용자가 작업 중이거나 오프라인 상태인 경우, 시스템은 사용자가 온라인이 될 때 메시지 발신 및 수신이 가능하도록 해야 합니다. 이를 비동기식 메시지 전달이라 하며, 일반적으로 저장 및 전달(store-and-forward) 메시징이라고 부릅니다.

보안     메시징 시스템은 사용자 인증, 메시지 및 자원에 대한 인증된 액세스, 회선을 통한 암호화와 같은 기본 보안 기능을 지원해야 합니다.

확장성     메시징 시스템은 성능이나 메시지 처리량이 실제로 저하되지 않으면서 로드 증가(사용자 수 및 메시지 수 증가)를 수용할 수 있어야 합니다. 업무와 응용 프로그램이 늘어나면 이는 매우 중요한 요구 사항이 됩니다.

관리성     메시징 시스템은 메시지 전달을 모니터링 및 관리하고 시스템 자원을 최적화하는 도구를 제공해야 합니다. 이러한 도구는 안정성, 보안 및 성능의 측정과 관리를 지원합니다.

중앙 집중식 메시징과 피어 투 피어(Peer to Peer) 메시징 비교

그림 1-1에서 확인할 수 있듯이 기존의 피어 투 피어(Peer to Peer) 메시징 시스템으로는 엔터프라이즈 메시징 시스템의 요구 사항을 만족시키기 어렵습니다.

그림 1-1 중앙 집중식 메시징과 피어 투 피어(Peer to Peer) 메시징 비교

피어 투 피어 메시징과 중앙 집중식 메시징의 차이를 보여주는 다이어그램. 그림은 텍스트에 설명되어 있습니다.

그러한 시스템에서 모든 메시징 구성 요소는 다른 모든 구성 요소와의 연결을 유지 관리합니다. 이 연결을 통해 빠르고 안정적이며 보안이 유지된 상태로 전달을 할 수 하지만, 안정성과 보안을 지원하는 코드가 각 구성 요소마다 존재해야 합니다. 시스템에 구성 요소가 추가되면서 연결 수는 기하급수적으로 늘어납니다. 그 결과 비동기식 메시지 전달 및 확장성을 구현하기 어려워집니다. 중앙 집중식 관리에도 문제가 있습니다.

그림 1-1에서도 확인할 수 있듯이 권장되는 엔터프라이즈 메시징 방식은 중앙 집중식 메시징 시스템입니다. 이 방식에서 각 메시징 구성 요소는 단일 중앙 메시지 서비스와의 연결을 유지 관리합니다. 이 메시지 서비스는 구성 요소 간의 메시지 라우팅 및 전달을 수행하며, 안정적인 전달 및 보안을 책임집니다.
구성 요소는 잘 정의된 프로그래밍 인터페이스를 통해 메시지 서비스와 상호 작용합니다. 구성 요소가 시스템에 추가되면 일차적으로 연결 수만 증가되므로, 메시지 서비스를 확장하여 시스템을 보다 쉽게 확장할 수 있습니다. 또한 중앙 메시지 서비스는 중앙 집중식 시스템 관리를 지원합니다.

메시징 시스템 개념

엔터프라이즈 메시징 시스템에는 몇 가지 기본 개념이 존재합니다. 아래에서 설명하는 메시지, 메시지 서비스 구조 및 메시지 전달 모델도 그 기본 개념에 포함됩니다.

메시지

메시지는 일정 형식의 데이터(메시지 본문) 그리고 대상, 수명 및 그 밖의 메시징 시스템이 결정하는 특성 등과 같이 메시지의 특성이나 등록 정보를 설명하는 메타 데이터(메시지 헤더)로 구성됩니다.

메시지 서비스 구조

메시징 시스템의 기본 구조는 그림 1-2와 같습니다. 공통 메시지 서비스를 통해 메시지를 교환하는 메시지 생성자와 메시지 사용자로 구성됩니다. 메시지 생성자와 사용자는 그 수의 제한 없이 동일한 메시징 구성 요소(또는 응용 프로그램)에 위치할 수 있습니다. 메시지 생성자가 메시지 서비스에 메시지를 보냅니다. 메시지 서비스는 메시지 라우팅 및 전달 구성 요소를 사용하는 방식으로 해당 메시지에 대해 인터레스트를 등록한 하나 이상의 메시지 사용자에게 메시지를 전달합니다. 메시지 라우팅 및 전달 구성 요소는 관련된 모든 사용자에게 메시지가 전달되도록 보장하는 역할을 합니다.

그림 1-2 메시지 서비스 구조

메시지 서비스에 메시지를 보내는 메시지 생성자를 표시하는 다이어그램으로 메시지를 메시지 사용자에게 전달합니다.

메시지 전달 모델

생성자와 사용자의 관계는 일대일, 일대다, 다대다 등 여러 종류가 있습니다. 예를 들어 다음과 같이 메시지를 전달할 수 있습니다.

주로 이 관계들은 지점간(point-to-point) 및 게시/가입 메시징의 2가지 메시지 전달 모델로 축소됩니다. 지점간 전달 모델은 특정 생성자가 보내고 특정 사용자가 받는 메시지에 중점을 둡니다. 게시/가입 전달 모델은 여러 생성자가 보내고 여러 사용자가 받는 메시지에 중점을 둡니다. 이 메시지 전달 모델은 중복될 수 있습니다.

지금까지 메시징 시스템은 이 2가지 메시지 전달 모델이 다양하게 결합된 형태를 지원했습니다. JMS (Java Message Service) 사양은 Java 프로그래밍용 API를 통한 메시징을 위한 표준 의미를 작성합니다. 이 API는 지점간 및 게시/가입 메시지 전달 모델을 모두 지원합니다("프로그래밍 도메인" 참조).

JMS 사양

JMS 사양은 메시징에 적용되는 프로그래밍 모델, 메시지 구조, API 등을 비롯한 규칙과 의미의 집합을 규정합니다. Message Queue는 JMS 구현을 제공하기 때문에 JMS 개념은 Message Queue 메시징 시스템의 작동 방식을 이해하는 토대가 됩니다. 이 소개 부분에서는 이 책의 나머지 장을 이해하는 데 필요한 개념 및 용어를 설명합니다.

JMS 메시지 구조

JMS 메시지는 헤더, 등록 정보 및 본문의 3가지 부분으로 구성됩니다.

헤더     헤더는 메시지의 JMS 특성, 즉 대상, 지속성 여부, 수명 및 우선 순위를 지정합니다. 이러한 특징은 메시징 시스템의 메시지 전달 방식에 영향을 미칩니다.

등록 정보     등록 정보(헤더의 확장으로 간주할 수 있음)는 선택 사항이며, 응용 프로그램이 다양한 선택 기준에 따라 메시지를 필터링할 때 사용 가능한 값을 제공합니다. 등록 정보는 선택 사항입니다.

메시지 본문     메시지 본문에는 교환할 실제 데이터가 포함됩니다. JMS는 6가지 본문 유형을 지원합니다.

JMS 프로그래밍 모델

JMS 프로그래밍 모델에서 JMS 클라이언트(구성 요소 또는 응용 프로그램)는 JMS 메시지 서비스를 통해 메시지를 교환합니다. 메시지 생성자는 메시지 서비스로 메시지를 보내며, 메시지 사용자는 메시지 서비스로부터 메시지를 받습니다. 이러한 메시징 작업은 JMS API (Application Programming Interface)를 구현하는 객체 집합(JMS 공급자가 제공)을 사용하여 수행됩니다.

이 절에서는 JMS API를 구현하고 JMS 클라이언트의 메시지 전달 설정에 사용되는 객체를 소개합니다(자세한 정보는 Message Queue Java Client Developer's Guide 참조). 그림 1-3은 메시지 전달 프로그램에 사용되는 JMS 객체들입니다.

그림 1-3 JMS 프로그래밍 객체

클라이언트와 JMS 메시지 서비스가 사용하는 JMS 객체 간의 관계를 보여주는 다이어그램. 그림 뒤에 자세한 설명이 이어집니다.[D]

JMS 프로그래밍 모델에서 JMS 클라이언트는 ConnectionFactory 객체를 사용하여 메시지 서비스와 메시지를 송수신할 연결을 만듭니다. Connection은 클라이언트와 메시지 서비스 간의 활성 연결입니다. 연결되면 통신 자원 할당 및 클라이언트 인증이 이루어집니다. 이는 비교적 중량급 객체이며, 대부분의 클라이언트는 단일 연결을 사용하여 모든 메시징을 수행합니다.

연결은 세션을 생성할 때 사용합니다. Session은 메시지 생성 및 사용을 위한 단일 스레드 컨텍스트입니다. 메시지를 보내고 받는 메시지 생성자 및 사용자를 생성할 때 사용하며, 전달할 메시지의 일련 순서를 정의합니다. 세션은 여러 확인 옵션이나 트랜잭션을 통해 안정적인 전달을 지원합니다.

클라이언트는 MessageProducer를 사용하여 API에서 대상 아이디 객체로 표시되는 지정된 물리적 대상으로 메시지를 보냅니다. 메시지 생성자는 물리적 대상으로 보낼 모든 메시지에 적용되는 기본 전달 모드(지속성 메시지 및 비지속성 메시지), 우선 순위 및 수명 값을 지정합니다.

그와 비슷하게 클라이언트는 MessageConsumer를 사용하여 API에서 대상 객체로 표시되는 지정된 물리적 대상으로부터 메시지를 받습니다. 메시지 사용자는 메시지 선택기를 사용하여 메시지 서비스에서 선택 기준과 일치하는 메시지 사용자에게 해당 메시지만을 전달하도록 할 수 있습니다.

메시지 사용자는 동기식 또는 비동기식 메시지 사용을 지원할 수 있습니다. 사용자에게 MessageListener를 등록하면 비동기식 사용이 이루어집니다. 세션 스레드가 MessageListener 객체의 onMessage() 메소드를 호출하면 클라이언트가 해당 메시지를 사용합니다.

JMS 관리 대상 객체

JMS 사양은 공급자별 구성 정보를 캡슐화하는 관리 대상 객체를 지정하여 공급자 독립 클라이언트를 용이하게 합니다.

"JMS 프로그래밍 모델"에서 설명하는 객체 중 2가지는 JMS 공급자의 JMS 메시지 서비스 구현 방식에 대한 것입니다. 연결 팩토리 객체는 공급자가 메시지 전달 시 사용하는 기본 프로토콜 및 메커니즘에 따라 다르며, 대상 객체는 공급자가 사용하는 물리적 대상의 특정 이름 지정 규약 및 기능에 따라 다릅니다.

일반적으로 이 공급자별 특성 때문에 JMS 클라이언트 코드는 특정 JMS 구현에 종속됩니다. 그러나 JMS 사양에서는 표준화되고 특정 공급자에 국한되지 않는 방식으로 액세스할 수 있도록 공급자별 구현 및 구성 정보를 연결 팩토리 및 대상 객체로 캡슐화해야 합니다.

관리 대상 객체는 관리자가 작성 및 구성하고 이름 서비스에서 저장하며 클라이언트가 표준 JNDI (Java Naming and Directory Service) 조회 코드를 사용하여 액세스합니다. 이렇게 관리 대상 객체를 사용하면 클라이언트 코드는 공급자 독립성을 갖게 됩니다.

연결 팩토리와 대상이라는 두 가지 관리 객체 유형은 공급자별 정보를 캡슐화하지만 클라이언트 내에서 그 용도는 매우 다릅니다. 연결 팩토리는 메시지 서버에 연결하는 데 사용되고 대상 객체는 물리적 대상을 식별하는 데 사용됩니다.

JMS/J2EE 프로그래밍: Message-Driven Bean

"JMS 프로그래밍 모델"에서 소개한 일반적인 JMS 클라이언트 프로그래밍 모델 외에도 Java 2 Platform, Enterprise Edition (J2EE 플랫폼) 응용 프로그램 컨텍스트에서 사용하는, 보다 특수화된 JMS 응용 프로그램이 있습니다. 이 특수화된 JMS 클라이언트를 Message-Driven Bean이라고 부르며, EJB 2.0 사양(http://java.sun.com/products/ejb/docs.html)에 지정된 EJB (Enterprise JavaBeans) 구성 요소 중 하나입니다.

Message-Driven Bean이 필요한 이유는 다른 EJB 구성 요소(Session Bean과 Entity Bean)들이 동기식 호출만 가능하기 때문입니다. 이 EJB 구성 요소들은 표준 EJB 인터페이스를 통해서만 액세스할 수 있으므로 비동기식으로 메시지를 수신할 메커니즘이 없습니다.

그러나 비동기식 메시징은 많은 엔터프라이즈 응용 프로그램에서 필요합니다. 그러한 응용 프로그램 중 대부분에서는 서버측 구성 요소가 서버 자원을 독점하지 않으면서 상호 통신하고 응답할 수 있어야 합니다. 즉 메시지 생성자와 밀접하게 연결되지 않으면서 메시지 수신 및 사용이 가능한 EJB 구성 요소가 필요합니다. 이 기능은 서버측 구성 요소가 응용 프로그램 이벤트에 응답해야 하는 모든 응용 프로그램에서 필요합니다. 또한 엔터프라이즈 응용 프로그램에서도 로드 증가에 따라 이 기능이 확장되어야 합니다.

Message-Driven Bean

MDB (Message-Driven Bean)는 특정 EJB 컨테이너(지원하는 구성 요소에 대해 분산 서비스를 제공하는 소프트웨어 환경)가 지원하는 특정 EJB 구성 요소입니다.

Message-Driven Bean     MDB는 JMS MessageListener 인터페이스를 구현하는 JMS 메시지 사용자입니다. onMessage 메소드(MDB 개발자가 작성)는 MDB 컨테이너가 메시지를 수신할 때 호출됩니다. 이 onMessage() 메소드는 표준 MessageListener 객체의 onMessage() 메소드처럼 메시지를 사용합니다. 다른 EJB 구성 요소에서처럼 MDB에 대해 메소드를 원격 호출하지 않으므로 MDB와 관련된 홈 또는 원격 인터페이스는 없습니다. MDB는 단일 대상으로부터의 메시지를 사용할 수 있습니다. 그림 1-4에서 확인할 수 있듯이 독립형 JMS 응용 프로그램, JMS 구성 요소, EJB 구성 요소 또는 웹 구성 요소에서 메시지를 생성할 수 있습니다.

그림 1-4 MDB와의 메시지

J2EE 환경에서 JMS 메시지 생성자가 메시지를 사용할 MDB 인스턴스에게 메시지를 보내는 다이어그램

MDB 컨테이너     MDB 인스턴스를 생성하고 비동기식으로 메시지를 사용하도록 설정하는 역할을 하는 특수화된 EJB 컨테이너가 MDB를 지원합니다. 여기에는 메시지 서비스와의 연결 설정(인증 포함), 지정된 대상과의 세션 풀 생성, 세션 풀 및 관련 MDB 인스턴스 사이에서의 수신 메시지 배포 관리가 포함됩니다. 이 컨테이너는 MDB 인스턴스의 라이프사이클을 제어하므로 MDB 인스턴스 풀이 받는 메시지 로드를 수용할 수 있도록 관리합니다.

MDB와 관련 있는 배포 설명자는 컨테이너가 메시지 사용 설정 시 사용하는 관리 대상 객체, 즉 연결 팩토리와 대상의 JNDI 조회 이름을 지정합니다. 또한 배치 설명자는 배치 도구가 컨테이너 구성 시 사용 가능한 다른 정보를 포함할 수 있습니다. 이 컨테이너 각각은 단일 MDB로만 이루어진 인스턴스를 지원합니다.

J2EE Application Server 지원

J2EE 구조(http://java.sun.com/j2ee/download.html#platformspec의 J2EE 플랫폼 사양 참조)에서 EJB 컨테이너는 J2EE Application Server가 호스팅합니다. Application Server는 트랜잭션 관리자, 지속성 관리자, 이름 서비스, JMS 공급자(메시징 및 MDB의 경우) 등과 같은 다양한 컨테이너가 필요로 하는 자원을 제공합니다.

Sun Java System Application Server에서 JMS 메시징 자원은 Sun Java System Message Queue가 제공합니다.

JMS 메시징 문제

이 절에서는 Message Queue 메시지 서비스의 관리에 영향을 미치는 다양한 JMS 프로그래밍 문제를 설명합니다. Message Queue 관리자가 필요로 하는 개념 및 용어에 중점을 둡니다.

JMS 공급자 독립성

JMS는 다른 JMS 공급자에게 이식 가능한 클라이언트 응용 프로그램 개발을 지원하도록 관리 대상 객체("JMS 관리 대상 객체" 참조)의 사용을 지정합니다. 관리 대상 객체를 사용하면 JMS 클라이언트는 공급자별 객체를 조회하고 참조할 때 논리적 이름을 사용할 수 있습니다. 그렇게 되면 클라이언트 코드는 공급자가 사용하는 특정 이름 또는 주소 지정 구문이나 구성 가능한 등록 정보를 알아 둘 필요가 없습니다. 따라서 코드 공급자 독립성을 갖게 됩니다.

관리 대상 객체는 Message Queue 관리자가 작성 및 구성하는 Message Queue 시스템 객체입니다. 이 객체는 JNDI 디렉토리 서비스에 위치하며, JMS 클라이언트는 JNDI 조회를 사용하여 이 객체에 액세스합니다.

또한 Message Queue 관리 대상 객체는 JNDI 디렉토리 서비스에서 조회하기보다는 클라이언트가 인스턴스화할 수 있습니다. 이 경우 응용 프로그램 개발자가 공급자별 API를 사용해야 하는 단점이 있습니다. 또한 이는 Message Queue 관리자가 Message Queue 메시지 서버를 성공적으로 제어하고 관리하는 능력을 저하시킵니다.

관리 대상 객체에 대한 자세한 내용은 "Message Queue 관리 대상 객체"를 참조하십시오.

프로그래밍 도메인

JMS는 서로 다른 2가지 메시지 전달 모델인 지점간 모델과 게시/가입 모델을 지원합니다.

지점간(대기열 대상)     메시지는 생성자로부터 사용자에게 전달됩니다. 이 전달 모델에서 대상은 대기열입니다. 메시지는 먼저 대기열 대상으로 전달된 다음, 대기열의 전달 정책("대기열 대상" 참조)에 따라 대기열로부터 해당 대기열에 등록된 사용자 중 하나에게 한 번에 하나씩 전달됩니다. 생성자 수의 제한 없이 생성자는 대기열 대상에게 메시지를 보낼 수 있으며, 각 메시지는 반드시 한 사용자에게만 전달되어 성공적으로 사용됩니다. 대기열 대상에 등록된 사용자가 없는 경우, 대기열은 받은 메시지를 보관했다가 사용자가 대기열에 등록하면 메시지를 전달합니다.

게시/가입(주제 대상)     단일 생성자가 사용자 수의 제한 없이 메시지를 전달합니다. 이 전달 모델에서 대상은 주제입니다. 메시지는 먼저 주제 대상으로 전달된 다음, 해당 주제에 가입한 모든 활성 사용자에게 전달됩니다. 생성자 수의 제한 없이 생성자는 어떤 주제 대상으로 메시지를 보낼 수 있으며, 각 메시지는 가입한 사용자 수의 제한 없이 전달될 수 있습니다. 또한 주제 대상은 영구 가입의 개념을 지원합니다. 영구 가입은 주제 대상에 등록되었지만 메시지가 전달되는 시점에 비활성화될 수 있는 사용자를 의미합니다. 나중에 활성화된 사용자는 메시지를 수신합니다. 주제 대상에 대해 등록된 사용자가 없는 경우, 해당 주제는 비활성 사용자에 대해 영구 가입이 없는 한 받은 메시지를 보관하지 않습니다.

이 2가지 메시지 전달 모델은 표 1-1에서 확인할 수 있듯이 각기 다른 프로그래밍 도메인을 나타내고 의미상 약간 차이가 있는 서로 다른 API 객체를 사용하여 처리됩니다.

표 1-1 JMS 프로그래밍 객체 

기본 유형
(통합 도메인)

지점간 도메인

게시/가입 도메인

Destination (대기열 또는 주제)1

Queue

Topic

ConnectionFactory

QueueConnectionFactory

TopicConnectionFactory

Connection

QueueConnection

TopicConnection

Session

QueueSession

TopicSession

MessageProducer

QueueSender

TopicPublisher

MessageConsumer

QueueReceiver

TopicSubscriber

1프로그래밍 방식에 따라 특정 대상 유형을 지정할 수 있습니다.

표 1-1의 첫 번째 열에 표시된 통합 도메인 객체를 사용하여 지점간 및 게시/가입 메시징을 모두 프로그래밍할 수 있습니다. 이 방법이 권장됩니다. 이전 JMS 1.02b 사양에 따라 지점간 도메인 객체를 사용하여 지점간 메시징을 프로그래밍하고 게시/가입 도메인 객체를 사용하여 게시/가입 메시징을 프로그래밍할 수 있습니다.

클라이언트 식별자

JMS 공급자는 JMS 클라이언트와 메시지 서비스 간의 연결에 해당 메시지 서비스가 클라이언트를 대신하여 유지 관리하는 상태 정보를 연관시키는 클라이언트 식별자 개념을 지원해야 합니다. 정의에 따라 클라이언트 식별자는 고유하며 한 번에 한 명의 사용자에게만 적용됩니다. 각 영구 가입이 한 명의 사용자에게만 적용되도록 클라이언트 식별자는 영구 가입 이름("게시/가입(주제 대상)" 참조)과 함께 사용됩니다.

JMS 사양에서는 클라이언트가 API 메소드 호출을 통해 클라이언트 식별자를 설정할 수 있지만, 관리자가 연결 팩토리 관리 대상 객체("JMS 관리 대상 객체" 참조)를 사용하여 설정하는 것이 좋습니다. 그러나 연결 팩토리에 고정된 경우, 각 사용자는 개별 연결 팩토리마다 고유 아이디를 가져야 합니다.

Message Queue에서는 ConnectionFactory 객체에서 구성 가능한 특수 변수 대체 구문을 사용하여 클라이언트 식별자가 연결 팩토리 및 사용자 고유성을 모두 가질 수 있습니다. 이 방법을 사용할 경우 영구 가입을 작성하는 여러 사용자가 이름 지정 충돌이나 보안 손실에 대한 염려 없이 단일 ConnectionFactory 객체를 사용할 수 있습니다. 따라서 사용자의 영구 가입 시 실수로 지워지거나 다른 사용자의 잘못된 클라이언트 식별자 설정 때문에 사용할 수 없게 되는 상황을 막을 수 있습니다.

이 Message Queue 기능 사용 방법에 대한 자세한 내용은 Message Queue Java Client Developer's Guide 중 연결 팩토리 속성 부분을 참조하십시오.

어떤 경우라도 영구 가입을 생성하려면 클라이언트가 JMS API를 사용하여 프로그래밍 방식으로 클라이언트 식별자를 설정하거나 클라이언트가 사용하는 ConnectionFactory 객체에 클라이언트 식별자를 구성해야 합니다.

안정적인 메시징

JMS는 2가지 전달 모드를 정의합니다.

지속성 메시지     이 메시지는 단 한 차례 전달 및 성공적인 사용이 보장됩니다. 이 메시지에서는 안정성이 중요합니다.

비지속성 메시지     이 메시지는 최대 한 차례 전달이 보장됩니다. 이러한 메시지의 경우 안정성은 중요한 사항이 아닙니다.

지속성 메시지의 경우 안정성 보장에는 2가지 측면이 있습니다. 한 가지는 메시지 서비스에서 주고 받는 메시지가 성공적으로 전달되도록 하는 것입니다. 다른 하나는 메시지 서비스가 지속성 메시지를 사용자에게 전달하기 전에 그 메시지를 잃지 않도록 하는 것입니다.

확인/트랜잭션

안정적인 메시징은 대상을 오가는 지속성 메시지가 성공적으로 전달될 수 있는지 여부에 따라 결정됩니다. 이는 Message Queue 세션이 지원하는 2가지 일반 메커니즘인 확인 또는 트랜잭션 중 하나를 사용하여 실현할 수 있습니다. 트랜잭션의 경우, 로컬 트랜잭션 또는 분산 트랜잭션 관리자가 제어하는 분산 트랜잭션이 있습니다.

확인(Acknowledgement)

확인을 사용하여 안정적으로 전달되도록 세션을 구성할 수 있습니다.

생성자의 경우, 이는 생성자의 send() 메소드가 반환되기 전에 메시지 서비스가 대상에게 지속성 메시지의 전달을 확인하는 것을 의미합니다. 사용자의 경우, 이는 메시지 서비스가 대상으로부터 해당 메시지를 삭제하기 전에 클라이언트가 대상에게서 지속성 메시지의 전달 및 사용을 확인하는 것을 의미합니다.

로컬 트랜잭션

또한 세션을 트랜잭션된 것으로 구성할 수 있는데, 이 경우 하나 이상의 메시지 생성 및/또는 사용을 트랜잭션이라는 기본 단위로 분류할 수 있습니다. JMS API는 트랜잭션을 시작, 완결 또는 롤백하는 메소드를 제공합니다.

트랜잭션 내부에서 메시지를 생성하거나 사용하면 브로커는 다양한 발신 및 수신을 추적하고, 클라이언트가 트랜잭션을 완결하도록 호출한 경우에만 작업을 완료합니다. 트랜잭션 내부에서 특정 발신 또는 수신 작업이 실패할 경우 예외가 발생합니다. 클라이언트 코드는 예외를 무시하거나 작업을 다시 시도하거나 전체 트랜잭션을 롤백하는 방법으로 예외를 처리할 수 있습니다. 트랜잭션이 완결되면 성공적인 작업이 모두 완료됩니다. 트랜잭션이 롤백되면 성공적인 작업이 모두 취소됩니다.

로컬 트랜잭션의 범위는 항상 단일 세션입니다. 즉 단일 세션 컨텍스트에서 수행되는 하나 이상의 생성자 또는 사용자 작업을 묶어 단일 로컬 트랜잭션으로 분류할 수 있습니다.

트랜잭션 범위가 단일 세션에 국한되므로 메시지 생성과 사용을 모두 총괄하는 종단간 트랜잭션은 만들 수 없습니다. (즉, 대상으로 메시지를 전달하는 것과 나중에 메시지를 클라이언트로 전달하는 것을 하나의 트랜잭션으로 분류할 수 없습니다.)

분산 트랜잭션

또한 Message Queue는 분산 트랜잭션을 지원합니다. 즉 메시지 생성 및 사용은 데이터베이스 시스템과 같은 다른 자원 관리자가 관련된 작업들을 포함하는 더 크고 분산된 트랜잭션의 일부가 될 수 있습니다. 분산 트랜잭션의 경우, 분산 트랜잭션 관리자는 JTA (Java Transaction API)인 XA Resource API 사양에 정의된 2단계 완결 프로토콜을 사용하여 여러 자원 관리자(메시지 서비스, 데이터베이스 관리자 등)가 수행하는 작업을 추적하고 관리합니다. Java에서 자원 관리자 및 분산 트랜잭션 관리자 간의 상호 작용은 JTA 사양에서 설명합니다.

분산 트랜잭션 지원은 메시징 클라이언트가 JTA에서 정의된 XA Resource 인터페이스를 통해 분산 트랜잭션에 참여할 수 있음을 의미합니다. 이 인터페이스는 2단계 완결을 구현하는 여러 메소드를 정의합니다. 클라이언트측에서 API 호출이 이루어지는 동안 Message Queue 브로커는 분산 트랜잭션 내부의 다양한 발신 및 수신 작업을 추적하고 트랜잭션 상태를 추적하며 JTS (Java Transaction Service)가 제공하는 분산 트랜잭션 관리자와의 조정을 통해서만 메시징 작업을 완료합니다.

로컬 트랜잭션과 마찬가지로 클라이언트는 예외를 무시하거나 작업을 다시 시도하거나 전체 분산 트랜잭션을 롤백하는 방법으로 예외를 처리할 수 있습니다.

Message Queue는 XA 연결 팩토리를 통해 분산 트랜잭션 지원을 구현합니다. 이를 통해 XA 연결을 생성하고, XA 연결을 통해 XA 세션을 생성할 수 있습니다("JMS 프로그래밍 모델" 참조). 또한 분산 트랜잭션을 지원하려면 타사의 JTS나 (JTS를 제공하는) J2EE 호환 Application Server가 필요합니다.

영구 저장소

안정성의 또 다른 중요한 측면은 일단 지속성 메시지가 대상에게 전달되었다면 메시지 서비스는 사용자에게 전달될 때까지 그 메시지를 잃어버리지 않아야 한다는 것입니다. 즉 지속성 메시지가 대상에 전달되면 메시지 서비스는 이를 영구 데이터 저장소에 저장해야 합니다("지속성 관리자" 참조). 어떤 이유로 메시지 서비스가 중단되는 경우, 메시지 서비스는 메시지를 복구하여 해당 사용자에게 전달할 수 있습니다. 그 결과 메시지 전달의 오버헤드가 늘어나지만 안정성은 증가합니다.

또한 메시지 서비스는 영구 가입도 저장해야 합니다. 주제 대상의 경우, 메시지 전달을 보장하려면 지속성 메시지만 복구하는 것으로는 충분하지 않기 때문입니다. 또한 메시지 서비스는 어떤 주제의 영구 가입에 대한 정보를 복구해야 합니다. 그렇지 않으면 메시지가 도착했을 시점에 비활성 상태였다가 나중에 활성화되는 가입자에게 메시지를 전달할 수 없습니다.

메시지 전달 보장이 중요한 메시징 응용 프로그램은 메시지가 지속성을 갖도록 지정하고 대기열 대상이나 주제 대상에 대한 영구 가입 중 하나를 사용해야 합니다.

성능 균형

메시지 전달의 안정성이 높아질수록 이를 실현하기 위해 더 많은 오버헤드와 대역폭이 필요합니다. 안정성과 성능 간의 균형은 설계 시 고려해야 할 중요한 사항입니다. 비지속성 메시지를 생성하고 사용하도록 선택함으로써 성능을 극대화할 수 있습니다. 한편 지속성 메시지를 생성 및 사용하고 트랜잭션된 세션을 사용할 경우 안정성을 극대화할 수 있습니다. 이 둘 간에는 Message Queue별 연결 및 확인 등록 정보의 사용을 비롯하여 응용 프로그램의 필요 사항에 따라 다양한 옵션이 존재합니다(Message Queue Java Client Developer's Guide 참조). 이러한 균형에 대해서는 "성능에 영향을 미치는 응용 프로그램 설계 요소"에서 자세히 설명합니다.

메시지 선택

JMS는 메시지 선택기에 설정된 기준을 토대로 메시지 서비스가 메시지 필터링 및 라우팅을 수행할 수 있는 메커니즘을 제공합니다. 생성자 클라이언트는 응용 프로그램별 등록 정보를 메시지에 포함시킬 수 있으며, 사용자 클라이언트는 그러한 등록 정보에 기반한 선택 기준을 사용하여 메시지에 인터레스트를 표시할 수 있습니다. 그 결과 클라이언트 작업이 간소화되고 해당 메시지가 필요하지 않은 클라이언트로 메시지를 전달하는 오버헤드가 없어집니다. 그러나 선택 기준을 처리하는 오버헤드가 메시지 서비스에 추가됩니다. 메시지 선택기 구문과 의미는 JMS 사양에 설명되어 있습니다.

메시지 순서 및 우선 순위

일반적으로 단일 세션을 통해 어떤 대상으로 보내지는 모든 메시지는 발신 순서에 따라 사용자에게 전달됩니다. 그러나 다른 우선 순위가 지정된 경우, 메시징 시스템은 우선 순위가 높은 메시지를 먼저 전달하려고 합니다.

그 외에 클라이언트 응용 프로그램의 메시지 사용 순서와 생성 순서 간의 관계는 대략적인 것에 불과합니다. 대상으로의 메시지 전달과 대상으로부터의 메시지 전달은 메시지 발신 순서, 메시지가 발신된 세션(연결), 메시지의 지속성 여부, 메시지의 수명, 메시지 우선 순위, 대기열 대상의 메시지 전달 정책("대기열 대상" 참조) 및 메시지 서비스 가용성 등 시간에 영향을 미치는 다양한 요소에 따라 결정되기 때문입니다.

Message Queue 메시지 서버가 상호 연결된 여러 브로커를 사용하는 경우("멀티 브로커 클러스터(엔터프라이즈판)" 참조), 클라이언트의 메시지 사용 순서는 더 복잡해지는데, 이는 서로 다른 브로커에서 대상으로부터의 메시지 전달 순서가 불확정적이기 때문입니다. 따라서 어떤 브로커가 전달하는 메시지는 먼저 메시지를 수신한 다른 브로커가 전달하는 메시지보다 먼저 처리될 수도 있습니다.

어떤 경우에도 해당 사용자에 대해 우선 순위가 높은 메시지는 우선 순위가 낮은 메시지보다 먼저 처리됩니다.



이전      목차      색인      다음     

Copyright 2004 Sun Microsystems, Inc. 모든 권리는 저작권자의 소유입니다.