1장 메시징 시스템 소개

Sun Java™ System Message Queue는 JMS(Java Message Service) 표준을 구현 및 확장하는 메시징 미들웨어 제품입니다. 이 문장의 내용이 완전히 이해된다면 Message Queue 요소 및 기능 절부터 시작할 수 있습니다. 그렇지 않으면 처음부터 시작해야 합니다.

이 장에서는 Message Queue와 같은 제품의 기반이 되는 메시징 기술과 Message Queue에서 JMS 사양을 구현 및 확장하여 이 기술을 표준화하는 방법에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

메시지 지향 미들웨어(Message-Oriented Middleware(MOM))

기업, 공공 기관 및 기술은 지속적으로 변화하므로 이러한 기관 및 기술에 사용되는 소프트웨어 시스템은 그러한 변화를 수용할 수 있어야 합니다. 기업을 병합하거나 서비스를 추가하거나 사용 가능한 서비스를 확장한 후에는 그 기업의 정보 시스템을 다시 구축하지 못할 수 있습니다. 새 구성 요소를 통합하거나, 기존 구성 요소를 가능한 한 효과적으로 확장하는 것이 가장 중요합니다. 이기종 구성 요소를 통합하는 가장 쉬운 방법은 이기종 구성 요소를 동종 요소로 다시 만드는 것이 아니라 차이에 상관없이 구성 요소 간의 통신을 가능하게 해주는 계층을 제공하는 것입니다. 이 계층을 미들웨어라 하며, 이는 독립적으로 개발되어 서로 다른 네트워크 플랫폼에서 실행되는 소프트웨어 구성 요소(응용 프로그램, Enterprise Java Bean, 서블릿 및 기타 구성 요소) 간의 상호 작용을 가능하게 해줍니다. 이 상호 작용이 가능할 때 네트워크가 컴퓨터가 될 수 있습니다.

그림 1-1에 표시된 것처럼 개념적으로 미들웨어는 응용 프로그램 계층과 플랫폼 계층(운영 체제 및 기본 네트워크 서비스) 사이에 있습니다.

서로 다른 네트워크 노드에 분산된 응용 프로그램은 다른 응용 프로그램을 호스트하는 운영 환경의 세부 정보나 다른 응용 프로그램에 연결해 주는 서비스를 고려할 필요 없이 응용 프로그램 인터페이스를 사용하여 통신합니다. 또한, 관리 인터페이스를 제공하여 상호 연결된 새 가상 응용 프로그램 시스템을 안정적이고 보안되게 만들 수 있습니다. 시스템의 성능을 측정하고 조정하고 기능적인 손실 없이 확장할 수 있습니다.

RPC(Remote Procedure Call) 기반 미들웨어 - 한 응용 프로그램의 프로시저를 사용하여 원격 응용 프로그램의 프로시저를 로컬 호출처럼 호출할 수 있게 해줍니다. 미들웨어는 원격 프로시저를 찾아서 호출자가 알기 쉽게 사용할 수 있도록 해주는 연결 메커니즘을 구현합니다. 일반적으로 이 유형의 미들웨어는 프로시저 기반 프로그램을 처리했지만, 지금은 객체 기반 구성 요소도 포함합니다.

ORB(Object Request Broker) 기반 미들웨어 - 응용 프로그램의 객체를 배포하여 이기종 네트워크 간에 공유할 수 있게 해줍니다.

MOM(Message Oriented Middleware) 기반 미들웨어 - 분산 응용 프로그램 간에 메시지를 전송 및 수신하여 데이터 통신과 교환을 가능하게 해줍니다.

