test

Sun Java System Message Queue 3.7 UR1 기술 개요

2장 클라이언트 프로그래밍 모델

이 장에서는 Message Queue 클라이언트 프로그래밍의 기본적인 내용에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

이 장에서는 Java 클라이언트의 설계와 구현을 중심으로 설명합니다. 일반적으로 C 클라이언트 설계는 Java 클라이언트 설계와 거의 비슷합니다. 이 장의 마지막 절에서는 Java 클라이언트와 C 클라이언트의 차이점에 대해 요약합니다. Message Queue 클라이언트 프로그래밍에 대한 자세한 내용은 Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients 및 Sun Java System Message Queue 3.7 UR1 Developer’s Guide for C Clients를 참조하십시오.

3 장, Message Queue 서비스에서는 Message Queue 서비스를 사용하여 메시징 성능을 지원, 관리 및 조정하는 방법에 대해 설명합니다.

설계 및 성능

Message Queue 응용 프로그램의 동작은 클라이언트 설계, 연결 구성, 브로커 구성, 브로커 조정, 자원 관리와 같은 여러 가지 요소에 따라 다릅니다. 이 중 일부는 개발자에게 책임이 있고 나머지는 관리자와 관련되어 있습니다. 그러나 개발자는 Message Queue 서비스에서 응용 프로그램 설계를 지원하고 확장하는 방법을 잘 알고 있어야 하고, 관리자는 응용 프로그램을 조정할 때 설계 목표를 잘 알고 있어야 합니다. 메시징 동작은 재설계, 신중한 모니터링 및 조정을 통해 최적화될 수 있습니다. 따라서 우수한 Message Queue 응용 프로그램 만들기의 핵심은 개발자와 관리자가 응용 프로그램 라이프사이클의 각 단계에서 실현될 수 있는 내용을 이해하고 원하는 동작과 관찰된 동작에 대한 정보를 공유하는 것입니다.

메시징 도메인

구성 요소와 응용 프로그램은 메시징 미들웨어를 통해 메시지를 생성하고 소비하면서 통신할 수 있습니다. JMS API에서는 이 통신을 제어하는 두 가지 패턴, 즉메시징 도메인 지점간 메시징 및 게시/가입 메시징을 정의합니다. JMS API는 이 패턴을 지원하도록 구성되어 있습니다. 연결, 세션, 제작자, 소비자, 대상, 메시지와 같은 기본 JMS 객체는 두 도메인 모두에서 메시징 동작을 지정하는 데 사용됩니다.

지점간 메시징

지점간 도메인에서는 메시지 제작자를 발신자라고 하고 소비자를 수신자라고 합니다. 메시지 제작자와 소비자는 대기열이라는 대상을 통해 메시지를 교환합니다. 즉, 발신자가 대기열에 메시지를 생성하고 수신자가 대기열의 메시지를 소비합니다.

그림 2–1에서는 지점간 도메인에서 가장 간단한 메시징 작업을 보여 줍니다. MyQueueSender는 Msg1을 대기열 대상 MyQueue1로 보냅니다. 그러면 MyQueueReceiver가 MyQueue1에서 메시지를 가져옵니다.

그림 2–1 간단한 지점간 메시징

메시지는 대기열 대상을 통해 발신자에서 수신자로 이동합니다. 그림은 텍스트에 설명되어 있습니다.

그림 2–2에서는 더 복잡한 지점간 메시징 그림을 사용하여 이 도메인에서의 가능성을 보여 줍니다. 발신자인 MyQSender1과 MyQSender2가 동일한 연결을 사용하여 메시지를 MyQueue1로 보냅니다. MyQSender3은 추가 연결을 사용하여 메시지를 MyQueue1로 보냅니다. 수신하는 쪽에서는 MyQReceiver1이 MyQueue1의 메시지를 소비하며 MyQReceiver2와 MyQReceiver3은 연결을 공유하면서 MyQueue1의 메시지를 소비합니다.

그림 2–2 복잡한 지점간 메시징

두 발신자가 하나의 연결을 사용하여 한 수신자에게 메시지를 보냅니다. 동일한 대기열로부터 메시지를 가져오는 두 소비자. 그림은 텍스트에 설명되어 있습니다.

더욱 복잡한 이 그림은 지점간 메시징에 대한 많은 추가 사항을 나타냅니다.

지점간 모델은 다음과 같은 많은 장점이 있습니다.

게시/가입 메시징

게시/가입 도메인에서는 메시지 제작자를 게시자라고 하고 메시지 소비자를 가입자라고 합니다. 게시자와 가입자는 주제라는 대상을 통해 메시지를 교환합니다. 즉, 게시자는 주제에 대한 메시지를 생성하고 가입자는 주제에 가입한 다음 해당 주제에서 메시지를 소비합니다.

