부록 C HTTP/HTTPS 지원

Message Queue 엔터프라이즈판은 직접 TCP 연결이 아닌 HTTP 또는 보안 HTTP (HTTPS) 전송을 통한 Java 클라이언트와 브로커 간의 통신을 지원합니다. HTTP/HTTPS 지원은 C 클라이언트에는 사용할 수 없습니다.

이 부록에서는 이 지원을 활성화하는 데 사용되는 구조를 설명하고 클라이언트에서 Message Queue 메시징에 HTTP 기반 연결을 사용할 수 있도록 하는 데 필요한 설정 작업에 대해 설명합니다. 이 부록은 다음 내용으로 구성되어 있습니다.

HTTP/HTTPS 지원 구조

Message Queue 메시징은 HTTP/HTTPS 연결 위에서 실행할 수 있습니다. HTTP/HTTPS 연결은 보통 방화벽을 통해서도 허용되기 때문에 이렇게 하면 방화벽으로 클라이언트 응용 프로그램과 브로커를 분리할 수 있습니다.

그림 C-1에서는 HTTP/HTTPS 지원과 관련된 주요 구성 요소를 보여줍니다.

클라이언트쪽에서는 HTTP 또는 HTTPS 전송 드라이버가 Message Queue 메시지를 HTTP 요청으로 캡슐화하고 요청이 정확한 순서로 웹 서버/응용 프로그램 서버에 전송되는지 확인합니다.

클라이언트는 필요한 경우 HTTP 프록시 서버를 사용해서 브로커와 통신할 수 있습니다. 프록시 주소는 클라이언트를 시작할 때 명령줄 옵션을 사용해서 지정합니다. 자세한 내용은 HTTP 프록시 사용을 참조하십시오.

HTTP 또는 HTTPS 터널 서블릿(모두 Message Queue와 함께 제공)이 웹 서버/응용 프로그램 서버에 로드되고 페이로드 메시지를 브로커로 전달하기 전에 클라이언트 HTTP 요청으로부터 추출하는 데 사용됩니다. HTTP/HTTPS 터널 서블릿은 클라이언트에서 이루어진 HTTP 요청에 대한 응답으로 브로커 메시지를 클라이언트에 다시 보내는 작업도 수행합니다. 한 HTTP/HTTPS 터널 서블릿을 사용해서 여러 브로커에 액세스할 수 있습니다.

그림 C-1 HTTP/HTTPS 지원 구조
HTTP 프록시와 HTTP 터널 서블릿이 방화벽을 통해 메시지를 전달하는 방법을 보여주는 다이어그램. 그림은 텍스트에 설명되어 있습니다.

브로커측에서는 httpjms 또는 httpsjms 연결 서비스가 해당 터널 서블릿에서 들어오는 메시지를 분해하고 다중화를 해제합니다.

웹 서버/응용 프로그램 서버가 오류로 다시 시작되면 모든 연결이 복원되며 클라이언트에는 아무 영향도 주지 않습니다. 브로커가 오류로 다시 시작되면 예외가 발생하며 클라이언트는 연결을 다시 설정해야 합니다. 드물기는 하지만, 웹 서버/응용 프로그램 서버와 브로커에 모두 오류가 발생하고 브로커가 다시 시작되지 않은 경우에는 웹 서버/응용 프로그램 서버가 클라이언트 연결을 복원한 후 클라이언트에 알리지 않고 브로커 연결을 계속 기다릴 수 있습니다. 이런 상황을 방지하려면 항상 브로커를 다시 시작해야 합니다.

그림 C-1에서 알 수 있듯이, HTTP와 HTTPS가 지원하는 구조는 서로 매우 비슷합니다. 가장 큰 차이는 HTTPS(httpsjms 연결 서비스)의 경우 터널 서블릿이 클라이언트 응용 프로그램과 브로커 모두에 대해 보안 연결을 갖는다는 점입니다.

브로커에 대한 보안 연결은 Message Queue의 HTTPS 터널 서블릿에 해당하는 SSL 사용 터널 서블릿을 통해 제공되며 연결을 요청하는 모든 브로커에 자체 서명된 인증서를 전달합니다. 인증서는 브로커가 HTTPS 터널 서블릿에 대해 암호화된 연결을 설정할 때 사용합니다. 이 연결이 설정되고 나면 클라이언트 응용 프로그램과 웹 서버/응용 프로그램 서버에서 클라이언트 응용 프로그램과 터널 서블릿 사이의 보안 연결을 처리할 수 있습니다.

HTTP 지원 활성화

다음 절에서는 HTTP 지원을 활성화하기 위해 수행하는 단계를 설명합니다.

▶ HTTP 지원을 활성화하는 방법

단계 1. HTTP 터널 서블릿 배포

HTTP 터널 서블릿을 Sun Java System Web Server 또는 Sun Java System Application Server에 웹 아카이브(.war) 파일로 배포할 수 있습니다.