이러한 모든 모델에서 한 소프트웨어 구성 요소가 네트워크를 통해 다른 구성 요소의 동작에 영향을 줄 수 있습니다. RPC 및 ORB 기반 미들웨어는 시스템의 구성 요소를 밀접하게 연결하는 반면, MOM 기반 시스템의 구성 요소는 느슨하게 연결합니다. RPC 또는 ORB 기반 시스템에서는 한 프로시저에서 다른 프로시저를 호출할 때 호출된 프로시저가 반환될 때까지 대기하였다가 다른 작업을 수행할 수 있습니다. 앞에서 설명한 것처럼 이러한 모델에서는 미들웨어가 부분적으로 수퍼링커의 역할을 하여 호출된 프로시저를 네트워크에서 찾고 네트워크 서비스를 통해 함수 또는 메소드 매개 변수를 프로시저에 전달한 다음 결과를 반환합니다.

MOM 기반 시스템에서는 그림 1-2에 표시된 것처럼 비동기식 메시지 교환을 통해 통신을 가능하게 합니다.

메시지 지향 미들웨어(Message Oriented Middleware)는 메시징 공급자를 사용하여 메시징 작업을 중재합니다. MOM 시스템의 기본 요소는 클라이언트, 메시지 및 MOM 공급자이며 API와 관리 도구를 포함합니다. MOM 공급자는 서로 다른 아키텍처를 사용하여 메시지 경로를 지정하고 전달할 수 있습니다. MOM 공급자는 중앙 집중식 메시지 서버를 사용하거나 각 클라이언트 컴퓨터에 라우팅 및 전달 기능을 배포할 수 있습니다. 일부 MOM 제품에서는 이 두 가지 방법을 결합하여 사용합니다.

클라이언트는 MOM 시스템을 통해 API를 호출하여 공급자가 관리하는 대상에게 메시지를 보냅니다. API 호출은 공급자 서비스를 호출하여 메시지 경로를 지정하고 메시지를 전달합니다. 메시지를 보낸 후 클라이언트는 다른 작업을 계속해서 수행할 수 있습니다. 이 때 공급자는 수신하는 클라이언트가 메시지를 검색할 때까지 해당 메시지를 보관합니다. 공급자의 중재로 연결된 메시지 기반 모델을 사용하여 구성 요소가 느슨하게 연결된 시스템을 만들 수 있습니다. 그런 시스템은 개별 구성 요소나 연결이 실패하더라도 중단 없이 계속해서 안정적으로 작동할 수 있습니다.

메시징 공급자를 사용하여 클라이언트 간에 메시징을 중재할 경우 관리 인터페이스를 추가하여 성능을 모니터 및 조정할 수 있다는 또 다른 이점이 있습니다. 따라서 클라이언트 응용 프로그램에서 메시지 보내기, 받기 및 처리 문제를 제외한 모든 문제를 효과적으로 줄일 수 있습니다. MOM 시스템 구현은 코드에서 담당하고 상호 운용성, 안정성, 보안, 확장성, 성능 등과 관련된 문제는 관리자가 해결해야 합니다.

지금까지는 메시지 지향 미들웨어를 사용하여 분산 구성 요소를 연결할 때의 장점에 대해 설명했습니다. 이 경우 몇 가지 단점도 있는데, 그 중 하나는 느슨하게 연결된 구성 요소가 원인입니다. RPC 시스템에서 호출 함수는 호출된 함수가 작업을 완료할 때까지 반환되지 않습니다. 비동기식 시스템에서 호출 클라이언트는 작업을 처리하는 데 필요한 자원이 부족하여 호출된 구성 요소가 실패할 때까지 수신자에게 작업을 계속해서 로드할 수 있습니다. 성능을 모니터하고 메시지 흐름을 조정하여 이러한 조건을 최소화하거나 방지할 수 있지만 RPC 시스템에서는 그런 작업이 필요하지 않습니다. 중요한 것은 각 시스템 종류의 장점과 단점을 이해하는 것입니다. 각 시스템은 서로 다른 작업에 적합합니다. 필요한 정확한 동작을 얻기 위해 두 종류의 시스템을 결합해야 하는 경우도 있습니다.

