메시징 도메인

구성 요소와 응용 프로그램은 메시징 미들웨어를 통해 메시지를 생성하고 소비하면서 통신할 수 있습니다. 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 복잡한 지점간 메시징

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

• 여러 제작자가 동일한 대기열에 메시지를 보낼 수 있습니다. 제작자는 하나의 연결을 공유하거나 여러 연결을 사용할 수 있지만, 모두 동일한 대기열에 액세스 가능합니다.

• 여러 수신자가 동일한 대기열의 메시지를 소비할 수 있지만, 각 메시지는 한 명의 수신자에 의해서만 소비될 수 있습니다. 따라서 Msg1, Msg2 및 Msg3은 서로 다른 수신자가 소비합니다(Message Queue의 확장).

• 수신자는 하나의 연결을 공유하거나 여러 연결을 사용할 수 있지만, 모두 동일한 대기열에 액세스 가능합니다. (Message Queue의 확장).

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

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

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

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

• 여러 수신자가 동일한 대기열의 메시지를 소비할 수 있으므로, 메시지가 수신되는 순서가 중요하지 않은 경우 메시지 소비 로드 균형을 조정할 수 있습니다(Message Queue의 확장).

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

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

게시/가입 메시징

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

그림 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를 선택해야 합니다. 두 도메인 결합의 예는 요청-응답 패턴을 참조하십시오.