HTTP 터널 서블릿을 .war 파일로 배포하는 작업은 웹 서버/응용 프로그램 서버에서 제공하는 배포 기법을 사용하여 수행합니다. HTTP 터널 서블릿 .war 파일(imqhttp.war)은 .jar, .war 및 .rar 파일이 들어 있는 디렉토리에 있으며 운영 체제에 따라 다릅니다(부록 A, "플랫폼별 Message Queue 데이터의 위치" 참조).

.war 파일에는 웹 서버/응용 프로그램 서버에서 서블릿을 로드하여 실행하는 데 필요한 기본 구성 정보가 들어 있는 배포 설명자가 포함되어 있습니다. 웹 서버/응용 프로그램 서버에 따라 서블릿 URL의 컨텍스트 루트 부분을 지정해야 하는 경우도 있습니다.

Sun Java System Web Server에 HTTP 터널 서블릿 배포

다음은 Sun Java System Web Server에 배포 시의 참조 지침입니다. 웹 브라우저를 사용하여 서블릿 URL에 액세스함으로써 HTTP 터널 서블릿 배포 성공 여부를 확인할 수 있습니다. 상태 정보를 표시해야 합니다.

▶ HTTP 터널 서블릿을 .war 파일로 배포하는 방법

브라우저 기반 관리 GUI에서 가상 서버 클래스 탭을 선택한 후 클래스 관리를 선택합니다.

해당 가상 서버 클래스 이름(예: defaultClass)을 선택하고 관리 버튼을 누릅니다.

가상 서버 관리를 선택합니다.

해당 가상 서버 이름을 선택하고 관리 버튼을 누릅니다.

웹 응용 프로그램 탭을 선택합니다.

웹 응용 프로그램 배포를 누릅니다.

WAR 파일 위치 및 WAR 파일 경로 필드에서 imqhttp.war 파일을 가리키는 적절한 값을 선택합니다. 이 파일이 있는 디렉토리는 운영 체제에 따라 다릅니다(부록 A, "플랫폼별 Message Queue 데이터의 위치" 참조).

응용 프로그램 URI 필드에 경로를 입력합니다.

응용 프로그램 URI 필드 값은 다음 터널 서블릿 URL의 /contextRoot 부분입니다.

http://hostName:portNumber/contextRoot/tunnel

예를 들어, contextRoot를 imq로 설정한 경우 응용 프로그램 URI 필드는 다음과 같습니다.

/imq

서블릿을 배포할 설치 디렉토리 경로(일반적으로 Sun Java System Web Server 설치 루트 아래)를 입력합니다.

확인을 누릅니다.

웹 서버 인스턴스를 다시 시작합니다.

이제 클라이언트에서 이 URL을 통해 HTTP 연결을 사용하는 메시지 서비스에 연결할 수 있습니다.

서버 액세스 로그 비활성화

서버 액세스 로그를 비활성화할 필요는 없지만 그렇게 하면 성능이 향상됩니다.

▶ 서버 액세스 로그를 비활성화하는 방법

로그 클라이언트 액세스 제어를 사용하여 로깅을 비활성화합니다.

Sun Java System Application Server에 HTTP 터널 서블릿 배포

이 절에서는 HTTP 터널 서블릿을 Sun Java System Application Server에 .war 파일로 배포한 다음 Message Queue 브로커에서 연결을 수신하도록 터널 서블릿을 구성하는 방법에 대해 설명합니다.

배포 도구 사용

▶ Application Server 환경에서 HTTP 터널 서블릿을 배포하는 방법

웹 기반 관리 GUI에서 다음을 선택합니다.

Application Server > 인스턴스 > server1 > 응용 프로그램 > 웹 응용 프로그램

배포 버튼을 누릅니다.

파일 경로: 텍스트 필드에 HTTP 터널 서블릿 .war 파일(imqhttp.war)의 위치를 입력한 다음 확인을 누릅니다.

imqhttp.war 파일의 위치는 운영 체제에 따라 다릅니다(부록 A, "플랫폼별 Message Queue 데이터의 위치" 참조).

컨텍스트 루트 텍스트 필드의 값을 설정한 다음 확인을 누릅니다.

컨텍스트 루트 필드 값은 터널 서블릿 URL의 /contextRoot 부분입니다.

http://hostName:portNumber/contextRoot/tunnel

예를 들어, 컨텍스트 루트 필드를 /imq로 설정할 수 있습니다.

터널 서블릿이 성공적으로 배포되었고 기본적으로 사용되며 다음 위치(이 예의 경우)에 있음을 나타내는 확인 화면이 표시됩니다.

/var/opt/SUNWappserver8/domains/domain1/server1/applications/
j2ee-modules/imqhttp_1

이제 클라이언트에서 이 URL을 통해 HTTP 연결을 사용하는 메시지 서비스에 연결할 수 있습니다.