그림 1-3에서는 MOM 시스템에서 두 RPC 기반 시스템 간의 통신을 가능하게 하는 방법을 보여줍니다. 그림의 왼쪽은 성능 향상을 위해 서로 다른 네트워크 노드에 클라이언트, 서버 및 데이터 저장소 구성 요소를 배포하는 응용 프로그램을 나타냅니다. 이것은 할인 항공 예약 시스템인데, 최종 사용자는 이 서비스를 유료로 이용하여 주어진 목적지와 시간 대에 이용 가능한 가장 저렴한 요금을 찾을 수 있습니다. 데이터 저장소에는 등록된 사용자와 이 프로그램에 참여하는 항공사에 대한 정보가 보관됩니다. 사용자의 요청이 있을 경우 서버의 논리는 참여하는 항공사에서 가격을 쿼리하여 정보를 정렬한 다음 가장 저렴한 세 가지 요금을 사용자에게 표시합니다. 그림의 오른쪽은 참여하는 항공사 중 한 항공사의 티켓/예약 시스템을 나타내는 RPC 기반 시스템을 보여줍니다. 그림의 오른쪽은 할인하는 사람이 연결된 항공사 수만큼 복제됩니다. 그런 각 항공사에 대해 데이터 저장소는 이용 가능한 항공편에 대한 정보(좌석, 비행 시간, 가격)를 보관합니다. 서버 구성 요소는 최종 사용자가 입력하는 데이터에 따라 해당 정보를 업데이트합니다. 또한 항공사 서버는 MOM 서비스에 가입하여 할인 예약 시스템에 대한 정보 요청을 수락하고 좌석 및 가격 정보를 반환합니다. 고객이 PanWorld의 할인 티켓 구매를 결정할 경우 해당 시스템의 서버 구성 요소는 데이터 저장소에서 해당 정보를 업데이트한 다음 요청자를 위한 티켓을 생성하거나 할인 서비스에 티켓을 생성하라는 메시지를 보냅니다.

이 예에서는 RPC 시스템과 MOM 시스템 간의 몇 가지 차이점에 대해 설명합니다. 분산 구성 요소가 연결되는 방식의 차이점에 대해서는 이미 설명했습니다. 다른 차이점으로는 RPC 시스템은 클라이언트와 서버 구성 요소를 배포 및 연결하는 데 사용되며 이 경우 클라이언트는 일반적으로 최종 사용자인 반면, MOM 시스템에서 클라이언트는 메시징을 통해서만 상호 운용 가능한 이기종 소프트웨어 구성 요소인 경우가 많습니다.

MOM 시스템의 보다 심각한 문제는 MOM이 소유 제품으로 구현된다는 사실입니다. SuperMOM-X를 사용하는 회사에서 SuperMOM-Y를 사용하는 회사를 인수할 경우 어떻게 될까요? 이 문제를 해결하려면 표준 메시징 인터페이스가 필요합니다. SuperMOM-X와 SuperMOM-Y가 모두 이 인터페이스를 구현하는 경우 한 시스템에서 실행하도록 개발된 응용 프로그램이 다른 시스템에서도 실행될 수 있습니다. 그런 인터페이스는 배우기 쉬우면서도 정교한 메시징 응용 프로그램을 지원하는 데 충분한 기능을 제공해야 합니다. 1998년에 소개된 JMS(Java Message Service) 사양이 이것을 목표로 합니다. 다음 절에서는 JMS의 기본 기능에 대해 설명하고 기존 소유 MOM 제품의 공통 요소를 포함하고 차이점과 추가 확장을 고려하도록 표준을 개발한 방법에 대해 설명합니다.

MOM 표준으로서의 JMS

JMS(Java Messaging Service) 사양은 원래 Java 응용 프로그램이 기존 MOM 시스템에 액세스할 수 있도록 개발되었습니다. JMS 사양은 소개된 이후 기존의 많은 MOM 공급업체에서 채택하였으며 자체 권한에 따라 비동기식 메시징 시스템으로 구현되었습니다.

JMS 사양을 만들 때 디자이너는 기존 메시징 시스템의 필수 요소를 캡처하려고 했습니다. 여기에는 다음이 포함됩니다.