그림 2–3에서는 게시/가입 도메인의 간단한 메시징 작업을 보여 줍니다. MyTopicPublisher는 Msg1을 대상인 MyTopic에 게시합니다. 그러면 MyTopicSubscriber1과 MyTopicSubscriber2가 각각 MyTopic에서 Msg1의 복사본을 받습니다.

그림 2–3 간단한 게시/가입 메시징

한 명의 게시자가 주제 대상을 통해 두 명의 가입자에게 동일한 메시지를 보내는 그림입니다. 그림은 텍스트에 설명되어 있습니다.

게시/가입 모델에는 여러 명의 가입자가 필요하지 않지만, 그림에서는 이 도메인을 사용하여 메시지를 브로드캐스트할 수 있다는 사실을 강조하기 위해 두 명의 가입자를 표시했습니다. 주제에 대한 모든 가입자가 해당 주제에 게시된 메시지의 복사본을 갖습니다.

가입자는 비영구 가입자일 수도 있고 영구 가입자일 수도 있습니다. 브로커는 모든 활성 가입자에 대한 메시지를 보관하지만, 활성 가입자가 영구 가입자인 경우에는 비활성 가입자에 대한 메시지만 보관합니다.

그림 2–4에서는 이 패턴이 제공하는 가능성을 설명하기 위해 더 복잡한 게시/가입 메시징 그림을 보여 줍니다. 여러 명의 제작자가 Topic1 대상에 메시지를 게시합니다. 여러 명의 가입자가 Topic1 대상의 메시지를 소비합니다. 가입자가 선택기를 사용하여 메시지를 필터링하지 않는 한, 각 가입자는 선택한 주제에 게시된 모든 메시지를 얻게 됩니다. 그림 2–4에서 MyTSubscriber2는 Msg2를 필터링했습니다.

그림 2–4 복잡한 게시/가입 메시징

세 명의 게시자가 주제 대상을 통해 세 명의 가입자에게 메시지를 보내는 그림입니다. 그림은 텍스트에 설명되어 있습니다.

더욱 복잡한 이 그림은 게시/가입자 메시징에 대한 많은 추가 사항을 나타냅니다.

게시/가입 모델의 가장 큰 이점은 메시지를 가입자에게 브로드캐스트할 수 있다는 점입니다.

도메인별 API 및 통합 API

JMS API는 지점간 도메인이나 게시/가입 도메인을 구현하는 데 사용할 수 있는 인터페이스와 클래스를 정의합니다. 표 2–1의 2열과 3열에는 도메인별 API가 표시되어 있습니다. JMS API는 일반 메시징 클라이언트를 프로그래밍할 수 있는 추가 통합 도메인을 정의합니다. 이런 클라이언트의 동작은 메시지를 생성하고 소비하는 대상의 유형에 따라 결정됩니다. 메시징은 대상이 대기열인 경우에는 지점간 패턴에 따라 동작하고, 대상이 주제인 경우에는 게시/가입 패턴에 따라 동작합니다.

표 2–1 JMS 프로그래밍 도메인 및 객체

기본 유형(통합 도메인) 

지점간 도메인 

도메인 게시/가입 

Destination(대기열 또는 주제)

Queue

Topic

ConnectionFactory

QueueConnectionFactory

TopicConnectionFactory

Connection

QueueConnection

TopicConnection

Session

QueueSession

TopicSession

MessageProducer

QueueSender

TopicPublisher

MessageConsumer

QueueReceiver

TopicSubscriber

통합 도메인은 JMS 버전 1.1에서 소개되었습니다. 이전의 1.02b 사양을 준수해야 할 경우 도메인별 API를 사용할 수 있습니다. 또한 도메인별 API를 사용하면 대기열 대상에 영구 가입자를 만드는 등 특정 유형의 프로그래밍 오류를 방지하는 깨끗한 프로그래밍 인터페이스의 장점이 있습니다. 하지만 도메인별 API는 동일한 트랜잭션이나 동일한 세션에서 지점간 및 게시/가입 작업을 결합할 수 없다는 단점이 있습니다. 이러한 결합이 필요한 경우 통합 도메인 API를 선택해야 합니다. 두 도메인 결합의 예는 요청-응답 패턴을 참조하십시오.

프로그래밍 객체

연결 팩토리, 연결, 세션, 제작자, 소비자, 메시지, 대상과 같이 JMS 메시징을 구현하는 데 사용되는 객체는 프로그래밍 도메인 전체에서 동일하게 유지되어야 합니다. 이 객체는 그림 2–5에 나와 있습니다. 이 그림에서는 연결 팩토리 객체부터 시작하여 객체가 파생되는 방법을 위에서 아래로 보여 줍니다.

객체 저장소에는 두 개의 객체(연결 팩토리와 대상)가 있습니다. 이는 이 객체들이 일반적으로 관리 대상 객체로 생성, 구성되고 관리됨을 나타냅니다. 이 장에서는 연결 팩토리와 대상이 프로그래밍 방식이 아니라 관리 목적으로 생성된다고 가정합니다.

그림 2–5 JMS 프로그래밍 객체