server.policy 파일 수정

Application Server에서 시행하는 일련의 기본 보안 정책은 수정하지 않으면 HTTP 터널 서블릿이 Message Queue 브로커에서 연결을 수신할 수 없도록 합니다.

응용 프로그램 서버 인스턴스마다 해당 보안 정책이나 규칙이 포함된 파일이 있습니다. 예를 들어, Solaris의 server1 인스턴스의 경우 이 파일의 위치는 다음과 같습니다.

터널 서블릿이 Message Queue 브로커에서 연결을 수신하도록 구성하려면 이 파일에 항목을 추가해야 합니다.

▶ 응용 프로그램 서버의 server.policy 파일을 수정하는 방법

server.policy 파일을 엽니다.

다음 항목을 추가합니다.


grant codeBase
"file:/var/opt/SUNWappserver8/domains/domain1/server1/ applications/j2ee-modules/imqhttp_1/-
{
permission java.net.SocketPermission "*", 'connect,accept,resolve";
};

단계 2. httpjms 연결 서비스 구성

기본적으로 브로커에 대해 HTTP 지원이 활성화되어 있지 않으므로 httpjms 연결 서비스가 활성화되도록 브로커를 재구성해야 합니다. 재구성한 경우 브로커 시작에 설명된 대로 브로커를 시작할 수 있습니다.

▶ httpjms 연결 서비스를 활성화하는 방법

브로커의 인스턴스 구성 파일을 엽니다.

인스턴스 구성 파일은 구성 파일이 연결되어 있는 브로커 인스턴스의 이름(instanceName)으로 식별되는 디렉토리에 저장됩니다(부록 A, "플랫폼별 Message Queue 데이터의 위치" 참조).

�/instances/instanceName/props/config.properties

imq.service.activelist 등록 정보에 httpjms 값을 추가합니다.

imq.service.activelist=jms,admin,httpjms

브로커는 시작할 때 호스트 시스템에서 실행 중인 웹 서버/응용 프로그램 서버와 HTTP 터널 서블릿을 찾습니다. 그러나 원격 터널 서블릿에 액세스하기 위해 servletHost 및 servletPort 연결 서비스 등록 정보를 재구성할 수 있습니다.

또한 성능 향상을 위해 pullPeriod 등록 정보를 재구성할 수도 있습니다. httpjms 연결 서비스 구성 등록 정보에 대한 자세한 설명은 표 C-1을 참조하십시오.

표 C-1 httpjms 연결 서비스 등록 정보
등록 정보	설명
imq.httpjms.http. servletHost	필요한 경우 이 값을 변경하여 HTTP 터널 서블릿을 실행하는 호스트의 이름(호스트 이름 또는 IP 주소)을 지정합니다(원격 호스트이거나 로컬 호스트의 특정 호스트 이름일 수 있음). 기본값: localhost
imq.httpjms.http. servletPort	이 값을 변경하여 브로커가 HTTP 터널 서블릿에 액세스하는 데 사용하는 포트 번호를 지정합니다(웹 서버에서 기본 포트를 변경한 경우 이 등록 정보를 적절히 변경해야 함). 기본값: 7675
imq.httpjms.http. pullPeriod	클라이언트 런타임이 브로커에서 메시지를 가져오기 위해 만든 HTTP 요청 사이의 간격(초)을 지정합니다(이 등록 정보는 브로커에서 설정되고 클라이언트 런타임에 전파됨). 값이 0 또는 음수인 경우 클라이언트는 하나의 HTTP 요청을 항상 보류 상태로 두고 가능한 빨리 메시지를 가져오도록 준비합니다. 클라이언트 수가 많은 경우 웹/응용 프로그램 서버 자원을 많이 사용하여 서버가 응답하지 않을 수 있습니다. 그런 경우 pullPeriod 등록 정보를 양수(초)로 설정해야 합니다. 이 등록 정보는 후속 가져오기 요청을 만들기 전에 클라이언트의 HTTP 전송 드라이버가 대기하는 시간을 설정합니다. 값을 양수로 설정하면 클라이언트가 응답 시간 동안 대기하는 대신 웹/응용 프로그램 서버 자원이 절약됩니다. 기본값: -1
imq.httpjms.http. connectionTimeout	클라이언트 런타임이 HTTP 터널 서블릿의 응답을 기다리는 시간(초)을 지정합니다. 이 시간이 초과되면 예외가 발생합니다(이 등록 정보는 브로커에서 설정되고 클라이언트 런타임에 전파됨). 이 등록 정보는 브로커가 HTTP 터널 서블릿과 통신한 후 연결을 해제할 때까지 기다리는 시간도 지정합니다. 이 경우에는 브로커와 터널 서블릿이 HTTP 서블릿에 액세스 중인 클라이언트가 비정상적으로 종료했는지 여부를 알 수 없으므로 시간 초과가 필요합니다. 기본값: 60