공급업체는 JMS 인터페이스를 구현하는 라이브러리, 메시지 경로를 지정하고 전달하는 기능, 메시징 서비스를 관리하고 모니터하고 조정하는 관리 도구 등으로 구성되는 JMS 공급자를 제공하여 JMS 사양을 구현합니다. 경로 지정 및 전달 기능은 중앙 집중식 메시지 서버나 브로커에서 수행되거나, 각 클라이언트 런타임의 일부인 기능을 통해 구현될 수 있습니다.

또한 JMS 공급자는 다음과 같은 다양한 역할을 할 수 있습니다. JMS 공급자를 독립 실행형 제품으로 만들거나 대용량 분산 런타임 시스템의 내장 구성 요소로 만들 수 있습니다. 독립 실행형 제품으로 만든 JMS 공급자는 엔터프라이즈 응용 프로그램 통합 시스템의 백본을 정의하는 데 사용될 수 있고, 응용 프로그램 서버에 내장된 JMS 공급자는 구성 요소 간 메시징을 지원할 수 있습니다. 예를 들어, J2EE는 JMS 공급자를 사용하여 Message-Driven Bean을 구현하고 EJB 구성 요소가 메시지를 보내고 받을 수 있도록 합니다.

기존 시스템의 모든 기능을 포함하는 표준을 만들었다면 학습 및 구현이 어려운 시스템이 생성되었을 것입니다. 대신, JMS는 메시징 개념과 기능의 공통 분모를 정의했습니다. 그 결과 배우기 쉽고 JMS 공급자에 대한 JMS 응용 프로그램의 이식성을 최대화하는 표준이 생성되었습니다. JMS는 프로토콜 표준이 아니라 API 표준입니다. JMS 클라이언트를 공급업체 간에 쉽게 이동할 수 있습니다. 그러나 일반적으로 서로 다른 JMS 공급업체 간에는 직접 통신할 수 없습니다.

다음 절에서는 JMS 사양에 정의된 기본 객체와 메시징 패턴에 대해 설명합니다.

JMS 메시징 객체 및 패턴

메시지를 보내거나 받으려면 메시지 브로커로도 구현되는 JMS 공급자에 JMS 클라이언트를 맨 먼저 연결해야 합니다. 그러면 클라이언트와 브로커 간에 통신 채널이 열립니다. 그런 다음 클라이언트는 메시지 작성, 생성 및 사용을 위한 세션을 설정해야 합니다. 세션을 클라이언트와 브로커 간의 특정 대화를 정의하는 메시지 스트림으로 간주할 수 있습니다. 클라이언트 자체는 메시지 생성자 및/또는 메시지 사용자입니다. 메시지 생성자는 메시지를 브로커가 관리하는 대상에게 보냅니다. 메시지 사용자는 해당 대상에 액세스하여 메시지를 사용합니다. 메시지는 헤더, 선택적 등록 정보 및 본문으로 구성됩니다. 본문에는 데이터가 저장되고, 헤더에는 브로커가 메시지 경로를 지정하고 관리하는 데 필요한 정보가 들어 있으며, 등록 정보는 클라이언트 응용 프로그램이나 공급자가 자체 메시지 처리 요건에 맞게 정의할 수 있습니다. JMS 사양을 구성하는 기본 객체는 연결, 세션, 대상, 메시지, 생성자 및 사용자입니다.

이러한 기본 객체를 사용하여 클라이언트 응용 프로그램은 두 가지 메시징 패턴 또는 도메인을 통해 메시지를 보내고 받을 수 있습니다. 그림 1-4를 참조하십시오.

클라이언트 A와 B는 서로 다른 두 대상을 경유하여 클라이언트 C, D, E에게 메시지를 보내는 메시지 생성자입니다.

클라이언트 A, C, D 간의 메시징은 지점간 패턴을 보여줍니다. 클라이언트는 이 패턴을 사용하여 메시지를 대기열 대상에게 보냅니다. 이 때 한 수신자만 대기열 대상으로부터 메시지를 받을 수 있습니다. 해당 대상에 액세스하는 다른 수신자는 해당 메시지를 받을 수 없습니다.