연결 팩토리, 연결, 세션, 제작자, 소비자, 메시지 및 대상 간의 관계를 나타내는 그림입니다. 그림은 텍스트에 설명되어 있습니다.

표 2–2에서는 메시지를 보내고 받는 데 필요한 단계를 요약합니다. 1-6단계는 발신자와 수신자 모두에게 동일합니다.

표 2–2 메시지 생성 및 소비

메시지 생성 

메시지 소비 

1. 관리자가 연결 팩토리 관리 대상 객체를 만듭니다.

2. 관리자가 물리적 대상과 해당 대상을 참조하는 관리 대상 객체를 만듭니다.

3. 클라이언트가 JNDI 조회를 통해 연결 팩토리 객체를 가져옵니다.

4. 클라이언트가 JNDI 조회를 통해 대상 객체를 가져옵니다.

5. 클라이언트가 연결을 만들고 이 연결에 관한 등록 정보를 설정합니다.

6. 클라이언트가 세션을 만들고 메시징 안정성을 제어하는 등록 정보를 설정합니다.

7. 클라이언트가 메시지 제작자를 만듭니다. 

클라이언트가 메시지 소비자를 만듭니다. 

8. 클라이언트가 메시지를 작성합니다. 

클라이언트가 연결을 시작합니다. 

9. 클라이언트가 메시지를 보냅니다. 

클라이언트가 메시지를 받습니다. 

다음 절에서는 연결, 세션, 메시지, 대상과 같이 제작자와 소비자가 소비하는 객체에 대해 설명합니다. 그런 다음 메시지의 생성과 소비를 설명하여 JMS 객체에 대한 내용을 마치겠습니다.

연결 팩토리 및 연결

클라이언트는 연결 팩토리 객체(ConnectionFactory)를 사용하여 연결을 만듭니다. 연결 객체(Connection)는 클라이언트와 브로커 간의 활성 연결을 나타냅니다. 이 연결 객체는 기본적으로 시작되거나 이 클라이언트의 관리자가 명시적으로 시작하는 기본 연결 서비스를 사용합니다.

연결이 만들어지면 통신 자원 할당 및 클라이언트 인증이 이루어집니다. 이는 비교적 중량급 객체이며, 대부분의 클라이언트는 단일 연결을 사용하여 모든 메시징을 수행합니다. 연결은 동시 사용을 지원합니다. 제작자와 소비자는 그 수의 제한 없이 동일한 연결을 공유할 수 있습니다.

연결 팩토리를 만들 때 해당 등록 정보를 설정하여 연결 팩토리에서 파생되는 모든 연결의 동작을 구성할 수 있습니다. Message Queue의 경우 등록 정보를 통해 다음과 같은 정보를 지정합니다.

클라이언트 응용 프로그램을 시작할 때 사용하는 명령줄에서 연결 팩토리 등록 정보를 대체할 수 있습니다. 해당 연결에 대한 등록 정보를 설정하여 주어진 연결에 대한 등록 정보를 대체할 수도 있습니다.

연결 객체를 사용하여 세션 객체를 만들거나, 예외 수신자를 설정하거나, JMS 버전 및 공급자 정보를 가져올 수 있습니다.

세션

연결이 클라이언트와 브로커 간의 통신 채널을 나타내는 경우 세션에 클라이언트와 브로커 간의 단일 대화가 표시됩니다.일반적으로 세션 객체를 사용하여 메시지, 메시지 제작자 및 메시지 소비자를 만듭니다. 세션을 만들 경우 많은 확인 옵션 또는 트랜잭션을 통해 안정적인 전달을 구성합니다. 자세한 내용은 안정적인 메시징을 참조하십시오.

JMS 사양에 따르면 세션은 메시지 생성 및 소비를 위한 단일 스레드 컨텍스트입니다. 단일 세션에 대해 여러 메시지 제작자와 소비자를 만들 수 있지만, 해당 제작자와 소비자를 순차적으로 사용해야 합니다. 스레딩 구현은 Java 클라이언트와 C 클라이언트 간에 약간 다릅니다. 스레딩 구현 및 제한에 대한 자세한 내용은 해당 개발 안내서를 참조하십시오.

세션 객체를 사용하여 다음을 수행할 수도 있습니다.

메시지

메시지는헤더, 등록 정보 및 본문으로 구성됩니다.이 구조를 이해해야 메시지를 적절하게 작성하고 특정 메시징 동작을 구성할 수 있습니다.

메시지 헤더

헤더는 모든 JMS 메시지에서 필수입니다. 헤더에는 10개의 사전 정의된 필드가 포함되어 있습니다. 이러한 필드에 대한 목록과 설명은 표 2–3을 참조하십시오.

표 2–3 JMS 정의 메시지 헤더

헤더 필드 

설명 

JMSDestination

메시지를 보낼 대상 객체의 이름을 지정합니다. (공급자가 설정)

JMSDeliveryMode