단계 3. HTTP 연결 구성

클라이언트 응용 프로그램에서는 제대로 구성된 연결 팩토리 관리 객체를 사용해서 브로커에 대한 HTTP 연결을 설정해야 합니다. 이 절에서는 HTTP 연결 구성 문제에 대해 논의합니다.

연결 팩토리 구성

HTTP 지원을 활성화하려면 연결 팩토리의 imqAddressList 속성을 HTTP 터널 서블릿 URL로 설정해야 합니다. HTTP 터널 서블릿 URL의 일반 구문은 다음과 같습니다.

여기서 hostName:portNumber는 HTTP 터널 서블릿을 호스트하는 웹 서버/응용 프로그램 서버의 이름과 포트이며, contextRoot는 웹 서버/응용 프로그램 서버에서 터널 서블릿을 배포할 때 설정된 경로입니다.

일반적인 연결 팩토리 속성, 특히 imqAddressList 속성에 대한 자세한 내용은 Java 클라이언트용 Message Queue 개발 안내서를 참조하십시오.

다음 방법 중 하나를 사용하여 연결 팩토리 속성을 설정할 수 있습니다.

연결 팩토리 관리 객체를 만드는 imqobjmgr 명령에 -o 옵션을 사용하거나(연결 팩토리 추가 참조) 관리 콘솔(imqadmin)을 사용하여 연결 팩토리 관리 객체를 만들 때 속성을 설정합니다.

클라이언트를 시작하는 명령에 -D 옵션을 사용합니다(Java 클라이언트용 Message Queue 개발 안내서 참조).

클라이언트 코드에서 프로그래밍 방식으로 연결 팩토리를 만든 후 API 호출을 사용하여 해당 연결 팩토리의 속성을 설정합니다(Java 클라이언트용 Message Queue 개발 안내서 참조).

단일 서블릿을 사용하여 다중 브로커에 액세스

다중 브로커를 실행할 경우 다중 웹 서버/응용 프로그램 서버 및 서블릿 인스턴스를 구성하지 않아도 됩니다. 동시에 실행 중인 브로커 간에 단일 웹 서버/응용 프로그램 서버와 HTTP 터널 서블릿 인스턴스를 공유할 수 있습니다. 다중 브로커 인스턴스가 단일 터널 서블릿을 공유하는 경우 imqAddressList 연결 팩토리 속성을 다음과 같이 구성해야 합니다.

http://hostName:portNumber/contextRoot/tunnel?ServerName=bkrHostName:instanceName

여기서 bkrHostName은 브로커 인스턴스 호스트 이름이고 instanceName은 클라이언트가 액세스할 특정 브로커 인스턴스의 이름입니다.

bkrHostName과 instanceName에 정확한 문자열을 입력했는지 확인하려면 브라우저에서 서블릿 URL에 액세스하여 HTTP 터널 서블릿의 상태 보고서를 생성합니다. 보고서에는 서블릿이 액세스하는 모든 브로커가 나열됩니다.

HTTP 프록시 사용

클라이언트 응용 프로그램을 시작하는 명령에 -D 옵션을 사용하여 이러한 등록 정보를 설정할 수 있습니다.

HTTPS 지원 활성화

다음 절에서는 HTTPS 지원을 활성화하는 단계에 대해 설명합니다. HTTP 지원 활성화와 비슷한 내용에 SSL 인증서 생성 및 액세스에 필요한 단계가 추가되어 있습니다.

▶ HTTPS 지원을 활성화하는 방법

HTTPS 터널 서블릿에 대해 자체 서명된 인증서를 생성합니다.

HTTP 터널 서블릿 .war 파일 배포 설명자를 다음과 같이 수정합니다.

인증서 키 저장소가 있는 위치를 가리킵니다.

인증서 키 저장소 비밀번호를 지정합니다.

HTTP 터널 서블릿을 배포합니다. 다음 서버에 HTTP 터널 서블릿을 배포할 수 있습니다.

Sun Java System Web Server

Sun Java System Application Server

브로커의 httpsjms 연결 서비스를 구성하고 브로커를 시작합니다.

HTTPS 연결을 구성합니다.

단계 1. HTTPS 터널 서블릿에 대해 자체 서명된 인증서 생성

Message Queue의 SSL 지원은 클라이언트가 알려지고 신뢰할 수 있는 서버와 통신한다는 가정 하에 전송 데이터를 보호하기 위한 것입니다. 따라서 자체 서명된 서버 인증서만 사용하여 SSL을 구현합니다. httpsjms 연결 서비스 구조에서 HTTPS 터널 서블릿은 브로커와 응용 프로그램 클라이언트에 대해 서버 역할을 담당합니다.

keytool 유틸리티를 실행하여 터널 서블릿에 대해 자체 서명된 인증서를 생성합니다. 명령 프롬프트에서 다음을 입력합니다.