클라이언트 B, E, F 간의 메시징은 게시/가입 패턴을 보여줍니다. 클라이언트는 이 브로드캐스트 패턴을 사용하여 주제 대상에게 메시지를 보냅니다. 이 때 주제 대상의 모든 가입자가 해당 메시지를 검색할 수 있습니다. 각 가입자는 고유의 메시지 복사본을 갖습니다.

도메인의 메시지 사용자는 메시지를 동기식으로 받을지 비동기식으로 받을지 여부를 선택할 수 있습니다. 동기식 사용자는 메시지를 검색하기 위해 명시적 호출을 생성하고, 비동기식 사용자는 대기 중인 메시지를 전달하기 위해 호출되는 콜백 메소드를 지정합니다. 또한, 사용자는 들어오는 메시지에 대한 선택 기준을 지정하여 메시지를 필터링할 수 있습니다.

관리 대상 객체

JMS 사양은 모든 가능성을 시도하지 않고 기존 MOM 시스템의 많은 요소를 결합하는 표준을 생성했습니다. 보다 자세히 말하자면 차이점과 추가 확장을 수용할 수 있는 확장 체계를 설정하려고 했습니다. JMS는 많은 메시징 요소를 개별 공급자가 정의 및 구현하도록 남겨 두었습니다. 이러한 요소로는 로드 균형 조정, 표준 오류 메시지, 관리 API, 보안, 기본 와이어 프로토콜, 메시지 저장소 등이 있습니다. 다음 Message Queue 요소 및 기능 절에서는 Message Queue에서 이러한 많은 요소를 구현하는 방법과 JMS 사양을 확장하는 방법에 대해 설명합니다.

JMS에서 완벽하게 정의하지 않은 두 메시징 요소는 연결 팩토리와 대상입니다. 이러한 요소는 JMS 프로그래밍 모델의 기본 요소이지만, 공급자가 이러한 객체를 정의 및 관리하는 방식에 많은 차이가 있으므로 공통 정의를 생성하는 것은 가능하지도 않고 바람직하지도 않습니다. 따라서 이 두 객체는 프로그래밍 방식으로 만들지 않고 관리 도구를 사용하여 만들어 구성하는 것이 일반적입니다. 그러면 두 객체가 객체 저장소에 저장되고 JMS 클라이언트가 표준 JNDI 조회를 통해 액세스할 수 있습니다.

연결 팩토리 관리 대상 객체는 클라이언트를 브로커에 연결하는 데 사용됩니다. 연결 팩토리 관리 대상 객체는 연결 처리, 클라이언트 아이디, 메시지 헤더 대체, 안정성, 흐름 제어 등과 같은 메시징 동작의 특정 측면을 관리하는 공급자별 정보를 캡슐화합니다. 지정된 연결 팩토리에서 파생되는 모든 연결은 해당 팩토리에 대해 구성된 동작을 나타냅니다.

관리 대상 객체는 브로커에서 물리적 대상을 참조하는 데 사용됩니다. 관리 대상 객체는 공급자별 이름 지정(주소 구문) 규약을 캡슐화하고 대상이 사용하는 메시징 도메인(대기열 또는 주제)을 지정합니다.

JMS 클라이언트는 관리 대상 객체를 조회할 필요가 없으며, 이러한 객체를 프로그래밍 방식으로 만들어 브로커의 메모리에 저장할 수 있습니다. 프로토타입을 신속하게 제작하려면 이러한 객체를 프로그래밍 방식으로 만드는 것이 가장 쉽습니다. 그러나, 프로덕션 환경에서 배포할 경우에는 중앙 저장소에서 관리 대상 객체를 조회하여 메시징 동작을 훨씬 쉽게 제어 및 관리할 수 있습니다.

관리자는 연결 팩토리 객체에 대해 관리 객체를 사용하여 이러한 객체를 재구성함으로써 메시징 성능을 조정할 수 있습니다. 그러면 다시 코드화하지 않고도 성능을 향상시킬 수 있습니다.