메시지가 지속성 메시지인지 여부를 지정합니다. (기본적으로 공급자가 설정하거나, 클라이언트가 제작자 또는 개별 메시지에 대해 명시적으로 설정)

JMSExpiration

메시지가 만료되는 시간을 지정합니다. (기본적으로 공급자가 설정하거나, 클라이언트가 제작자 또는 개별 메시지에 대해 설정)

JMSPriority

0(낮음)-9(높음) 범위에서 메시지의 우선 순위를 지정합니다. (기본적으로 공급자가 설정하거나, 클라이언트가 제작자 또는 개별 메시지에 대해 명시적으로 설정)

JMSMessageID

공급자 설치 컨텍스트 내에서 메시지에 대한 고유 아이디를 지정합니다. (공급자가 설정)

JMSTimestamp

공급자가 메시지를 받은 시간을 지정합니다. (공급자가 설정)

JMSCorrelationID

클라이언트가 두 메시지 간의 통신을 정의하는 데 사용하는 값(클라이언트가 필요에 따라 설정)

JMSReplyTo

소비자가 회신을 보낼 대상을 지정합니다. (클라이언트가 필요에 따라 설정)

JMSType

메시지 선택기에서 평가할 수 있는 값(클라이언트가 필요에 따라 설정)

JMSRedelivered

메시지가 이미 전달되었지만 확인되지 않았는지 여부를 나타냅니다. (공급자가 설정)

이 표에서 알 수 있듯이 메시지 헤더 필드는메시지 식별, 메시지 라우팅 구성, 메시지 처리 정보 제공과 같은 다양한 목적으로 사용됩니다.

가장 중요한 필드 중 하나인 JMSDeliveryMode가 메시지 전달의 안정성을 결정합니다. 이 필드는 메시지가 지속성 메시지인지 여부를 나타냅니다.

일부 메시지 헤더 필드는 공급자(브로커 또는 클라이언트 런타임) 또는 클라이언트에 의해 설정됩니다. 메시지 제작자는 특정 메시징 동작을 가져올 헤더 값을 구성해야 합니다. 메시지 소비자는 헤더 값을 읽고 메시지 경로가 지정된 방법과 향후의 메시지 처리에 필요한 내용을 이해해야 합니다.

헤더 필드(JMSDeliveryMode, JMSExpiration 및 JMSPriority)는 세 가지 수준에서 설정할 수 있습니다.

이러한 필드가 여러 수준으로 설정되는 경우, 연결 팩토리에 설정된 값이 개별 메시지에 설정된 값을 대체하며 주어진 메시지에 설정된 값이 메시지 제작자에 설정된 값을 대체합니다.

메시지 헤더 필드의 이름은 언어 구현에 따라 다릅니다. 자세한 내용은 Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients 또는 Sun Java System Message Queue 3.7 UR1 Developer’s Guide for C Clients를 참조하십시오.

메시지 등록 정보

메시지는 등록 정보 이름과 등록 정보 값 쌍으로 지정되는 등록 정보라는 선택적 헤더 필드를 포함할 수도 있습니다. 클라이언트와 공급자는 이 등록 정보를 통해 메시지 헤더를 확장할 수 있으며, 등록 정보에는 클라이언트나 공급자가 메시지를 식별하여 처리하는 데 유용한 정보가 들어 있을 수 있습니다. 수신 클라이언트는 메시지 등록 정보를 사용하여 지정된 기준에 맞는 메시지만 전달하도록 요청할 수 있습니다. 예를 들어 소비자 클라이언트는 뉴저지에 있는 시간제 직원에 대한 급여 메시지에 대해서만 관심 분야를 표시할 수 있습니다. 공급자는 지정된 기준에 맞지 않는 메시지를 전달하지 않습니다.

JMS 사양에서는 아홉 가지 표준 등록 정보를 정의합니다. 이러한 등록 정보 중 일부는 클라이언트가, 다른 일부는 공급자가 설정합니다. 등록 정보의 이름은 예약된 문자 "JMSX"로 시작됩니다.클라이언트나 공급자는 이러한 등록 정보를 사용하여 메시지를 보낸 사람, 메시지 상태, 메시지 전달 빈도, 메시지가 전달된 시간 등을 확인할 수 있습니다. 이러한 등록 정보를 통해 공급자는 메시지 경로를 지정하고 진단 정보를 제공할 수 있습니다.

Message Queue에서는 메시지 등록 정보도 정의합니다. 메시지 등록 정보는 메시지를 전달할 수 없을 경우의 메시지 처리 방법과 압축된 메시지를 식별하는 데 사용됩니다. 자세한 내용은 Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients의 Managing Message Size를 참조하십시오.

메시지 본문

메시지 본문에는 클라이언트가 교환하고자 하는 데이터가 포함되어 있습니다.

표 2–4에 나와 있는 것처럼 JMS 메시지의 유형에 따라 본문에 포함되는 내용과 소비자가 본문을 처리하는 방법이 결정됩니다. 세션 객체에는 각 메시지 본문 유형에 대한 생성 메소드가 포함되어 있습니다.