유틸리티는 필요한 정보를 묻는 메시지를 표시합니다(Unix 시스템에서 키 저장소를 만들 권한을 가지려면 keytool을 수퍼유저(루트)로 실행해야 할 수도 있음).

먼저 keytool은 키 저장소 비밀번호, 일부 조직 정보 및 사용자의 확인을 묻는 메시지를 차례로 표시합니다. 확인이 끝나면 키 쌍을 생성하는 동안 일시 중지됩니다. 그런 다음 특정 키 쌍을 잠글 비밀번호(키 비밀번호)를 묻습니다. 이 프롬프트에 대한 응답으로 Return 키를 눌러야 합니다. 그러면 키 비밀번호가 키 저장소 비밀번호와 동일하게 지정됩니다.


주	입력한 비밀번호를 기억해야 합니다. 나중에 이 비밀번호를 제공해야 터널 서블릿이 키 저장소를 열 수 있습니다.

JDK keytool 유틸리티는 자체 서명된 인증서를 생성하여 keyStoreLocation 인수에서 지정한 위치의 Message Queue 키 저장소 파일에 넣을 수 있습니다.

단계 2. HTTP 터널 서블릿 .war 파일의 설명자 파일 수정


주	HTTPS 터널 서블릿에서 키 저장소를 볼 수 있어야 합니다. keyStoreLocation에 생성된 키 저장소를 HTTPS 터널 서블릿에서 액세스할 수 있는 위치로 이동/복사합니다(단계 3. HTTP 터널 서블릿 배포 참조).

HTTP 터널 서블릿의 .war 파일에는 웹 서버/응용 프로그램 서버에서 서블릿을 로드하여 실행하는 데 필요한 기본 구성 정보가 들어 있는 배포 설명자가 포함되어 있습니다.

하지만 imqhttps.war 파일의 배포 설명자에서는 터널 서블릿에 필요한 키 저장소 파일이 있는 위치를 알 수 없습니다. 따라서 imqhttps.war 파일을 배포하기 전에 터널 서블릿의 배포 설명자(XML 파일)를 편집하여 키 저장소 위치 및 비밀번호를 지정해야 합니다.

▶ HTTPS 터널 서블릿 .war 파일을 수정하는 방법

.war 파일을 임시 디렉토리로 복사합니다.

cp /usr/share/lib/imq/imqhttps.war /tmp(Solaris)

cp /opt/sun/mq/share/lib/imqhttps.war /tmp(Linux)

cp IMQ_HOME/lib/imqhttps.war /tmp(Windows)

임시 디렉토리를 현재 디렉토리로 만듭니다.

$ cd /tmp

.war 파일의 내용을 추출합니다.

$ jar xvf imqhttps.war

.war 파일의 배포 설명자를 나열합니다.

$ ls -l WEB-INF/web.xml

keystoreLocation과 keystorePassword 인수(필요한 경우 servletPort 및 servletHost 인수 포함)에 정확한 값을 제공하도록 web.xml 파일을 편집합니다.

.war 파일의 내용을 다시 어셈블합니다.

$ jar uvf imqhttps.war WEB-INF/web.xml

이제 수정된 imqhttps.war 파일을 사용하여 HTTPS 터널 서블릿을 배포할 수 있습니다 (키 저장소 비밀번호 노출이 우려되는 경우에는 파일 시스템 권한을 사용하여 imqhttps.war 파일에 대한 액세스를 제한할 수 있음).

단계 3. HTTP 터널 서블릿 배포

HTTP 터널 서블릿을 Sun Java System Web Server 또는 Sun Java System Application Server에 웹 아카이브(WAR) 파일로 배포할 수 있습니다.

HTTP 터널 서블릿을 .war 파일로 배포하는 작업은 웹 서버/응용 프로그램 서버에서 제공하는 배포 기법을 사용하여 수행합니다. HTTPS 터널 서블릿 .war 파일(imqhttps.war)은 운영 체제에 따라 다른 디렉토리에 있습니다(부록 A, "플랫폼별 Message Queue 데이터의 위치" 참조).

클라이언트와 브로커 사이에서 종단간 보안 통신이 이루어질 수 있도록 웹 서버에 암호화가 활성화되었는지 확인해야 합니다.

웹 아카이브 파일로 배포

Sun Java System Web Server에서 HTTP 터널 서블릿 배포

이 절에서는 Sun Java System Web Server에서 HTTPS 터널 서블릿을 .war 파일로 배포하는 방법에 대해 설명합니다. 웹 브라우저를 사용하여 서블릿 URL에 액세스함으로써 HTTPS 터널 서블릿 배포 성공 여부를 확인할 수 있습니다. 상태 정보를 표시해야 합니다.