관리자는 물리적 대상에 대해 관리 객체를 사용하여 클라이언트에게 사전 구성된 객체에 액세스하도록 요구함으로써 브로커에서 이러한 대상의 증가를 제어할 수 있습니다.

관리 대상 객체는 개발자가 공급자별 구현 세부 정보를 보지 못하도록 차단하고, 개발자가 특정 공급자를 위해 개발하는 코드를 약간만 변경하거나 변경하지 않고 다른 공급자에게 이식할 수 있도록 해줍니다.

관리 대상 객체를 사용하면 그림 1-5에 표시된 것처럼 기본 JMS 응용 프로그램에 최종 기능 하나가 추가됩니다.

그림 1-5에서는 메시지 생성자와 메시지 사용자가 관리 대상 객체를 사용하여 해당 물리적 대상에 액세스하는 방법을 보여줍니다. 표시된 단계는 관리자와 클라이언트 응용 프로그램이 이 메커니즘을 사용하여 메시지를 보내고 받기 위해 수행해야 하는 작업을 나타냅니다.

관리자는 브로커에 물리적 대상을 만듭니다.

관리자는 관리 대상 객체를 만든 다음 해당하는 물리적 대상의 이름과 유형(대기열 또는 주제)을 지정하여 관리 대상 객체를 구성합니다.

메시지 생성자는 JNDI 조회 호출을 사용하여 관리 대상 객체를 조회합니다.

메시지 생성자는 대상에게 메시지를 보냅니다.

메시지 사용자는 메시지를 받을 관리 대상 객체를 조회합니다.

메시지 사용자는 대상으로부터 메시지를 받습니다.

연결 팩토리 관리 대상 객체를 사용하는 과정도 비슷합니다. 관리자는 관리 도구를 사용하여 연결 팩토리 관리 대상 객체를 만들어 구성합니다. 클라이언트는 연결 팩토리 객체를 조회한 후 해당 연결 팩토리 객체를 사용하여 연결을 생성합니다.

관리 대상 객체를 사용하면 메시징 처리 과정에 몇 단계가 추가되지만, 메시징 응용 프로그램의 견고성과 이식성이 향상됩니다.

Message Queue 요소 및 기능

지금까지는 메시지 지향 미들웨어의 요소에 대해 설명하고 JMS를 사용하여 MOM 응용 프로그램에 이식성을 추가하는 방식에 대해 설명했습니다. 이제 Message Queue에서 JMS 사양을 구현하는 방법과 안정적이고 보안되고 확장 가능한 메시징 서비스를 제공하기 위해 사용하는 기능과 도구에 대해 설명하겠습니다.

우선, 많은 JMS 공급자와 마찬가지로 Message Queue를 독립 실행형 제품으로 사용하거나, 비동기식 메시징을 제공하기 위해 J2EE 응용 프로그램 서버에 내장된 활성화 기술로 사용할 수 있습니다. 5장, "Message Queue 및 J2EE"에서는 Message Queue가 J2EE에서 수행하는 역할에 대해 자세히 설명합니다. 다른 JMS 공급자와 다르게, Message Queue는 JMS 참조 구현으로 지정되었습니다. 이렇게 지정함으로써 Message Queue가 올바르고 완벽한 JMS 구현임을 증명합니다. 또한, Message Queue 제품이 향후의 JMS 개정 및 확장을 통해 최신 상태로 유지됨을 보장합니다.

Message Queue 서비스

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 호출을 만들 경우 브로커의 물리적 대상에 메시지를 전달하는 데 사용될 프로토콜에 적합한 메시지 비트를 패키지화하는 코드가 이러한 라이브러리에서 호출됩니다.

Java 및 C 클라이언트 지원

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 공급자에만 해당되며 다른 공급자에게 연결할 클라이언트 응용 프로그램에서는 사용할 수 없습니다.

Java 클라이언트에 대한 SOAP 지원

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 서비스는 다음 작업을 수행하는 데 사용할 수 있는 명령줄 도구를 제공합니다.

