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

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

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

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

설계 및 성능

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

메시징 도메인

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

지점간 메시징

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

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

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

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

여러 생성자가 동일한 대기열에 메시지를 보낼 수 있습니다. 생성자는 연결을 공유하거나 서로 다른 연결을 사용할 수 있지만, 모두 동일한 대기열에 액세스할 수 있습니다.

여러 수신자가 동일한 대기열에서 메시지를 사용할 수 있지만, 각각의 메시지는 한 명의 수신자만 사용할 수 있습니다. 따라서 Msg1, Msg2 및 Msg3은 서로 다른 수신자가 사용합니다. 이것은 Message Queue 확장입니다.

수신자는 연결을 공유하거나 서로 다른 연결을 사용할 수 있지만, 모두 동일한 대기열에 액세스할 수 있습니다. 이것은 Message Queue 확장입니다.

발신자와 수신자는 타이밍에 구애 받지 않습니다. 즉, 수신자는 클라이언트가 메시지를 보낼 때 실행 여부와 관계 없이 메시지를 불러올 수 있습니다.

발신자와 수신자를 런타임에 동적으로 추가 및 삭제할 수 있으므로 필요에 따라 메시징 시스템을 확대하거나 축소할 수 있습니다.

메시지는 보낸 순서대로 대기열에 배치되지만 사용되는 순서는 메시지 만료일, 메시지 우선 순위, 메시지를 사용하는 데 선택기가 사용되는지 여부 등과 같은 요소에 따라 다릅니다.

여러 수신자가 동일한 대기열에서 메시지를 사용할 수 있으므로 메시지가 수신되는 순서가 중요하지 않은 경우 메시지 사용 로드 균형을 조정할 수 있습니다. 이것은 Message Queue 확장입니다.

대기열을 대상으로 하는 메시지는 수신자가 없더라도 항상 보관됩니다.

Java 클라이언트는 대기열 브라우저 객체를 사용하여 대기열의 내용을 조사할 수 있습니다. 그런 다음 이 조사를 통해 수집한 정보를 기반으로 메시지를 사용할 수 있습니다. 즉, 사용 모델은 일반적으로 선입선출(FIFO)이지만 사용자는 원하는 메시지를 알고 있는 경우 메시지 선택기를 사용하여 대기열의 헤드에 없는 메시지를 사용할 수 있습니다. 또한, 관리 클라이언트도 대기열 브라우저를 사용하여 대기열의 내용을 모니터할 수 있습니다.

게시/가입 메시징

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

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

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

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

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

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

여러 생성자가 동일한 주제에 메시지를 게시할 수 있습니다. 생성자는 연결을 공유하거나 서로 다른 연결을 사용할 수 있지만, 모두 동일한 주제에 액세스할 수 있습니다.

여러 가입자가 동일한 주제에서 메시지를 사용할 수 있습니다. 가입자는 선택기를 사용하여 메시지를 필터링하지 않거나 사용하기 이전에 메시지가 만료된 경우가 아니면 주제에 게시된 모든 메시지를 검색합니다.

가입자는 연결을 공유하거나 서로 다른 연결을 사용할 수 있지만, 모두 동일한 주제에 액세스할 수 있습니다.

영구 가입자는 활성 가입자이거나 비활성 가입자일 수 있습니다. 브로커는 비활성 가입자에 대한 메시지를 보관합니다.

게시자와 가입자를 런타임에 동적으로 추가 및 삭제할 수 있으므로 필요에 따라 메시징 시스템을 확대하거나 축소할 수 있습니다.

메시지는 보낸 순서대로 주제에 게시되지만 사용되는 순서는 메시지 만료일, 메시지 우선 순위, 메시지를 사용하는 데 선택기가 사용되는지 여부 등과 같은 요소에 따라 다릅니다.

게시자와 가입자는 타이밍에 구애를 받습니다. 즉, 주제 가입자는 가입한 이후에 게시된 메시지만 사용할 수 있습니다.

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

도메인별 API 및 통합 API

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

표 2-1 JMS 프로그래밍 도메인 및 객체
기본 유형 (통합 도메인)	지점간 도메인	게시/가입 도메인
Destination(Queue 또는 Topic)1	Queue	Topic
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver	TopicSubscriber