표 2–4 메시지 본문 유형

유형 

설명 

StreamMessage

본문이 Java 프리미티브 값의 스트림을 포함하는 메시지. 이 메시지는 순차적으로 채워지고 읽혀집니다. 

MapMessage

본문에 일련의 이름-값 쌍을 포함하는 메시지. 항목 순서는 정의되지 않습니다. 

TextMessage

본문에 Java 문자열을 포함하는 메시지(예: XML 메시지) 

ObjectMessage

본문에 일련화된 Java 객체를 포함하는 메시지 

BytesMessage

본문에 해석되지 않은 바이트의 스트림이 포함된 메시지 

Message

헤더와 등록 정보는 있지만 본문이 없는 메시지 

Java 클라이언트는 클라이언트 런타임에서 전송 중인 메시지의 본문을 압축하도록 등록 정보를 설정할 수 있습니다. 소비자측의 Message Queue 런타임에서 메시지를 전달하기 전에 압축을 풉니다.

메시지 생성

메시지 제작자는 연결 및 세션 컨텍스트 내에서 메시지를 전송하거나 게시합니다. 메시지 생성은 매우 간단합니다. 클라이언트는 메시지 제작자 객체(MessageProducer)를 사용하여 물리적 대상(API에서는 대상 객체로 표현됨)으로 메시지를 보냅니다.

제작자를 만들 때 모든 제작자의 메시지가 전송되는 기본 대상을 지정할 수 있습니다. 지속성, 우선 순위, 수명 등을 제어하는 메시지 헤더 필드에 대한 기본값을 지정할 수도 있습니다. 그러면 이 기본값은 메시지를 보낼 때 대체 대상을 지정하거나 지정된 메시지의 헤더 필드에 대한 대체 값을 설정하여 기본값을 대체하지 않는 한 해당 제작자가 만든 모든 메시지에서 사용됩니다.

메시지 제작자는 JMSReplyTo 메시지 헤더 필드를 설정하여 요청-응답 패턴을 구현할 수도 있습니다. 자세한 내용은 요청-응답 패턴을 참조하십시오.

메시지 소비

메시지 소비자는 연결 및 세션 컨텍스트 내에서 메시지를 받습니다. 클라이언트는 메시지 소비자 객체(MessageConsumer)를 사용하여 지정된 물리적 대상(API에서는 대상 객체로 표현됨)으로부터 메시지를 받습니다.

다음 세 가지 요소는 브로커가 소비자에게 메시지를 전달하는 방법에 영향을 미칩니다.

메시지 전달 및 클라이언트 설계에 영향을 미치는 다른 중요한 요소로는 소비자에게 필요한 안정성 수준이 있습니다. 안정적인 메시징을 참조하십시오.

동기식 및 비동기식 소비자

메시지 소비자는 동기식 또는 비동기식 메시지 소비를 지원할 수 있습니다.

선택기를 사용하여 메시지 필터링

메시지 소비자는 메시지 선택기를 사용하여 등록 정보가 특정 선택 기준과 일치하는 메시지만 메시지 서비스에서 전달하게 할 수 있습니다. 소비자를 만들 때 이 기준을 지정합니다.

선택기는 SQL-like 구문을 사용하여 메시지 등록 정보에 대해 일치시킵니다. 예를 들면 다음과 같습니다.

color = ”red’
size > 10

Java 클라이언트는 대기열을 찾아볼 때 선택기를 지정할 수도 있습니다. 그러면 소비 대기 중인 선택된 메시지를 확인할 수 있습니다.

영구 가입자 사용

세션 객체를 사용하여 주제에 대한 영구 가입자를 만들 수 있습니다. 브로커는 가입자가 비활성화된 경우에도 이러한 종류의 가입자에 대한 메시지를 보관합니다.

브로커는 가입자의 상태를 유지하였다가 가입자가 다시 활성화되면 메시지를 다시 전달해야 하므로, 지정된 가입자가 들어오고 나가는 것을 식별할 수 있어야 합니다. 가입자의 아이디는 가입자를 만든 연결의 ClientID 등록 정보와 가입자를 만들 때 지정한 가입자 이름으로부터 구성됩니다.

요청-응답 패턴

동일한 연결 또는 세션(통합 API를 사용하는 경우)에서 제작자와 소비자를 결합할 수 있습니다. 또한 JMS API를 통해 임시 대상을 사용하여 메시징 작업에 대한 요청-응답 패턴을 구현할 수 있습니다.

요청-응답 패턴을 설정하려면 다음 작업을 수행해야 합니다.

  1. 소비자가 응답을 보낼 수 있는 임시 대상을 만듭니다.

  2. 보낼 메시지에서 메시지 헤더의 JMSReplyTo 필드를 해당 임시 대상으로 설정합니다.