HTTPS 터널 서블릿을 배포하기 전에 웹 서버의 클래스 경로에 JSSE .jar 파일이 포함되어 있는지 확인합니다. 이 작업을 수행하는 가장 간단한 방법은 jsse.jar, jnet.jar 및 jcert.jar 파일을 WebServer_TOPDIR/bin/https/jre/lib/ext로 복사하는 것입니다.

▶ HTTPS 터널 서블릿을 .war 파일로 배포하는 방법

브라우저 기반 관리 GUI에서 가상 서버 클래스 탭을 선택합니다. 클래스 관리를 누릅니다.

해당 가상 서버 클래스 이름(예: defaultClass)을 선택하고 관리 버튼을 누릅니다.

가상 서버 관리를 선택합니다.

해당 가상 서버 이름을 선택하고 관리 버튼을 누릅니다.

웹 응용 프로그램 탭을 선택합니다.

웹 응용 프로그램 배포를 누릅니다.

WAR 파일 위치와 WAR 파일 경로 필드에서 수정된 imqhttps.war 파일(HTTPS 터널 서블릿 .war 파일을 수정하는 방법 참조)을 가리키는 적절한 값을 선택합니다.

응용 프로그램 URI 필드에 경로를 입력합니다.

응용 프로그램 URI 필드 값은 다음 터널 서블릿 URL의 /contextRoot 부분입니다.

https://hostName:portNumber/contextRoot/tunnel

예를 들어, contextRoot를 imq로 설정한 경우 응용 프로그램 URI 필드는 다음과 같습니다.

/imq

서블릿을 배포할 설치 디렉토리 경로(일반적으로 Sun Java System Web Server 설치 루트 아래)를 입력합니다.

확인을 누릅니다.

웹 서버 인스턴스를 다시 시작합니다.

이제 클라이언트에서 이 URL을 통해 보안 HTTPS 연결을 사용하는 메시지 서비스에 연결할 수 있습니다.

서버 액세스 로그 비활성화

서버 액세스 로그를 비활성화할 필요는 없지만 그렇게 하면 성능이 향상됩니다.

▶ 서버 액세스 로그를 비활성화하는 방법

로그 클라이언트 액세스 제어를 사용하여 로깅을 비활성화합니다.

Sun Java System Application Server에 HTTP 터널 서블릿 배포

이 절에서는 Sun Java System Application Server에서 HTTPS 터널 서블릿을 .war 파일로 배포하는 방법에 대해 설명합니다.

배포 도구 사용

▶ Application Server 환경에서 HTTPS 터널 서블릿을 배포하는 방법

웹 기반 관리 GUI에서 다음을 선택합니다.

App Server > 인스턴스 > server1 > 응용 프로그램 > 웹 응용 프로그램

배포 버튼을 누릅니다.

파일 경로: 텍스트 필드에 HTTPS 터널 서블릿 .war 파일(imqhttps.war)의 위치를 입력한 다음 확인을 누릅니다.

imqhttps.war 파일의 위치는 운영 체제에 따라 다릅니다(부록 A, "플랫폼별 Message Queue 데이터의 위치" 참조).

컨텍스트 루트 필드의 값을 설정하고 확인을 누릅니다.

컨텍스트 루트 필드 값은 터널 서블릿 URL의 /contextRoot 부분입니다.

https://hostName:portNumber/contextRoot/tunnel

예를 들어, 컨텍스트 루트 필드를 다음과 같이 설정할 수 있습니다.

/imq

다음 화면에 터널 서블릿이 성공적으로 배포되었고 기본적으로 사용되며 다음 위치 (이 예의 경우)에 있다고 표시됩니다.

/var/opt/SUNWappserver8/domains/domain1/server1/applications/
j2ee-modules/imqhttps_1

이제 클라이언트에서 이 URL을 통해 HTTPS 연결을 사용하는 메시지 서비스에 연결할 수 있습니다.

server.policy 파일 수정

Application Server에서 시행하는 일련의 기본 보안 정책은 수정하지 않으면 HTTPS 터널 서블릿이 Message Queue 브로커에서 연결을 수신할 수 없도록 합니다.

터널 서블릿이 Message Queue 브로커에서 연결을 수신하도록 구성하려면 이 파일에 항목을 추가해야 합니다.

▶ 응용 프로그램 서버의 server.policy 파일을 수정하는 방법

server.policy 파일을 엽니다.

다음 항목을 추가합니다.


grant codeBase
"file:/var/opt/SUNWappserver8/domains/domain1/server1/ applications/j2ee-modules/imqhttps_1/-
{
permission java.net.SocketPermission "*", 'connect,accept,resolve";
};

단계 4. httpsjms 연결 서비스 구성

기본적으로 브로커에 대해 HTTPS 지원이 활성화되어 있지 않으므로 httpsjms 연결 서비스가 활성화되도록 브로커를 재구성해야 합니다. 재구성한 경우 브로커 시작에 설명된 대로 브로커를 시작할 수 있습니다.