GUI 기반 관리 콘솔을 사용하여 다음과 같은 명령줄 기능을 수행할 수도 있습니다.

Message Queue 서비스 확장

클라이언트 수 또는 연결 수가 증가하면 병목 현상 제거 또는 성능 향상을 위해 메시지 서비스를 확장해야 할 수 있습니다. Message Queue 메시지 서비스는 사용자의 필요에 따라 많은 확장 옵션을 제공합니다. 이러한 옵션은 편의상 다음과 같은 범주로 정렬될 수 있습니다.

지점간 도메인을 사용하는 경우에는 다중 사용자가 하나의 대기열에 액세스할 수 있도록 허용하여 사용자 측면을 확장할 수 있습니다. 이 방법을 사용할 경우 최대 활성 및 백업 사용자 수를 지정할 수 있습니다. 또한 로드 균형 조정 메커니즘은 사용자의 현재 용량과 메시지 처리 속도를 고려합니다. 이것은 Message Queue 기능입니다. JMS 사양은 한 명의 사용자만 대기열에 액세스하는 경우의 메시징 동작을 정의합니다. 여러 사용자의 액세스가 허용되는 대기열에 대한 동작은 공급자별로 다릅니다. 이 확장 옵션에 대한 자세한 내용은 Message Queue 개발 안내서를 참조하십시오.

상태 없는 수평 확장은 브로커를 추가한 다음 해당 브로커에 기존 클라이언트를 재배포하여 이루어집니다. 이 방법은 쉽게 구현할 수 있지만 메시징 작업이 독립 작업 그룹으로 분류될 수 있는 경우에만 적합합니다.

상태 있는 수평 확장은 브로커를 클러스터에 연결하여 이루어집니다. 브로커 클러스터에서 각 브로커는 로컬 응용 프로그램 클라이언트 뿐만 아니라 클러스터에 있는 모든 다른 브로커에도 연결됩니다. 브로커는 동일한 호스트에 있거나 네트워크에 분산될 수 있습니다. 대상 및 사용자에 대한 정보가 클러스터에 있는 모든 브로커에 복제됩니다. 대상 또는 가입자에 대한 업데이트가 함께 전파되므로 각 브로커는 생성자가 보내는 메시지를 클러스터에 있는 다른 브로커에 연결되는 사용자에게 직접 연결하도록 메시지 경로를 지정할 수 있습니다. 백업 사용자가 사용되는 환경에서 하나의 브로커나 연결이 실패할 경우 액세스할 수 없는 사용자에게 보낸 메시지를 다른 브로커에 있는 백업 사용자에게 전달할 수 있습니다.

브로커 또는 연결이 실패할 경우 영구 항목(대상 및 영구 가입)에 대한 상태 정보가 동기화되지 않을 수 있습니다. 예를 들어, 클러스터된 브로커가 중단되어 대상이 클러스터에 있는 다른 브로커에 생성되고 첫 번째 브로커가 다시 시작될 경우 해당 브로커는 새 대상에 대해 알 수 없습니다. 이 문제를 사전에 방지하기 위해 클러스터의 한 브로커를 마스터 브로커로 지정할 수 있습니다. 이 브로커는 마스터 구성 파일에서 대상 및 영구 가입에 대한 모든 변경을 추적하고 클러스터에서 일시적으로 오프라인 상태인 브로커를 업데이트합니다. 자세한 내용은 4장, "브로커 클러스터"를 참조하십시오.

마스터 브로커를 사용하는 경우에도 Message Queue는 브로커 또는 연결이 실패할 경우 서비스 가용성만 제공하고 데이터 가용성은 제공하지 않습니다. 예를 들어, 클러스터된 브로커를 사용할 수 없는 경우 해당 브로커에 보관된 모든 영구 메시지는 해당 브로커가 복구될 때까지 사용할 수 없습니다. 현재는 SunCluster Message Queue 에이전트를 통해서만 데이터 가용성이 제공됩니다. 이 경우 영구 저장소는 공유 파일 시스템에 유지됩니다. 브로커가 실패할 경우 두 번째 노드의 Message Queue 에이전트가 공유 저장소를 인계할 브로커를 시작합니다. 클라이언트가 해당 브로커에 다시 연결되므로 영구 데이터에 대한 액세스와 서비스가 지속됩니다.