1프로그래밍 방식에 따라 특정 대상 유형을 지정해야 합니다.

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

프로그래밍 객체

연결 팩토리, 연결, 세션, 생성자, 사용자, 메시지, 대상 등과 같이 JMS 메시징을 구현하는 데 사용되는 객체는 프로그래밍 도메인 전체에서 동일하게 유지되어야 합니다. 이러한 객체는 그림 2-5를 참조하십시오. 이 그림에서는 객체가 파생되는 방법을 연결 팩토리 객체에서부터 위에서 아래로 보여줍니다.

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

표 2-2에서는 메시지를 보내고 받는 데 필요한 단계를 요약합니다. 단계 1과 단계 3 ~ 6은 발신자와 수신자에 대해 동일합니다.

표 2-2 메시지 생성 및 사용
메시지 생성	메시지 사용
1. 관리자가 연결 팩토리 관리 대상 객체를 만듭니다.




2. 관리자가 물리적 대상과 해당 대상을 참조하는 관리 대상 객체를 만듭니다.
3. 클라이언트가 JNDI 조회를 통해 연결 팩토리 객체를 가져옵니다. 4. 클라이언트가 JNDI 조회를 통해 대상 객체를 가져옵니다.

5. 클라이언트가 연결을 만들고 이 연결에 관한 등록 정보를 설정합니다.
6. 클라이언트가 세션을 만들고 메시징 안정성을 제어하는 등록 정보를 설정합니다.
7. 클라이언트가 메시지 생성자를 만듭니다.	클라이언트가 메시지 사용자를 만듭니다.
8. 클라이언트가 메시지를 작성합니다.	클라이언트가 연결을 시작합니다.
9. 클라이언트가 메시지를 보냅니다.	클라이언트가 메시지를 받습니다.

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

연결 팩토리 및 연결

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

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

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

브로커가 있는 호스트의 이름, 원하는 연결 서비스, 클라이언트가 해당 서비스에 액세스하는 데 사용하는 포트

연결이 실패할 경우 브로커에 자동으로 재연결하는 방법. 이 기능은 연결이 끊어진 경우에 클라이언트를 동일한 브로커나 다른 브로커에 다시 연결합니다. 데이터 페일오버는 보장되지 않습니다. 다른 브로커에 다시 연결할 때 지속성 메시지와 기타 상태 정보가 손실될 수 있습니다.

브로커가 영구 가입을 추적하는 데 필요한 클라이언트의 아이디

연결을 시도하는 사용자의 기본 이름 및 비밀번호. 이 정보는 연결 시 비밀번호를 지정하지 않은 경우에 사용자를 인증하고 작업 권한을 부여하는 데 사용됩니다.

안정성을 고려하지 않는 클라이언트에 대해 브로커 확인을 억제할지 여부

브로커와 클라이언트 런타임 간의 제어 및 페이로드 메시지의 흐름을 관리하는 방법.

대기열 찾아보기 처리 방법(Java 클라이언트만 해당)

특정 메시지 헤더 필드를 대체할지 여부

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

연결 객체를 사용하여 세션 객체를 만들거나, 예외 수신기를 설정하거나, 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)는 다음과 같은 세 가지 수준으로 설정될 수 있습니다.

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

메시지 헤더 필드의 이름은 언어 구현에 따라 다릅니다. 자세한 내용은 Java 클라이언트용 Message Queue 개발 안내서 또는 C 클라이언트용 Message Queue 개발 안내서를 참조하십시오.

메시지 등록 정보

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

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

Message Queue에서는 메시지 등록 정보도 정의합니다. 메시지 등록 정보는 메시지를 전달할 수 없을 경우의 메시지 처리 방법과 압축된 메시지를 식별하는 데 사용됩니다. 자세한 내용은 Java 클라이언트용 Message Queue 개발 안내서를 참조하십시오.

메시지 본문

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

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

표 2-4 메시지 본문 유형
유형	설명
StreamMessage	본문이 Java 프리미티브 값의 스트림을 포함하는 메시지. 이 메시지는 순차적으로 채워지고 읽혀집니다.
MapMessage	본문에 일련의 이름-값 쌍을 포함하는 메시지. 항목 순서는 정의되지 않습니다.
TextMessage	본문에 Java 문자열을 포함하는 메시지. 예를 들어, XML 메시지
ObjectMessage	본문에 일련화된 Java 객체를 포함하는 메시지
BytesMessage	본문에 해석되지 않은 바이트의 스트림이 포함된 메시지

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