▶ httpsjms 연결 서비스를 활성화하는 방법

브로커의 인스턴스 구성 파일을 엽니다.

�/instances/instanceName/props/config.properties

imq.service.activelist 등록 정보에 httpsjms 값을 추가합니다.

imq.service.activelist=jms,admin,httpsjms

브로커는 시작할 때 호스트 시스템에서 실행 중인 웹 서버와 HTTPS 터널 서블릿을 찾습니다. 그러나 원격 터널 서블릿에 액세스하기 위해 servletHost 및 servletPort 연결 서비스 등록 정보를 재구성할 수 있습니다.

또한 성능 향상을 위해 pullPeriod 등록 정보를 재구성할 수도 있습니다. httpsjms 연결 서비스 구성 등록 정보에 대한 자세한 설명은 표 C-2를 참조하십시오.

표 C-2 httpsjms 연결 서비스 등록 정보
등록 정보	설명
imq.httpsjms.https servletHost	필요한 경우 이 값을 변경하여 HTTPS 터널 서블릿을 실행하는 호스트의 이름(호스트 이름 또는 IP 주소)을 지정합니다(원격 호스트이거나 로컬 호스트의 특정 호스트 이름일 수 있음). 기본값: localhost
imq.httpsjms.https servletPort	이 값을 변경하여 브로커가 HTTPS 터널 서블릿에 액세스하는 데 사용하는 포트 번호를 지정합니다(웹 서버에서 기본 포트를 변경한 경우 이 등록 정보를 적절히 변경해야 함). 기본값: 7674
imq.httpsjms.https pullPeriod	브로커에서 메시지를 가져오기 위해 각 클라이언트가 만든 HTTP 요청 사이의 간격(초)을 지정합니다(이 등록 정보는 브로커에서 설정되고 클라이언트 런타임에 전파됨). 값이 0 또는 음수인 경우 클라이언트는 하나의 HTTP 요청을 항상 보류 상태로 두고 가능한 빨리 메시지를 가져오도록 준비합니다. 클라이언트 수가 많은 경우 웹 서버 자원을 많이 사용하여 서버가 응답하지 않을 수 있습니다. 그런 경우 pullPeriod 등록 정보를 양수(초)로 설정해야 합니다. 이 등록 정보는 후속 가져오기 요청을 만들기 전에 클라이언트의 HTTP 전송 드라이버가 대기하는 시간을 설정합니다. 값을 양수로 설정하면 클라이언트가 응답 시간 동안 대기하는 대신 웹 서버 자원이 절약됩니다. 기본값: -1
imq.httpsjms.https connectionTimeout	클라이언트 런타임이 HTTPS 터널 서블릿의 응답을 기다리는 시간(초)을 지정합니다. 이 시간이 초과되면 예외가 발생합니다(이 등록 정보는 브로커에서 설정되고 클라이언트 런타임에 전파됨). 이 등록 정보는 브로커가 HTTPS 터널 서블릿과 통신한 후 연결을 해제할 때까지 기다리는 시간도 지정합니다. 이 경우에는 브로커와 터널 서블릿이 HTTPS 서블릿에 액세스 중인 클라이언트가 비정상적으로 종료했는지 여부를 알 수 없으므로 시간 초과가 필요합니다. 기본값: 60

단계 5. HTTPS 연결 구성

클라이언트 응용 프로그램에서는 제대로 구성된 연결 팩토리 관리 객체를 사용해서 브로커에 대한 HTTPS 연결을 설정해야 합니다.

하지만 클라이언트는 JSSE(Java Secure Socket Extension)에서 제공하는 SSL 라이브러리에도 액세스해야 하며 루트 인증서도 있어야 합니다. SSL 라이브러리는 JDK 1.4와 함께 제공됩니다. 이전 버전의 JDK가 있는 경우에는 JSSE 구성을 참조하십시오. 그렇지 않으면 루트 인증서 가져오기로 이동하십시오.

이 문제를 해결하고 나면 계속해서 HTTPS 연결을 구성할 수 있습니다.

JSSE 구성

▶ JSSE를 구성하는 방법

JSSE .jar 파일을 JRE_HOME/lib/ext 디렉토리로 복사합니다.

jsse.jar, jnet.jar, jcert.jar

JSSE 보안 공급자를 정적으로 추가합니다. 이 작업은

security.provider.n=com.sun.net.ssl.internal.ssl.Provider

를 JRE_HOME/lib/security/java.security 파일에 추가하여 수행할 수 있습니다.
(여기서 n은 보안 공급자 패키지에서 다음으로 사용할 수 있는 우선 순위 번호입니다.)

JDK1.4를 사용하지 않는 경우에는 클라이언트 응용 프로그램을 시작하는 명령에 -D 옵션을 사용해서 다음 JSSE 등록 정보를 설정해야 합니다.

java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol

루트 인증서 가져오기