메시지 소비자가 메시지를 처리할 때 메시지의 JMSReplyTo 필드를 검사하여 응답이 필요한지를 결정하고 지정된 대상에게 응답을 보냅니다.

요청-응답 메커니즘은 제작자가 응답 대상에 대한 관리 대상 객체를 설정해야 하는 번거로움을 덜어주고, 소비자가 요청에 쉽게 응답할 수 있게 해 줍니다. 이 패턴은 제작자가 계속하기 전에 요청이 처리되었는지 확인해야 하는 경우에 유용합니다.

그림 2–6에서는 주제에 메시지를 보내고 임시 대기열에서 응답을 받는 요청-응답 패턴에 대해 설명합니다.

그림 2–6 요청/응답 패턴

게시자가 주제 대상을 통해 두 가입자에게 메시지를 보내고 대기열을 통해 응답을 받습니다. 그림은 텍스트에 설명되어 있습니다.

그림에 표시된 것처럼 MyTopicPublisher는 Msg1을 대상 MyTopic에 생성합니다. MyTopicSubsriber1과 MyTopicSubscriber2는 메시지를 받고 MyTempQueue에 응답을 보냅니다. MyTQReceiver는 이 대기열에서 응답을 검색합니다. 이 패턴은 다수의 클라이언트에 가격 정보를 게시하고 순차적 처리를 위해 (응답) 주문을 대기열에 넣는 응용 프로그램에 유용할 수 있습니다.

임시 대상은 대상을 만든 연결 기간 동안만 지속됩니다. 제작자는 임시 대상에 보낼 수 있지만, 대상을 만든 동일한 연결에 의해 생성되는 것은 임시 대상에 액세스할 수 있는 소비자뿐입니다.

요청/응답 패턴은 임시 대상 만들기에 따라 다르므로 다음과 같은 경우에는 이 패턴을 사용하지 않아야 합니다.

안정적인 메시징

메시지 전달은 두 개의 홉에서 발생합니다. 첫 번째 홉은 제작자의 메시지를 브로커의 물리적 대상으로 가져오고, 두 번째 홉은 물리적 대상의 메시지를 소비자에게 가져옵니다. 따라서 브로커로 이동하는 홉, 브로커가 실패할 때 브로커 메모리에 있는 홉 그리고 브로커에서 소비자로 이동하는 홉 중 하나에 해당할 경우 메시지가 손실될 수 있습니다. 안정적인 전달에서는 이러한 경우에도 전달이 실패하지 않습니다. 비지속성 메시지는 브로커가 실패할 경우 항상 손실될 수 있으므로 안정적인 전달은 지속성 메시지에만 적용됩니다.

다음 두 메커니즘을 사용하여 안정적인 전달을 확실히 합니다.

다음 절에서는 안정성을 보장하는 이러한 2가지 측면에 대해 설명합니다.

확인

확인은 클라이언트와 메시지 서비스 간에 안정적인 메시지 전달을 확인하기 위해 보내는 메시지입니다. 확인은 제작자와 소비자에서 서로 다르게 사용됩니다.

메시지 생성 시, 브로커는 메시지를 받아서 대상에 넣고 영구적으로 저장했음을 확인합니다. 제작자의 send() 메소드는 이 확인을 받을 때까지 차단됩니다. 이러한 확인은 지속성 메시지를 보낼 때 클라이언트에 대해 투명합니다.

메시지 소비 시, 클라이언트가 대상으로부터의 메시지 전달을 수신하고 메시지를 소비했음을 확인한 다음 브로커가 해당 대상에서 메시지를 삭제합니다. JMS는 서로 다른 안정성 정도를 나타내는 다양한 확인 모드를 지정합니다.

안정성보다는 성능을 더 고려하는 클라이언트를 위해 Message Queue 서비스는 NO_ACKNOWLEDGE 모드를 제공하여 JMS API를 확장합니다. 이 모드에서는 브로커가 클라이언트 확인을 추적하지 않기 때문에 소비자 클라이언트에서 메시지를 성공적으로 처리했는지 확인할 수 없습니다. 이 모드를 선택하면 비영구 가입자에게 보내는 비지속성 메시지에 대한 성능이 향상될 수 있습니다.

트랜잭션

트랜잭션은 하나 이상의 메시지 생성 및/또는 소비를 기본 단위로 묶는 방법입니다. 위에서 설명한 클라이언트 및 브로커 확인 프로세스는 트랜잭션에도 적용됩니다. 이 경우 클라이언트 런타임과 브로커 확인이 트랜잭션 수준에서 암시적으로 수행됩니다. 트랜잭션이 완결되면 브로커 확인이 자동으로 보내집니다.

세션은 트랜잭션된 세션으로 구성할 수 있으며, JMS API는 트랜잭션 초기화, 완결 또는 롤백을 위한 메소드를 제공합니다.

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