활성화 기술로서의 Message Queue

Java 2 Platform, Enterprise Edition(J2EE 플랫폼)은 Java 프로그래밍 환경에서 분산된 구성 요소 모델의 사양입니다. J2EE 플랫폼의 요구 사항 중 하나는 분산 구성 요소가 안정적인 비동기식 메시지 교환을 통해 다른 구성 요소와 서로 상호 작용할 수 있어야 한다는 것입니다. 이 기능은 JMS 공급자가 제공하며 다음과 같은 두 가지 역할을 할 수 있습니다. 이 기능을 사용하여 서비스를 제공하고 JMS 메시지를 사용할 수 있는 EJB(Enterprise Java Bean) 구성 요소의 특수 유형인 MDB(Message-Driven Bean)를 지원할 수 있습니다.

J2EE 호환 응용 프로그램 서버는 지정된 JMS 공급자가 제공하는 자원 어댑터를 통해 해당 공급자의 기능을 사용해야 합니다. Message Queue는 그런 자원 어댑터를 제공합니다. 응용 프로그램 서버 환경에 배포되어 실행되는 J2EE 구성 요소(MDB 포함)는 플러그 인된 JMS 공급자 지원을 사용하여 상호 간이나 외부 JMS 구성 요소와 JMS 메시지를 교환할 수 있습니다. 따라서 분산 구성 요소에 강력한 통합 기능을 제공하게 됩니다.

제품 판

Message Queue는 엔터프라이즈판과 플랫폼판의 두 버전으로 사용할 수 있습니다. 두 버전 모두 JMS 사양을 완전히 구현하지만 각각은 다른 기능 집합과 허가된 용량을 가집니다.

엔터프라이즈판은 플랫폼판에 다음과 같은 기능을 추가합니다.

HTTP 및 HTTPS 지원

C 클라이언트 지원

확장 가능한 연결 용량

브로커 클러스터

대기열 당 무제한 수의 메시지 사용자에게 대기열 전달(플랫폼판의 전달은 대기열 당 세 명의 사용자로 제한됨)

클러스터 내의 다른 브로커에 대한 클라이언트 연결 페일오버

메시지 기반 모니터링 API

Message Queue 엔터프라이즈판에는 사용되는 CPU 수에 기반하여 무기한 영구 사용권이 있습니다. 사용권은 다중 브로커 메시지 서비스의 브로커 수에 제한이 없습니다.

Message Queue 플랫폼판의 경우 브로커가 지원하는 클라이언트 연결의 수에 제한이 없습니다. 이 기능은 기본 사용권 또는 90일 시험 사용권과 함께 제공됩니다.

기본 사용권은 기간 제한이 없지만 엔터프라이즈판 기능을 포함하지 않습니다.

90일 시험 엔터프라이즈 사용권으로는 엔터프라이즈판의 모든 기능을 사용 및 평가할 수 있지만 소프트웨어 사용 기간이 90일로 제한됩니다. 이 사용권 사용에 대한 자세한 내용은 Message Queue 관리 설명서에 설명된 시작 옵션을 참조하십시오.

허가된 기능과 용량, 재배포 권한, 플랫폼판을 엔터프라이즈판으로 업그레이드하는 방법 등에 대한 자세한 내용은 Message Queue 설치 설명서를 참조하십시오.

Message Queue 기능 요약

Message Queue는 JMS 사양의 요구 사항을 훨씬 능가하는 성능과 기능을 갖추고 있습니다. 이러한 기능을 사용하여 Message Queue는 24시간 중차대한 작업으로 무수히 많은 메시지를 교환하는 많은 수의 분산 구성 요소로 구성된 시스템과 통합할 수 있습니다. 기능에 대한 요약 설명은 Appendix B, "Message Queue 기능"을 참조하십시오.

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