웹 서버 인증서에 서명한 CA의 루트 인증서가 기본적으로 트러스트 데이터베이스에 있지 않거나 독자적인 웹 서버/응용 프로그램 서버 인증서를 사용하는 경우에는 인증서를 트러스트 데이터베이스에 추가해야 합니다. 여기에 해당되면 다음 지침에 따르고, 그렇지 않으면 연결 팩토리 구성으로 이동합니다.

인증서가 certFile에 저장되어 있고 trustStoreFile이 키 저장소라면 다음 명령을 실행합니다.

JRE_HOME/bin/keytool -import -trustcacerts
-alias aliasForCertificate -file certFile
-keystore trustStoreFile

클라이언트 응용 프로그램을 시작하는 명령에 -D 옵션을 사용해서 다음과 같은 JSSE 등록 정보도 지정해야 합니다.

연결 팩토리 구성

HTTPS 지원을 활성화하려면 연결 팩토리의 imqAddressList 속성을 HTTPS 터널 서블릿 URL로 설정해야 합니다. HTTPS 터널 서블릿 URL의 일반 구문은 다음과 같습니다.

여기서 hostName:portNumber는 HTTPS 터널 서블릿을 호스트하는 웹 서버의 이름과 포트이며, contextRoot는 웹 서버에서 터널 서블릿을 배포할 때 설정된 경로입니다.

일반적인 연결 팩토리 속성, 특히 imqAddressList 속성에 대한 자세한 내용은 Java 클라이언트용 Message Queue 개발 안내서를 참조하십시오.

다음 방법 중 하나를 사용하여 연결 팩토리 속성을 설정할 수 있습니다.

클라이언트 응용 프로그램을 시작하는 명령에 -D 옵션을 사용합니다(Java 클라이언트용 Message Queue 개발 안내서 참조).

클라이언트 응용 프로그램 코드에서 프로그래밍 방식으로 연결 팩토리를 만든 후 API 호출을 사용하여 해당 연결 팩토리의 속성을 설정합니다(Java 클라이언트용 Message Queue 개발 안내서 참조).

단일 서블릿을 사용하여 다중 브로커에 액세스

다중 브로커를 실행할 경우 다중 웹 서버 및 서블릿 인스턴스를 구성하지 않아도 됩니다. 동시에 실행 중인 브로커 간에 단일 웹 서버와 HTTPS 터널 서블릿 인스턴스를 공유할 수 있습니다. 다중 브로커 인스턴스가 단일 터널 서블릿을 공유하는 경우 imqAddressList 연결 팩토리 속성을 다음과 같이 구성해야 합니다.

https://hostName:portNumber/contextRoot/tunnel?ServerName=bkrHostName:instanceName

여기서 bkrHostName은 브로커 인스턴스 호스트 이름이고 instanceName은 클라이언트가 액세스할 특정 브로커 인스턴스의 이름입니다.

bkrhostName과 instanceName에 정확한 문자열을 입력했는지 확인하려면 브라우저에서 서블릿 URL에 액세스하여 HTTPS 터널 서블릿의 상태 보고서를 생성합니다. 보고서에는 서블릿이 액세스하는 모든 브로커가 나열됩니다.

HTTPS tunnel servlet ready.

Servlet Start Time : Thu May 30 01:08:18 PDT 2002

Accepting secured connections from brokers on port : 7674

Total available brokers = 2

Broker List :

jpgserv:broker2

cochin:broker1

HTTP 프록시 사용

클라이언트 응용 프로그램을 시작하는 명령에 -D 옵션을 사용하여 이러한 등록 정보를 설정할 수 있습니다.

문제 해결

이 절에서는 HTTP 또는 HTTPS 연결에서 발생할 수 있는 문제와 문제 해결 방법에 대해 설명합니다.

서버 또는 브로커 오류

웹 서버가 오류로 다시 시작되면 모든 연결이 복원되며 클라이언트에는 아무 영향도 주지 않습니다. 그러나, 브로커가 오류로 다시 시작되면 예외가 발생하며 클라이언트는 연결을 다시 설정해야 합니다.

웹 서버와 브로커 모두에 오류가 발생하여 브로커가 다시 시작되지 않는 경우 웹 서버는 클라이언트에게 알리지 않고 클라이언트 연결을 복원한 후 브로커가 연결될 때까지 기다립니다. 이런 상황을 방지하려면 브로커가 다시 시작되었는지 항상 확인하십시오.

터널 서블릿을 통한 클라이언트 연결 오류

HTTPS 클라이언트가 터널 서블릿을 통해 브로커에 연결되지 않는 경우 다음을 수행합니다.

서비스가 다시 시작되면 HTTPS 클라이언트가 터널 서블릿을 통해 브로커에 연결할 수 있어야 합니다.

이전 목차 색인 다음
Sun Java System Message Queue 3 2005Q4 관리 설명서