트랜잭션의 범위는 항상 단일 세션입니다. 즉, 단일 세션 컨텍스트에서 수행되는 하나 이상의 제작자 또는 소비자 작업을 묶어 단일 트랜잭션으로 분류할 수 있습니다. 트랜잭션 범위가 단일 세션에 국한되므로 메시지 생성과 소비를 모두 총괄하는 종단간 트랜잭션은 만들 수 없습니다.

또한 JMS 사양은 분산 트랜잭션을 지원합니다. 즉, 메시지 생성 및 소비는 데이터베이스 시스템과 같은 다른 자원 관리자가 관련된 작업을 포함하는, 더 크고 분산된 트랜잭션의 일부가 될 수 있습니다. Java Systems Application Server에 제공된 것과 같은 트랜잭션 관리자는 분산 트랜잭션을 지원할 수 있어야 합니다.

분산 트랜잭션의 경우, 분산 트랜잭션 관리자는 JTA(Java Transaction API)인 XA Resource API 사양에 정의된 2단계 완결 프로토콜을 사용하여 여러 자원 관리자(메시지 서비스, 데이터베이스 관리자 등)가 수행하는 작업을 추적하고 관리합니다. Java에서 자원 관리자 및 분산 트랜잭션 관리자 간의 상호 작용은 JTA 사양에서 설명합니다.

분산 트랜잭션 지원은 메시징 클라이언트가 JTA에서 정의된 XAResource 인터페이스를 통해 분산 트랜잭션에 참여할 수 있음을 의미합니다. 이 인터페이스는 2단계 완결을 구현하는 여러 메소드를 정의합니다. 클라이언트측에서 API 호출이 이루어지는 동안 JMS 메시지 서비스는 분산 트랜잭션 내부의 다양한 발신 및 수신 작업을 추적하고 트랜잭션 상태를 추적하며 JTS(Java Transaction Service)가 제공하는 분산 트랜잭션 관리자와의 조정을 통해서만 메시징 작업을 완료합니다. 로컬 트랜잭션과 마찬가지로 클라이언트는 예외를 무시하거나 작업을 다시 시도하거나 전체 분산 트랜잭션을 롤백하는 방법으로 예외를 처리할 수 있습니다.

주 –

Message Queue는 Java Enterprise Edition 플랫폼에서 JMS 공급자로 사용되는 경우에 한해 분산 트랜잭션을 지원합니다. 분산 트랜잭션 사용 방법에 대한 자세한 내용은 Application Server 공급자가 제공한 설명서를 참조하십시오.

영구 저장소

안정성의 또 다른 측면은 메시지가 소비자에게 전달될 때까지 브로커가 지속성 메시지를 잃어버리지 않아야 한다는 것입니다. 즉, 메시지가 물리적 대상에 전달되면 브로커는 이를 영구 데이터 저장소에 저장해야 합니다. 어떤 이유로 브로커가 중단되는 경우, 브로커는 메시지를 나중에 복구하여 해당 소비자에게 전달할 수 있습니다.

브로커는 영구 가입을 영구히 저장해야 합니다. 그렇지 않으면, 오류 발생 시 브로커는 메시지가 주제 대상에 도달한 다음에 활성화되는 영구 가입자에게 메시지를 전달할 수 없습니다.

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

3 장, Message Queue 서비스에서는 Message Queue 서비스에서 제공한 기본 메시지 저장소 그리고 관리자가 대체 저장소를 설정하고 구성하는 방법에 대해 설명합니다.

시스템에서의 메시지 경로

지금까지 설명한 자료를 요약하여 이 절에서는 Message Queue 서비스를 사용하여 제작자에서 소비자로 메시지를 전달하는 방법에 대해 설명합니다. 완벽한 이해를 위해서는 더 자세한 정보가 필요합니다. 이러한 전달 단계에서 시스템에 의해 처리된 메시지는 두 가지 범주로 구분됩니다.

메시지 전달은 그림 2–7에 설명되어 있습니다.

그림 2–7 메시지 전달 단계

안정적으로 전달되는 지속성 메시지의 메시지 전달 프로세스 단계를 보여 주는 다이어그램. 그림은 텍스트에 설명되어 있습니다.

안정적으로 전달되는 지속성 메시지의 메시지 전달 단계는 다음과 같습니다.

메시지 생성

1. 클라이언트 런타임이 연결을 통해 메시지 제작자에서 브로커로 메시지를 전달합니다.

메시지 처리 및 경로 지정

2. 브로커가 연결을 통해 메시지를 읽고 적절한 대상에 저장합니다.

3. 브로커가 (지속성) 메시지를 데이터 저장소에 저장합니다.

4. 브로커가 메시지 제작자의 클라이언트 런타임에게 메시지 수신 확인을 보냅니다.

5. 브로커가 메시지 경로 지정을 결정합니다.

6. 브로커가 대상의 메시지를 해당 연결에 기록하여 소비자에 대한 고유 식별자 태그를 붙입니다.

메시지 소비

7. 메시지 소비자의 클라이언트 런타임이 연결에서 메시지 소비자로 메시지를 전달합니다.