메시지 생성

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

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

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

메시지 사용

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

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

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

동기식 및 비동기식 사용자

메시지 사용자는 동기식 또는 비동기식 메시지 사용을 지원할 수 있습니다.

메시지를 요청하는 데 사용되는 메소드에 따라 동기식 사용자는 메시지가 도착할 때까지 무한히 대기하거나, 지정된 시간 동안 메시지를 대기하거나, 사용할 준비가 된 메시지가 없는 경우 즉시 돌아가도록 선택할 수 있습니다. "사용됨"은 해당 객체를 클라이언트에서 즉시 사용할 수 있음을 의미합니다. 성공적으로 전송되었지만 브로커가 처리를 마치지 않은 메시지는 사용할 수 없습니다.

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

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

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

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

영구 가입자 사용

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

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

요청-응답 패턴

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

메시지 생성자는 다음을 수행하여 요청-응답 패턴을 설정해야 합니다.

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

요청-응답 메커니즘은 생성자에게 응답 대상에 대한 관리 대상 객체 설정 문제를 줄여주고 사용자가 요청에 쉽게 응답할 수 있게 해줍니다. 이 패턴은 생성자가 계속하기 전에 요청이 처리되었는지 확인해야 하는 경우에 유용합니다.

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

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

임시 대상은 만들어진 연결 기간 동안만 지속됩니다. 생성자는 임시 대상에 보낼 수 있지만, 임시 대상에 액세스할 수 있는 사용자만 대상을 만든 연결에 생성됩니다.

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

안정적인 메시징

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

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

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

확인

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

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

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

AUTO_ACKNOWLEDGE 모드에서 세션은 클라이언트에서 사용하는 각 메시지를 자동으로 확인합니다. 또한 브로커가 사용된 각 메시지에 대해 클라이언트 확인을 처리했음을 확인할 때까지 세션 스레드는 차단됩니다.

CLIENT_ACKNOWLEDGE 모드에서 클라이언트는 메시지 객체의 acknowledge() 메소드를 호출하여 하나 이상의 메시지를 사용한 후 명시적으로 확인합니다. 이것은 세션이 메소드의 이전 호출 이후에 세션에 사용된 모든 메시지를 확인하기 때문입니다. 또한 브로커가 클라이언트 확인을 처리했음을 확인할 때까지 세션 스레드는 차단됩니다.

안정성보다는 성능을 더 고려하는 클라이언트를 위해 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 호출이 이루어지는 동안 브로커는 분산 트랜잭션 내부의 다양한 발신 및 수신 작업을 추적하고 트랜잭션 상태를 추적하며 JTS(Java Transaction Service)가 제공하는 분산 트랜잭션 관리자와의 조정을 통해서만 메시징 작업을 완료합니다.

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

영구 저장소

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

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

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

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

시스템에서의 메시지 경로

지금까지 설명한 자료를 요약하여 이 절에서는 Message Queue 서비스를 사용하여 생성자에서 사용자로 메시지를 전달하는 방법에 대해 설명합니다. 전체적인 설명을 위해 세부 정보를 추가해야 합니다. 전달 단계에서 시스템에 의해 처리된 메시지는 두 가지 범주로 구분됩니다.

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

메시지 생성

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

메시지 처리 및 경로 지정

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

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

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

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 패키지를 제공합니다.

안정적인 SOAP 메시징을 수행하려면 다음을 수행해야 합니다.

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

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

JMS 메시지를 원하는 대상에게 보냅니다.

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

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

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

SOAP 메시지 및 처리 방법에 대한 자세한 내용은 Java 클라이언트용 Message Queue 개발 안내서를 참조하십시오.

Java 및 C 클라이언트

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

JMS 프로그래밍 모델은 Message Queue C 클라이언트 설계의 기초입니다. C 클라이언트용 Message Queue 개발 안내서에서는 C 데이터 유형 및 함수가 이 모델을 구현하는 방법에 대해 설명합니다.

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

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

이전 목차 색인 다음
Sun Java System Message Queue 3 2005Q4 기술 개요