8. 메시지 소비자의 클라이언트 런타임이 메시지 소비에 대한 확인을 브로커로 보냅니다.

메시지 수명 끝

9. 브로커가 클라이언트 확인을 처리하고 모든 확인이 수신되면 (지속성) 메시지를 삭제합니다.

10. 브로커가 소비자의 클라이언트 런타임에서 클라이언트 확인이 처리되었는지 확인합니다.

관리자가 대상에서 메시지를 삭제한 경우 또는 관리자가 영구 가입을 제거하거나 다시 정의한 경우, 메시지가 소비되기 전에 브로커가 이를 삭제할 수 있으므로 주제 대상의 메시지가 전달되지 않고 제거되는 상황이 벌어집니다. 이때 브로커가 메시지를 삭제하지 않고 사용 불능 메시지 대기열이라는 특수 대상에 메시지를 저장하도록 할 수도 있습니다. 메시지는 만료되는 경우, 메모리 제한으로 인해 제거되거나 클라이언트에서 예외가 발생하여 전달에 실패하면 사용 불능 메시지 대기열에 저장됩니다. 사용 불능 메시지 대기열에 메시지를 저장하여 시스템 문제를 해결하고 특정 상황에서 메시지를 복구할 수 있습니다.

SOAP 메시지 작업

SOAP( Java 클라이언트에 대한 SOAP 지원 참조)를 사용하면 분산 환경에서 두 피어 간에 구조화된 데이터(XML 스키마에서 지정)를 교환할 수 있습니다. Sun의 SOAP 구현에서는 현재 안정적인 SOAP 메시징과 SOAP 메시지 게시를 지원하지 않습니다. 그러나 Message Queue 서비스를 사용하여 안정적인 SOAP 메시징을 수행할 수 있으며, 원하는 경우 SOAP 메시지를 게시할 수 있습니다. Message Queue 서비스는 SOAP 메시지를 직접 전달하지 않습니다. 그러나 SOAP 메시지를 JMS 메시지로 래핑하고, 이러한 메시지를 일반 JMS 메시지처럼 생성 및 소비하며, JMS 메시지에서 SOAP 메시지를 추출할 수 있습니다.

Message Queue에서는 javax.xml.messaging과 com.sun.messaging.xml의 두 가지 패키지를 통해 SOAP 지원을 제공합니다. 이러한 라이브러리에서 구현된 클래스를 사용하여 SOAP 메시지를 수신하고, SOAP 메시지를 JMS 메시지로 래핑하며, JMS 메시지에서 SOAP 메시지를 추출할 수 있습니다. J2EE 플랫폼은 SOAP 메시지를 어셈블 및 역어셈블하는 데 사용할 수 있는 java.xml.soap 패키지를 제공합니다.

Procedure안정적인 SOAP 메시징을 수행하는 방법

  1. java.xml.soap 패키지에 정의된 객체를 사용하여 SOAP 메시지를 구성하거나, javax.xml.messaging 패키지에 정의된 서블릿을 사용하여 SOAP 메시지를 수신하거나, JAX-RPC와 같은 웹 서비스를 사용하여 SOAP 메시지를 수신합니다.

  2. Message Transformer 유틸리티를 사용하여 SOAP 메시지를 JMS 메시지로 변환합니다.

  3. JMS 메시지를 원하는 대상으로 보냅니다.

  4. JMS 메시지를 비동기식 또는 동기식으로 소비합니다.

  5. JMS 메시지를 소비한 후 Message Transformer 유틸리티를 사용하여 해당 메시지를 SOAP 메시지로 변환합니다.

  6. java.xml.soap 패키지에 정의된 SAAJ API를 사용하여 SOAP 메시지를 역어셈블합니다.

    SOAP 메시지 및 처리 방법에 대한 자세한 내용은 Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients의 5 장, Working with SOAP Messages를 참조하십시오.

Java 및 C 클라이언트

Message Queue에서는 레거시 C 및 C++ 응용 프로그램을 사용하여 JMS 기반 메시징에 참여할 수 있도록 메시징 서비스에 C API를 제공합니다.

JMS 프로그래밍 모델은 Message Queue C 클라이언트 설계의 기초입니다. Sun Java System Message Queue 3.7 UR1 Developer’s Guide for C Clients에서는 C 데이터 유형 및 함수가 이 모델을 구현하는 방법에 대해 설명합니다.

Java 인터페이스와 마찬가지로 C 인터페이스도 다음 기능을 지원합니다.

그러나 Java Message Service 사양은 Java 클라이언트에 대해서만 표준으로 사용됩니다. 즉, C Message Queue API는 Message Queue 공급자 전용이므로 다른 JMS 공급자가 사용할 수 없습니다. 다른 JMS 공급자는 C 클라이언트를 포함하는 메시징 응용 프로그램을 처리할 수 없습니다.

C 인터페이스는 다음 기능을 지원하지 않습니다.