JEUS

Transcription

1 JEUS Web Container 안내서 JEUS v6.0 Fix#8 Copyright 2011 TmaxSoft Co., Ltd. All Rights Reserved.

2 Copyright Notice Copyright 2011 TmaxSoft Co., Ltd. All Rights Reserved. 대한민국경기도성남시분당구서현동 우 ) Restricted Rights Legend All TmaxSoft Software (JEUS ) and documents are protected by copyright laws and the Protection Act of Com puter Programs, and international convention. TmaxSoft software and documents are made available under the terms of the TmaxSoft License Agreement and may only be used or copied in accordance with the terms of this agreement. No part of this document may be transmitted, copied, deployed, or reproduced in any form or by any means, electronic, mechanical, or optical, without the prior written consent of TmaxSoft Co., Ltd. 이소프트웨어 (JEUS ) 사용설명서의내용과프로그램은저작권법, 컴퓨터프로그램보호법및국제조약에의해서보호받고있습니다. 사용설명서의내용과여기에설명된프로그램은 TmaxSoft Co., Ltd. 와의사용권계약하에서만사용이가능하며, 사용권계약을준수하는경우에만사용또는복제할수있습니다. 이사용설명서의전부또는일부분을 TmaxSoft의사전서면동의없이전자, 기계, 녹음등의수단을사용하여전송, 복제, 배포, 2차적저작물작성등의행위를하여서는안됩니다. Trademarks JEUS is registered trademark of TmaxSoft Co., Ltd. Other products, titles or services may be registered trademarks of their respective companies. JEUS 는 TmaxSoft Co., Ltd. 의등록상표입니다. 기타모든제품들과회사이름은각각해당소유주의상표로서참조용으로만사용됩니다. Open Source Software Notice This product includes open source software developed and/or licensed by "OpenSSL", "RSA Data Security, Inc.", "Apache Foundation", and "Jean-loup Gailly and Mark Adler". Information about the aforementioned and the related open source software can be found in the "${INSTALL_PATH}/license/oss_licenses" directory. 본제품은 OpenSSL, RSA Data Security, Inc., Apache Foundation 및 Jean-loup Gailly와 Mark Adler 에의해개발또는라이선스된오픈소스소프트웨어를포함합니다. 관련상세정보는제품의디렉터리 ${IN STALL_PATH}/license/oss_licenses 에기재된사항을참고해주십시오. 안내서정보안내서제목 : JEUS Web Container 안내서발행일 : 소프트웨어버전 : JEUS v6.0 Fix #8 안내서버전 : v2.1.3

3 내용목차 안내서에대하여... xiii 제1장 JEUS 웹 개요 JEUS 웹구조와주요기능 웹컨테이너와 JEUS 시스템 웹컨테이너의기본컴포넌트 JEUS Web 디렉터리구조 JEUS 웹툴 JEUS Web 환경설정 환경변수 XML 설정파일... 8 제2장 웹컨테이너 개요 웹컨테이너주요기능과구조 주요기능 디렉터리구조 웹컨테이너설정 개요 기본설정 자동모니터링 stdout과 stderr Redirection Context Group Database Connection Pool Session Logging Shutdown Timeout Logging 설정 공통설정항목 Access log 관련설정항목 User log 관련설정항목 웹컨테이너제어와모니터링 웹컨테이너제어 웹컨테이너모니터링 제3장 Context Group 개요 Context Group 주요기능과구조 주요기능 디렉터리구조 Context Group 설정 JEUS iii

4 기본설정 인코딩설정 JSP 엔진설정 Logging 설정 Session 설정 Response Header 설정 Context Group 모니터링 Context Group 튜닝 제4장 웹서버연결과클러스터링 개요 웹서버연결 리스너 Worker Thread와 Worker Thread Pool Thread Pool의 Active-Management와상태통보 여러개의웹컨테이너와웹서버클러스터링 리스너설정 HTTP, TCP, HTTPS 리스너설정 WebtoB 리스너설정 AJP13 리스너설정 Tmax 리스너설정 자동 Thread Pool 관리설정 (Thread 상태통보 ) 리스너연동과클러스터링을위한웹서버설정 Apache 웹서버설정과클러스터링 IIS 웹서버설정과클러스터링 SunOne(Iplanet) 웹서버설정과클러스터링 WebtoB 웹서버설정과클러스터링 TCP 리스너사용 맞춤통신프로토콜정의 Dispatcher 설정클래스구현 TCP Handler 구현 맞춤프로토콜코드를위한 TCP 리스너설정 TCP 클라이언트구현 TCP 클라이언트컴파일과실행 보안 (SSL) 리스너사용 개요 디렉터리구조 보안리스너설정 SSL Keystore 설정 SSL Truststore 설정 보안리스너속성설정 보안리스너시작하기 보안리스너에연결하기 iv JEUS Web Container 안내서

5 4.7. 리스너튜닝 제5장 Session Tracking 개요 Session Tracking의주요기능 기본기능 클러스터환경에서 Session Tracking Session Routing(Sticky Session) Session Server 혼합모드 분산 Session Server URL Rewriting과 Cookie Shared Session 데이터 Session Tracking 설정 중앙 Session Server 설정 분산 Session Server 설정 Session Tracking 튜닝 제6장 Web Context( 웹애플리케이션 ) 개요 Web Context의기본개념과구조 기본구조 WAR 파일구조 디렉터리구조 Web Context 등록 Context 디렉터리생성 Deployment Descriptor 파일설정 Shared Library에대한레퍼런스추가 하위호환성을위한 Context 레벨의추가옵션설정 보안 Role 매핑 Symbolic 레퍼런스매핑 Context 등록 배치컴파일러를사용한 JSP 프리컴파일 등록확인 Web Context 요청 Web Context 모니터링 Web Context 튜닝 제7장 가상호스트 개요 가상호스트의기본개념 기본개념 기본가상호스트 ServletContext 객체와가상호스트에대한주의사항 가상호스트설정 JEUS v

6 도메인이름등록 WEBMain.xml에가상호스트설정 가상호스트를통한 Context 요청 URL 매칭에관한기본규칙 URL 매칭의예 제8장 JEUS WebCache 개요 JSP Caching 기본내용 <cache> 태그 jeus:cache 사용예 flush 기능사용 refresh 기능사용 HTTP Response Caching 필터설정 제9장 Reverse Proxy 개요 적용예시 사용방법 Proxy 서버설정 Context-path 설정 Proxy Filter 설정 Deploy 설정예 제10장 따라하기 용어해설 색인 vi JEUS Web Container 안내서

7 그림목차 [ 그림 1.1] 웹컨테이너와 JEUS 시스템... 2 [ 그림 1.2] 웹컨테이너의기본컴포넌트... 4 [ 그림 1.3] JEUS Web 모듈에관련된기본디렉터리구조... 5 [ 그림 2.1] 웹컨테이너구조... 9 [ 그림 2.2] JEUS 웹컨테이너관련디렉터리 [ 그림 3.1] 웹컨테이너에연관된 Context Group [ 그림 3.2] Context Group의상세모습과그하위컴포넌트들 [ 그림 3.3] Context Group 디렉터리구조 [ 그림 4.1] JEUS 웹컨테이너중웹서버연결부분컴포넌트 [ 그림 4.2] 웹컨테이너의웹서버와클라이언트리스너 [ 그림 4.3] 2개의웹서버가 2개의웹컨테이너에각각연결되어있는작은클러스터 [ 그림 4.4] 2개의 WebtoB 웹서버가 2개의웹컨테이너와연결된경우 [ 그림 4.5] 2개의 WebtoB 리스너가 1개의 WebtoB에연결된경우 [ 그림 4.6] 복잡한 WebtoB 웹서버구성 [ 그림 4.7] 보안리스너의초기디렉터리 [ 그림 4.8] Internet Explorer에서의인증서보안경고창 [ 그림 4.9] 보안된 SSL 연결 [ 그림 5.1] JEUS 웹컨테이너의구조중 Session에관련된부분들 [ 그림 5.2] 웹컨테이너가 Session Cookie를발급하는과정 [ 그림 5.3] Session ID Cookie로웹컨테이너에두번째요청을보내는과정 [ 그림 5.4] Session ID Cookie를이용하여 2개의웹컨테이너와 Session을시작하는경우 [ 그림 5.5] Session Routing이없는경우클라이언트 Session 삭제 [ 그림 5.6] Session Cookie에추가의웹컨테이너 ID 부여 [ 그림 5.7] Session Routing의작동 [ 그림 5.8] 장애가발생한웹컨테이너의문제 [ 그림 5.9] Session Server가사용될경우클라이언트의첫 HTTP 요청처리 [ 그림 5.10] Session 데이터의요청처리 [ 그림 6.1] JEUS 웹컨테이너에 context/web application [ 그림 6.2] WAR 파일구조 [ 그림 6.3] Web Context 디렉터리의구조 [ 그림 6.4] 웹브라우저에서 Servlet 요청하기 [ 그림 6.5] JEUS 웹컨테이너에의해생성되는기본오류페이지 [ 그림 7.1] JEUS 웹컨테이너의가상호스트컴포넌트 [ 그림 7.2] 가상호스트의기본적인개념 [ 그림 7.3] Context Group과가상호스트, Context 간의유효한관계의예 [ 그림 7.4] 웹컨테이너에서 DNS 이름으로같은경로를가진 Context 사용 [ 그림 8.1] 엔트리캐싱에사용되는자료구조 JEUS vii

8

9 표목차 [ 표 1.1] JEUS Web 모듈환경변수... 7 JEUS ix

10

11 예목차 [ 예 2.1] 웹컨테이너기본설정 : <<JEUSMain.xml>> [ 예 2.2] 자동모니터링설정 : <<WEBMain.xml>> [ 예 2.3] stdout과 stderr redirection 설정 : <<WEBMain.xml>> [ 예 2.4] Context Group 설정 : <<WEBMain.xml>> [ 예 2.5] Session 설정 : <<WEBMain.xml>> [ 예 2.6] 웹컨테이너 Logging 설정 : <<WEBMain.xml>> [ 예 2.7] <access-log> 에필터등록 : <<WEBMain.xml>> [ 예 3.1] Context Group 설정 : <<WEBMain.xml>> [ 예 3.2] Context Group 기본설정 : <<WEBMain.xml>> [ 예 3.3] Context Group 인코딩설정 : <<WEBMain.xml>> [ 예 3.4] JSP 엔진설정 : <<WEBMain.xml>> [ 예 3.5] Context Group 레벨에서 Session 설정 : <<WEBMain.xml>> [ 예 3.6] Response Header 설정 : <<WEBMain.xml>> [ 예 4.1] 리스너설정 : <<WEBMain.xml>> [ 예 4.2] HTTP, TCP, HTTPS 리스너설정 : <<WEBMain.xml>> [ 예 4.3] WebtoB 리스너설정 : <<WEBMain.xml>> [ 예 4.4] AJP13 리스너설정 : <<WEBMain.xml>> [ 예 4.5] Tmax 리스너설정 : <<WEBMain.xml>> [ 예 4.6] 자동 Thread Pool 관리설정 : <<WEBMain.xml>> [ 예 4.7] Apache 웹서버설정 : <<WEBMain.xml>> [ 예 4.8] AJP13 프로토콜을사용 : <<workers.properties>> [ 예 4.9] <<httpd.conf>> [ 예 4.10] <<uriworkermap.properties>> [ 예 4.11] <<magnus.conf>> [ 예 4.12] <<magnus.conf>> [ 예 4.13] 웹컨테이너 A : <<WEBMain.xml>> [ 예 4.14] 웹컨테이너 B : <<WEBMain.xml>> [ 예 4.15] http.m of WebtoB 웹서버 A (IP address ) [ 예 4.16] <<SampleConfig.java>> [ 예 4.17] <<SampleServlet.java>> [ 예 4.18] <<web.xml>> [ 예 4.19] <<WEBMain.xml>> [ 예 4.20] <<JEUSMain.xml>> [ 예 4.21] <<jeus-web-dd.xml>> [ 예 4.22] <<Client.java>> [ 예 4.23] JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name>\WEBMain.xml. 100 [ 예 4.24] JEUS_HOME\config\<node-name>\JEUSMain.xml [ 예 4.25] JEUS_HOME\webhome\app_home\webapps\MyContext\WEB-INF\jeus-web-dd.xml [ 예 4.26] JEUS_HOME\webhome\app_home\webapps\MyContext\WEB-INF\web.xml [ 예 4.27] JEUS_HOME\webhome\app_home\webapps\MyContext\hello.html JEUS xi

12 [ 예 4.28] 보안리스너설정 : <<WEBMain.xml>> [ 예 4.29] <<JEUS_HOME\config\<node-name>\JEUSMain.xml>> [ 예 5.1] Session Tracking 설정 : <<WEBMain.xml>> [ 예 5.2] 노드클러스터링을하지않은상태에서중앙 Session Server 사용 : <<WEBMain.xml>> [ 예 5.3] <<vhost.properties>> [ 예 6.1] Web Context 설정파일 : <<jeus-web-dd.xml>> [ 예 6.2] Shared Library 레퍼런스추가 : <<libraries.xml>> [ 예 6.3] 보안 Role 매핑 : <<web.xml>> [ 예 6.4] 보안 Role 매핑 : <<jeus-web-dd.xml>> [ 예 6.5] Symbolc 레퍼런스매핑 : <<web.xml>> [ 예 6.6] Symbolc 레퍼런스매핑 : <<jeus-web-dd.xml>> [ 예 6.7] Context 등록 : <<JEUSMain.xml>> [ 예 7.1] 가상호스트설정 : <<WEBMain.xml>> [ 예 7.2] 가상호스트의설정 : <<WEBMain.xml>> [ 예 7.3] 가상호스트의설정 : <<JEUSMain.xml>> [ 예 7.4] vhost1ctx1 : <<jeus-web-dd.xml>> [ 예 7.5] vhost1ctx2 : <<jeus-web-dd.xml>> [ 예 7.6] vhost2ctx1 : <<jeus-web-dd.xml>> [ 예 7.7] vhost2ctx2 :<<jeus-web-dd.xml>> [ 예 7.8] default1 : <<jeus-web-dd.xml>> [ 예 7.9] default2 :<<jeus-web-dd.xml>> [ 예 7.10] default3 : <<jeus-web-dd.xml>> [ 예 8.1] <cache> 태그설정 : <<jeuscache.tld>> [ 예 8.2] <<cache.jsp>> [ 예 8.3] <<main.jsp>> [ 예 8.4] 필터설정 : <<web.xml>> [ 예 9.1] <<proxy-config.dtd>> [ 예 10.1] <<JEUSMain.xml>> [ 예 10.2] <<WEBMain.xml>> xii JEUS Web Container 안내서

13 안내서에대하여 안내서의대상 본안내서는 JEUS 웹컨테이너의사용법, 웹컨테이너를구성하는요소들의개념및컨트롤및모니터링방법들에대해서설명하는안내서로 Java EE Web 모듈들을디플로이하고관리하는시스템관리자와개발자를대상으로한다. Sun Microsystems에서제정한 Servlet 2.5와 JSP 2.1 스펙은, 간단한개인방문록에서부터수백만사용자가사용하는웹사이트나완벽한보안을보장하는 e-commerce 웹사이트를개발할수있는표준을제공하고있다. TmaxSoft JEUS의웹컨테이너는 Servlet, JSP 스펙을효율적이고유연하게구현하였다. 본안내서에서는 JEUS 웹컨테이너의사용법, 웹컨테이너를구성하는요소들의개념, 컨트롤및모니터링방법들에대해서설명한다. 안내서의전제조건 본안내서를원활하게이해하기위해서는다음과같은사항을미리알고있어야한다. Java EE, Servlet, JSP에대한기본적인이해 Servlet 디플로이와패키징에관련된실무적인지식 JEUS의기본구조이해 참고 JEUS Web 기술에대한더자세한정보가필요하다면 "JEUS Server 안내서 ", 필요에따라 "JEUS Web Service 안내서 " 를참고한다. 안내서의제한조건 본안내서에서는 JEUS 웹컨테이너에관련된사항들에대해서만설명하고 Java EE 표준에대한사항들 은언급하지않는다. 참고 Java EE 와관련된내용은 Java EE 5 스펙, Servlet 2.5 스펙 JSP 2.1 스펙이나 cle.com/technetwork/java/index.html 을참고한다. 안내서에대하여 xiii

14 안내서구성 본안내서는총 10개의장으로구성되어있다. 제1장 JEUS 웹 JEUS 웹모듈에대한가장상위의컴포넌트인 JEUS 웹컨테이너에대한기본개념과 Web 모듈을관리할수있는툴과환경설정을위한기본정보를설명한다. 제2장웹컨테이너 JEUS 웹컨테이너의하위모듈과주요기능, 기본적인설정방법에대해서설명한다. 제3장 Context Group Context Group에대해상세하게설명한다. 제4장웹서버연결과클러스터링 웹서버를설정할때알아야할사항들과자체적으로가지고있는웹서버를최대한이용하는방법에대하여설명한다. 제5장 Session Tracking Session Tracking의주요기능과설정방법, 튜닝에대해서설명한다. 제6장 Web Context( 웹애플리케이션 ) JEUS 웹컨테이너내의 Java EE 웹모듈 (Web Application, Context) 을조립, 등록, 모니터링하는모든방법에대하여설명한다. 제7장가상호스트 가상호스트에대한기본개념, 기본규칙과구조, 기본가상호스트의개념등에대해설명한다. 제8장 JEUS WebCache 웹애플리케이션의성능향상을위한 JEUS WebCache를적용하는방법을설명한다. 제9장 Reverse Proxy 웹애플리케이션의성능향상을위한 Reverse Proxy 개념및사용법에대한설명한다. 제10장따라하기 JEUS를간단하게체험해볼수있도록예제를설명한다. xiv JEUS Web Container 안내서

15 안내서규약 표기 <<AaBbCc123>> <Ctrl>+C [Button] 진하게 " "( 따옴표 ) ' 입력항목 ' 하이퍼링크 > 참고주의 [ 그림 1.1] [ 표 1.1] AaBbCc123 의미프로그램소스코드의파일명 Ctrl과 C를동시에누름 GUI의버튼또는메뉴이름강조다른관련안내서또는안내서내의다른장및절언급화면 UI에서입력항목에대한설명메일계정, 웹사이트메뉴의진행순서하위디렉터리또는파일있음하위디렉터리또는파일없음참고또는주의사항주의할사항그림이름표이름 Java 코드, XML 문서 [ command argument ] < xyz > 옵션파라미터 < 와 > 사이의내용이실제값으로변경됨선택사항. 예 ) A B: A나 B 중하나파라미터등이반복되어서나옴 안내서에대하여 xv

16 시스템사용환경 본안내서는모든예제와환경구성을 Microsoft Windows 의스타일을따랐다. UNIX와같은다른환경에서작업하는사람은몇가지사항만고려하면별무리없이사용할수있다. 대표적인것이구분자인데, Windows 스타일인 \ 를 UNIX 스타일인 / 로바꿔서사용하면무리가없다. 이외에환경변수도 UNIX 스타일로변경해서사용하면된다. 그러나 Java 표준을고려해서문서를작성했기때문에, 대부분의내용은동일하게적용된다. 관련안내서 안내서 JEUS Server 안내서 JEUS Web Service 안내서 JEUS WebAdmin 안내서 JEUS Reference Book 설명 JEUS 시스템과서버의개요와시스템관리를위한안내서이다. JEUS 내의웹서비스에대해기술한안내서이다. JEUS의웹관리툴인 WebAdmin을사용한 JEUS 의설정및제어, 모니터링, 클러스터링, 리소스설정및관리에대해기술한안내서이다. JEUS를사용할때도움이되는 Reference를기술한안내서이다. 참고자료 Java EE 5 스펙 Servlet 2.5 스펙 JSP 2.1 스펙 JEUS_HOME\docs\reference\schema\index.html에서 WEBMain.xml XML Reference 웹컨테이너의 WEBMain.xml 설정파일에대해자세히설명한다. JEUS_HOME\docs\reference\schema\index.html에서 jeus-web-dd.xml XML Reference JEUS Context( 웹애플리케이션 ) Deployment Descriptor에대해자세히설명한다. JEUS_HOME\docs\api\jeusapi\index.html에서 Webcontainer Tcp Listener API Reference TCP 리스너를사용한통신프로토콜을구현하기위한 API( 제4장웹서버연결과클러스터링 에설명됨 ) 에대해설명한다. xvi JEUS Web Container 안내서

17 연락처 Korea TmaxSoft Co., Ltd 272-6, Seohyeon-dong, Bundang-gu, Seongnam-si, Gyeonggi-do, South Korea Tel: Fax: Web (Korean): 기술지원 : USA TmaxSoft, Inc. 560 Sylvan Avenue Englewood Cliffs, NJ U.S.A Tel: Fax: info@tmaxsoft.com Web (English): Japan TmaxSoft Japan Co., Ltd. 5F Sanko Bldg, Mita, Minato-Ku, Tokyo, Japan Tel: Fax: info@tmaxsoft.co.jp Web (Japanese): 안내서에대하여 xvii

18 China TmaxSoft China Co., Ltd. Beijing Silver Tower, RM 1508, 2# North Rd Dong San Huan, Chaoyang District, Beijing, China, China Tel: ~8 Fax: Web (Chinese): xviii JEUS Web Container 안내서

19 제 1 장 JEUS 웹 본장에서는 JEUS 웹모듈에대한가장상위의컴포넌트인 JEUS 웹컨테이너에대한기본개념과웹모 듈을관리할수있는툴과환경설정을위한기본정보를설명한다 개요 JEUS 웹모듈은복잡하지만 JEUS 시스템중에서실용성있는컴포넌트중의하나이다. 이모듈은사용자에게다이내믹하고고성능이며안정적인 Java 기반의웹콘텐츠를제공하기위해만들어진 JSP, Servlet, 정적 HTML과같은수십개의하위컴포넌트들로구성되어있다. 본장의나머지부분에서는웹모듈의주요컴포넌트들에대하여살펴보고어떻게이들이연계되어있는지알아본다. 이후장에서는운영환경에서어떻게이하위컴포넌트들을설정하고제어하며모니터링하는지에대하여기술적으로상세히설명한다 JEUS 웹구조와주요기능 JEUS 웹모듈관련컴포넌트중가장기본적이면서도최상위레벨의컴포넌트가 JEUS 웹컨테이너 ( 이하웹컨테이너 ) 이다. 웹컨테이너는 Java EE 5, Servlet 2.5, JSP 2.1을준수하고 Servlet과 JSP뿐만아니라 HTML과같은정적내용까지도효과적으로수행할수있다. 참고 JEUS 시스템의설정파일들과툴에서는웹컨테이너 (Web Container) 를웹엔진 (Web Engine) 이라 고부르기도한다 웹컨테이너와 JEUS 시스템 다음은 JEUS 시스템구조체내에서웹컨테이너가어떻게연관되어있는지보여주고있다. 컴포넌트들은웹컨테이너들의외부에존재하고웹애플리케이션과웹컨테이너를운영하기위한환경과기본인프라를제공한다. 제 1 장 JEUS 웹 1

20 [ 그림 1.1] 웹컨테이너와 JEUS 시스템 Client Layer Web/Internet Layer JEUS/WAS Layer EIS Layer HTML Browser HTTP Node JEUS Manager Databa se Applet HTTP/ RMI JNDI Service Security Service TP Monitor Client JNLP Client JNLP Load balancer/ Web Server Other Services Engine Container Directory Server Java Corba Application RMI/II OP Servlet/JSP Engine EJB Engine JMS Engine Other ORB Legacy EIS Java Application RMI WS Engine Other Services Other JEUS Nodes 주요컴포넌트들은다음과같다. 클라이언트 JEUS 시스템에접근하는객체이고웹컨테이너의서비스를요청한다. 웹컴포넌트를접근한다면이클라이언트는사용자에의해조작되는 HTTP 기반의웹브라우저가된다. 부하분산기 (Load Balancer) 클라이언트의 HTTP 요청을웹서버간에나누어전달하여일정한요청수가시스템에전달될수있도록한다. 예를들어, WebtoB 서버가부하분산기로사용될수있다. 자세한내용은 제4장웹서버연결과클러스터링 을참고한다. Web Server 클라이언트의 HTTP 요청을받아필요한경우에 JEUS의웹컨테이너에전달한다. 자세한내용은 제4 장웹서버연결과클러스터링 을참고한다. JEUS 관리자와노드웹컨테이너가동작하는환경을제공한다. 성능과안정성을극대화하기위해서여러개의노드를클러스터링으로묶기도한다. 자세한내용은 "JEUS Server 안내서 " 를참고한다. Web Container 그림에서는 Servlet Engine 으로표기된웹서버나 HTTP 클라이언트로부터서비스요청을받고웹애플리케이션을실행시켜궁극적으로는 HTML 응답페이지를통해응답을준다. 자세한내용은 제2장웹컨테이너 를참고한다. 2 JEUS Web Container 안내서

21 Session Server 분산된환경에서클라이언트의 Session을관리하고이 Session 데이터가모든웹컨테이너에서사용되도록한다. 자세한내용은 제5장 Session Tracking 을참고한다. JNDI Naming Server Servlet과 JSP와같은웹애플리케이션이시스템내부의객체나리소스를접근할수있도록한다. EJB 나 Data Source가그예라고할수있다. 자세한내용은 "JEUS Server 안내서 " 의 JNDI 부분을참고한다. EJB와 JMS Engine 웹애플리케이션에 EJB와 JMS 서비스를제공한다. 이엔진들은 JNDI Naming Server를통하여접근된다. Security Server 웹애플리케이션들에게보안정책을적용시킨다. 자세한내용은 "JEUS Server 안내서 " 의보안부분을참고한다. TX ( 트랜잭션 ) 관리자트랜잭션을관리한다. 자세한내용은 "JEUS Server 안내서 " 의 JTS 부분을참고한다. 데이터베이스많은양의데이터를저장하는, 가장일반적인방법이다. Tmax Server TP 모니터링서비스를제공한다. Tmax 서버는 JEUSMain.xml에설정된 WebT Connection Pool을통해접근된다. 그림에서는보이지않고자세한내용은 Tmax 제품의 "WebT User Guide" 를참고한다. 제 1 장 JEUS 웹 3

22 웹컨테이너의기본컴포넌트 지금까지웹컨테이너가 JEUS 시스템내부의다른컴포넌트들과어떻게연계되는지살펴보았고, 지금부 터는각각의컴포넌트들을구성하며웹컨테이너자체에포함된컴포넌트들에대해자세히설명한다. 물리적으로웹컨테이너는다음의컴포넌트들로구성되어있다. [ 그림 1.2] 웹컨테이너의기본컴포넌트 JEUS Web Container Client A Web Server A Context Group A Web server connection/list ener Virtual Host A Misc. context group settings Default Virtual Host Monitoring thread Context/Web app A Context/Web app B Misc. container settings Client B Client C Web Server B Context Group B Web server connection/list ener Virtual Host B Context/Web app C Misc. context group settings Default Virtual Host Context/Web app D Session handling settings Session Server 주요컴포넌트들은다음과같다. JEUS Web Container 자체는 Java EE 기반의웹컨테이너이다. 제2장웹컨테이너 에이컴포넌트에대하여자세하게설명되어있다. Monitoring Thread 웹컨테이너의다른컴포넌트들을감시하는역할을한다. Web Server connections 외부의웹서버 (WebtoB와 Apache) 와컨테이너가연결되기위한컴포넌트이다. 웹서버 Connection은여러개의웹서버와웹컨테이너들이서로연결되어성능과안정성을향상시킨커다란클러스터링으로구성되도록한다. 이에대한내용은 제4장웹서버연결과클러스터링 을참고한다. 여기서중요한점은웹서버 Connectivity가 Context Group 레벨에서설정된다는것이다. Session handling 분산환경에서만사용되고, Session Routing 기술이나 Session Server를사용하거나, 또는두기술을모두적용시켜활용가능하다. 자세한내용은 제5장 Session Tracking 을참고한다. 4 JEUS Web Container 안내서

23 Context group JEUS 웹컨테이너에포함된것이다. 이것은여러개의 Context들과가상호스트들을관리가능한단위로묶고, 이들에게운영환경을제공한다. 자세한내용은 제3장 Context Group 을참고한다. 가상호스트특정한 Domain Name을호출했을때, 해당 Context에보다강력한제어능력을주기위해만들어졌다. Context는가상호스트내에명시적으로설정될수도있고, Context Group 바로아래에묵시적인기본가상호스트로도설정될수있다. 자세한내용은 제7장가상호스트 를참고한다. Context( 또는웹애플리케이션 ) Java EE 스펙에준하고컨테이너내에서운영된다. 이들은본래 WAR(Web ARchive) 안에포함되며, 웹컨테이너내의 Context group 또는가상호스트에디플로이된다. 자세한내용은 제6장 Web Context( 웹애플리케이션 ) 를참고한다. 위에서제시한모든기능들이본안내의전체적인구성이된다 JEUS Web 디렉터리구조 다음은 JEUS Web 모듈에관련된기본디렉터리구조이다. [ 그림 1.3] JEUS Web 모듈에관련된기본디렉터리구조 JEUS_HOME\ bin\ 0 I 0 I jeusadmin jspc Legend: 0I: binary or executable file X: XML document J: JAR file T: Text file C: Class file V: java source file DD: deployment descriptor webhome\ app_home\ autodeploy\ config\ <node-name>_<cotainername>\ <node-name>_<containername>\ <node-name>\ X JEUSMain.xml <node-name>_servlet_ <engine-name>\ X X X WEBMain.xml web.xml webcommon.xml logs\ <node-name>\ servlet\ 주의깊게살펴봐야할디렉터리는다음과같다. JEUS_HOME JEUS 제품을설치할때선택된다 ( 예. c:\jeus6\). bin\ jeusadmin, jspc를포함하고있는디렉터리이다. 제 1 장 JEUS 웹 5

24 config\<node-name>\ JEUS 시스템에설정되어있는각웹컨테이너에해당하는하위디렉터리들을가지고있다. <node-name>_servlet_<engine-name>\ 이디렉터리는웹컨테이너의 XML 기반설정파일을가지고있다 (WEBMain.xml). 파일 web.xml webcommon.xml 설명자신만의 web.xml 파일을가지고있지않은웹애플리케이션을위한기본 web.xml 파일이다. 모든웹애플리케이션들에적용되는공통설정파일이다. 이파일은표준을따르는 web.xml과동일한파일이다. Java EE XSD 인 web-app_2_5.xsd 에는이파일들에대한정의가포함되어 있다. logs\<node-name>\<node-name>_<container-name>\servlet 웹컨테이너의 Logging 데이터를저장하고있다. webhome\ 웹애플리케이션을위한 Home 디렉터리로서다음과같은작업디렉터리를가지고있다. 디렉터리 app_home\ 설명 엔진로딩후에디플로이대상이되는웹애플리케이션이존재하며그 형태는 archive 타입과 exploded 타입모두가능하다. jeusadmin 콘솔툴이나 WebAdmin 을통해서디플로이를할경우이작 업디렉터리를사용한다. autodeploy\ <nodename_containername>\ 엔진을기동 (Booting) 하는경우 archive 타입의웹애플리케이션을엔진 이자동으로디플로이시킨다. 웹애플리케이션이디플로이될경우사용하는작업디렉터리이다. 만일 JSP 와관련해서생성되는파일에위치를지정하고싶을경우 WEBMain.xml 이나 jeus-web-dd.xml 의 <jsp engine> 요소를통해서설 정가능하다 JEUS 웹툴 JEUS 웹모듈에관련된툴들은다음과같다. WebAdmin 웹컨테이너를대상으로작업할수있는가장좋은툴이다. 이툴의사용법은 "JEUS WebAdmin 안내서 " 를참고한다. 6 JEUS Web Container 안내서

25 jeusadmin 콘솔툴명령창에서웹엔진을제어할수있는툴로, 웹컨테이너에대한기본제어와모니터링기능을제공한다. 이툴에대한사용법은 JEUS Reference Book 의 서블릿엔진관련명령어 와 "JEUS Server 안내서 " 를참고한다. JSP batch compiler 처음접근하는 JSP에대한빠른수행능력을위해 JSP를미리컴파일할수있는기능을제공한다. batch compiler에대한사용법은 JEUS Reference Book 의 4.4. appcompiler 와 JEUS Reference Book 의 4.7. jspc 를참고한다 JEUS Web 환경설정 웹컨테이너를사용하기위해서환경변수와 XML 파일에필요한정보를설정해야한다. 본절에서는 JEUS Web 모듈에서사용하는환경변수와 XML 설정파일에대해서설명한다 환경변수 JEUS Web 모듈에서사용하는환경변수들은 JEUS JVM에시스템설정을전달하기위해사용된다. 이시스템과 JVM 사이의변수매핑은 JEUS_HOME\bin\ 디렉터리에위치한다양한 JEUS 스크립트에존재한다. 어떤시스템변수들은스크립트에직접반영이되지않은것도있다. 즉, 이값들을 OS 환경변수값을수정함으로또는스크립트외부에서수정하는것이실제로적용되지않을수도있다는것을의미한다. 그러므로, 이값들은항상 JEUS_HOME/config의 xml 파일에서설정하도록한다. 대부분의환경변수값들은 JEUS를설치할때자동으로설정된다. 환경변수는수정가능하지만일반적으로권장하지는않는다. 반드시필요한경우에만 XML 설정파일에서이환경변수들을수정하는것이더일반적이다. 다음은 JEUS Web 모듈에관련된시스템환경변수에대한설명이다. [ 표 1.1] JEUS Web 모듈환경변수 환경변수 JEUS_HOME JEUS_WSDIR 설명 JEUS 가설치된기본위치를설정한다. 예 ) C:\Jeus6 ( 반드시설정되어야한다 ) JEUS 웹서버 (WebtoB) 의홈디렉터리이다. 예 ) C:\Jeus6\webserver ( 기본값 ) 참고 이시스템값들을설정하는방법은 OS 에따라각기다르다. 설정방법에대한내용은해당 OS 매뉴 얼을참고한다. 제 1 장 JEUS 웹 7

26 XML 설정파일 다음은 JEUS Web 과관련된설정파일에대한설명이다. JEUSMain.xml (jeus-main-config.xsd) 위치 목적 상세정보위치 JEUS_HOME\config\<node-name>\ JEUS 시스템에새로운웹컨테이너를추가할때사용한다. JEUS Server 안내서 WEBMain.xml (web-main-config. xsd) 위치 목적 상세정보위치 JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine- name>\ 웹컨테이너주요설정파일이다. 본안내서 jeus-web-dd.xml (jeus-web-dd. xsd) 위치 목적 상세정보위치 <ctxroot>\web-inf\ 웹애플리케이션 (context) Deployment Descriptor 이다. 본안내서 web.xml (web-app_2_5.xsd) 위치 목적 상세정보위치 <ctxroot>\web-inf\ Java EE 표준웹모듈의 Deployment Descriptor 이다. Servlet 2.5 스펙 web.xml (web-app_2_5.xsd) 위치 목적 상세정보위치 JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name>\ Web.xml 을개별적으로가지고있지않은 Context 의기본 web.xml 파일이다. Servlet 2.5 스펙 webcommon.xml (web-app_2_5.xsd) 위치 목적 상세정보위치 JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name>\ 웹컨테이너의모든 Context 에적용되는공통되는설정파일이다. Servlet 2.5 스펙 8 JEUS Web Container 안내서

27 제 2 장웹컨테이너 본장에서는 JEUS 웹컨테이너의하위모듈과주요기능, 기본적인설정방법에대해서설명한다 개요 JEUS 시스템의웹컨테이너는 Servlet 2.5와 JSP 2.1 스펙으로생성된 Java 기술기반의동적인웹페이지를실행하기위한환경과운영기반을제공한다. 또한웹컨테이너는 HTML과이미지파일들과같은 Static Content( 정적콘텐츠 ) 들도서비스할수있다. 웹컨테이너는 JEUS 웹모듈의최상위컴포넌트이다. 여기에는많은수의하위모듈들과설정할수있는기능들이존재한다. 예를들어여러개의웹컨테이너들은부하분산과 Fail-Over 기능을제공하기위하여클러스터로구성될수도있고, WebtoB나 Apache 웹서버와같은웹서버와연결될수도있다 웹컨테이너주요기능과구조 다음은웹컨테이너컴포넌트로본장에서주로설명할부분을타원으로표시하고나머지부분들은다음장에서설명한다. [ 그림 2.1] 웹컨테이너구조 JEUS Web Container Context Group A Client A Web Server A Web server connection/list ener Virtual Host A Misc. context group settings Default Virtual Host Monitoring thread Context/Web app A Context/Web app B Misc. container settings Client B Web Server B Context Group B Web server connection/list ener Virtual Host B Misc. context group settings Default Virtual Host Session handling settings Session Server Context/Web app C Context/Web app D 다음에설명하는하위절에서는웹컨테이너의가장중요한하위모듈들을설명한다. 이모듈들은각자가 많은기능들을포함하고있지만여기서모두설명하지않고별도의장들에서설명하도록한다. 제 2 장웹컨테이너 9

28 주요기능 웹컨테이너의하위모듈들과기능들은다음과같다. 자동모니터링웹컨테이너자체감시의가장중요한부분은자동모니터링을이용하는것이다. 이기능은컨테이너내의모든자원과 Pool들의상태를감시하고문제가발생하였을때대응할수있다. 설정에대한자세한내용은 자동모니터링 을참고한다. stdout와 stderr redirection 설정여부에따라 stdout과 stderr를사용해서로그를남긴다. 설정에대한자세한내용은 stdout 과 stderr Redirection 을참고한다. Context Group 각웹컨테이너는하나이상의 Context Group을포함할수있다. Context Group은여러개의리스너, 가상호스트, Context를관리한다. 설정에대한자세한내용은 Context Group 을참고한다. Database Connection Pool 웹애플리케이션에서는 Database Connection Pool을생성하여사용한다. 설정에대한자세한내용은 Database Connection Pool 을참고한다. Session 관리웹컨테이너의 Session 관리에대한여러가지사항을설정한다. Session 클러스터링의참여여부, Session 객체의공유여부, Session Cookie 설정, timeout 등웹컨테이너의 Session과관련된모든설정을할수있다. 설정에대한자세한내용은 Session 을참고한다. Shutdown Timeout Shutdown Timeout 기능으로관리자가 down 명령을내렸을때웹컨테이너가실제로종료되기까지웹컨테이너가기다리는시간을지정한다. 설정에대한자세한내용은 Shutdown Timeout 을참고한다. 위에서열거된목록은 JEUS 웹컨테이너의최상위뷰를표현하고있다. 이들은웹컨테이너의주요하위모듈인 Context Group과 Context가사용할수있는모듈들과서비스들을의미한다. 10 JEUS Web Container 안내서

29 디렉터리구조 다음은 JEUS 웹컨테이너를다룰때가장많이사용되는디렉터리들이다. [ 그림 2.2] JEUS 웹컨테이너관련디렉터리 JEUS_HOME\ config\ X <node-name>\ JEUSMain.xml <node-name>_servlet_ <engine-name1>\ Legend: 0I: binary or executable file X: XML document J: JAR file T: Text file C: Class file V: java source file DD: deployment descriptor X X webhome\ WEBMain.xml <node-name>_servlet_ <engine-name2>\ app_home\ WEBMain.xml autodeploy\ <node-name>_<container-name>\ JEUS_HOME\ JEUS가설치된최상위디렉터리이다. config\<node-name>\ JEUS Manager 및컨테이너에대한설정파일인 JEUSMain.xml을가지고있다. config\<node-name>\<node-name>_servlet_<engine-name>\ 웹컨테이너의모든설정이포함된 WEBMain.xml 파일이포함되어있다. webhome\ 웹애플리케이션을위한 home 디렉터리로서다음과같은작업디렉터리를가지고있다. 디렉터리 app_home\ autodeploy\ <nodename_containername>\ 설명엔진로딩후에디플로이대상이되는웹애플리케이션이존재하며그형태는 archive 타입과 exploded 타입모두가능하다. jeusadmin 콘솔툴이나 WebAdmin을통해서디플로이를할경우이작업디렉터리를사용한다. 엔진을기동 (Booting) 하는경우 archive 타입의웹애플리케이션을엔진이자동으로디플로이한다. 웹애플리케이션이디플로이될경우사용하는작업디렉터리이다. 제 2 장웹컨테이너 11

30 디렉터리 설명 만일 JSP 관련해서생성되는파일에위치를지정하고싶을경우 WEB Main.xml 이나 jeus-web-dd.xml 의 <jsp engine> 요소를통해서설정이 가능하다. 로그는웹컨테이너를통해직접적으로생성되지않고 Context Group 레벨에서설정하고생성된다. 자세 한내용은 제 3 장 Context Group 을참고한다 웹컨테이너설정 본절에서는 JEUS 웹컨테이너의주요기능에대한설정방법에대해서설명한다 개요 웹컨테이너설정하기위해서는기본설정파일인 JEUSMain.xml과 WEBMain.xml이필요하다. WEBMain.xml은 JEUSMain.xml에추가된 JEUS 웹컨테이너를설정하는파일로웹컨테이너의설정디렉터리에해당파일이존재해야한다. WEBMain.xml의수정은 XML 파일을직접편집하거나 WebAdmin 을사용하여설정을할수있다. WEBMain.xml 파일에는웹컨테이너설정의여러부분을대표하는태그들이존재한다. 각태그들을다음하위절에서설명한다. Context Group과 Session 설정의일부는본절에서간략히설명하고좀더자세한내용은별도의장의내용을참고한다. 참고본장에서설명하는설정에대한내용은 WebAdmin을이용해서설정할수있다. WebAdmin을이용해서 JEUSMain.xml에웹컨테이너추가방법과 WEBMain.xml 파일을설정하는자세한내용은 "JEUS WebAdmin 안내서 " 의엔진컨테이너와서블릿엔진부분을참고한다 기본설정 다음은웹컨테이너의기본설정파일인 JEUSMain.xml의예이다. [ 예 2.1] 웹컨테이너기본설정 : <<JEUSMain.xml>> <?xml version="1.0"?> <jeus-system xmlns=" <node> <engine-container> <engine-command> 12 JEUS Web Container 안내서

31 <type>servlet</type> <name>engine1</name> </engine-command> </engine-container> </node> </jeus-system> <engine-command> 태그가 JEUS 기동 (Booting) 과정에사용되기위해서는다음디렉터리가존재해야한다. JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name> 다음은디렉터리명을설정하는항목에대한설명이다. 항목 <node-name> <engine-name> 설명 JEUS의노드명이다. JEUSMain.xml의 <engine-command> 의하위태그인 <name> 에설정된값이어야한다. 위의예제에서 hostname 이 johan 이라면 <engine-name> 은 jo han_servlet_engine1 이된다. JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name> 아래에는반드시 WEBMain.xml 이라는파일이존재해야한다. 참고 각엔진컨테이너에는단한개의웹컨테이너가존재할수있다 자동모니터링 웹컨테이너자체감시의가장중요한부분은자동모니터링을이용하는것이다. 자동모니터링은웹컨테이너의자동관찰시스템이다. 이기능은컨테이너내의모든자원과 Pool들의상태를감시하고문제가발생하였을때대응할수있는기능을한다. 자동모니터링에는 3가지의모니터링이존재한다. Thread Pool Monitor 컨테이너의 Worker Thread Pool을모니터링한다. 자세한내용은 제4장웹서버연결과클러스터링 을참조한다. Class-reloading Monitor 웹컨테이너에등록된 Servlet 클래스들의변경을모니터링한다. 자세한내용은 제6장 Web Context( 웹애플리케이션 ) 를참조한다. 제 2 장웹컨테이너 13

32 Session Monitor 클라이언트 Session 기한만료를모니터링하고사용되지않는 Session을제거한다. 자세한내용은 제 5장 Session Tracking 을참조한다. 모니터링에대하여관리자가해야할것은상태를파악하기위한시간간격을설정하는것이다. 모니터링 thread가사용하는시간주기를 WEBMain.xml의 <monitoring> 태그와그하위태그들을사용하여설정한다. 자세한내용은 JEUS_HOME\docs\reference\schema\index.html에서 WEBMain.xml XML Reference 를참조한다. 다음은자동모니터링을설정한 XML 예제이다. [ 예 2.2] 자동모니터링설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <monitoring> <check-thread-pool>60000</check-thread-pool> <check-class-reload>60000</check-class-reload> <check-session>60000</check-session> </monitoring> </web-container> 문제가발생했을때는각모니터링 Thread 의하위컴포넌트에해당하는 XML 설정부분에서따로설정한 다 stdout 과 stderr Redirection WEBMain.xml에는 2개의태그들이 stdout과 stderr Redirection을위해설정되고다음디렉터리에로그를남긴다. JEUJEUS_HOME\logs\JeusSystem\<node-name>_<container-name> stdout과 stderr의설정여부에따라서다음의로그를남긴다. JEUS_HOME\logs\JeusSystem\<node-name>_<container-name>\stdout_<date>.log JEUS_HOME\logs\JeusSystem\<node-name>_<container-name>\stderr_<date>.log Redirection 기능이지정되지않으면기본값으로웹컨테이너를관리하는 JEUS Manager의로그에출력된다. 다음은로그파일에 stdout과 stderr 데이터가남도록설정한예이다. [ 예 2.3] stdout과 stderr redirection 설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" 14 JEUS Web Container 안내서

33 <monitoring> </monitoring> <redirect-stdout>true</redirect-stdout> <redirect-stderr>true</redirect-stderr> </web-container> 설정정보는 <redirect-stdout> 과 <redirect-stderr> 태그에 Boolean 값인 true 또는 false 로설정한다 Context Group 각웹컨테이너는하나이상의 Context Group을포함할수있다. Context Group은개별적인작은웹컨테이너이다. Context Group은여러개의리스너, 가상호스트, Context를관리한다. Context는컨테이너에서수행되는실제웹애플리케이션과같은개념이다. Context Group은그안에포함된모든 Context와가상호스트에공통적으로적용되는설정과서비스들을가지고있다. Context Group의또한가지중요한기능은웹서버연결과클러스터환경에서의 Session Handling 그리고 active management이다. 참고 Context Group은많은양의설정을담고있으므로 제3장 Context Group 에서따로상세히설명한다. Context에대한자세한내용은 제6장 Web Context( 웹애플리케이션 ) 에서설명하고, 가상호스트는 제7장가상호스트 에서설명한다. Context Group은여러개의웹애플리케이션또는가상호스트를관리하는컨테이너이다. 각웹컨테이너에는하나이상의 Context Group이존재할수있고, WEBMain.xml의최상위태그인 <context-group> 을이용하여설정된다. [ 예 2.4] Context Group 설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <monitoring> </monitoring> <context-group> <!-- See chapter 제3장 Context Group --> </context-group> <context-group> </context-group> 제 2 장웹컨테이너 15

34 </web-container> 웹컨테이너레벨에서정의된설정들은모든 Context Group 과웹컨테이너의하위 Context 에글로벌하게 적용된다 Database Connection Pool 웹애플리케이션에서는다음과같이 Database Connection을생성할수있다. Driver mydriver = (Driver)Class.forName("jeus.jdbc.pool.Driver").newInstance(); Connection conn = mydriver.connect("datasource1"); conn에서사용되는인자는 JEUSMain.xml의 <database> 요소에등록된 <export-name> 이다. <database> 의자세한설정방법에대해서는 "JEUS Server 안내서 " 를참고한다. 참고 JEUS5.0 FIX #13 이전까지웹컨테이너는독립적인 DB Connection Pool을사용했다. 그러나 JEUS5.0 FIX #13 이후버전에서는 javax.sql.datasource를사용하도록변경되었다. 그래서 JEUSMain.xml에위에서설명한것처럼등록과정이반드시선행되어야한다. 또한버전을업그레이드하는경우 WEBMain.xml의 <db-connection-pool> 을 JEUSMain.xml의 <database> 로포팅하는과정이필요하다. 그리고 jeus.jdbc.pool.driver을사용하지않고 JNDI lookup 을이용해서 Datasource를얻은다음 DB Connection을획득하는전통적인방법역시가능하다 Session 웹컨테이너의 Session을관리하기위한여러가지를설정한다. Session 클러스터링의참여여부, Session 객체의공유여부, Session Cookie 설정, timeout 등웹컨테이너의 Session과관련된모든설정을할수있다. 추가적으로클러스터링된환경에서의 Session에대한사항은 제5장 Session Tracking 에서설명한다. 웹컨테이너의 Session과관련된여러가지설정을할수있다. Session 설정은웹컨테이너외에도다음의여러레벨에서설정이가능하다. Web Container 레벨 : WEBMain.xml의 <web-contianer> 하위 <session-config> 태그 Context Group 레벨 : WEBMain.xml의 <context-group> 하위 Context 레벨 : jeus-web-dd.xml의 <jeus-web-dd> 하위 Web Container 레벨에서 Session 설정이되어있다면, 하위 Context Group 또는 jeus-web-dd에 Session 설정을하지않았을경우공통적으로웹컨테이너의 Session 설정부분이적용된다. 16 JEUS Web Container 안내서

35 참고 Web Container 레벨, Context Group 레벨, Context 레벨의설정이중복되었을경우하위레벨의세부적인설정에가장높은우선순위를부여한다. 즉, 세군데모두설정을하였다면 Context 레벨 > Context Group 레벨 > Web Container 레벨순으로설정값이적용된다. 만약하위레벨에서특정설정을하지않았다면상위레벨의설정값을적용하고모든레벨에서설정하지않은값은엔진내부적인기본값으로동작한다. 다음은 Web Container 레벨의 Session 설정의예이다. Session 설정은 <web-contianer> 하위 <sessionconfig> 에구성한다. [ 예 2.5] Session 설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <session-config> <distributable>false</distributable> <shared>false</shared> <timeout>30</timeout> <reload-persistent>false</reload-persistent> <url-rewriting>false</url-rewriting> <session-cookie> <jsessionid-name>jsessionid</jsessionid-name> <version>0</version> <path>/</path> <max-age>-1</max-age> <secure>false</secure> </session-cookie> </session-config> </web-container> 다음은설정태그에대한설명이다. <distributable> Session 클러스터링에참여할지의여부를설정한다. 설정값 true false 설명 Session 클러스터링에참여한다. Session 클러스터링에참여하지않는다.( 기본값 : false) JEUS 웹컨테이너는크게 2 가지방식의 Session 클러스터링방식을지원한다. 중앙집중방식과분 산방식이다. 제 2 장웹컨테이너 17

36 Session 정보를관리하는환경에대한보다자세한내용은 제5장 Session Tracking, 중앙집중식 Session 클러스터링의경우 JEUS Server 안내서 의 중앙세션서버, 분산식 Session 클러스터링의경우 JEUS Server 안내서 의 분산세션서버 를각각참고한다. <shared> 현 Context에서생성된 Session 객체를다른 Context들에서도공유하여사용할지의여부를설정한다. 즉, Context A에서생성된 HTTPSession 객체가 Context B에서도같은사용자에의해사용될수있는지에대한것이다. Session 클러스터링이아닌환경의경우최대공유범위는동일애플리케이션내의 Context이며, Session 클러스터링환경의경우공유범위는제한이없다. Boolean 형식의설정이며, 설정을하지않았을경우기본값으로 "false" 가설정된다. <timeout> 생성된 Session 객체의유효주기를설정한다. 보통웹애플리케이션설정인 web.xml에서 Session의 timeout을설정하지만, web.xml에서특별한설정을하지않았다면 JEUS의 Session 설정즉, <session-config><timeout> 에서설정한값이적용된다. 다시말하면, web.xml의 Session timeout 설정이존재한다면현설정값은적용되지않는다 (web.xml 의 Session timeout이가장우선순위가높다 ). Int 형식의설정이며분단위의시간을설정한다. 설정을하지않았을경우기본값으로 "30" 즉, 30분이주어진다. 참고위의설정 shared가 true일경우즉, Session이여러 Context들간에공유가된다면해당 Session의 timeout은 JEUS 웹컨테이너에서는해당 Session이처음생성되는 Context의 timeout 설정을따르도록한다. <reload-persistent> 일반적으로 Servelet Context가변경되어리로딩이발생할때해당 Context 내의 Session 객체의속성들은모두삭제된다. 하지만, reload-persistent가 "true" 로설정되어있으면 Session 객체의속성들을계속유지시켜준다. Boolean 형식의설정이며, 설정을하지않았을경우기본값으로 "false" 가주어진다. <url-rewriting> 기본적으로웹컨테이너는클라이언트의 Session ID를여러번요청중에도지속적으로유지하기위하여쿠키를사용한다. 문제는만약에요청과함께쿠키가처음생성된곳의도메인이름이요청이생성된곳의이름과다르면대부분의브라우저 Session 쿠키정보를보내지않는다는것이다. 설정값 true 설명 쿠키에의존하는대신에 URL rewriting 을강제로대신사용하게한다. 18 JEUS Web Container 안내서

37 설정값 설명 이렇게함으로써, Session Tracking 이다른도메인이름이사용되어몇번의요 청이들어와도가능하게된다. URL rewriting 이라함은 context 에의해반환되는 모든 URL 에유일한 JSESSIONID URL 파라미터를붙이는것을의미한다. false 이기능은사용되지않고, 기본적인쿠키기반만사용된다.( 기본값 : false) <session-cookie> 사용자의 Session을추적하는기본기술은모든클라이언트응답에반환되는이 Session 쿠키를이용한다. 자세한내용은 제5장 Session Tracking 을참고한다. 웹컨테이너에서 Response를내보낼때 HTTP 헤더의 Session 쿠키에대한설정을여기서한다. 일반적으로엔진에서쿠키를구성하나, 특별한쿠키정보를구성하고싶을때사용한다. 다음과같은세부항목을설정할수있다. 태그 <jsessionid-name> <version> 설명 Session 쿠키의이름으로표준이름인 "JSESSIONID" 을사용하지않고다른이름을사용할때이설정을사용한다. String 형식의설정이며, 설정을하지않았을경우기본값으로 "JSESSIONID" 가주어진다. 쿠키의버전을설정한다. Int 형식의설정으로다음의값중에하나를설정한다. - 0 : NS 쿠키유형을가진다.( 기본값 : 0) - 1 : RFC 스펙의쿠키유형을가진다. <domain> Session 쿠키가보내질때서버의도메인이름을설정한다. 쿠키는이도메인요청에대해서만되돌아온다. 하나의적합한도메인이름은 "." 으로시작되어야하며 <host_name> 을지정해서는안된다. 이에대한자세한내용은 RFC-2109 스펙을확인한다. String 형식의설정이며, 설정을하지않았을경우쿠키에도메인정보를포함하 지않도록한다. <path> Session 쿠키가보내질도메인내의 URL 경로를설정한다. 쿠키는도메인이적 합할때해당 URL 의어떤요청과더불어보내진다. 예를들어만일 "/examples" 란경로가설정되고, 도메인은 ".foo.com" 으로설정되었다고가정할때, 클라이언트의요청들은 " 의형식에맞을때만해당쿠키를포함하여서버로요청한다. 이또한위의도메인설정과더불어 RFC-2109 스펙을확인한다. String 형식의설정이며, 설정을하지않았을경우엔진내부에서적절한 path를선택하고설정을하였을경우일반적으로설정된고정 path 정보를쿠키에포함한다. path를설정할경우설정한고정값이항상쿠키의정보로포함된다. path의최상위값인 "/" 가아닌다른값으로설정을할경우는애플리케이션들의 Session 공유특성들을고려하여주의깊게값을설정한다. 제 2 장웹컨테이너 19

38 태그 <max-age> 설명 Session 쿠키의 expires 속성을설정한다. 이시간주기가되면쿠키는클라이언 트로부터제거되고더이상보내지지않는다. Int 형식의설정이며초단위시간을설정한다. 설정을하지않았을경우기본값으로 -1이주어진다. -1 값의의미는쿠키의 "expires" 속성을사용하지않겠다는것을의미한다. 즉, 브라우저의 Lifecycle을따르겠다는의미로서브라우저가닫힐때쿠키는사용자의 Session이끝남과동시에끝난다. <secure> Session 쿠키의 "secure" 속성을설정한다. 만일 "true" 로설정되면 Session 쿠키 는오직 secure http connection 인 HTTPS 위에서만보내진다. Boolean 형식이며, 설정을하지않았을경우기본값으로 "false" 가주어진다 Logging 웹컨테이너에서생성되는로그메시지는 System log, User log, Access log 3가지이다. 이중 System log 는 JEUSMain.xml에서 <system-logging> 을통해설정한다. User log 및 Access log는 WEBMain.xml의 <logging> 을통해설정한다. Logging 설정은웹컨테이너전체혹은하위 Context Group 별로따로설정할수있다. Logging 설정에대한자세한내용은 2.4. Logging 설정 에서설명한다 Shutdown Timeout Shutdown Timeout 기능으로관리자가 down 명령을내렸을때웹컨테이너가실제로종료되기까지웹컨테이너가기다리는시간을지정한다. 이설정은관리자가웹컨테이너는 Worker Thread들이작업을모두마치기까지기다리도록한다. down 명령을수행했을때어떤 Worker Thread도실행되고있지않으면컨테이너는이설정을무시하고바로종료를수행한다. 다음은 Shutdown Timeout 설정에대한예로 <web-container> 태그에 <shutdown-timeout> 하위에구성한다. <?xml version="1.0"?> <web-container xmlns=" <shutdown-timeout>10000</shutdown-timeout> </web-container> 20 JEUS Web Container 안내서

39 2.4. Logging 설정 웹컨테이너에서별도로설정가능한 Logger는 Access log와 User log이다. Access log 웹컨테이너에요청된 request 및그처리결과에대한로그이다. User log javax.servlet.servletcontext.log(string msg) 또는 javax.servlet.servletcontext.log(string msg, Throwable t) 등의 API를사용하여 Servlet 애플리케이션내에서생성되는메시지를기록하는로그이다. 별도의설정이없을경우웹컨테이너당 1개의 Access log 및 User log 파일이생성된다. JEUS의 log의기본위치 (JEUS_LOGHOME) 는 JEUS_HOME\logs\<node-name> 이다. Access log 기본위치 <JEUS_LOGHOME> 아래에 <node-name>_<container-name>\servlet\accesslog\access.log가기본로그파일이다. JEUS_HOME이 c:\jeus6 이고 node_name이 johan, container_name이 container1인경우다음이기본로그파일이다. c:\jeus6\logs\johan_container1\servlet\accesslog\access.log User log 기본위치 <JEUS_LOGHOME> 아래에 <node-name>_<container-name>\servlet\userlog\user.log가기본로그파일이다. JEUS_HOME이 c:\jeus6 이고 node_name이 johan, container_name이 container1인경우다음이기본로그파일이다. c:\jeus6\logs\johan_container1\servlet\userlog\user.log 공통설정항목 본절에서는 Access log과 User log 설정항목중공통으로적용되는설정정보에대해서설명한다. 설정정보는 <context-group> 태그아래 <logging> 에구성한다. <access-log> 와 <user-log> 는 <logging> 설정의하위요소이며 <context-group> 단위로설정이가능하다. <logging> 설정은다음의예제와같이 <web-container> 또는 <context-group> 의하위요소로존재한다. <web-container> 설정의하위요소로 <logging> 을설정하면 <web-container> 내의모든 <context-group> 에공통으로적용된다. <context-group> 의하위요소로설정된 <logging> 은해당 <context-group> 에만적용되며 <web-container> 의 <logging> 설정보다우선한다. 제 2 장웹컨테이너 21

40 참고 <web-container> 하위에는 <access-log> 를설정하지않아도기본적으로 Logging을하도록되어있다. 이때의도하지않게하나의파일에너무많은양의 Logging이될수있으므로 JEUS6 Fix #8 부터는 <web-container> 하위에 <access-log> 설정이없으면 <log rotation> 정책을적용하여 Logging하도록한다. 웹컨테이너에 Access log가생성되는것을원하지않으면 <enable> 을 false로설정한다. 다음은웹컨테이너 Logging 설정에대한예이다. [ 예 2.6] 웹컨테이너 Logging 설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <logging> <user-log> <level>fine</level> <use-parent-handlers> true </use-parent-handlers> <handler> <smtp-handler> <name>smtphandler</name> <level>severe</level> <smtp-host-address> mail.com </smtp-host-address> <from-address> jeus@mail.com </from-address> <to-address> admin@mail.com </to-address> <send-for-all-messages> false </send-for-all-messages> </smtp-handler> </handler> </user-log> <access-log> <enable>true</enable> <format> [%{yyyy.mm.dd HH:mm:ss}t] %a %m %U%q" %s %Dms </format> <handler> 22 JEUS Web Container 안내서

41 <file-handler> <name>filehandler</name> <valid-hour>1</valid-hour> </file-handler> </handler> </access-log> </logging> </context-group> </web-container> 다음은 <access-log>, <user-log> 에공통으로설정하는항목에대한설명이다. <level> logger의레벨을설정한다. 이레벨이하의메시지만 Logger를통해출력될수있다. <level> 의값으로는 Logging API의레벨인 SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST가올수있다.( 기본값 : INFO) 주의 <access-log> 설정에서 <level> 설정은무의미하다. <use-parent-handlers> Logger가자신의 handler 뿐만아니라상위 Logger의 handler를사용할것인지의여부를지정한다. ( 기본값 : true) <filter-class> Logger가로그메시지를 handler에게보내기전에수행하는필터링에사용할클래스를지정한다. 여기에지정된클래스는 lib\application 디렉터리의 jar 파일내에포함되어야한다. <handler> logger가사용할 handler를지정한다. 이항목이설정되어있지않다면 access-log의경우는기본적으로 file handler가사용되고, user-log의경우는 console handler와 file handler가사용된다. <handler> 에는다음과같은하위항목들이있다. <console-handler> 화면으로로그메시지를출력하는 handler이다. 이 handler는다음과같은기본적인 handler 설정만가지고있다. 태그 <name> 설명 handler 가툴에서보여질때사용할이름을지정한다. 만약지정되어있지않으 면 class name 과 hash code 로이름이대체된다. 제 2 장웹컨테이너 23

42 태그 <level> 설명 handler가출력할메시지의레벨을지정한다. 즉, Logger를통과한로그메시지가이 Logger가사용하는각각의 handler에게전달되는데이 handler의레벨에부합하는로그메시지만이 handler에의해출력된다. 기본값은 FINEST 로 Logger 를통과하는모든로그메시지가 handler 에의해출 력되도록되어있다. 단, Access log 일경우, INFO 레벨이상에서는 Access Log 를출력하지않는다. <encoding> <filter-class> handler가출력하는문자열의인코딩을지정한다. 한글 querystring의출력을지원하기위해서기본값은 system encoding이아닌 'ISO ' 로설정되어있다. HttpServletRequest.getQueryString() 은스펙에따라 WEBMain.xml에인코딩설정이있어도디코딩처리를하지않기때문에 'ISO ' 로디코딩해야 access log에한글 querystring이정상적으로출력된다. handler가로그메시지를출력하기전에수행할필터링에이용되는클래스이다. Logger의 <filter-class> 와마찬가지로 lib\application에이클래스를포함한 jar 파일이존재해야한다. <file-handler> 파일로로그메시지를출력하는 handler 로 <console-handler> 의설정이외에다음과같은설정을 가지고있다. 태그 <file-name> 설명 handler 가출력할파일의이름을지정한다. 절대경로로되어있다면그경로로파일이생기고상대경로라면각 Logger 의 기본경로를기준으로한상대경로로인식한다. 이설정을하지않으면각 Logger 별로지정된 path 로파일을생성해서로그메시지를출력한다. <valid-day>, <valid-hour> <buffer-size> <append> <log rotation> handler가출력할파일을시간마다따로생성할경우에사용한다. 둘중하나만사용할수있는데, valid-day는날짜별로 valid-hour는시간별로파일을변경한다. valid-hour는 24의약수이거나 (ex. 3, 6) 24로나눈나머지가약수 (ex. 27, 30) 의이름을지정한다. 파일이름의형식은 valid-day의경우파일끝에 '_YYYYM MDD' 가붙거나 valid-hour의경우 '_YYYYMMDD_HH' 가붙는다. 이때 HH는파일로그의시작시간이다. 파일로출력할때사용할버퍼의크기를지정한다. 버퍼가클수록 Logging의성능은좋아지지만예상치못한상황으로 JEUS가종료될때에는그버퍼크기만큼로그가손실된다.( 기본값 : 20KB) 파일로출력할때이미파일이존재하면덮어쓸지파일끝에추가할지를결정한다.( 기본값 : true) JEUS Server 안내서 의 로그파일 Rotation 설정 을참고한다. <smtp-handler> 24 JEUS Web Container 안내서

43 로그메시지를 로전송하는 handler 이다. 하나의로그메시지가하나의 로전송된다. <console-handler> 의설정이외에다음과같은설정을가지고있다. 태그 <smtp-host-address> <from-address> <to-address> <cc-address> <bcc-address> <send-for-all-mes sages> 설명 을보낼호스트의주소를지정한다. 을보내는사람의주소를지정한다. 을받는사람의주소를지정한다. 을참조하는사람의주소를지정한다. 을숨은참조하는사람의주소를지정한다. 모든메시지를 smtp-handler로보낼지를결정한다. false인경우 JEUS 시스템에서 로전송하기로결정되어있는메시지만이 handler를사용해서보내진다. 이설정은 jeus.systemuser logger에만유효하다. <socket-handler> 로그메시지를소켓으로전송하는 handler 로 <console-handler> 의설정이외에다음과같은설정 을가지고있다. 태그 <address> <port> 설명 handler 가접속할머신의 IP 주소를지정한다. handler 가접속할머신의 port 를지정한다. <user-handler> 사용자가생성한 handler 클래스를지정하는항목으로 <console-handler> 의설정이외에다음과 같은설정을가지고있다. 태그 <handler-class> 설명 사용자가생성한 handler 의클래스를지정한다. 이클래스는 lib\application 디렉터리의 jar 파일에포함되어있어야한다. 또한 이클래스는 Logging API 의 java.util.logging.handler 를상속받고 jeus.util.log ging.jeushandler 를구현해야한다. <handler-property> <formatter-class> <formatter-property> jeus.util.logging.jeushandler의 setproperty() 에사용되는 Map 객체에들어갈프로퍼티를지정한다. handler가사용할 formatter 클래스를지정한다. 이클래스도 lib\application 디렉터리의 jar 파일에포함되어있어야한다. 또한 jeus.util.logging.jeusformatter interface를구현해야한다. 기본값은 JEUS에서사용하는 jeus.util.logging.sim pleformatter이다. jeus.util.logging.jeusformatter의 setproperty() 에사용되는 Map 객체에들어갈프로퍼티를지정한다. 제 2 장웹컨테이너 25

44 Access log 관련설정항목 다음은 Access log 에만사용되는설정에대한설명이다. <access-log> 태그 <enable> <format> <exclude-ext> 설명 Access log 관련하여아무것도설정하지않을경우기본파일에기본형식으로 Access log를남긴다. 이설정은 Access log를남기는것을원치않을경우사용한다. Access log에남길로그의형식을지정한다. 설정하지않을경우기본형식으로로그를남긴다. 자세한설명은 "<access-log> 의 <format> 설정 " [26] 을참고한다. 특정확정자들을 "," 로구분하여설정한다. <access-log> 의 <format> 설정 <access-log> 의하위요소인 <format> 을사용하여사용자정의 Access log format을지정하는것이가능하다. <format> 에넣을값은임의의 String 값이가능하다. 단 % 기호는특수기호로인식된다. 즉, % 를접두사로사용하는다음에열거하는단어들은 runtime에여러가지 request/response property로대체되어 Access log에남게된다. Runtime에대체되는특수단어들1 단어 %a %A %b %B %h %H %m %p %q %r %s %S %t %u %U %v 설명 Remote IP address Local IP address HTTP header를제외한 response body의총길이 ( - 는 0을나타낸다 ) HTTP header를제외한 response body의총길이 Remote host name 또는 IP address Request protocol Request method (GET, POST ) Local port number Query string( 앞에? 가붙음 ) method 와 request URI HTTP response status code User session ID Date and time( 기본시간형식. 후술함 ) Remote user name Request URL Local server name 26 JEUS Web Container 안내서

45 단어 %D %T 설명 processing time( 단위 : millisecond) processing time( 단위 : 초 ) Runtime 에대체되는특수단어들 2 request cookie, header, attribute, session attribute 등에서특정값을가져와표시할수있다. 단어 {xxx}i {xxx}c {xxx}r {xxx}s {xxx}t 설명 request header에서 key가 xxx 인값을표시한다. request cookie에서 key가 xxx 인값을표시한다. request attribute에서 key가 xxx 인값을표시한다. Session 정보에서 key가 xxx 인값을표시한다. xxx 를 JDK standard DateFormat으로기술하면 access-log의시간형식을바꿀수있다. 기본 <format> [%{yyyy.mm.dd HH:mm:ss}t] %a "%m %U%q" %s %Dms Access log 필터설정 사용자의특별한설정이없을경우, 다음과같은기본형식의모든 Access log를기록한다. [ :42:57] "GET /examples/images/bluebtn.gif" 404 0ms 하지만보통 Access log의양은상당히많기때문에, 특정형식또는조건을만족하는로그만 Access log 로기록하고싶을경우가때때로존재한다. 이를위해제공되는기능이 Access log 필터기능이다. Access log 필터기능지원을위해, JEUS에서는 jeus.util.accessloggerfilter 인터페이스및 jeus.util.ab stractaccessloggerfilter 추상클래스를제공하고있다. 다음은 jeus.servlet.util.accessloggerfilter 인터페이스의상세내용이다. package jeus.servlet.util; import java.util.logging.filter; import java.util.logging.logrecord; /** * Access Logger의내용을필터링하기위해필요한정보들을제공하는인터페이스. * {@link Filter} 를상속한필터인터페이스로서부수적으로제공되는인터페이스를통해 * {@link Filter#isLoggable(java.util.logging.LogRecord)} 안에서다양하게필터링정책을정하도록가이드한다. 제 2 장웹컨테이너 27

46 */ public interface AccessLoggerFilter extends Filter { /** * 서버에접속한 remote client의 address 정보를반환한다. * record a LogRecord remote client의 address. 만약올바른값을얻지못할경우 null을반환한다. */ public String getremoteaddr( LogRecord record ); /** * 요청의메소드를반환한다. ex) GET, POST, PUT, etc... * record a LogRecord request method. 만약올바른값을얻지못할경우 null을반환한다. */ public String getmethod( LogRecord record ); /** * 요청의 uri를반환한다. * record a LogRecord request uri. 만약올바른값을얻지못할경우 null을반환한다. */ public String getrequesturi( LogRecord record ); /** * 응답의 status값을반환한다. ex) 200, 404 * record a LogRecord status. */ public int getstatus( LogRecord record ); } /** * 요청에따른처리시간을 ms단위로반환한다. record a LogRecord processing time. 만약올바른값을얻지못할경우 -1을반환한다. */ public long getprocessingtimemillis( LogRecord record ); 사용자가 Access log 의특정패턴에대해필터링하는경우위의 AccessLoggerFilter 인터페이스및 Abstrac taccessloggerfilter 추상클래스를이용하여쉽게필터를구현, 적용할수있다. 28 JEUS Web Container 안내서

47 사용자의필터클래스는 jeus.servlet.util.abstractaccessloggerfilter 를상속하고, java.util.logging.filter 의 isloggable() 메소드를구현해야한다. isloggable() 메소드를구현할때, 위의 jeus.servlet.util.accesslog gerfilter 의 API 중에서사용자가필요한정보를적절히선택하여이용및구현한다. 다음은요청확장자가 "gif" 인경우에만, 해당요청을 Access log 로기록하는사용자필터클래스를정의한 예이다. package sample; import jeus.servlet.util.abstractaccessloggerfilter; import java.util.logging.*; public class SimpleAccessLoggerFilter extends AbstractAccessLoggerFilter { public boolean isloggable( LogRecord record ) { // get the request uri String requesturi = getrequesturi(record ); } } // allow only "gif" extension return requesturi!= null && requesturi.endswith( "gif" ); sample.simpleaccessloggerfilter는사용자가정의한클래스이며 jeus.servlet.util.abstractaccesslog gerfilter를한다. java.util.logging.filter#isloggable() 메소드를구현하였으며, 클라이언트의요청 URI를얻기위하여 jeus.servlet.util.accessloggerfilter#getrequesturi() API를이용한다. 해당클래스를컴파일한후, jar 파일형태로 lib\application 디렉터리에포함한다. WEBMain.xml의 <access-log> 설정에해당필터를등록한다. 다음은 WEBMain.xml의 <access-log> 설정에해당필터를등록하는예이다. [ 예 2.7] <access-log> 에필터등록 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <logging> <access-log> <enable>true</enable> <filter-class> sample.simpleaccessloggerfilter </filter-class> 제 2 장웹컨테이너 29

48 <handler> <file-handler> <name>filehandler</name> <valid-hour>1</valid-hour> </file-handler> </handler> </access-log> </logging> </context-group> </web-container> User log 관련설정항목 User log에만해당하는별도의하위요소는없다. User log는다음에별도로설명할 Context deployment descriptor에서설정하여특정 Context 단독으로사용하는것이가능하다. 그러한경우에는 Context deploy ment descriptor 내의 <user-log> 설정이우선순위를갖는다 웹컨테이너제어와모니터링 본절에서는웹컨테이너제어와모니터링하는방법에대해서설명한다 웹컨테이너제어 웹컨테이너를제어한다는것은웹컨테이너의시작과종료를제어한다는의미와같다. 이 2가지작업은 WebAdmin과 jeusadmin 콘솔툴을사용하여가능하다. 본절에서는웹컨테이너에대한정보만포함하며 Context Group과 Context(Web application) 에대해서는언급하지않는다. jeusadmin 콘솔툴을이용한웹컨테이너제어 jeusadmin 콘솔툴을이용한예를이용해서웹컨테이너제어를설명한다. 다음의예는 johan_servlet_en gine1 라는웹컨테이너가적절히 JEUSMain.xml과 WEBMain.xml에설정되어있다고가정한다. jeusadmin 시작 jeusadmin을시작하고 JEUS 노드에연결한다. C:\> jeusadmin johan 사용자와패스워드를입력하면 jeusadmin 명령창이나타난다. 30 JEUS Web Container 안내서

49 노드시작 JEUS 노드가시작되어있지않으면다음의명령을실행한다. johan> boot 설정된웹컨테이너와모든다른엔진들이자동으로시작된다. 노드종료하나의엔진을시작하거나종료하기위해서는해당컨테이너를시작하거나종료해야한다. 따라서 "jo han_container" container의 johan_servlet_engine1 이라는웹컨테이너가시작되었다고가정하고다음의명령으로종료한다. johan> downcon johan_container1 웹컨테이너시작 종료된웹컨테이너를시작하려면다음의명령을실행한다. johan> startcon johan_container1 위의예에서는웹컨테이너에관련된명령을몇가지알아보았다. 자세한내용은 "JEUS Server 안내서 " 를 참고한다. WebAdmin 을이용한웹컨테이너제어 "JEUS WebAdmin 안내서 " 의 Servlet Engine 제어설명을참고한다 웹컨테이너모니터링 모니터링은근본적으로특정웹컨테이너의수행하는경우데이터와상황정보를수집하는것을의미한 다. 주의 웹컨테이너를모니터링하기위해서는콘솔툴보다는보다상세하고완전한엔진상태정보를제공 하는 WebAdmin 의사용을권장한다. 콘솔툴을통한웹컨테이너모니터링 jeusadmin 콘솔에서는웹컨테이너에대한기초정보를얻을수있는기능을제공한다. 자세한내용은 "JEUS Server 안내서 " 와 JEUS Reference Book 의 서블릿엔진관련명령어 를참고한다. WebAdmin 을통한웹컨테이너모니터링 WebAdmin을통하여웹컨테이너를모니터링할수있다. WebAdmin의엔진컨테이너통계부분과 Session 서버통계부분을이용한다. 제 2 장웹컨테이너 31

50

51 제 3 장 Context Group 본장에서는 Context Group 에대해상세하게설명한다 개요 JEUS 내부에서웹애플리케이션 ( 또는 Context) 은 Context Group으로그룹핑되어있다. 또한, 여러개의 Context Group들도 JEUS 웹컨테이너에존재할수있다. 관련내용은 제2장웹컨테이너 를참고한다. Context Group은웹애플리케이션에많은중요한서비스들을제공한다. 이러한서비스들의예는웹서버연결, JSP 컴파일, Logging, active management, response header 설정등이있다. 즉, Context Group의설정과서비스들은종속되어있는모든웹애플리케이션 (Context) 에적용된다. JEUS 시스템에웹애플리케이션을성공적으로디플로이하기위해서는이개념을반드시이해해야한다 Context Group 주요기능과구조 개념적으로, Context Group은 웹컨테이너내의웹컨테이너 로생각할수있다. 그뿐만아니라 Context Group은복수개의웹애플리케이션 (Context) 를호스팅할수있는 Virtual Server라고생각할수있다. 각 Context Group에는그에등록된웹애플리케이션들이사용할별도의설정과하위컴포넌트들이존재한다. 많은서비스들과설정들이최상위웹컨테이너로부터상속된다는사실도매우중요하다. 앞에서설명했듯이, 이러한서비스들에는 Session 처리설정 (Session 처리설정이 Context Group에설정되어있으면웹컨테이너의설정은무시된다 ) 이있다. 제 3 장 Context Group 33

52 다음은 제 1 장 JEUS 웹 에서제시한웹컨테이너구조이다. 본장에서주로설명할부분은타원으로표시 되어있다. [ 그림 3.1] 웹컨테이너에연관된 Context Group JEUS Web Container Context Group A Client A Web Server A Web server connection/list ener Virtual Host A Misc. context group settings Default Virtual Host Monitoring thread Context/Web app A Context/Web app B Misc. container settings Client B Web Server B Context Group B Web server connection/list ener Virtual Host B Misc. context group settings Default Virtual Host Session handling settings Session Server Context/Web app C Context/Web app D 다음그림은 Context Group 의상세확대한모습으로본장에서주로설명할부분은타원으로표시되어있 다. [ 그림 3.2] Context Group 의상세모습과그하위컴포넌트들 34 JEUS Web Container 안내서

53 주요기능 Context Group에관계된주요하위컴포넌트들과기능들은다음과같다. Virtual Host Virtual Host( 이하가상호스트 ) 는 Context Group 레벨에서설정한다. 여러개의가상호스트들이추가될수있으며각가상호스트에는여러개의웹 Context를디플로이할수있다. 가상호스트에대해서는 제7장가상호스트 를참고한다. Context Context는 Context Group과웹컨테이너에서실행되는웹애플리케이션과동일한개념이다. 여러개의 Context가한개의 Context Group에디플로이될수있으며 Context Group과웹컨테이너의서비스들을모두사용할수있다. 또한 Context는 Context Group 바로아래에또는 Context Group 내의가상호스트에바로디플로이가능하다. 전자의경우에는 Context가묵시적으로기본가상호스트에속한다고볼수있다. Context에대해서는 제6장 Web Context( 웹애플리케이션 ) 에서자세히설명한다. Web Server 연결요청을받아들이고적당한웹애플리케이션에전달하기위해서는클라이언트의 HTTP 요청을받아적절한 Context Group에전달하는웹서버와의연결을설정해야한다. 그러므로, Context Group 내의 Context들은그 Context Group에설정된웹서버를통해서만요청을받을수있다. 이의미는 2가지다른 Context Group에등록된각기다른 Context는서로다른웹서버의서비스를받을수있다는것이다. 이것이각 Context Group이논리적으로각기다른가상호스트로등록될수있는주요한이유이다. 웹서버연결에대한내용은 Context Group레벨에서설정되지만중요하고큰주제이므로이에대한설명은 제4장웹서버연결과클러스터링 에서진행한다. 인코딩 Context Group은등록된모든 Context에의해사용될수있는인코딩설정을가지고있다. 설정에대한자세한내용은 인코딩설정 을참고한다. JSP Engine 각 Context Group은 JSP 엔진을포함하고있다고도볼수있다. JSP 엔진은 jsp 자원을클라이언트가요청하였을때 JSP페이지들을컴파일하여 Servlet 코드로만드는작업을한다. 설정에대한자세한내용은 JSP 엔진설정 을참고한다. logging logging 옵션을 <web-container> 절에설정하면모든 Context Group에공통으로적용되고, <contextgroup> 절에설정하면설정한 Context Group에만적용된다. 설정에대한자세한내용은 Logging 설정 을참고한다. 제 3 장 Context Group 35

54 Session 관리 ( 웹컨테이너에서의설정을재설정 ) Context Group에 Session 관련설정을할수있다. 설정에대한자세한내용은 Session 설정 을참고한다. Response Header 사용자임의의 HTTP Header Response 이름과값의짝으로정의해서사용한다. 설정에대한자세한내용은 Response Header 설정 을참고한다 디렉터리구조 다음은 Context Group 과관계된 JEUS 시스템디렉터리에대한설명이다. [ 그림 3.3] Context Group 디렉터리구조 JEUS_HOME\ config\ <node-name>\ <node-name>_servlet_ <engine-name>\ X WEBMain.xml logs\ <node-name>\ <node-name>_ <container-name>\ servlet\ acesslog\ Legend: 0I: binary or executable file X: XML document J: JAR file T: Text file C: Class file V: java source file DD: deployment descriptor T acess_mmddyyyy.log errorlog\ T error_mmddyyyy.log userlog\ T user_mmddyyyy.log webhome\ app_home\ autodeploy\ JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name>\ Context Group 을설정하기위한 WEBMain.xml 을가지고있다. Context 는별도의파일에설정된다 ( jeus-web-dd.xml ). 36 JEUS Web Container 안내서

55 JEUS_HOME\logs\<node-name>\<node-name>_<container-name>\servlet\ 웹컨테이너를위한로그파일을보관하는최상위디렉터리이다. 사용자가 Context Group별로그를설정하는경우다음과같은구조로로그파일이생성된다. userlog\<context group name>\ user logging 메시지들이여기에저장된다. 이디렉터리는 valid day 시간설정이되어있지않으면다음디렉터리하위에 user.log 가생성된다. JEUS_HOME\logs\<node-name>\<node-name>_<container-name>\servlet\userlog\<context-group-name>\ valid day 가사용되면, 이디렉터리하위의파일들은주어진날들동안유효하고, user_mmd DYYYY.log 와같이파일명이생성된다. errorlog\ error logging 메시지파일은 Context Group 별로따로설정할수없다. 또한, errorlog 설정은 JEUSMain.xml을통해서만설정할수있다 ("JEUS Server 안내서 " 참조 ). 따라서, error logging 파일은 Context Group 별로구분하지않는다. accesslog\<context-group-name>\ access logging 메시지들이저장된다. valid day 시간설정이되어있지않으면다음디렉터리하위에 access.log 가생성된다. JEUS_HOME\logs\<node-name>\<node-name>_ <container-name>\servlet\accesslog\<context-group-name>\ valid day 가사용되면, 이디렉터리하위의파일들은주어진날들동안유효하고 access_mmd DYYYY.log 와같은이름의파일이생성된다 Context Group 설정 Context Group 을추가하고설정하는방법은간단하다. 그리고, 모든설정은엔진설정디렉터리의 WEB Main.xml 파일내에존재한다. 참고 1. WebAdmin을이용하여 WEBMain.xml에서 Context Group의설정에대한설명은 "JEUS WebAdmin 안내서 " 의 Context Group 설정을참고한다. 2. 본절에서는 Context Group의설정가능한모든컴포넌트들에대하여설명한다. 더상세한설명은 <context-group> 태그에대한설명이있는 JEUS_HOME\docs\reference\schema\index.html의 WEBMain.xml XML Reference를참고한다. 수작업으로환경을편집하려면 WEBMain.xml 파일을열고 <web-container> 태그아래에 <contextgroup> 태그를추가하고수정한다. 제 3 장 Context Group 37

56 [ 예 3.1] Context Group 설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> </context-group> <context-group>... </context-group>... </web-container> 다음은위의컴포넌트들의설정사항들이포함된 WEBMain.xml 파일의예이다. 이예는 XML 규칙과순서만보여주지만, 뒤이어설명될하위절에서는각 XML 부분들이구체적으로어떻게설정되는지보여줄것이다. <?xml version="1.0"?> <web-container xmlns=" <context-group> <group-name>mygroup</group-name> <virtual-host> <!-- See chapter 제7장가상호스트 --> </virtual-host> <webserver-connection> <!-- See chapter 제4장웹서버연결과클러스터링 --> </webserver-connection> <attach-stacktrace-on-error>...</attach-stacktrace-on-error> <encoding> <!-- See sub-section 인코딩설정 --> </encoding> <jsp-engine> <!-- See sub-section JSP 엔진설정 --> </jsp-engine> <logging> <!-- See sub-section Logging 설정 --> </logging> <session-config> <!-- See chapter Session 설정 --> </session-config> <response-header> <!-- See sub-section Response Header 설정 --> </response-header> </context-group> 38 JEUS Web Container 안내서

57 </web-container> 기본설정 Context Group의기본설정은 WEBMain.xml의 <context-group> 태그바로하위에설정되고다음과같이정의된다. [ 예 3.2] Context Group 기본설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <group-name>mygroup</group-name> <attach-stacktrace-on-error>true</attach-stacktrace-on-error> </context-group> </web-container> 다음은설정항목에대한설명이다. 항목 <group-name> <attach-stacktrace-on-error> 설명내부적으로통용되는 Context Group의식별자이다. 서버에문제가발생하였을때오류의상세내역을브라우저로보여줄것인지에대한설정이며, Boolean 값으로설정한다. 이메시지는개발할때는유용하지만운영할때는제거하는것이바람직하다. 다음의하위절들은 <context grpup> 하위컴포넌트들이어떻게설정되는지에대해설명한다 인코딩설정 Context Group은등록된모든 Context에의해사용될수있는인코딩설정을가지고있다. 여기에는 3가지의인코딩설정이존재한다. Request Url encoding HTTP 요청 URL을위한인코딩이다. Request Url encoding은웹브라우저로부터받은 HTTP 요청의 Request Line에적용된다. Request Url encoding이설정되지않은경우에는 Request encoding이적용된다. 일반적으로 Request Url en coding을지정해야하는경우는 HTTP Request Line의인코딩이 HTTP body와다른특별한경우이다. 제 3 장 Context Group 39

58 Request Url encoding은다음의순서에따라결정된다. 1. WEBMain.xml에정의된 forced 인코딩 2. HTTP header의 Accept-Language 필드값에해당하는인코딩 3. WEBMain.xml에정의된 default 인코딩 4. 위의어떤것도적용되지않으면기본적으로 ISO 로설정된다. 위의목록에서첫번째설정이가장높은우선순위를가지며첫번째설정이없을경우두번째설정이적용되는식으로순차적으로우선순위를갖는다. 단, 사용자가 Request 객체에 setcharacteren coding() 으로설정한경우, query string 및쿠키에대해서는사용자가설정한인코딩이최우선적으로적용된다. 따라서관리자는 WEBMain.xml에 default 와 forced 요청인코딩을정의할수있다. default와 forced 를동시에설정하는것은의미가없으므로하나만설정하도록한다. Request encoding HTTP Request header의 query string, 쿠키및 postdata에사용되는인코딩이다. 이인코딩은 jeusweb-dd.xml에서도설정이가능하며 jeus-web-dd.xml의설정이우선적으로적용된다. Request 인코딩은다음의순서에따라결정된다. 1. 애플리케이션 (Servlet/JSP) 에서의설정 (request.setcharacterencoding() 으로설정한인코딩 ) 2. WEBMain.xml에정의된 forced 인코딩 3. HTTP요청의 Content-Type의 charset에의한인코딩 4. HTTP header의 Accept-Language 필드값에해당하는인코딩 5. WEBMain.xml에정의된 default 인코딩 6. 위의어떤것도적용되지않으면기본적으로 ISO 로설정된다. 위의목록에서첫번째설정이가장높은우선순위를가지며첫번째설정이없을경우두번째설정이적용되는식으로순차적으로우선순위를갖게된다. HTTP Request Line의 query string은다음과같은우선순위로인코딩이적용된다. 1. request.setcharacterencoding() 으로지정한인코딩 2. Request URL encoding : 애플리케이션에서설정되지않은경우 3. Request encoding : Request URL encoding이설정되지않은경우 Response encoding 웹컨테이너로부터받은전체응답 HTTP 메시지에적용되는인코딩이다. Response encoding은 PrintWriter.println() 을 byte 배열로변환할때나 HTTP 헤더의 Content- Type:text/html;charset=XXX 부분의 XXX 값을설정하고웹컨테이너의응답에어떤인코딩을사용 40 JEUS Web Container 안내서

59 할지결정한다. 이인코딩도역시 jeus-web-dd.xml에서도설정이가능하며 jeus-web-dd.xml의설정이우선적으로적용된다. Response encoding은다음의우선순위목록에따라결정된다. 1. WEBMain.xml에정의된 forced 인코딩 2. Servlet에서의설정 (Servlet에서는 response.setcontenttype ( text/html;charset=xxx ), JSP에서는 <%@ page contenttype= text/html;charset=xxx %> 로프로그래머가설정한 XXX 값의인코딩 ) 3. WEBMain.xml에정의된 default 인코딩 4. 위의어떤것도적용되지않으면기본적으로 ISO 로설정된다. 위의목록에서첫번째설정이가장높은우선순위를가지며첫번째설정이없을경우두번째설정이적용되는식으로순차적으로우선순위를갖게된다. 위의내용처럼관리자는 WEBMain.xml에 default 와 forced response encoding을정의할수있다. 다음은 Context Group에서인코딩을설정한예로 WEBMain.xml에 <request url-encoding>, <requestencoding>, <response-encoding> 태그를이용하여설정할수있다. [ 예 3.3] Context Group 인코딩설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <encoding> <request-url-encoding> <forced>utf-8</forced> </request-url-encoding> <request-encoding> <default>euc-kr</default> </request-encoding> <response-encoding> <default>euc-kr</default> </response-encoding> </encoding> </context-group> </web-container> 각설정은 default 나 forced 로설정가능하다. 전자는어떤인코딩도없을경우에기본값으로사용하 고후자는모든경우에항상강제적으로사용하도록한다. 제 3 장 Context Group 41

60 다음목록은 Servlet/JSP 프로그래머나 JEUS 관리자가 WEBMain.xml에흔히설정할수있는인코딩값들이다. ISO ( 웹컨테이너에서기본으로사용하고있는인코딩, ISO Latin) UTF-8(UCS 변환포맷 ) EUC-KR( 한국어 ) EUC-JP( 일본어 ) JSP 엔진설정 각 Context Group은 JSP 엔진을포함하고있다. JSP 엔진은 jsp 자원을클라이언트가요청하였을때 JSP 페이지들을컴파일하여 Servlet 코드로만드는작업을한다. JSP 엔진의설정은 Context가속하는 Context Group의설정을상속받는다. JSP에대한자세한정보는 JSP 2.1 스펙을참고한다. 각 Context Group에는 JSP 엔진 (JSP 컴파일러 ) 이웹애플리케이션에대하여어떻게동작해야하는지에대한설정을한다. 다음은 JSP 엔진설정에대한예로 WEBMain.xml의 <context-group> 태그내의 <jspengine> 에설정한다. [ 예 3.4] JSP 엔진설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <jsp-engine> <keep-generated>true</keep-generated> <java-compiler>javac</java-compiler> <jsp-work-dir>c:\myjspworkdir\</jsp-work-dir> <compile-output-dir> c:\myjspworkdir\ </compile-output-dir> <compile-option>-g:none verbose</compile-option> <compile-encoding>8859_1</compile-encoding> <check-included-jspfile>true</check-included-jspfile> </jsp-engine> </context-group> </web-container> 42 JEUS Web Container 안내서

61 다음은설정태그에대한설명이다. <java-compiler>, <compile-output-dir>, <compiler-option>, <compiler-encoding> Java compiler options으로 JSP에서생성된 java 소스코드를 Servlet 클래스파일로컴파일할때필요한컴파일러를설정한다. 다음과같은옵션을포함한다. 항목 <java-compiler> <compile-output-dir> <compiler-option> <compiler-encoding> 설명 java compiler 실행명령어이다. 예 ) javac JSP에서생성된클래스파일의위치이다. java compiler 실행옵션이다. 예 ) -verbose g:none 이설정은웹컨테이너가적당한인코딩을알아서지정하므로많이사용되지않는다. 예 ) UTF8 <jsp-work-dir> JSP에서생성된 Java 소스파일들이저장되는루트디렉터리를지정한다. <compile-output-dir> 을설정하지않고 <jsp-work-dir> 만지정한경우클래스파일도동일한위치에생성된다. <jsp-work-dir> 을지정하지않는경우, 파일은 EAR 애플리케이션과모듈을구분하여, 디폴트디렉터리 (JEUS_HOME\webhome\<container_name>\_generated_\) 하위에생성된각각의디렉터리에저장된다. 각디렉터리의경로는다음과같다. EAR 애플리케이션 JEUS_HOME\webhome\<container_name>\_generated_\<application_name>\ 모듈 JEUS_HOME\webhome\<container_name>\_generated_\<module_name>\ <keep-generated> Boolean 옵션은 JSP 포맷에서변환을거친후 Servlet 소스코드의저장여부를결정한다. 디버깅을위해서이옵션을 true 로설정해놓으면유용하다. <check-included-jspfile> true 로설정되면요청한 JSP 페이지뿐만아니라 <%@ include file= xxx.jsp %> directive로 include 된모든 JSP들에대하여변경되었는지확인한다. 이설정이 true 로설정되고 include된 JSP파일이변경되었음이확인되면변경된파일은재컴파일된다. 기본설정인 false 는변경확인을하지않는다. 즉, 요청된 JSP만변경확인을한다. 제 3 장 Context Group 43

62 Logging 설정 Logging 옵션을 <web-container> 에설정하면모든 Context Group에공통으로적용되고, <context-group> 에설정하면설정한 Context Group에만적용된다. <context-group> 에설정된 Logging은 <web-container> 에설정된 Logging보다우선한다. <context-group> 의하위요소로설정하는 <logging> 은 <web-container> 의하위요소로설정하는 <logging> 과그구성이동일하다. 따라서, 자세한설정은 2.4. Logging 설정 을참고한다. Context Group에서설정가능한로그는다음과같다. User log Servlet에서생성된메시지와 ServletContext.log() 메소드에의해생성된내용들이별도의 user 로그에남겨진다. Access log Context Group에대한모든요청과사용자접근이별도의로그파일에남는다. 주의 요청이극도로빈번한사이트에서는 Access log 의양이방대해질수가있으므로, Access log 기능을 사용하지않는것이좋다. 별도의설정이없을경우웹컨테이너당 1개의 Access log 및 User log 파일이생성된다. JEUS의 log의기본위치 (JEUS_LOGHOME) 는 JEUS_HOME\logs\<node-name> 이다. GroupName은 <context-group> 의하위요소인 <group-name> 으로설정된값이다. Access log 기본위치 <JEUS_LOGHOME> 하위의 <node-name>_<container-name>\servlet\accesslog\<groupname>\ac cess.log가기본로그파일이다. JEUS_HOME이 c:\jeus6 이고 node_name이 johan, container_name이 container1, GroupName이 MyGroup인경우다음이기본로그파일이다. c:\jeus6\logs\johan_container1\servlet\accesslog\mygroup\access.log User log 기본위치 <JEUS_LOGHOME> 하위의 <node-name>_<container-name>\servlet\userlog\<groupname>\user.log 가기본로그파일이다. JEUS_HOME이 c:\jeus6 이고 node_name이 johan, container_name이 container1, GroupName이 MyGroup인경우다음이기본로그파일이다. c:\jeus6\logs\johan_container1\servlet\userlog\mygroup\user.log 44 JEUS Web Container 안내서

63 Context Group 에관련하여마지막으로설정할수있는것은 Logging 이다. 여기에는 2 가지종류의 Logging 메시지가있다. Logging 메시지설명 User 메시지 Access 로그 ServletContext.log() 메소드호출로 Servlet 프로그래머에의해지정된 Logging 데이 터이다. Context Group 과그 Context 의모든클라이언트요청을레코딩한다. 이설정들은 WEBMain.xml의 <context-group><logging> 태그의각기다른태그 (<user-log>, <access-log>) 로설정된다. 공통설정항목, Access log 및 User log 관련설정항목에대한설명은각각 공통설정항목, Access log 관련설정항목, User log 관련설정항목 을참고한다 Session 설정 Context Group에 Session 관련설정을할수있다. 이설정은웹컨테이너에서설정한것과동일하다. 다만 Context Group에서의설정은웹컨테이너에서의설정보다높은우선순위를가지고적용된다. 자세한내용은 Session 을참고한다. 다음은 Context Group 레벨에서 Session을설정한예이다. [ 예 3.5] Context Group 레벨에서 Session 설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <session-config> <distributable>false</distributable> <shared>false</shared> <timeout>30</timeout> <reload-persistent>false</reload-persistent> <url-rewriting>false</url-rewriting> <session-cookie> <jsessionid-name>jsessionid</jsessionid-name> <version>0</version> <path>/</path> <max-age>-1</max-age> <secure>false</secure> </session-cookie> </session-config> 제 3 장 Context Group 45

64 </context-group> </web-container> Response Header 설정 사용자임의의 HTTP Response Header를이름과값의짝으로정의할수있다. Custom Response Header는각 Context Group 하위의 <response-header><custom-header> 태그에설정된다. 이태그가존재하면다음의두항목과함께복수개의 <header-field> 태그가포함될수있다. 다음은 Response Header 설정을한예이다. [ 예 3.6] Response Header 설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <response-header> <custom-header> <header-field> <field-name>test</field-name> <field-value>testvalue</field-value> </header-field> </custom-header> </response-header> </context-group> </web-container> 다음은설정태그에대한설명이다. <header-field> 태그 <field-name> <field-value> 설명 <custom header> 필드의이름을지정한다. <field name> 과함께전달될값을지정한다. 46 JEUS Web Container 안내서

65 3.4. Context Group 모니터링 Context Group 을모니터링은 jeusadmin 과 WebAdmin 기능을사용한다. jeusadmin 을사용한 Context Group 모니터링 jeusadmin에서 info 를수행하여디플로이되어있는모든 Context Group의목록을조회할수있다. 다음은특정 Context Group에대한정보를조회하는방법이다. info <context group name> WebAdmin 을사용한 Context Group 모니터링 WebAdmin을사용하여 Context Group을모니터링할수있다. WebAdmin화면왼쪽의 JEUS 노드트리에서 JEUS 매니저 > 엔진컨테이너 > container name > 엔진 > 서블릿엔진 > 컨텍스트그룹에서원하는 Context Group name을클릭하면해당 Context Group에대한정보를조회할수있다 Context Group 튜닝 Context Group의최적화된성능을주기위해서는다음의 2가지를반드시고려해야한다. 일반적으로 JSP 엔진의컴파일러는변경할필요가없다. sun.tools.javac 설정으로그대로유지하여또다른외부프로세스가 JSP 페이지를컴파일할때필요하지않도록한다. <check-included-jspfile> 는 include된 JSP들이자주변경되지않는다면설정을 false 로그대로유지한다. 이것은 include 된 JSP 파일들에대한변경점검을하지않기때문에성능향상에도움이된다. 모든종류의로그는성능향상을위하여다음의설정을사용한다. "fatal" 로그레벨과 file 타겟 큰버퍼사이즈 제 3 장 Context Group 47

66

67 제 4 장웹서버연결과클러스터링 본장에서는웹컨테이너의앞단에서사용할수있는 1 개이상의웹서버를설정할때알아야할사항들 과자체적으로가지고있는웹서버를최대한이용하는방법에대하여설명한다 개요 웹컨테이너를사용하기위해서는 HTTP 클라이언트와웹컨테이너사이에서중간자역할과코디네이터역할을하는 1개이상의웹서버를설정해야한다. 이러한관점에서웹서버는클라이언트와웹컨테이너구조에서중간계층역할을수행한다. 웹서버의기능은기본적으로클라이언트의 HTTP 요청을받고분석하고, 뒷단의웹컨테이너에있는 Context( 웹애플리케이션 ) 에전달해야할요청이라고판단되면컨테이너로요청을전달하는것이다. 컨테이너는그요청을분석하고수행하여클라이언트에게응답을전달할수있는웹서버에게돌려보낸다. 그러한중간계층으로서웹서버는 2가지종류가있다. WebtoB 웹서버와 Apache 웹서버가그것이다. 이 2가지의웹서버외에컨테이너자체에는개발과테스트용도로사용할수있는 2개의간단한웹서버와 TCPListener 라는특수목적을가진웹서버가존재한다. Apache, IIS, SunOne(Iplanet) 웹서버와의연결을위한 AJP13, WebtoB, HTTP, HTTPS, TCP, TMAX 등의리스너를통하여여러종류의웹서버, 클라이언트연결이존재한다. 앞의 2개의리스너는앞단의웹서버를통하여클라이언트의요청을컨테이너에게중재시켜주는역할을한다. Tmax 리스너는 Tmax와의연동을위한특별한리스너이고, 나머지는웹컨테이너에통합된형태의클라이언트리스너들이다. 각기다른연결방법에따라어떻게설정하는지와웹컨테이너와연결하기위해웹서버에어떤것들을설정해야하는지도설명한다. 그리고간단히웹서버클러스터를구성하는방법도설명한다. 제 4 장웹서버연결과클러스터링 49

68 4.2. 웹서버연결 본절에서는웹컨테이너, 웹서버, 클라이언트간의기본적인구조를설명하고웹컨테이너와연결할수있는여러종류의웹서버리스너들에대하여설명한다. 다음은웹서버연결에관련된웹컨테이너의주요부분을보여주고있다. [ 그림 4.1] JEUS 웹컨테이너중웹서버연결부분컴포넌트 JEUS Web Container Context Group A Client A Web Server A Web server connection/list ener Virtual Host A Misc. context group settings Default Virtual Host Monitoring thread Context/Web app A Context/Web app B Misc. container settings Client B Web Server B Context Group B Web server connection/list ener Virtual Host B Misc. context group settings Default Virtual Host Session handling settings Session Server Context/Web app C Context/Web app D 리스너 우선 리스너 가어떤의미를가지고있는지에대하여분명히이해해야한다. 리스너는일반적으로웹서버나 HTTP 클라이언트가직접접근할수있는웹컨테이너측의소켓이라고생각할수있다. 이리스너 ( 소켓 ) 는웹서버 ( 또는 HTTP 클라이언트 ) 로부터요청을받고웹컨테이너에서처리한 static 또는 dynamic content를반환한다. dynamic content는 JSP 나 Servlet과같은 Java 기반의콘텐츠를의미하고 static content는 HTML 페이지나이미지파일과같은이미생성된데이터를의미한다. 리스너에는 2가지종류가존재한다. [ 그림 4.2] 웹컨테이너의웹서버와클라이언트리스너 JEUS Node A Web Container A Client A HTTP protocol Port 80 Custom protocol Port 9900 Context Group A Web Server Listener A Client B Web Server A HTTP protocol Port 8088 Context Group B Client (HTTP) Listener A 50 JEUS Web Container 안내서

69 웹서버리스너외부의웹서버들과연결되고이들과통신을위해서맞춤프로토콜을사용한다. 클라이언트는이웹서버를통하여웹컨테이너와통신한다. 클라이언트리스너주로클라이언트와직접연결되고 HTTP 프로토콜을사용한다. 이리스너들은종류에상관없이컨테이너레벨에서설정되지않고, Context Group 레벨에서설정된다. 주목할점은 Context Group 리스너의또다른사항은이론적으로는다수의리스너가각 Context Group에설정될수있다는것이다. 단, 한가지의제약조건은각리스너들이각기다른리스닝포트를지정받아설정되어야한다는것이다. HTTP/HTTPS 리스너 HTTP/HTTPS 리스너는 static content와 JSP/Servlet, SOAP over HTTP 웹서비스에대한 HTTP 요청을웹컨테이너가직접받을때사용한다. HTTP 리스너는 SSL을지원하며 4.3. 리스너설정 과 4.6. 보안 (SSL) 리스너사용 에상세한설명이있다. WebtoB 또는 Apache/IIS/SUNOne 웹서버등의웹서버가웹컨테이너앞단에위치하는경우에는 WebtoB 리스너혹은 AJP13 리스너를사용한다. TCP 리스너 TCP 리스너는일반적인리스너에맞춤프로토콜 (HTTP를사용하지않음 ) 을사용하는리스너이다 리스너설정 과 4.5. TCP 리스너사용 에서자세히설명한다. WebtoB 리스너 WebtoB는 JEUS 웹애플리케이션서버의기본웹서버다. WebtoB는 static 페이지전송, CGI, SSI, PHP 등기본적인웹서버기능들을모두지원한다. JEUS 웹컨테이너와인터페이스할때에는 Servlet/JSP 서비스도제공한다. WebtoB 리스너는위에서언급한리스너와조금다른종류의리스너라고할수있다. WebtoB 리스너는다른리스너와달리리스너가 WebtoB 서버의위치를찾아서, 접속하고자하는특징을가진다. 그러므로, WebtoB 리스너를사용할때에는 WebtoB 서버가리스닝모드로대기를하고, WebtoB 리스너 ( 즉, 웹컨테이너 ) 가연결을시도한다. 이러한연결방식을 Reverse Connection Pooling이라한다. 참고 위문장은 WebtoB 서버가웹컨테이너보다먼저구동중에있어야한다는것을의미한다. 이런특징의결과로방화벽밖에 WebtoB 서버를위치하고안쪽에서리스너를이용하여연결을맺을수있다. 이것은방화벽이주로외부로부터의연결시도를억제하고내부로부터의연결은가능하게하여방화벽의장점을그대로살릴수있는특징을부여한다. 둘째, WebtoB와웹컨테이너가같은머신내에존재하면둘간의통신은 Pipe 통신을사용한다. 일반적인소켓방식을사용하는것보다 Pipe 통신을함으로 제 4 장웹서버연결과클러스터링 51

70 써월등한성능향상을기대할수있다. Pipe 통신은 UNIX(LINUX) 계열의장비에만사용이가능하다 (Windows 계열의장비에는일반소켓만사용가능하다 ) 리스너설정 과 4.4. 리스너연동과클러스터링을위한웹서버설정 에서자세히설명한다. 참고 JEUS 내부적으로제공하는 WS 엔진은노드당하나만을사용할수있다. Ajp13 리스너 위에서언급한 WebtoB 이외의다른웹서버, 예를들면 Apache, IIS, SunOne(Iplanet) 등을사용할경우에도 JEUS 웹애플리케이션과의상호연동이가능하도록해주는프로토콜이다. mod_jk module을통해지원을하며 AJP1.3 프로토콜을사용한다 리스너설정 과 4.4. 리스너연동과클러스터링을위한웹서버설정 에서자세히설명한다. Tmax 리스너 Tmax는분산환경에서이질적인자원을통합해주는시스템소프트웨어이다. Tmax 리스너는 Tmax와연동하기위한특수한리스너로 WebtoB 리스너와마찬가지로활동적인리스너이기때문에웹컨테이너를구동시키기전에 Tmax가먼저구동되어있어야한다. Tmax 리스너는 JEUS 와 Tmax 간의정보를주고받거나, http 요청을 Tmax의게이트웨이를통해받음으로써통신채널을일원화하는등의용도로사용될수있다 Worker Thread 와 Worker Thread Pool 웹서버리스너와연관된중요한개념중하나가 Worker Thread 에관한것이다. 각리스너에는 Pool(Worker Thread Pool) 이라는것이포함되어있다. 이것은 Worker Thread들을관리한다. 리스너의포트로요청이도착했을때 1개의 Worker Thread가이 Pool에서꺼내지고, 요청을처리하기위해지정받은후응답을만들어낸다. 여기에서의 처리 라는개념은 static content를가져오는것에부터 JSP나 Servlet을실행하는것까지모두를포함한다. Worker Thread 라는개념은이문서의많은부분에서거론된다. 예를들어 Context Group의 Active- Management 설정은직접적으로이 Worker Thread Pool에연관되어있다. 그러므로, Thread Pool 포트 또는 Thread Pool 주소 라는개념이사용될때에는 Worker Thread를주관하는리스너의포트번호와 IP 주소를의미한다 ( 그리고간접적으로 Worker Thread도의미한다 ). Worker Thread Pool 대신에 Thread Pool 을사용하기도한다. 웹서버리스너를설정할때에는 Thread Pool의일정한사양도같이설정해야한다 Thread Pool 의 Active-Management 와상태통보 각리스너에설정되는 Thread Pool 은 Active-Management 에관한설정도포함되어있다. 52 JEUS Web Container 안내서

71 Active-Management는관리자가설정된상태가되면웹컨테이너가경고성 통지하거나웹컨테이너가자동으로재시작하도록설정할수있다. 설정되어야할조건은 Servlet Worker Thread가 Block되었다고판단하는기준시간에대한설정이며, 설정한시간에따라가 Servlet Worker Thread가 Block되었다고판단을한다. 경고 통보또는컨테이너재시작같은특정작업이시작되기전에몇개까지의 Block된 Thread들이존재할수있는지를설정한다. 주의재시작옵션은임시적인해결책이고, 재시작이발생할경우에는관리자가원인을찾아반드시문제를해결해야한다. 그리고 Active-Management 기능을설정할때너무자주발생하지않도록유의해야한다 여러개의웹컨테이너와웹서버클러스터링 여러개의웹서버와리스너들을연결시키는것을클러스터링이라하고이과정에서생성된조직체를클러스터라고한다. 거대한사이트에서는많은양의클라이언트요청을처리하기위하여 부하분산 이라는기술과함께반드시사용되어야하는기술이다. 부하분산은기본적으로클러스터내의어떤서버에게요청을처리하도록지정할것인지를정의하여클러스터내의서버들에게골고루요청이전달되어처리되도록한다. 부하분산기는모든클라이언트요청을받아그순간가장여유로운웹서버에게지정해주는소프트웨어이다. 다음은 2개의웹서버 (WebtoB 또는 Apache) 가각각 2개의웹컨테이너에연결되어있는작은클러스터구조를보여주고있다. [ 그림 4.3] 2개의웹서버가 2개의웹컨테이너에각각연결되어있는작은클러스터 JEUS Node A Web Container A Context Group A Web Server Listener A JEUS Node B Web Container B Client Requests Load Balancer Web Server A Context Group B Web Server Listener B JEUS Node C Web Container C Context Group C Web Server Listener C JEUS Node D Web Container D Web Server B Context Group D Web Server Listener D 제 4 장웹서버연결과클러스터링 53

72 참고 위그림과같은설정은각웹컨테이너에동일한 Context Group 과 Context 를가지고있어야한다 ( 즉, Context A, B, C, D 는모두같은것이어야한다 ). 또한, 웹서버와리스너의연동과클러스터링에서중요한것은클라이언트 Session을어떻게 Tracking하는지에대한것이다. 클라이언트 Session 데이터가여러개의웹컨테이너 (Context) 에정확하게분배되는지에대한사항은클러스터규모가커질수록더중요해진다. 이중요한사항에대해서는 제5장 Session Tracking 에서설명한다. 본장에서는 Session 데이터의존재에대하여무시하고진행한다. 이러한웹서버클러스터를실제로어떻게설정하는지에대하여본장의 4.4. 리스너연동과클러스터링을위한웹서버설정 에서자세히설명한다 리스너설정 리스너를설정하는작업은매우간단하다. 그러나, 웹서버리스너를실제웹서버 (WebtoB, Apache, IIS, SunOne, etc...) 와연동시킬경우에는웹서버측에서도설정이필요하다. 그러나클라이언트타입리스너는그자체가완전한웹서버역할을하기때문에별도의설정이필요하지않다. 본절에서는웹컨테이너측의 Context Group 리스너의설정에대해서만설명한다. WebtoB 리스너, AJP13 리스너, Tmax 리스너가다른종류의리스너설정과는차이점이있기때문에 WebtoB 리스너, AJP13 리스너, Tmax 리스너에관련된사항들을제외한다른나머지리스너에관련된사항들만을설명한다. WebtoB와다른웹서버의해당설정은 4.4. 리스너연동과클러스터링을위한웹서버설정 을참고한다. 참고 Context Group 의웹리스너설정은 WebAdmin 에서도가능하다. 모든리스너는 WEBMain.xml의 <context-group><webserver-connection> 태그하위에설정된다. 각 Context Group에는단하나의 <webserver-connection> 태그가존재할수있지만그하위에는여러개의리스너설정이존재할수있다는의미이다. 각 Context Group은단한개의 <webserver-connection> 설정을가져야한다. [ 예 4.1] 리스너설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <webserver-connection> <webtob-listener> </webtob-listener> <http-listener> 54 JEUS Web Container 안내서

73 </http-listener> <http-listener> <scheme>https</scheme> <ssl-config> <enable-secure>true</enable-secure> </ssl-config> </http-listener> <tcp-listener> </tcp-listener> <ajp13-listener> </ajp13-listener> </webserver-connection> </context-group> </web-container> HTTP, TCP, HTTPS 리스너설정 HTTP, TCP, HTTPS 리스너의설정은단한가지의예외를제외하고모두동일하므로모두같은방법으로설명한다. 다음의 XML 태그들은 HTTP, TCP, HTTPS 리스너를설정할때사용되는것들이다. HTTP 리스너 : <http-listener> TCP 리스너 : <tcp-listener> 보안 /SSL 리스너 : <http-listener>,<ssl-config> 다음의 XML 예제는 HTTP 리스너의설정이며, 그밖의다른리스너에대해서는순차적으로설명한다. [ 예 4.2] HTTP, TCP, HTTPS 리스너설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <webserver-connection> <http-listener> 제 4 장웹서버연결과클러스터링 55

74 <listener-id>weblistener1</listener-id> <ip> </ip> <port>8007</port> <output-buffer-size>16384</output-buffer-size> <thread-pool> <min>10</min> <max>20</max> <step>2</step> <max-idle-time>60000</max-idle-time> <max-wait-queue>10</max-wait-queue> <max-queue>50</max-queue> <thread-state-notify> <!-- see next sub-section --> </thread-state-notify> </thread-pool> <postdata-read-timeout> </postdata-read-timeout> <scheme>http</scheme> <back-log>100</back-log> <server-access-control> true </server-access-control> <allowed-server> </allowed-server> </http-listener> </webserver-connection> </context-group> </web-container> 위태그들의하위태그 ( 설정 ) 들은다음과같다. <listener-id> 리스너의유일한식별자이다. 이름은 WEBMain.xml 파일내부에서유일한것이어야한다. <ip> 클라이언트가연결되어있는 IP 주소이다. 보통의경우에는이설정을하지않아도머신의 IP 주소가사용되므로설정할필요가없고, IP 주소가 2개이상이어서그중하나를지정해야하는등의특별한경우에만설정한다. HTTP 리스너에서설정가능한태그이다. <port> 클라이언트가연결되어있는포트번호이다. HTTP를위해서는기본적으로 80번을사용하고 SSL을위해서는 443을사용한다. 56 JEUS Web Container 안내서

75 (IANA, 에서정의 ) JEUS 설정에서는어떤포트도기본으로설정되어있지않으므로이태그는모든리스너에서반드시지정해야한다. <output-buffer-size> Servlet 결과가임시적으로저장되는내부 Cache 버퍼의크기를결정한다. 버퍼가가득찼을때에는한번에클라이언트에게모두보내진다. 이옵션은성능향상을위해사용되지만일반적으로사용되지않는다. <thread-pool> 각리스너의 Worker Thread Pool의크기와행동방식을결정짓는다. Worker Thread가클라이언트요청을처리하기위해서사용되며 Pool 크기가크면클수록더많은요청이동시에처리될수있다 ( 시스템리소스를많이사용한다 ). 다음의하위태그를이용해서 Thread Pool 정보를설정한다. 태그 <min>, <max> <step> <maximum-idle-time> 설명 Pool에서관리할최소및최대 Worker Thread의개수이다. Pool의크기가증가할때 Thread가몇개씩증가할것인지를지정한다. Pool 내에존재하던 Thread가제거되기전까지의사용되고있지않은시간을지정한다 ( 결과로시스템자원은늘어난다 ). 각 Worker Thread Pool은 request wait queue를가지고있다. 이 Queue는실제가용한 Worker Thread보다많은요청이들어올때사용된다. 이 Queue 는소켓리스너에의해유지되는낮은레벨의 Backlog Queue보다상위레벨의 Queue이다. 다음의두태그는이 Queue와관련된것들이다. <max-wait-queue> 더많은 Worker Thread 가 Pool 에생성되기전에얼마나많은요청들이 Re quest Wait Queue 에존재할수있는지에대해결정한다 ( 몇개의 Thread 가 증가될지는 step 설정에서정의된다 ). 단, NIO(Non-blocking I/O) 방식의리스너에서는이설정값은무시된다. <max-queue> 설정은 Queue 에대기할수있는최대요청값을설정한다. 이 Queue가가득찬후에더많은요청이도착하면 busy 페이지가클라이언트에게반환된다. 각 Thread Pool은장애가발생하였을때취하는액션을정의하는 <thread-state-notify> 태그를가지고있다. 이것에대해서는다음하위절들을참조한다. 값이 -1일경우 Queue 크기에제한을두지않는것을의미한다 (Blocking 방식의리스너의경우 ). 만약 Listener가 NIO(Non-blocking I/O) 방식을사용한다면엔진내부적으로 Bounded Queue를사용하므로항상 0보다커야한다. NIO(Non-blocking I/O) 방식에서 0보다같거나작은값을설정한경우는디폴트값인 4096을사용한다. 제 4 장웹서버연결과클러스터링 57

76 참고 NIO(Non-blocking I/O) 방식에서는 thread의 <max>, <min>, <max-queue>, <max-idle-time> 에따른동작방식이 Blocking방식과약간다르다. NIO(Non-blocking I/O) 방식의경우최초 <min> 값만큼 Worker Thread를생성하고 Queue가 full 상태일때 Worker Thread를 <max> 까지늘려준다. 또한 <min> 보다늘어난 Worker Thread에대해서는 <max-idle-time> 의설정시간동안 thread가 idle상태가될때 <min> 까지 idle thread를종료시킨다. Blocking방식에서는 Queue가 <max-wait-queue> 만큼되면 Worker Thread를 <max> 까지늘린다. <postdata-read-timeout> 웹서버나 Web Client에서 post-data를읽어들일때기다릴수있는최대시간값이다. 읽기는 request.getinputstream().read() 메소드로한다.( 기본값 : 30000, 단위 : millisecond) <scheme> javax.servlet.http.httpservletrequest.getscheme() 메소드에의해반환되는프로토콜의값을정의한다. WebtoB나 Apache에서 SSL 기능을사용할경우에는 https 값이지정되어야한다. 보안리스너의경우에는특별히설정하지않아도 "https" 로동작한다. <back-log> 요청이매우빈번하고리스너가더이상지탱하지못할경우에 Queuing될수있는최대클라이언트요청값을지정한다. 리스너 Server 소켓이인스턴스화되었을때 java.net.serversocket(int port, int backlog) 에전달된다. Queuing된클라이언트연결요청값이 backlog 크기를초과할경우에는클라이언트는 connection refused 메시지를받는다. <server-access-control> Boolean 스위치는클라이언트또는웹서버접근제한을켜고끈다. <allowed-server> <server-access-control> 이켜져있을때만사용할수있다. 목록은어떤클라이언트또는서버들이이리스너에접근할수있는지지정한다. 목록의클라이언트들은그들의 IP 주소를이용하여식별한다. <use-nio> HTTP, TCP 리스너에서만설정가능하며이것을 true로할경우 NIO(Non-blocking I/O) 리스너로동작하게된다. NIO 리스너를사용하면커넥션을담당하는 Thread와 Worker Thread가분리되어있어서기존방식에서동시에처리할수있는커넥션의개수가 Worker Thread 수보다작을수밖에없는문제점을해결할수있다. 58 JEUS Web Container 안내서

77 <selector-count> NIO HTTP, TCP 리스너사용시 (use-nio=true) Selector의개수를지정하는설정이다. 기본으로한개로설정되며커넥션의개수가많아성능이저하될경우 Selector 개수를적절히증가시켜주면성능이향상될수있다. <dispatcher-config-class> TCP 리스너에서는정식명칭의 dispatcher config class 클래스이름을지정하는태그이다. TCP 리스너는 HTTP 프로토콜을사용하지않는다. 대신, TCP 리스너와그클라이언트사이에한정된맞춤프로토콜을제공한다. 이맞춤프로토콜은 <dispatcher-config-class> 를이용하여정의된다. <dispatcher-config-class> 태그는 jeus.servlet.tcp.tcpdispatcherconfig로구현한정식클래스명을정의한다. 구현된클래스는반드시 JEUS_HOME\lib\application 아래에위치해야한다. TCP 클라이언트를서비스하기위해서는 jeus.servlet.tcp.tcpservlet을구현한클래스를생성해야하며이를 web.xml에매핑해야한다. 자세한내용은 4.5. TCP 리스너사용 을참고한다 WebtoB 리스너설정 WebtoB 리스너는다른종류의리스너와는다르다. 그래서본절에서그차이점에대해별도로설명한다. 다음은 WebtoB 리스너설정의예로 WEBMain.xml 파일내 <webserver-connection> 의 <webtob-listener> 태그에서설정한다. [ 예 4.3] WebtoB 리스너설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <webserver-connection> <webtob-listener> <listener-id>weblistener2</listener-id> <port>9900</port> <output-buffer-size>16384</output-buffer-size> <thread-pool> <min>10</min> <max>10</max> <step>4</step> <max-idle-time>60000</max-idle-time> <max-wait-queue>2</max-wait-queue> <thread-state-notify> <max-thread-active-time> </max-thread-active-time> 제 4 장웹서버연결과클러스터링 59

78 <notify-threshold> 100 </notify-threshold> <restart-threshold> 18 </restart-threshold> <notify-subject> JEUS WEB CONTAINER THREAD STATE WARNING </notify-subject> <restart-subject> JEUS WEB CONTAINER RESTART WARNING </restart-subject> </thread-state-notify> </thread-pool> <postdata-read-timeout> </postdata-read-timeout> <scheme>http</scheme> <hth-count>2</hth-count> <request-prefetch>true</request- prefetch> <disable-pipe>false</disable-pipe> <webtob-address> </webtob-address> <registration-id>mygroup</registration-id> <webtob-home>c:\webtob\</webtob-home> <read-timeout>120000</read-timeout> <reconnect-timeout>60000</reconnect-timeout> <webtob-backup> <port>9901</port> <output-buffer-size> </output-buffer-size> <thread-pool> </thread-pool> <webtob-address> </webtob-address> </webtob-backup> </webtob-listener> </webserver-connection> </context-group> 60 JEUS Web Container 안내서

79 </web-container> 다음은설정태그에대한설명이다. 태그 <listener-id> <port> <output-buffer-size> <thread-pool> 설명 HTTP, TCP, HTTPS 리스너설정 에서설명한유일한이름이다. WebtoB 서버와연결할포트로, 포트값은 WebtoB 설정파일내의 JSVPORT 설정값과일치해야한다 HTTP, TCP, HTTPS 리스너설정 에서설명한것과같다 HTTP, TCP, HTTPS 리스너설정 에서설명한것과같다. WebtoB에서다른점은 <min>, <max> 값이 WebtoB 설정파일의 *SERVER 절에지정된 MinProc, MaxProc 값과일치해야한다. <min> 과 <max> 값을설정하기전에 4.4. 리스너연동과클러스터링을위한웹서버설정 을먼저읽어보길바란다. 또한, <max-queue> 크기설정은사용하지않지만 WebtoB 설정파일에서 MaxQCount 값으로설정될수있다. <postdata-read-timeout> <scheme> <hth-count> <request-prefetch> HTTP, TCP, HTTPS 리스너설정 을참고한다 HTTP, TCP, HTTPS 리스너설정 을참고한다. WebtoB 설정파일의 *NODE 절에지정된 HTH 프로세스개수와일치해야한다 리스너연동과클러스터링을위한웹서버설정 을참조한다. 웹컨테이너측에서요청을처리하는동안다음요청을 WebtoB로부터미리받아올것인지정한다 (Boolean값). 기능이활성화되면, 웹컨테이너는각 WebtoB Worker Thread 마다하나의 Queue를할당한다. Queue는 Worker Thread가현재요청을처리하는동안 WebtoB로부터오는요청을버퍼링한다. 따라서웹컨테이너는 WebtoB로부터다음요청을받는시간을단축할수있다. 이기능의단점은요청을처리하는도중웹컨테이너에심각한문제가발생하면, Queue에축적된요청들을잃어버릴수있다는점이다. <disable-pipe> <webtob-address> <registration-id> <webtob-home> 설정이 "true" 로설정되어있으면 WebtoB와웹컨테이너의효율적인 Pipe 통신을불가능하게한다. WebtoB 서버와웹컨테이너가다른머신에서수행되고있으면필요한항목이다. 웹컨테이너와연결을맺을 WebtoB의 IP 주소항목이다. WebtoB 설정파일의 *SERVER 값과일치해야한다. 설정하지않은경우기본값으로이값은 Context Group의이름과같은값으로설정된다. JEUS_WSDIR이라는환경변수로정의된 WebtoB의기본 WebtoB Home과다를경우에설정한다 ( 또는그환경변수가설정되어있지않을때 ). 제 4 장웹서버연결과클러스터링 61

80 태그 설명 2 개이상의 WebtoB 인스턴스가로컬머신에서운영되고있고웹컨테이너가 이 2 개이상의 WebtoB 인스턴스에연결될필요가있을때유용하다. <read-timeout> WebtoB 웹서버는지속적으로웹컨테이너에게 WebtoB 의설정파일에정의 된 svrchktime 변수값의간격으로 ping 메시지를보낸다. 웹컨테이너는여기에서정의한시간간격으로 WebtoB의 ping을체크한다. WebtoB의 ping이여기에서설정된시간간격내에서발견되지않으면통신연결은끊어진것으로간주되어다시설정된다. 그러므로, 여기의값은 svrchktime 보다커야한다. <reconnect-timeout> WebtoB 서버와 WebtoB 리스너사이의연결들이운영도중끊어지는경우가 발생할수있다. reconnect-timeout 은이러한경우에재연결시도를위한제 한시간이다. 제한된시간이지나면현재의모든 WebtoB 연결은끊어지고, 만약 WebtoB 백업이지정되어있으면웹컨테이너는다음 WebtoB 서버에 Fail-over를시도한다. 다음 WebtoB 백업마저장애가발생한다면그다음의것을시도한다. 최후의 WebtoB 마저장애가발생하면주 WebtoB 리스너에시도하게된다. -1 은무한대반복시도, 0 은재연결시도를하지않음을의미한다. <webtob-backup> WebtoB 리스너의설정과비슷하다. 하지만 WebtoB backup 태그는 Automatic Connection Recovery기능을수행하기위해서주서버가심각한장애상태가되었을때, 두번째 WebtoB 서버에연결하기위한연결정보를정의한다. 따라서 Backup WebtoB의설정은 Main WebtoB 장애가발생하면 Backup WebtoB로연결하기때문에무장애시스템구현을가능하게한다. 여기서주의할것은백업서버에 Thread Pool에대한설정이없다면주 WebtoB 리스너의설정에서상속받는다는것이다. 참고 WebtoB 웹서버설정과클러스터링 에서는어떻게실제의 WebtoB 서버가설정되어이리스 너에게연결되는지설명한다. 또한리스너설정과 WebtoB 의설정파일간의관계도설명한다 AJP13 리스너설정 AJP13 리스너는 WEBMain.xml 파일내 <webserver-connection> 태그아래의 <ajp13-listener> 태그에서설정한다. 다음은 AJP13 리스너의 XML 설정예이다. 62 JEUS Web Container 안내서

81 [ 예 4.4] AJP13 리스너설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <webserver-connection> <ajp13-listener> <listener-id>weblistener3</listener-id> <port>9901</port> <output-buffer-size>8192</output-buffer-size> <thread-pool> <min>10</min> <max>10</max> </thread-pool> </ajp13-listener> </webserver-connection> </context-group> </web-container> 다음은설정태그에대한설명이다. 태그 <listener-id> <ip> <port> <output-buffer-size> 설명 HTTP, TCP, HTTPS 리스너설정 에서설명한유일한이름이다. 클라이언트가연결되어있는 IP 주소이다. 보통의경우에는이설정을하지않아도머신의 IP 주소가사용되므로설정할필요가없고, IP 주소가 2개이상이어서그중하나를지정해야하는등의특별한경우에만설정한다. AJP13 리스너에서설정가능한태그이다. 특정웹서버와연결할포트를설정한다. 이값은특정웹서버설정파일내의 JEUS에해당하는서버에대한설정값과일치해야한다. 특정웹서버설정과관련된사항은 4.4. 리스너연동과클러스터링을위한웹서버설정 을참고한다 HTTP, TCP, HTTPS 리스너설정 에서설명한것과같다. 다만 AJP13 리스너의경우이설정값을 mod_jk module 의 workers.properties 파일의 max_packet_size 와일치시킨다. mod_jk module 의설정에대해서는 4.4. 리스너연동과클러스터링을위한웹서버설정 을참고한다. <thread-pool> HTTP, TCP, HTTPS 리스너설정 에서설명한것과같다. 다만 AJP13 리스너의경우 min, max 값을서로다르게줄특별한이유가없다. 제 4 장웹서버연결과클러스터링 63

82 태그 설명 특별한상황이아닌이상 min, max를일치시킨후이값을 mod_jk module의 workers.properties 파일의 connection_pool_size, connec tion_pool_size_min_size와일치시킨다. mod_jk module의설정에대해서는 4.4. 리스너연동과클러스터링을위한웹서버설정 을참고한다. <postdata-read-timeout> HTTP, TCP, HTTPS 리스너설정 에서설명한것과같다 Tmax 리스너설정 각 Tmax 리스너는 WEBMain.xml 파일내 <webserver-connection> 태그아래의 <tmax-listener> 태그에서설정한다. 다음은 Tmax 리스너의 XML 설정예이다. [ 예 4.5] Tmax 리스너설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <webserver-connection> <tmax-listener> <listener-id>weblistener4</listener-id> <port>9902</port> <output-buffer-size>16384</output-buffer-size> <thread-pool> <min>10</min> <max>10</max> <step>4</step> <max-idle-time>60000</max-idle-time> <max-wait-queue>2</max-wait-queue> <thread-state-notify> <max-thread-active-time> </max-thread-active-time> <notify-threshold>100</notify-threshold> <restart-threshold> 18 </restart-threshold> <notify-subject> JEUS WEB CONTAINER THREAD STATE WARNING </notify-subject> <restart-subject> 64 JEUS Web Container 안내서

83 JEUS WEB CONTAINER RESTART WARNING </restart-subject> </thread-state-notify> </thread-pool> <postdata-read-timeout> </postdata-read-timeout> <tmax-address> </tmax-address> <reconnect-timeout>60000</reconnect-time> <server-group-name>tmaxgroup</server-group-name> <server-name>svr1</server-name> <tmax-backup-address> </tmax-backup-address> <tmax-backup-port>9902</tmax-backup-port> </tmax-listener> </webserver-connection> </context-group> </web-container> 다음은설정태그에대한설명이다. 태그 <listener-id> <port> <output-buffer-size> <thread-pool> <postdata-read-timeout> <tmax-address> <reconnect-timeout> <server-group-name> <server-name> 설명 HTTP, TCP, HTTPS 리스너설정 에서설명한유일한이름이다. Tmax 서버와연결할포트로, 이포트값은 Tmax 설정파일내의 JEUS에해당하는서버에대한설정값과일치해야한다 HTTP, TCP, HTTPS 리스너설정 에서설명한것과같다 HTTP, TCP, HTTPS 리스너설정 에서설명한것과같다. Tmax 리스너의경우도 WebtoB 리스너와동일하게동작한다 HTTP, TCP, HTTPS 리스너설정 에서설명한것과같다. 웹컨테이너와연결을맺을 Tmax 서버의 IP 주소항목이다. Tmax 서버와 Tmax 리스너사이의연결중일부가운영도중끊어질경우가생길수있다. <reconnect-timeout> 은이러한경우에재연결시도를위한제한시간이다. 역시 WebtoB와동일하나 Tmax 리스너의경우는 Backup을하나만설정할수있다는것이차이점이다. Tmax 리스너를설정하여 Tmax와연결할때에 Tmax에어떤서버와연결할것인지를설정해야한다. <server-group-name> 은연결할서버가속해있는그룹을설정한다. 이설정은반드시해야하는설정이다. 실제로 Tmax 리스너가연결할 Tmax의서버이름을설정한다. 이설정은반드시해야하는설정이다. 제 4 장웹서버연결과클러스터링 65

84 태그 <tmax-backup-address> <tmax-backup-port> <use-nio> 설명 Tmax 서버에장애가발생했을때 backup으로동작하는서버의주소이다. WebtoB Backup Server 설정과동일하나 Tmax 리스너의경우는주소와포트만설정하고나머지는 primary server의설정을그대로가져간다. Tmax 서버에장애가발생했을때 backup으로동작하는서버에연결할포트번호를설정한다. tmax-backup-address가설정되어있다면 tmax-backup - port도함께설정되어야한다. true로할경우 NIO(Non-blocking I/O) Tmax 리스너로동작하게된다. NIO 방식을사용하면커넥션을담당하는 Thread와 Worker Thread가분리되어있어서기존방식에서동시에처리할수있는커넥션개수가 Worker Thread 수보다작을수밖에없는문제점을해결할수있다. 설정하지않았을경우기본값을 false이다. <selector-count> NIO 를사용할때 (use-nio=true) Selector 의개수를지정하는설정이다. 기본으로 1 개로설정이되며커넥션의개수가많아성능이저하될경우 Se lector 개수를적절히증가시켜주면성능이향상될수있다 자동 Thread Pool 관리설정 (Thread 상태통보 ) <thread-state-notify> 태그는 통지나자동재시작의실행을위해필요한최소의 Worker Thread 수와관련된 오류 조건을정의한다. 다음은 알림자를포함하고있는설정예이다. <thread-state-notify> 태그는웹서버리스너의 <thread-pool> 태그아래에설정된다. [ 예 4.6] 자동 Thread Pool 관리설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <webserver-connection> <http-listener> <listener-id>weblistener1</listener-id> <port>8007</port> <output-buffer-size>16384</output-buffer-size> <thread-pool> <min>10</min> <max>20</max> <step>2</step> <max-idle-time>60000</max-idle-time> <max-wait-queue>10</max-wait-queue> 66 JEUS Web Container 안내서

85 <max-queue>50</max-queue> <thread-state-notify> <max-thread-active-time> </max-thread-active-time> <notify-threshold>100</notify-threshold> <restart-threshold> 18 </restart-threshold> <notify-subject> JEUS WEB CONTAINER THREAD STATE WARNING </notify-subject> <restart-subject> JEUS WEB CONTAINER RESTART WARNING </restart-subject> <thread-interrupt-execution> true </thread-interrupt-execution> <restart-engine-execution> true </restart-engine-execution> <active-timeout-notificatio> true </active-timeout-notificatio> </thread-state-notify> </thread-pool> <postdata-read-timeout> </postdata-read-timeout> <scheme>http</scheme> <back-log>100</back-log> <server-access-control> true </server-access-control> <allowed-server> </allowed-server> </http-listener> </webserver-connection> </context-group> </web-container> 제 4 장웹서버연결과클러스터링 67

86 다음과같은항목들이반드시설정되어야한다. 태그 <max thread active time> 설명 Block 되기전까지 Worker Thread 가사용될수있는최대시간값을말한다. 이시간은 Worker Thread가클라이언트요청을서비스할때부터측정된다 (Servlet이수행될때 ). 여기서정한시간이초과되었거나또는 thread가자유롭게되어 worker Pool로되돌아갈때만료된다 (thread가 Block되지않는상황 ). 설정값이 0이거나음수이면무시된다. <notify-threshold-ratio> 존재할수있는 Block 된 Thread 의최대비율을설정한다. 전체 thread 개수 대비 Block 된 Thread 의비율이초과되면, 오류조건으로결정되어 알 림자를통하여 통보가전송된다. 1 보다작은소숫점으로설정하며 0 이거나음수이면무시된다. <restart-threshold-ratio> 존재할수있는 Block된 Thread의최대비율을설정한다. 전체 thread 개수대비 Block된 Thread의비율이초과되면, 오류조건으로결정되어 알림자를통하여 통보가전송된다. 그후에 restart-engine-execution에의해웹컨테이너가재시작될수있다. 1 보다작은소숫점으로설정하며 0 이거나음수이면이설정이무시된다. <notify-subject> <restart-subject> <thread-interrupt-execu tion> <restart-engine-execu tion> 경고 을전송할때사용된다. 컨테이너로그및통보할때사용하는 에사용된다. active-timeout 발생할때해당 Thread의 interrupt 발생유무를결정한다. true 인경우 interrupt를발생시키며, 기본값은 false이다. thread 비율이 <restart-threshod-ratio> 를넘어선경우해당엔진의재시작여부를결정한다. true 인경우엔진이재시작되며, 기본값은 false 이다. <active-timeout-notifica tion> active-timeout 발생이 notificatin 유무를결정한다. true 인경우 전송이이루어지며, 기본값은 false 이다 리스너연동과클러스터링을위한웹서버설정 본절에서는어떻게여러웹서버를설정하여해당리스너와연동할수있는지에대해설명한다. 여러개의웹서버와리스너들이서로연결되어클러스터를형성하는상황및설정하는방법에대해살펴보도록하겠다. 클러스터링에대한자세한내용은 여러개의웹컨테이너와웹서버클러스터링, Session이어떻게관리되는지에대한설명은 제5장 Session Tracking 을참고한다. 68 JEUS Web Container 안내서

87 Apache 웹서버설정과클러스터링 Apache 웹서버를웹컨테이너앞단에서사용하기전에다음과같은과정이선행되어야한다. 1. 컨테이너리스너와 Apache Server 간의통신을위하여 mod_jk 라이브러리를설치한다. 2. WEBMain.xml에서 AJP13 리스너를설정한다. ( AJP13 리스너설정 참조 ) 3. workers.properties 파일을생성하고편집한다. 4. Apache 웹서버의 httpd.conf 파일에연동구절을삽입한다. 5. Apache 웹서버를재시작한다. 참고 Apache 의경우 Apache HTTP Server 2.2.4, mod_jk 의경우 을기준으로설명한다. mod_jk 라이브러리설치하기 Apache 웹서버를웹컨테이너의앞단에서사용하기위해서는 mod_jk 라는모듈을 Apache 설치모듈에추가해야한다. mod_jk 모듈은서버와컨테이너간의통신프로토콜을구현한것이다. 이프로토콜은 Apache JServ Protocol 1.3(AJP 1.3) 이다. 다음의 URL을통해해당 binary를 down받을수있으며적절한위치에복사한다. down 받은 library 파일을일반적으로 "mod_jk.so" 이름을변경한다. 참고 만약위의 URL 과 JEUS 에서도특정 OS 의적절한바이너리를구하지못할경우는 source code 를다 운받아새로컴파일해야한다. WEBMain.xml 설정 <ajp13-listener> 태그를원하는 Context Group에추가한다. WEBMain.xml에서포트번호를주의해야하며이포트번호는다음에설명할 workers.properties파일의포트정보와일치되어야한다. 다음은 Apache Listener의설정예이다. [ 예 4.7] Apache 웹서버설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> 제 4 장웹서버연결과클러스터링 69

88 <webserver-connection> <ajp13-listener> <listener-id>weblistener3</listener-id> <port>9901</port> <output-buffer-size>8192</output-buffer-size> <thread-pool> <min>10</min> <max>10</max> </thread-pool> </ajp13-listener> </webserver-connection> </context-group> </web-container> 위의예에서는 9901 번포트가설정되어있고 output-buffer-size 는 bytes, Thread Pool 은 10 개로설 정되어있다. 이값들은다음의 workers.properties 설정과같아야한다. workers.properties 설정 workers.properties 파일은 mod_jk module을위한설정파일이며, AJP13 프로토콜을사용할때가장중요한설정이다. mod_jk module에는여러버전이존재하나현시점에서가장최신버젼인 을기준으로설명한다. 먼저 JEUS의노드는 johan, johan1의 2개의노드가있으며, 서로다른호스트의각각 <host_name> johan, johan1으로존재한다고가정한다. 각노드에는서블릿엔진이 engine1, engine2로각각 2개씩있다고가정한다. 즉, host johan에는 johan이라는노드에 johan_servlet_engine1, johan_servlet_engine2의엔진이존재하고 host johan1에는 johan1이라는노드에 johan1_servlet_engine1, johan1_servlet_engine2가존재한다. 총 2개의노드에 4개의서블릿엔진이존재하며각엔진당 AJP13 리스너들이서로다른포트번호로등록되어있다. 편의상순서대로 9901, 9902, 9903, 9904번을리스너포트로설정했다고가정하자. 다음은위의 JEUS 환경구성에서의 AJP13 프로토콜을사용하기위한예제이다. [ 예 4.8] AJP13 프로토콜을사용 : <<workers.properties>> worker.list=jeus_load_balancer_workers worker.jeus_load_balancer_workers.type=lb worker.jeus_load_balancer_workers.balance_workers=johan_servlet_engine1,johan_s ervlet_engine2,johan1_servlet_engine1,johan1_servlet_engine2 worker.jeus_load_balancer_workers.sticky_session=true ########################################### # listener specific configuration ########################################### worker.johan_servlet_engine1.host=johan 70 JEUS Web Container 안내서

89 worker.johan_servlet_engine1.port=9901 ########################################### # common configuration ########################################### worker.johan_servlet_engine1.type=ajp13 worker.johan_servlet_engine1.lbfactor=1 worker.johan_servlet_engine1.socket_timeout=30 worker.johan_servlet_engine1.connection_pool_timeout=30 worker.johan_servlet_engine1.connection_pool_size=10 worker.johan_servlet_engine1.connection_pool_minsize=10 worker.johan_servlet_engine1.max_packet_size=8192 worker.johan_servlet_engine1.retries=1 worker.johan_servlet_engine2.host=johan worker.johan_servlet_engine2.port=9902 worker.johan_servlet_engine2.reference=johan_servlet_engine1 worker.johan1_servlet_engine1.host=johan1 worker.johan1_servlet_engine1.port=9903 worker.johan1_servlet_engine1.reference=johan_servlet_engine1 worker.johan1_servlet_engine2.host=johan1 worker.johan1_servlet_engine2.port=9904 worker.johan1_servlet_engine2.reference=johan_servlet_engine1 workers.properties파일은몇몇정의를제외하고일반적으로 "worker.<worker_name>.<directive>=<val ue>" 의형식으로설정을정의한다. 다음은중요한몇몇설정에대한설명이다. worker.list 해당 worker를정의하는항목이다. worker의이름들은 comma(',') 로구분되며여러 worker들을나열할수있다. 다음은위예제에대한설명이다. worker.list=jeus_load_balancer_workers 이예제에서는 "jeus_load_balancer_workers" 라는이름의 worker를하나정의하였다. worker.<worker_name>.type worker의타입을정의한다. "ajp13", "ajp14", "jni", "lb", "status" 등이올수있다. AJP13을지원하기위해 jeus에서는 "ajp13", "lb" 만의설정으로도충분하다. 다음은위예제에대한설명이다. worker.jeus_load_balancer_workers.type=lb "jeus_load_balancer_workers" 는 load balancer type으로정의한다. 제 4 장웹서버연결과클러스터링 71

90 worker.<worker_name>.balance_workers comma(',') 로구분하여 load balance를원하는 worker들을나열할수있다. 위의 woker.list에적은 worker들이나타나서는안된다. JEUS의 AJP13 리스너와연동하는경우올바른 load balancer 및 sticky session 역할을하기위해서는 worker의이름을 JEUS의서블릿엔진이름으로해야한다. JEUS의경우 Session ID의라우팅정보로서블릿엔진이름을이용하며 mod_jk에서는 worker의이름을이용하기때문이다. 다음은위예제에대한설명이다. worker.jeus_load_balancer_workers.balance_workers=johan_servlet_engine1,... "jeus_load_balancer_workers" 는 johan_servlet_engine1, johan_servlet_engine2, johan1_servlet_en gine1, johan1_servlet_engine2 총 4개의 worker를 load balance한다. worker.<worker_name>.sticky_session Session ID를기반으로라우팅을지원할지에대한설정이다. "true"(or 1) 또는 "false"(or 0) 로설정을할수있다. 기본값은 true이며, JEUS에서는 sticky session을기본으로지원하므로항상 "true" 로설정한다. 다음은위예제에대한설명이다. worker.jeus_load_balancer_workers.sticky_session=true "jeus_load_balancer_workers" 는 sticky session을지원한다. worker.<worker_name>.host JEUS의 AJP13 리스너가존재하는호스트이름혹은 IP 주소를입력한다. 다음은위예제에대한설명이다. worker.johan_servlet_engine1.host=johan "johan_servlet_engine1" worker는 <host_name> 이 johan이다. worker.<worker_name>.port JEUS의 AJP13 리스너의포트번호를설정한다. 다음은위예제에대한설명이다. worker.johan_servlet_engine1.port=9901 "johan_servlet_engine1" worker는포트를 9901을사용한다. 이는 johan_servlet_engine1에해당하는 WEBMain.xml의 AJP13 리스너의포트와동일한값을입력한것이다. worker.<worker_name>.lbfactor load balancer worker에해당하는 worker에만의미가있다. 해당 worker가얼마나많은일을할지를정의하는것으로쉽게 worker의 priority를지정한다고생각해도된다. 72 JEUS Web Container 안내서

91 만약 5로설정을하고다른 worker가 1로설정되어있다면해당 worker는 5배의많은요청을받게될것이다. 기본적으로모두 1로설정을하면큰무리가없다. worker.<worker_name>.socket_timeout mod_jk와 remote host 간의통신에있어서초단위의 socket timeout을설정한다. 쉽게설명하자면 JEUS의 Servlet Container가지정한시간내에응답을보내오지않으면 mod_jk에서에러를발생시키는시간제한을의미한다 (waiting timeout의의미 ). 0(default) 일경우 timeout이없는것을의미한다. 넉넉한값을주도록한다 (JEUS와연동하는경우 0 이외의다른값으로설정할것을추천한다 ). 다음은위예제에대한설명이다. worker.johan_servlet_engine1.socket_timeout=30 "johan_servlet_engine1" worker는 30초의 socket timeout을사용한다. worker.<worker_name>.connection_pool_timeout 초단위의 timeout을설정한다. connection pool에서소켓을 close하기까지 open된소켓을유지하는시간을의미한다. 쉽게설명하자면 JEUS의서블릿컨테이너와맺은커넥션이설정한시간동안 inactive상태이면소켓을종료하고 pool의 thread를줄인다 (inactive timeout의의미 ). 0(default) 일경우 timeout이없는것을의미한다. 넉넉한값을설정하도록한다 (JEUS와연동하는경우 0이외의다른값으로설정할것을권장한다 ). 다음은위예제에대한설명이다. worker.johan_servlet_engine1.connection_pool_timeout=30 "johan_servlet_engine1" worker는 30초의 socket timeout을사용한다. 즉, connection pool에서소켓을 close하기까지 30초동안커넥션을유지한다. worker.<worker_name>.connection_pool_size JEUS의리스너와 mod_jk 간의커넥션을 cache하는크기 (size) 를의미한다. JEUS AJP13 리스너의 min, max 값과일치시켜설정한다. (JEUS AJP13에서는 min, max를동일한값으로설정할것을권장한다 ) 다음은위예제에대한설명이다. worker.johan_servlet_engine1.connection_pool_size=10 "johan_servlet_engine1" worker는 Thread Pool size가 10이다. 이는 johan_servlet_engine1에해당하는 WEBMain.xml의 AJP13 리스너의 Thread Pool의 max와동일한값을넣어준것이다. (min, max는동일하게맞추어주는것을권장한다 ) worker.<worker_name>.connection_pool_minsize 제 4 장웹서버연결과클러스터링 73

92 JEUS의리스너와 mod_jk간의커넥션을 cache하는최소의크기 (size) 를의미한다. JEUS AJP13 리스너의 min, max 값과일치시켜설정한다. (JEUS AJP13에서는 min, max를동일한값으로설정할것을권장한다 ) worker.<worker_name>.max_packet_size 최대크기의 AJP packet size를 byte단위로설정한다. 최대 bytes까지가능하다. JEUS AJP13 리스너의 output-buffer-size와일치하여설정하면무리가없다.( 기본값 : 8192) 다음은위예제에대한설명이다. worker.johan_servlet_engine1.max_packet_size=8192 "johan_servlet_engine1" worker는최대 8192의 max ajp13 packet을이용한다. 이는 johan_servlet_en gine1에해당하는 WEBMain.xml의 AJP13 리스너의 output-buffer-size와동일한값을넣어준것이다 (JEUS 및 mod_jk에서는 8192 bytes의 default를이용한다 ). worker.<worker_name>.retries JEUS의서블릿컨테이너로부터 error를받았을경우재시도할횟수를지정한다. 기본으로 3의값이주어진다. JEUS AJP13 리스너와연동하는경우는 1을추천한다. 1의경우 retry를하지않겠다는의미이다. 다음은위예제에대한설명이다. worker.johan_servlet_engine1.retries=1 "johan_servlet_engine1" worker는 retry를사용하지않는다. JEUS와연동할경우추천사항이다. worker.<worker_name>.reference 많은 load balancer worker들을설정할때유용하며지정된값에해당하는 worker의설정값을 reference 할수있는설정이다. 예를들어 "worker.castor.reference=worker.pollux" 라고설정했다면명시적으로 castor worker에서설정한값을제외하고모든 pollux worker의설정들을상속받게된다. 다음은위예제에대한설명이다. worker.<node-name>_servlet_<engine-name>.reference=johan_servlet_engine1 해당서블릿엔진즉, 해당 worker는특정설정을제외하고는모두 " johan_servlet_engine1" worker 의설정과동일한값들을상속받아사용한다. 참고호스트, 포트정보를제외하고는모두 "johan_servlet_engine1" 의속성들을그대로사용함을알수있다. 물론 WEBMain.xml의 read-timeout, output-buffer-size, thread의 min, max가 4개의서블릿엔진의 AJP13 리스너에서동일하다고가정한것이다. 만약다를경우해당설정값들을재정의하여사용한다. 74 JEUS Web Container 안내서

93 다음은위의예제에항목외의의미있는항목에대한설명들이다. worker.<node-name>_servlet_<engine-name>.host=<host-name> 해당 Servlet Engine 즉, 해당 worker 의적절한호스트이름또는 IP 주소를적절하게설정한다. worker.<node-name>_servlet_<engine-name>.port=<port> 해당 Servlet Engine 즉, 해당 worker 의적절한포트를설정한다. httpd.conf 설정 httpd.conf 파일에는 mod_jk 모듈을이용하기위해다음사항을추가해야한다 (Windows에 Apache 웹서버가설치되어있다고가정한다 ). [ 예 4.9] <<httpd.conf>> LoadModule jk_module "c:/ajp13/lib/mod_jk.so" JkWorkersFile "c:/ajp13/conf/workers.properties" JkLogFile "c:/ajp13/log/mod_jk.log" JkLogLevel debug JkMount /examples/* jeus_load_balancer_workers 항목 LoadModule JkWorkersFile JkLogFile JkLogLevel JkMount 설명위에서 down받은 mod_jk.so를 Apache 웹서버에 load한다. mod_jk.so의경우 "c:/ajp13/lib" 위치에저장하였다고가정하였다. workers.properties파일이위치한경로를지정한다. 위에서작성한 workers.prop erties의경우 "c:/ajp13/conf" 위치에저장하였다고가정하였다. 로그파일들이남을경로를지정한다. 로그들은 "c:/log" 위치에 "mod_jk.log" 란이름으로저장할것임을설정하였다. 저장로그레벨은 "debug" 로하였다. "de bug" 이외에 "error", "info" 등으로설정가능하다. 로그를저장할때의적절한레벨을설정한다. 저장로그레벨은 "debug" 로하였다. "debug" 이외에 "error", "info" 등으로설정가능하다. 가장중요한설정으로, 어떤 URL요청이들어왔을때어떤 worker로분배할지를선택한다. workers.properties에서설정한특정 worker를지정하면된다. 여기서는 /examples의하위모든요청을 workers.properties에서설정한 load balancer worker인 "jeus_load_balancer_workers" 로보낸다. "jeus_load_bal ancer_workers" 는또다른 4명의다른 worker들로구성되고웹서버로요청이들어오면 4명의 worker에게적절히 load balance될것이다. 제 4 장웹서버연결과클러스터링 75

94 IIS 웹서버설정과클러스터링 IIS 웹서버를웹컨테이너앞단에서사용하기전에다음의과정이선행되어야한다. 1. 컨테이너리스너와 IIS 웹서버간의통신을위하여 mod_jk 라이브러리 (ISAPI Redirector) 를설치한다. 2. WEBMain.xml에서 AJP13 리스너를설정한다 ( AJP13 리스너설정 참조 ). 3. workers.properties 파일을생성하고편집한다. 4. uriworkermap.properties 파일을생성하고편집한다. 5. IIS 웹서버의환경을설정한다. 6. IIS 웹서버를재시작한다. 참고 IIS 의경우 IIS 6, mod_jk 의경우 을기준으로설명한다. mod_jk 라이브러리설치하기 (ISAPI Redirector 설정 ) IIS 웹서버를웹컨테이너의앞단에서사용하기위해서는 "isapi_redirect" 라는 IIS plugin을 IIS에추가해야한다. 다음의 URL에서 Windows용 binary를 down받을수있으며일반적으로 "isapi_redirect.dll" 를이름으로설정하여사용한다. 참고 만약위의 URL 과 JEUS 에서도특정 OS 의적절한바이너리를구하지못할경우는 source code 를 down 받아새로컴파일해야한다. "isapi_redirect.dll" 이 "c:\ajp13" 에위치한다고가정하고이를복사한다. c:\ajp13\isapi_redirect.dll WEBMain.xml 설정 Apache 웹서버설정과클러스터링 의 "WEBMain.xml 설정 [69]" 과동일하다. workers.properties 설정 Apache 웹서버설정과클러스터링 의 "workers.properties 설정 " [70] 과동일하다. 76 JEUS Web Container 안내서

95 uriworkermap.properties 설정 uriworkermap.properties 설정은매우간단하다. 웹서버로들어온요청들에대해 URI 패턴을검사하여 JEUS로 forwarding하는 rule mapping을정의하는설정파일이며, 형식은다음과같다. /<application_name>=<worker_name> 만약 /examples의하위모든요청을 worker1에게매핑하려면 "/examples/*=worker1" 과같이설정한다 Apache 웹서버설정과클러스터링 의 "workers.properties 설정 " [70] 에서이미 load balancer worker인 jeus_load_balancer_workers를설정하였으므로다음과같이설정한다. [ 예 4.10] <<uriworkermap.properties>> /examples/*=jeus_load_balancer_workers IIS 웹서버환경설정 위에서 "isapi_redirector.dll" 은 "c:\ajp13\isapi_redirect.dll" 에위치한다고가정했다. "workers.properties", "uriworkermap.properties" 의경우 "c:\ajp13\conf" 하위에존재한다고가정한다. 또한 "isapi.log" 란이름의로그를 "c:\ajp13\log" 하위에저장한다고가정하자. 다음은 isapi_redirect를 IIS plugin에추가하는방법이다. 1. Windows에서레지스트리편집기를실행하고 regedit명령을실행한다. 2. "HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0" 과같은레지스트리키를생성한다. 3. "extension_uri" 라는문자열값을추가한후, 값으로 "/jakarta/isapi_redirect.dll" 을입력한다. 4. "log_file" 이라는문자열값을추가한후, 값으로로그파일정보를입력한다. "c:\ajp13\log\isapi.log" 5. "log_level" 이라는문자열값을추가한후, 값으로 "debug" 를입력한다. "debug" 외에 "error", "emerg" 등을입력할수있다. 적절한레벨의정보를입력한다. 6. "worker_file" 이라는문자열값을추가한후, 값으로 worker 설정파일이존재하는경로를입력한다. 예 ) "c:\ajp13\conf\workers.properties" 7. "worker_mount_file" 이라는문자열값을추가한후, 값으로 uriworkermap 설정파일이존재하는경로를 입력한다. 예 ) "c:\ajp13\conf\uriworkermap.properties" 제 4 장웹서버연결과클러스터링 77

96 8. IIS 관리콘솔툴을실행하고 "jakarta" 라는새로운가상디렉터리를생성한다. 이름은반드시 "jakarta" 여야하며물리적은경로는 isapi_redirect.dll이위치한곳을선택해야한다. 예 ) "c:\ajp13". 또한가상디렉터리액세스권한에 " 실행 (ISAPI응용프로그램또는 CGI)" 을체크한다. 9. IIS 관리콘솔에서해당 [ 웹사이트 ] > [ 속성 ] > [ISAPI 필터 ] 탭에서필터를하나추가한다. 이름부분은적당히 "ajp13 filter for jeus", 실행파일부분에는 isapi_redirector.dll이위치한 full path를지정한다. 예 ) c:\ajp13\isapi_redirect.dll 10. IIS 관리콘솔에서 [ 웹서비스확장 ] 을선택하고마우스오른쪽버튼을클릭해서 [ 새웹서비스확장 ] 을선택한다. 확장이름부분은적당히 "ajp13 filter for jeus" 를입력한다. [ 추가 ] 버튼을통해 isapi_redirect.dll 이위치한곳을선택하거나 0이파일이위치한 full path를입력한다. 예 ) c:\ajp13\isapi_redirect.dll, 이어서확장상태를허용됨으로설정을체크하고 [ 확인 ] 버튼을클릭한다. 11. IIS 관리콘솔에서 IIS를재시작한다. [ 웹사이트 ] > [ 속성 ] > [ISAPI 필터 ] 탭에서 "ajp13 filter for jeus" 필터부분상태정보에녹색화살표가위로향하고있음을반드시확인한다. 웹서비스확장에서 "ajp 13 filter for jeus" 로등록한웹서비스확장의상태가허용됨으로되어있음을확인한다 SunOne(Iplanet) 웹서버설정과클러스터링 SunOne(Iplanet) 웹서버를웹컨테이너앞단에서사용하기전에다음과같은과정이선행되어야한다. 1. 컨테이너리스너와 SunOne(Iplanet) 웹서버간의통신을위하여 mod_jk 라이브러리 (NSAPI Redirector) 를설치한다. 2. WEBMain.xml에서 AJP13 리스너를설정한다 ( AJP13 리스너설정 참조 ). 3. workers.properties 파일을생성하고편집한다. 4. SunOne 웹서버설정 (magnus.conf, obj.conf파일 ) 을수정한다. 5. SunOne 웹서버를재시작한다. 참고 SunOne(iplanet) 의경우 Sun ONE 웹서버 6.1, mod_jk 의경우 을기준으로설명한다. mod_jk 라이브러리설치하기 SunOne(Iplanet) 웹서버를웹컨테이너의앞단에서사용하기위해서는 "nsapi_redirect" 라는 SunOne(Iplanet) plugin 을 SunOne(Iplanet) 웹서버에추가해야한다. 78 JEUS Web Container 안내서

97 " 에서 Windows 용 binary 를 down 받을 수있으며일반적으로 "nsapi_redirect.dll" 를이름으로설정하여사용한다. 참고 만약위의 URL 과 JEUS 에서도특정 OS 의적절한 binary 를구하지못할경우는 source code 를다운 받아새로컴파일해야한다. "nsapi_redirect.dll" 이 "c:\ajp13" 에위치한다고가정하고이를복사한다. c:\ajp13\nsapi_redirect.dll WEBMain.xml 설정 Apache 웹서버설정과클러스터링 의 "WEBMain.xml 설정 [69]" 과동일하다. workers.properties 설정 Apache 웹서버설정과클러스터링 의 "workers.properties 설정 " [70] 과동일하다. SunOne(Iplanet) 웹서버설정 위에서 "nsapi_redirector.dll" 은 "c:\ajp13\nsapi_redirect.dll" 에위치한다고가정했다. workers.properties의경우 "c:\ajp13\conf" 하위에존재한다고가정한다. 또한 "nsapi.log" 란이름의로그를 "c:\ajp13\log" 하위에저장한다고가정한다. 다음은 nsapi_redirect를 SunOne(Iplanet) 에추가하는방법이다. 해당 magnus.conf에다음과같은설정을추가한다. [ 예 4.11] <<magnus.conf>> Init fn="load-modules" funcs="jk_init,jk_service" shlib="c:/ajp13/nsapi_redirec t.dll" shlib_flags="(global now)" Init fn="jk_init" worker_file="c:/ajp13/conf/workers.properties" log_level="deb ug" log_file="c:/ajp13/log/nsapi.log" "/exmaples" 의하위모든요청에대해 workers.properties에서설정한 "jeus_load_balancer_workers" 로 forward하는설정을 magnus.conf에추가한다. <Object name= "default"> 태그안에 "jknsapi" 란이름을설정한다. 반드시 "jknsapi" 라고설정할필요는없다. 새로운 Object를선언하기위한것이므로적절한이름을설정한다. "jknsapi" 란이름으로정의하였다면 <Object name="jknsapi"> 태그를정의하고 worker를할당하는설정을추가한다. 제 4 장웹서버연결과클러스터링 79

98 [ 예 4.12] <<magnus.conf>> <Object name="default"> NameTrans fn="assign-name" from="/examples/*" name="jknsapi" </Object> <Object name="jknsapi"> ObjectType fn="force-type" type="text/plain" Service fn="jk_service" worker="jeus_load_balancer_workers" path="/examples/*" </Object> WebtoB 웹서버설정과클러스터링 본절에서는 2개의예를통하여간단한 WebtoB 클러스터환경을구성해보겠다. 각컨테이너가각각의 WebtoB 서버를가지는간단한평행구조설정과각 Context Group과컨테이너가클러스터내의모든 WebtoB 서버와연결되는설정이다. 간단한구성의경우 첫번째의간단한예에서는 2개의 WebtoB 서버가각각 2개씩의전용웹컨테이너에각각연결된다 ( 총 4 개의컨테이너 ). 다음은간단한평행구조설정을표현한그림이다. [ 그림 4.4] 2개의 WebtoB 웹서버가 2개의웹컨테이너와연결된경우 JEUS Node A Web Container A Context Group A WebToB Listener A JEUS Node B Web Container B Client Requests Third-party Load Balancer WebToB Server A Context Group B WebToB Listener B JEUS Node C Web Container C Context Group C WebToB Listener C Session server (necessary). JEUS Node D Web Container D WebToB Server B Context Group D WebToB Listener D 80 JEUS Web Container 안내서

99 따라서, 2개의 JEUS 노드의 Context Group들은해당그룹들이동일하도록설정해야한다 ( 즉, Context Group A, B, C, D는모두동일하다 ). 그리고, 이런구성에서는 Session Server를사용해야한다. 간단한 Session Routing 기술은모든웹서버와 Context Group들이서로연결되어있을경우에만작동되기때문이다 ( 좀더복잡한시나리오는나중에소개한다 ). 그러나, WebtoB 서버가부하분산기로사용되면 ( 그림에서는타사제품의부하분산기사용되고있음 ), SessionServer가없더라도 Session Routing이가능하다 ( 기본적으로 SessionServer의사용은권장사항이다 ). 다음그림은점선안의모습을좀더자세히보여주는그림이다. 이안에서는 2개의 Context Group/ 리스너들 ( 리스너 A, B) 가 2개의서로다른웹컨테이너에설정되고 1개의 WebtoB Server(A) 에연결되어있는모습을보여준다. [ 그림 4.5] 2개의 WebtoB 리스너가 1개의 WebtoB에연결된경우 JEUS Node A Web Container A Load balancer WebToB Server A HTH = 2 HTH 1 MinProc = 6 MaxProc = Context Group A WebToB Server Listener A min threads = 2 max threads = 10 JEUS Node B Web Container B HTH 2 MinProc = 6 MaxProc = Context Group B WebToB Server Listener B min threads = 4 max threads = 15 WebtoB 서버가 HTH 프로세스를가지고있음을주시해보자. 각 HTH 프로세스는몇개의하위프로세스를가지고있는컨테이너처럼행동한다. 이러한하위프로세스는 WebtoB 리스너의한 Worker Thread 에연결될때사용된다. 이것은 HTH의수, HTH의최소및최대값, 연동되는 WebtoB 리스너의수가리스너들의최대및최소 Worker Thread Pool 값의설정과관계가있음을나타낸다. 주의해서설정해야할파라미터는 WebtoB 리스너의 Worker Thread Pool max 값과 WebtoB 서버설정의 MaxProc 값이다. HTH 프로세스의개수는 WebtoB 서버설정에존재하는 HTH 프로세스개수값을그대로 WebtoB 리스너의 hth-count설정에반영하기만하면된다. WebtoB 서버의 MaxProc 값과 WebtoB 리스너의 thread-pool max값은다음과같은공식으로표현될수있다. MinProc = Listener A min threads + Listener B min threads + + Listener X min threads setting. MaxProc = Listener A max threads + Listener B max threads + + Listener X max threads setting. WebtoB 서버의연결은이값들이제대로설정되어있지않아도무방하다. 그러나성능에악영향을끼칠수있음을감안해야한다. 또한 WEBMain.xml의 <hth-count> 태그는 WebtoB 설정파일의 *NODE 요소설정중 HTH 프로세스개수와동일해야한다. 제 4 장웹서버연결과클러스터링 81

100 다음은 WebtoB 리스너 A와 B가해당 WEBMain.xml에어떻게설정되어야하는지에대한예이다. [ 예 4.13] 웹컨테이너 A : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <webserver-connection> <webtob-listener> <!--Listener A--> <listener-id>weblistenera</listener-id> <port>9900</port> <output-buffer-size>16384</output-buffer-size> <thread-pool> <min>2</min> <max>10</max> <step>2</step> <max-idle-time>60000</max-idle-time> <max-wait-queue>5</max-wait-queue> </thread-pool> <postdata-read-timeout> </postdata-read-timeout> <scheme>http</scheme> <hth-count>2</hth-count> <disable-pipe>false</disable-pipe> <webtob-address> </webtob-address> <registration-id>mygroup</registration-id> <webtob-home>c:\webtob\</webtob-home> <read-timeout>120000</read-timeout> <reconnect-timeout>60000</reconnect-timeout> <webtob-backup> </webtob-backup> </webtob-listener> </webserver-connection> </context-group> </web-container> 82 JEUS Web Container 안내서

101 [ 예 4.14] 웹컨테이너 B : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <webserver-connection> <webtob-listener> <!--Listener B--> <listener-id>weblistenerb</listener-id> <port>9900</port> <output-buffer-size>16384</output-buffer-size> <thread-pool> <min>4</min> <max>15</max> <step>2</step> <max-idle-time>60000</max-idle-time> <max-wait-queue>5</max-wait-queue> </thread-pool> <postdata-read-timeout> </postdata-read-timeout> <scheme>http</scheme> <hth-count>2</hth-count> <disable-pipe>false</disable-pipe> <webtob-address> </webtob-address> <registration-id>mygroup</registration-id> <webtob-home>c:\webtob\</webtob-home> <read-timeout>120000</read-timeout> <reconnect-timeout>60000</reconnect-timeout> <webtob-backup> </webtob-backup> </webtob-listener> </webserver-connection> </context-group> </web-container> 다음은 WebtoB Server A 가 [ 그림 4.5] 에있는간단한예와같이설정되기위해 http.m 파일에어떻게설정 되는지를보여주는예이다. 제 4 장웹서버연결과클러스터링 83

102 [ 예 4.15] http.m of WebtoB 웹서버 A (IP address ) *NODE foo HTH = 2, JSVPORT = 9900, *SVRGROUP jsvg NODENAME = foo, SVRTYPE = JSV *SERVER MyGroup SVGNAME = jsvg, MinProc = 6, MaxProc = 25 *URI uri1 Uri = "/examples/", Svrtype = JSV uri2 Uri = "/test/", Svrtype = JSV *EXT jsp MimeType = "application/jsp", SvrType = JSV 위의예에서는리스너 A의포트 = 리스너 B의포트 = WebtoB Server의 JSVPORT(=9900) 이다. 또한 Context Group A와 B의이름이 MyGroup 으로동일하다. 이이름은등록 ID로사용되고, http.m의 *SERVER 요소에도존재한다. 또한두 WEBMain.xml 파일의 <hth-count> 태그의값은 http.m의 *NODE 하위의 HTH 수와동일함을주목한다 ( 값은모든파일에서동일하게 2로주어졌다 ). 마지막으로중요한것은 min과 max 값설정이다. 샘플설정파일들에서앞에서제시한공식에따라다음과같이설정되었다. HTH MinProc = 6 = 2 thread + 4 thread, HTH MaxProc = 25 = 10 thread + 15 thread 그리고 HTH의수가 2(http.m에서 ) 이고 MinProc/MaxProc의값이 HTH 당값이기때문에 Worker Thread/ 연결값은 2배가됨을짐작할수있다. 그러므로, 이설정의 Worker Thread의최대값은 MaxProc * HTH 수 = 25 * 2 = 50 이된다. WebtoB 리스너는자동으로현재 HTH 프로세스수에맞춰진다. 그러므로 WebtoB 리스너를설정할때에는 HTH 프로세스가 1개인것처럼생각해서설정한다. 마지막으로, 동일한설정이또다른 Context Grop이추가될때마다적용된다. 복잡한구성의경우 다음의예에서는 4개의 Context Group을가지고있고, 8개의 WebtoB 리스너를가진 4개의웹컨테이너가 2개의 WebtoB 서버에연결된다. 즉, 모든컨테이너와 Context Group은모든 WebtoB 서버에연결된다. 84 JEUS Web Container 안내서

103 [ 그림 4.6] 복잡한 WebtoB 웹서버구성 JEUS Node A Web Container A Context Group A WebToB Listener A1 WebToB Listener A2 JEUS Node B Web Container B Client Requests Third-party Load Balancer WebToB Server A Context Group B WebToB Listener B1 WebToB Listener B2 JEUS Node C Web Container C Context Group C WebToB Listener C1 WebToB Listener C2 Session server (optional, session routing possible). JEUS Node D WebToB Server B Web Container D Context Group D WebToB Listener D1 WebToB Listener D2 위그림에서는특별한설정사항을볼수없다. 각웹서버와각웹서버리스너에서위의예와동일한방법으로설정한다. 한가지차이점은각 Context Group이모든웹서버에연결되어있고, Session Routing을이용할수있다는것이다. 이런환경에서 Session Server를사용하는것은선택사항이다. 하지만, 높은안정성을위해서는 Session Routing과함께 Session Server의사용을권장한다. Session Server는웹컨테이너의장애가발생하는경우기본적으로세션데이터를복구하는기능을가진다 TCP 리스너사용 TCP 리스너는내부 HTTP 리스너가동작하는것과같은방식으로동작한다. 그러나, 주목해야할점은 TCP 리스너는 HTTP프로토콜을지원하지않는다는것이다. 대신에, 개발자는표준 HTTP 프로토콜대신에맞춤통신프로토콜을구현할수있다. TCP 라는개념은이리스너가통신프로토콜구조의낮은레벨에서작업할수있다는것을강조하게된다. 즉, 이것은애플리케이션레벨에서보다는전송레벨에서동작한다고볼수있다 (HTTP 리스너는애플리케이션레벨의리스너이다 ). 그러므로, TCP 리스너가동작하기위해서는애플리케이션레벨의통신프로토콜의구현이요구된다. 본절에서는이러한맞춤프로토콜제공자를구현하는방법과그것을어떻게 TCP 리스너와함께등록하 는지, 그리고 TCP 리스너에접속하는클라이언트를작성하고맞춤프로토콜을사용하여통신하는방법 에대하여알아본다. 제 4 장웹서버연결과클러스터링 85

104 TCP 리스너는 HTTP 또는 HTTPS 프로토콜을가지고사용할수없는통신요구사항이있을경우에만사용한다. 본절에서는다음의과정과절차를다룰것이다. 1. 맞춤통신프로토콜정의 2. dispatcher 설정클래스구현 ( 프로토콜설정정보 ) 3. TCP handler Servlet 구현 ( 프로토콜구현 ) 4. 맞춤프로토콜구현을위한 TCP 리스너설정 5. TCP 클라이언트구현 6. TCP 클라이언트컴파일과구동 TCP 리스너 API는 JEUS_HOME\docs\api\jeusapi\index.html에서 Webcontainer Tcp Listener API Reference 에도설명되어있다. 먼저, 본절에서사용할용어에대해서정의해보자. 파일 프로토콜 ( 통신프로토콜 ) 메시지 TCP 클라이언트 TCP Handler TCP dispatcher configu ration class 설명 TCP 클라이언트와 TCP Handler 사이에서 (TCP 리스너가중간역할 ) 교환되는메시지의구조와내용을정의한다. TCP 클라이언트와 TCP Handler 사이에서교환되는데이터이다. 프로토콜에서정의한구조에맞아야한다. TCP 리스너와교신하며메시지를주고받는외부의애플리케이션 (TCP Handler 에의해처리된다 ) 이다. 메시지를주고받는것은표준소켓을사용한다. TCP 리스너를통하여메시지를받고구현된방법대로메시지를처리한다. TCP Handler는 jeus.servlet.tcp.tcpservlet의하위클래스의형태로구현되고웹컨테이너에보통서블릿처럼등록된다. TCP Handler는 TCP 프로토콜위에존재하는맞춤프로토콜의 제공자 또는 구현체 처럼동작한다고말할수있다. TCP 설정 dispatcher 클래스는 jeus.servlet.tcp.tcpdispatcherconfig를확장한클래스이다. 이클래스는맞춤프로토콜에대한정보를 TCP 리스너로전달하여이 non-http 메시지를해석하여처리하도록한다. 이클래스는 JEUS_HOME\lib\application 디렉터리아래에놓아두고, WEB Main.xml 의 TCP 리스너설정항목중 <dispatcher-config-class> 태그에설정 한다 ( 4.3. 리스너설정 참조 ). TCP 리스너 맞춤메시지에대한해석과라우팅인프라를제공한다. TCP 클라이언트와 TCP Handler 사이에서 non-http 중간매개체로역할을한다. 이것은다른 HTTP 리스너와마찬가지로웹컨테이너내에존재한다. 86 JEUS Web Container 안내서

105 맞춤통신프로토콜정의 TCP 리스너는 TCP 클라이언트와 TCP Handler 간에통신되는모든메시지들을두부분으로나누는데, 헤더와바디가그것이다. 일반적으로헤더는기본적이면서도표준정보를전달하고크기도정해져있다. 바디는전송될임의의사용자데이터가포함된다 ( 예, HTTP 응답의 HTML 코드 ). TCP 리스너가어떻게사용되는지설명하기위하여여기에서간단한프로토콜 ( 메시지구조 ) 을정의한다. 이것은나중에사용할것이다. 맞춤통신프로토콜 ( 맞춤메시지구조 ) 은다음과같은내용을가진다. 헤더 1. 헤더는 4 Bytes의 magic 수로시작한다. 이는사용되는프로토콜을식별한다 로설정한다 Byte의 type 필드가 magic 수다음에쓰인다. 0 은 요청 을 1 은 응답 을의미한다. 3. 세번째항목은 4 Bytes의 body length이다. 이항목은메시지의바디부분의 Byte 수를기록한다. 여기의예에는크기가 128 Bytes로고정되어있다. 4. 마지막네번째의항목은 32 Bytes의 string으로 service name을기록한다. 여기서는그값으로요청을처리하는 TCPServlet의이름을넣는다. 바디메시지의바디부분은 128 Bytes 길이를가진문자데이터를넣으면된다. 여기서는이 128 Byte 블록을 2개의임의의 64 Bytes 텍스트 string으로넣는다. 이제부터어떻게 TCP 리스너를통하여맞춤프로토콜을적용하는지에대하여살펴본다. 먼저, 설정 dis patcher 클래스를구현하고 TCP Handler 클래스 (TCPServlet의하위클래스 ) 를구현한다 Dispatcher 설정클래스구현 Dispatcher 설정클래스는 jeus.servlet.tcp.tcpdispatcherconfig 클래스의하위클래스이다. 이클래스의 abstract 메소드는 TCP 리스너가알맞은 TCP Handler에게메시지를전달하기위해필요한여러가지정보들을전달되도록구현되어야한다. 이메소드들은 JEUS_HOME\docs\api\jeusapi\index.html에서 Web container Tcp Listener API Reference에설명되어있다. 다음의코드 (SampleConfig.java) 는전절에서정의된프로토콜에기반하여어떻게구현하였는지를보여준다. 특정메소드들이어떻게사용되었는지는주석을참고한다. [ 예 4.16] <<SampleConfig.java>> package sample.config; import javax.servlet.*; import javax.servlet.http.*; import jeus.servlet.tcp.*; 제 4 장웹서버연결과클러스터링 87

106 /* This class extends the abstract class jeus.servlet.tcp. TCPDispatcherConfig class. This implementation provides routing and handling information to the TCP listener according to our defined communications protocol. */ public class SampleConfig extends TCPDispatcherConfig { /* Any init code goes into this method. This method will be Called once after starting the TCP listener. We leave this method empty for our simple example. */ public void init() {} /* This method returns the fixed-length of the header so that the TCP listener knows when to stop reading the header. The header length for our example is 41 (bytes): 4 (magic) + 1 (type) + 4 (body length) + 32 (service name). */ public int getheaderlength() { return 41; } /* This method must return the length of the body. For our example, this length is represented as an int in the header, starting at position 5 (see the protocol definition above). */ public int getbodylength(byte[] header) { return getint(header, 5); } /* This method must return the context path so that the request can be routed by the TCP listener to the context that contains the TCP handler (TCPServlet implementation). For our example, we always use the context path /tcptest. */ public String getcontextpath(byte[] header) { return "/tcptest"; } /* This method must return the name (path) of the TCP 88 JEUS Web Container 안내서

107 handler(tcpservlet) relative to the context path. For our example, we fetch this name from the 9th position in the header. */ public String getservletpath(byte[] header) { return "/" + getstring(header, 9, 32); } /* This method returns some path info from the header. It is not used in our example and thus returns null. */ public String getpathinfo(byte[] header) { return null; } /* This method returns any session ID embedded in the header. It is not used in our example and thus returns null. */ public String getsessionid(byte[] header) { return null; } } /* This method determines whether the TCP listener should keep the socket connection open after the TCP handler has delivered its response. If it returns false, the connection will be dropped like in HTTP communications. If it returns true the connection will be kept open like in the Telnet or FTP protocols. For our example, we choose to make it persistent (connection not closed by the TCP listener). */ public boolean ispersistentconnection() { return true; } TCP Handler 구현 TCP Handler 는항상 jeus.servlet.tcp.tcpservlet 의하위클래스이다. 여기에는항상 overridden 되는 abstract void service(tcpservletrequest req, TCPServletResponse, res) 메소드가존재한다. 제 4 장웹서버연결과클러스터링 89

108 이서비스메소드는맞춤프로토콜에준하는메시지를처리할수있도록구현되어야한다. 메시지는 TCPServletRequest 객체에전달되고 TCP Handler로부터전달된응답은 TCPServletResponse 객체의 output stream으로출력된다. 다음예제는맞춤프로토콜에준하는메시지를처리하는 TCP Handler의구현코드이다. 이는다소직설적인구현으로 TCPServletRequest에서헤더와바디가꺼내어져오고 System.out에헤더와바디의각항목들이출력된다. 그후에 service() 메소드는 2개의응답메시지를생성하고 TCPServle tresponse 객체의 output stream에출력한다. [ 예 4.17] <<SampleServlet.java>> package sample.servlet; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import jeus.servlet.tcp.*; /** * Sample TCPServlet implementation * * Protocol scheme: * * common header (for request and response) : total 41 byte * * magic field: length = 4 byte, value = 7777 * type field : length = 1 byte, 0 : request, 1:response * body length field : length = 4, value = 128 * service name field : length = 32 * * request and response body * * message1 field : length = 64 * message2 field : length = 64 * */ public class SampleServlet extends TCPServlet { public void init(servletconfig config) throws ServletException { } public void service( TCPServletRequest req, TCPServletResponse res) throws ServletException, IOException { byte[] header = req.getheader(); byte[] body = req.getbody(); 90 JEUS Web Container 안내서

109 String encoding = res.getcharacterencoding(); if (encoding == null) encoding = "euc-kr"; DataInputStream in = new DataInputStream( new ByteArrayInputStream(header)); int magic = in.readint(); System.out.println( "[SampleServlet] received magic = " + magic); byte type = (byte)in.read(); System.out.println( "[SampleServlet] received type = " + type); int len = in.readint(); System.out.println( "[SampleServlet] received body length = " + len); byte[] svcname = new byte[32]; in.readfully(svcname); System.out.println( "[SampleServlet] received service name = " + (new String(svcname)).trim()); String rcvmsg = null; rcvmsg = (new String(body, 0, 64)).trim(); System.out.println( "[SampleServlet] received msg1 = " + rcvmsg); //rcvmsg = (new String(body, 64)).trim(); try { rcvmsg = (new String(body, 64, 64, encoding)).trim(); } catch (Exception e) {} System.out.println( "[SampleServlet] received msg2 = " + rcvmsg); String msg1 = "test response"; String msg2 = "test response2"; byte[] result1 = null; byte[] result2 = null; if (encoding!= null) { try { result1 = msg1.getbytes(encoding); result2 = msg2.getbytes(encoding); } catch (UnsupportedEncodingException uee) { 제 4 장웹서버연결과클러스터링 91

110 result1 = msg1.getbytes(); result2 = msg2.getbytes(); } } else { result1 = msg1.getbytes(); result2 = msg2.getbytes(); } header[4] = (byte)1; // mark as response ServletOutputStream out = res.getoutputstream(); out.write(header); byte[] buf1 = new byte[64]; System.arraycopy(result1, 0, buf1, 0, result1.length); out.write(buf1); byte[] buf2 = new byte[64]; System.arraycopy(result2, 0, buf2, 0, result2.length); out.write(buf2); } out.flush(); //out.close(); } public void destroy() { } 맞춤프로토콜코드를위한 TCP 리스너설정 위에서구현한코드 (SampleConfig.java와 SampleServlet.java) 를기반으로하여 TCP 리스너를설정한다. 1. SampleConfig.java 와 SampleServlet.java를컴파일한다. C:\tcptest>javac -classpath d:\jeus\lib\system\jeus.jar Sam pleconfig.java SampleServlet.java 2. SampleConfig.class 파일을다음의디렉터리에위치시킨다. JEUS_HOME\lib\application\sample\config 3. SampleServlet.class 를다음디렉터리에위치시킨다 ( tcpcontext 디렉터리이름을알맞은것으로대체 한다 ). JEUS_HOME\webhome\app_home\tcpcontext\WEB-INF\classes\sample\servlet 92 JEUS Web Container 안내서

111 Context Group에대한설명은 제3장 Context Group 을, Context 등록은 제6장 Web Context( 웹애플리케이션 ) 를참고한다. 4. 간단한 web.xml을생성하고 SampleServlet에대한정보를다음과같이설정한다. [ 예 4.18] <<web.xml>> <?xml version="1.0"?> <web-app xmlns= > <display-name>tcphandlerapp</display-name> <distributable/> <servlet> <servlet-name>sample</servlet-name> <servlet-class> sample.servlet.sampleservlet </servlet-class> </servlet> <servlet-mapping> <servlet-name>sample</servlet-name> <url-pattern>/sample</url-pattern> </servlet-mapping> </web-app> 위의 web.xml 파일에서 TCP Handler인 sample.servlet.sampleservlet을간략하게 sample 이라는서블릿이름과 URL 경로인 /sample 로어떻게매핑하는지를확인한다. 이맞춤프로토콜구현코드를이용하려는 TCP 클라이언트는헤더에 sample 이라는서비스이름을명시한다 맞춤통신프로토콜정의 를참고한다. 서비스이름은 TCP 리스너에의해호출되는 SampleConfig 클래스의 getservletpath() 에의해추출된다. 여기서는클라이언트가헤더에 sample 이라고지정해주었고, TCP 리스너는 sample 서비스이름을 web.xml에정의된 sample.servlet.sampleservlet TCPServlet 클래스를통하여매핑하게된다. 5. web.xml 파일을다음의디렉터리에위치시킨다. JEUS_HOME\webhome\app_home\tcpcontext\WEB-INF 6. JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name> 디렉터리의 WEBMain.xml 을수정한다. WEBMain.xml 파일은다음정보들을포함해야한다. 새로운 Context Group(TCPGroup) 그리고 TCP 리스너에대한설정정보를 WEBMain.xml에추가한다. 다음은예제가동작하기위한 WEBMain.xml의설정정보이다. [ 예 4.19] <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns= > <context-group> <group-name>tcpgroup</group-name> 제 4 장웹서버연결과클러스터링 93

112 <webserver-connection> <tcp-listener> <listener-id>tcplistener1</listener-id> <port>5555</port> <thread-pool> <min>25</min> <max>30</max> <step>2</step> <max-idle-time>1000</max-idle-time> </thread-pool> <dispatcher-config-class> sample.config.sampleconfig </dispatcher-config-class> </tcp-listener> </webserver-connection> </context-group> </web-container> TCP 리스너포트 (5555), sample.config.sampleconfig을사용하기위한 <dispatcher class> 의설정, 앞에서추가한새로운 Context Group의이름 ( tcpcontextgroup ) 을주의깊게확인한다. 7. JEUS_HOME\config\<node-name> 디렉터리의 JEUSMain.xml을수정한다. JEUSMain.xml 파일은새로운 Context( TCPSample ) 정보들을포함해야한다. JEUS_HOME은 "c:\jeus6" 로가정한다. [ 예 4.20] <<JEUSMain.xml>> <?xml version="1.0"?> <jeus-system xmlns=" <node> <name>tmax1</name> </node> <application> <name>tcpsample</name> <path> c:\jeus6\webhome\app_home\tcpcontext </path> <deployment-target> <target> <engine-container-name> tmax1_container1 </engine-container-name> <web-context-group> <name>mygroup</name> </web-context-group> 94 JEUS Web Container 안내서

113 </target> </deployment-target> <deployment-type>component</deployment-type> <web-component/> </application> </jeus-system> TCP Context의공식적인이름도 TCPSample 이라고설정했다. 다음과정에서는이이름의용도를잘살펴보자. 8. 마지막으로, 이 TCP Context를위해 deployment descriptor를생성해야한다. jeus-web-dd.xml 이라는파일을생성하고다음의디렉터리에위치시킨다. JEUS_HOME\webhome\app_home\tcpcontext\WEB-INF [ 예 4.21] <<jeus-web-dd.xml>> <?xml version="1.0"?> <jeus-web-dd xmlns= > <context-path>/tcptest</context-path> <docbase>tcpcontext</docbase> </jeus-web-dd> 위의예에서어떻게 Context 경로를 SampleConfig.java 의 getcontextpath() 메소드에의해반환되는 값과일치하도록설정하는지유의하여살펴보기바란다 ( /tcptest ). 참고 3부터 7의과정은 Web Context와디플로이에대한내용을다루는 제6장 Web Context( 웹애플리케이션 ) 에서자세히설명한다. 9. 위의과정이모두완료되면모든파일들을저장하고 제2장웹컨테이너 에서설명한것과같이웹컨테이너를재시작한다. 10. TCPGroup Context Group, TCPSample Context와 sample TCPServlet의디플로이를확인하기위하여위와같이설정을하면, TCP 리스너에연결되는 TCP 클라이언트의구현과구동에대하여알아보고, SampleServlet TCP Handler의 service() 메소드를호출한다 TCP 클라이언트구현 여기의 TCP 클라이언트는아주간단명료하다. TCP 리스너와소켓연결을맺고이연결을통하여메시지를전송한다. 이메시지는 맞춤통신프로토콜정의 에서정의한맞춤통신프로토콜에준하는바이트스트림이다. 설정된 TCP 리스너는메시지를받을것이고 SampleConfig 클래스에 dispatch 정보를물을것이다. 이정보는 SampleServlet 구현코드의 service() 메소드의호출을암시하고있다. SampleServlet은클라이언트 제 4 장웹서버연결과클러스터링 95

114 로부터전달된데이터를출력하고응답을생성하여전송한다. 이응답은클라이언트가받아 System.out 으로출력한다. 다음은그에대한예이다. [ 예 4.22] <<Client.java>> package sample.client; import java.io.*; import java.net.*; public class Client { private String address; private int port; private int magic = 7777; private byte type = 0; private int bodylength = 128; private byte[] servicename="sample".getbytes(); public Client(String host, int port) { this.address = host; this.port = port; } public void test() throws IOException, UnsupportedEncodingException { Socket socket = new Socket(address, port); DataOutputStream out = new DataOutputStream( new BufferedOutputStream(socket.getOutputStream())); DataInputStream in = new DataInputStream( new BufferedInputStream(socket.getInputStream())); out.writeint(7777); out.write(type); out.writeint(bodylength); byte[] buf = new byte[32]; System.arraycopy(serviceName, 0, buf, 0, servicename.length); out.write(buf); byte[] msg1 = "test request".getbytes(); byte[] msg2 = "test request2".getbytes(); buf = new byte[64]; System.arraycopy(msg1, 0, buf, 0, msg1.length); out.write(buf); buf = new byte[64]; System.arraycopy(msg2, 0, buf, 0, msg2.length); out.write(buf); 96 JEUS Web Container 안내서

115 out.flush(); // rx msg int magic = in.readint(); System.out.println("[Client] received magic = " + magic); byte type = (byte)in.read(); System.out.println("[Client] received type = " + type); int len = in.readint(); System.out.println("[Client] received body length = " + len); byte[] svcname = new byte[32]; in.readfully(svcname); System.out.println("[Client] received service name = " + (new String(svcname)).trim()); byte[] body = new byte[128]; in.readfully(body); String rcvmsg = null; rcvmsg = (new String(body, 0, 64)).trim(); System.out.println("[Client] received msg1 = " + rcvmsg); rcvmsg = (new String(body, 64, 64, "euc-kr")).trim(); System.out.println("[Client] received msg2 = " + rcvmsg); } out.close(); in.close(); socket.close(); } public static void main(string[] argv) throws Exception { Client client = new Client("localhost", 5555); client.test(); } 위의클라이언트코드에서프로토콜에필요한다양한헤더의필드들을어떻게설정하는지확인한다. magic 수는 7777로, type 은 0( 요청 ), body length 는 128 Bytes( 고정길이 ), service name 은 sample 로되어있다 (SampleServlet의이름은 web.xml에설정되어있다 ). 그리고 2개의메시지들을생성하여헤더정보를전송한후에 TCP 리스너에게그들을전송한다. 마지막으로 hostname을 localhost 로포트번호는 5555 로설정하였다. 제 4 장웹서버연결과클러스터링 97

116 TCP 클라이언트컴파일과실행 본절에서는어떻게이클라이언트를컴파일하고실행하는지에대해설명한다. TCP 리스너가설정되어 localhost 에 5555 포트를이용하여운영되고있다고가정한다. 이런환경에서다음과정을거쳐 TCP 클라이언트를컴파일하고실행시켜보자. 1. Client.java를컴파일한다. C:\tcptest>javac -classpath d:\jeus\lib\system\jeus.jar Cli ent.java 2. Client.class 파일을현재작업디렉터리 (c:\tcptest) 의 sample\client 디렉터리하위로이동한다. 3. Client.class를다음과같이실행한다 ( 모두한줄에 ). C:\tcptest>java -classpath d:\jeus\lib\system\jeus.jar;. s ample.client.client 4. JEUS 관리자의콘솔윈도우는다음과같이 TCP Handler의결과값을보여줘야한다 (SampleServlet 클래스 ). [SampleServlet] received magic = 7777 [SampleServlet] received type = 0 [SampleServlet] received body length = 128 [SampleServlet] received service name = sample [SampleServlet] received msg1 = test request [SampleServlet] received msg2 = test request2 참고만약 WEBMain.xml의 <redirect-stdout> 태그가 true 로설정되어있으면 JEUS_HOME\logs\<nodename>_servlet_<engine-name>\stdout_<date>.log 로결과가남겨진다. 5. 다음은클라이언트의실행윈도우에남겨질것이다. [Client] received magic = 7777 [Client] received type = 1 [Client] received body length = 128 [Client] received service name = sample [Client] received msg1 = test response [Client] received msg2 = test response2 98 JEUS Web Container 안내서

117 4.6. 보안 (SSL) 리스너사용 본절에서는 JEUS 웹컨테이너에서보안리스너를설정하는방법에대해설명한다. 또한 WEBMain.xml에기본리스너를설정하는방법과필수 keystore, truststore 파일을설정하고보안리스너에게위치나이파일들의암호를알려주는방법, 마지막으로보안된 SSL 연결을통하여 HTML 파일을가져오도록보안리스너를시작하고연결하는방법에대하여설명한다 개요 JEUS 웹컨테이너의보안리스너는직접적인클라이언트대컨테이너의 HTTPS 요청을지원한다. HTTPS 프로토콜은 SSL(Secure Socket Layer) 기술을사용하여인증, 메시지기밀, 메시지무결성서비스를제공한다. 최근에는, 민감한정보 ( 신용카드번호 ) 가교환되는대부분의온라인서비스들은 SSL을사용한다. JEUS 보안리스너는 JSSE(Java Secure Socket Extensions) API 기반의 HTTPS/SSL 연결을지원한다. 이기능은사용은가능하지만, 실제많은운영환경이웹컨테이너보다는웹서버에서지원하는 SSL 기능에의존한다. SSL과 JSSE에대한상세한정보를참고한다. 시작하기전에, 다음과같은사항들이설정되어있다고가정한다. WEBMain.xml에서블릿엔진이설정되어시스템에추가되어있다. 자세한내용은 제2장웹컨테이너 를참조한다. WEBMain.xml에 MyGroup 이라는 Context Group이추가되어있다. 자세한내용은 제3장 Context Group 을참조한다. MyGroup 은 TestContext 라는 Context를가지고 /Test 라는 context path를가진다. MyContext 디렉터리는 hello.html 을가지고이파일은우리가추가할보안리스너를통하여접근될것이다. MyContext\WEB-INF 디렉터리에는내용이없는 web.xml파일이존재한다. 자세한내용은 제 6장 Web Context( 웹애플리케이션 ) 를참조한다 디렉터리구조 다음은보안리스너의초기디렉터리구조이다. 제 4 장웹서버연결과클러스터링 99

118 [ 그림 4.7] 보안리스너의초기디렉터리 JEUS_HOME\ config\ <node-name>\ X webhome\ <node-name>_servlet_ <engine-name>\ app_home\ WEBMain.xml MyContext\ WEB-INF\ Legend: 0I: binary or executable file X: XML document J: JAR file T: Text file C: Class file V: java source file DD: deployment descriptor X X web.xml jeus-web-dd.xml T hello.html 파일에는다음과같은항목들이존재한다. [ 예 4.23] JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name>\WEBMain.xml <?xml version="1.0"?> <web-container xmlns=" <context-group> <group-name>mygroup</group-name> </context-group> </web-container> [ 예 4.24] JEUS_HOME\config\<node-name>\JEUSMain.xml <?xml version="1.0"?> <jeus-system xmlns=" <node> <name>tmax1</name> </node> <application> <name>testcontext</name> <path> c:\jeus6\webhome\app_home\mycontext </path> <deployment-target> 100 JEUS Web Container 안내서

119 <target> <engine-container-name> tmax1_container1 </engine-container-name> <web-context-group> <name>mygroup</name> </web-context-group> </target> </deployment-target> <deployment-type>component</deployment-type> <web-component/> </application> </jeus-system> [ 예 4.25] JEUS_HOME\webhome\app_home\webapps\MyContext\WEB-INF\jeus-web-dd.xml <?xml version="1.0"?> <jeus-web-dd xmlns=" <context> <context-path>/test</context-path> </context> </jeus-web-dd> [ 예 4.26] JEUS_HOME\webhome\app_home\webapps\MyContext\WEB-INF\web.xml <?xml version="1.0"?> <web-app xmlns=" <description>a test module.</description> <display-name>test Module</display-name> </web-app> [ 예 4.27] JEUS_HOME\webhome\app_home\webapps\MyContext\hello.html <html> <head> <title>hello</title> </head> <body> <h4><b>hello, World</b> (This is hello.html file)</h4> </body> </html> 참고 위의모든파일과디렉터리를전부설명하지않았다. 더자세한정보는 context 와관련파일들에대 한설명이있는 제 6 장 Web Context( 웹애플리케이션 ) (jeus-web-dd.xml 과 web.xml) 를참고한다. 제 4 장웹서버연결과클러스터링 101

120 Context 에대해서알지못하면, 여기의내용을모두이해하지못할수도있다. 본절에서는설명을목적으 로할뿐이며, 제시된예제를실행하기위해서는위에서제시한설정이필요하다 보안리스너설정 다음은 <enable-secure> 를 true로설정하여모든보안설정정보를기본값으로사용하고있는예이다. [ 예 4.28] 보안리스너설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <context-group> <group-name>mygroup</group-name> <webserver-connection> <http-listener> <listener-id>securelistener1</listener-id> <port>443</port> <output-buffer-size>8192</output-buffer-size> <thread-pool> <min>2</min> <step>1</step> <max-idle-time>300000</max-idle-time> <max-wait-queue>4</max-wait-queue> <max-queue>-1</max-queue> </thread-pool> <postdata-read-timeout> 30000</postdata-read-timeout> <back-log>50</back-log> <server-access-control> false</server-access-control> <scheme>https</scheme> <ssl-config> <enable-secure>true</enable-secure> </ssl-config> </http-listener> </webserver-connection> <group-docbase>webapps</group-docbase> </context-group> </web-container> 보안리스너설정과관련된요소는다음과같다. <enable-secure> SSL(Secure Socket Layer) 통신지원여부를결정한다. 102 JEUS Web Container 안내서

121 true 이면설정된값에따라 SSL 통신을지원하고, false 이면지원하지않는다.( 기본값 : false) <client-auth> 클라이언트의인증여부를설정한다. 설정값 true false 설명서버가클라이언트에게인증서를요청하여클라이언트에대한인증을수행한다. 클라이언트에대한인증과정을수행하지않는다. 일반적으로 B2B를제외한보통의경우에는클라이언트인증을수행하지않는다.( 기본값 : false) <ssl-protocol> 암호화 / 복호화하는데사용되는 SSL 프로토콜을지정한다. Sun JVM을사용한다면 TLS, IBM JVM을사용할때는 SSL이기본값으로설정된다. <cipher-suite> SSL handshaking 후에실제데이터를전송할때사용하는암호 suite들을지정한다. 일반적으로 JDK에서제공하는 cipher-suite를사용하며, 디폴트로제공되지않는 ipher-suite를사용할때사용한다. <keystore-file> key와인증서를저장하고있는파일을지정한다. 절대경로, 상대경로모두허용된다. 만일상대경로가사용된다면 JEUS_HOME\config\<node-name> 아래에서해당파일을찾는다. JVM 인자로 jeus.ssl.keystore과 javax.net.ssl.keystore을이용해서설정할수있다. 우선순위는다음과같다. 1. webmain.xml의 <keystore-file> 설정 2. -Djeus.ssl.keystore 옵션 3. -Djavax.net.ssl.keyStore 옵션 기본값은 JEUS_HOME\config\<node-name>\keystore 이다. <keystore-pass> keystore 파일을열기위한패스워드이다. JVM 인자로 jeus.ssl.keypass과 javax.net.ssl.keystorepassword를이용해서설정할수있다. 우선순위는다음과같다. 1. webmain.xml의 <keystore-pass> 설정 2. -Djeus.ssl.keypass 옵션 3. -Djavax.net.ssl.keyStorePassword 옵션 제 4 장웹서버연결과클러스터링 103

122 기본값은 jeuskeypass이다. 암호화해서설정할수있다 (ex. {AES}i0syYrTxIq+N4RTw3=). <keystore-keypassword> keystore 파일의 key들을사용하기위한패스워드이다. 일반적으로 keystore-password와똑같게설정해서사용하기때문에아무런설정이없을경우 keystore password와동일하게설정된다. keystore password와 keystore keypassword의값이다를경우항상이값을설정해야한다. 암호화해서설정할수있다 (ex. {AES}i0syYrTxIq+N4RTw3=). <keystore-type> keystore의타입을지정한다. Sun의 keytool에의해서 keystore를생성한다면 JKS(Java's Key Store) 를, OpenSSL이나 Microsoft KeyManager로 keystore를생성한다면 PKCS12를사용해야된다. JVM 인자로 javax.net.ssl.keystoretype을이용해서설정할수있다. 우선순위는다음과같다. 1. webmain.xml의 <keystore-type> 설정 2. -Djavax.net.ssl.keyStoreType 옵션 기본값은 JKS이다. <key-management-algorithm> keystore에저장할 key에대한관리알고리즘을설정한다. JVM인자로 ssl.keymanagerfactory.algorithm을이용해서설정할수있다. 우선순위는다음과같다. 1. webmain.xml의 key-management-algorithm 설정 2. -Dssl.KeyManagerFactory.algorithm 옵션 기본값은 Sun JVM을사용할경우 SunX509를, IBM JVM을사용할경우에는 IbmX509로설정된다. <truststore-file> 클라이언트인증서를저장하고있는파일을지정한다. 절대경로, 상대경로모두허용된다. 만일상대경로가사용된다면 JEUS_HOME\config\<node-name> 아래에서해당파일을찾는다. JVM 인자로 jeus.ssl.truststore과 javax.net.ssl.truststore을이용해서설정할수있다. 우선순위는다음과같다. 1. webmain.xml의 <truststore-file> 설정 2. -Djeus.ssl.truststore옵션 3. -Djavax.net.ssl.trustStore옵션 기본값은 JEUS_HOME\config\<node-name>\truststore 이다. 104 JEUS Web Container 안내서

123 <truststore-pass> truststore 파일을열기위한패스워드이다. JVM 인자로 jeus.ssl.trustpass과 javax.net.ssl.truststorepassword를이용해서설정할수있다. 우선순위는다음과같다. 1. webmain.xml의 <truststore-pass> 설정 2. -Djeus.ssl.trustpass 옵션 3. -Djavax.net.ssl.trustStorePassword 옵션 기본값은 jeustrustpass 이다. 암호화해서설정할수있다.(ex. {AES}i0syYrTxIq+N4RTw3=) <truststore-type> truststore의타입을지정한다. Sun의 keytool에의해서 keystore를생성한다면 JKS(Java's Key Store) 를, OpenSSL이나 Microsoft KeyManager로 keystore를생성한다면 PKCS12를사용해야한다. JVM 인자로 javax.net.ssl.truststoretype을이용해서설정할수있다. 우선순위는다음과같다. 1. webmain.xml의 <truststore-type> 설정 2. -Djavax.net.ssl.trustStoreType 옵션 기본값은 JKS 이다. <trust-management-algorithm> truststore에저장할 trust에대한관리알고리즘을설정한다. JVM 인자로 ssl.trustmanagerfactory.algorithm을이용해서설정할수있다. 우선순위는다음과같다. 1. webmain.xml의 <trust-management-algorithm> 설정 2. -Dssl.TrustManagerFactory.algorithm 옵션 기본값은 Sun JVM을사용할경우 SunX509를, IBM JVM을사용할경우에는 IbmX509로설정된다. 추가된부분은 <scheme>, <ssl-config> 태그이다. 이태그에대한자세한설명은 4.3. 리스너설정 을참 고한다. 특히, 리스너의포트를 443 으로설정하는것을주목한다. 이포트번호는웹브라우저에서기본적 으로사용하는 HTTPS/SSL 포트번호이다. <scheme> 부분을 https 로설정하는것도주목한다. 참고 443 포트의사용이허락되지않을수도있다. 이런경우에는 3456 과같은다른포트를선택한다. Windows 에서는 netstat an 으로현재사용중인포트의목록을볼수있다. 제 4 장웹서버연결과클러스터링 105

124 SSL Keystore 설정 SSL 프로토콜은최소한서버를클라이언트에게인증해야만한다. 이는서버측의보안리스너는클라이 언트에게 X.509 인증서를제공할수있어야한다는것을의미한다. 참고 현재, 보안리스너는서버인증만지원하고상호인증 ( 클라이언트 ) 은지원하지않는다. JSSE는 J2SDK 1.4에서제공하는 JKS keystore를사용하여서버인증서를저장한다. 더불어, 보안리스너는 JEUS_HOME\config\<node-name>\sslkeystore 로저장된 JKS keystore를기본으로사용한다. 그러므로 sslkeystore 파일을자체적으로생성할필요가있다. 이는 J2SDK 1.4에서제공하는 keytool 을사용하여다음과같이생성한다 ( 굵은글씨는사용자가입력해야할내용들이다 ). C:\>keytool -genkey -alias jeusssl -keyalg RSA -validity 7 -keyst ore d:\jeus\config\johan\keystore Enter keystore password: jeus123 What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: RND What is the name of your organization? [Unknown]: TmaxSoft What is the name of your City or Locality? [Unknown]: Seoul What is the name of your State or Province? [Unknown]: seoul What is the two-letter country code for this unit? [Unknown]: KR Is <CN=localhost, OU=RND, O=TmaxSoft, L=Seoul, ST=Kyoungi, C=KR> cor rect? [no]: yes Enter key password for <jeusssl> (RETURN if same as keystore password): C:\> 위의과정은 JEUS_HOME\config\johan\keystore에 keystore를생성한다 ( 여기서 <node-name> 은 johan 이고로컬머신의이름과동일하다 ). 개인키와인증서 ( 자가사인한공개키와다른정보들 ) 는생성되어이파일에저장된다. 이인증서는보안리스너 ( 실제로는 JSSE를구현한프로그램 ) 에의해사용되어클라이언트에게자신을인증하게된다. 106 JEUS Web Container 안내서

125 참고 first and last name 에 localhost 를포함한이유는인증서는개인보다는머신 (Server) 을대상으로발급되기때문이다. 실제환경에서는 IP 주소나 DNS 이름을넣는다. keystore의위치는바꿀수있다. 이에대한자세한내용은 SSL Truststore 설정 에서설명한다 SSL Truststore 설정 SSL 상호 ( 클라이언트 ) 인증이발생할때에는클라이언트가서버에게자신의인증서를보내줘야한다. 이인증서는서버의신뢰된인증서목록에등록되어신뢰가이루어진다. 이인증서들은 truststore 라는곳에저장된다. 현재의보안리스너는상호인증방법을사용하여설정할수없지만리스너에게는 truststore를제공해야한다. JEUS에서보안리스너에의해사용되는 truststore는 JEUS_HOME\config\<node-name>\truststore 에위치한다. 일반적으로이파일은 Verisign과같은공인인증기관 (CA) 에서발급된인증서들을포함한다. J2SDK 1.4 와함께제공되는 JRE_HOME\lib\security\cacerts은널리알려진 CA들로부터발급된신뢰된인증서들의목록이다. 실제개발환경에서는이파일을 JEUS_HOME\config\<node-name>\truststore에복사한다. 그다음에클라이언트를위한인증서들을생성, 서명하여이 truststore에포함시킨다. 이렇게생성된상호인증서를클라이언트들에게배포하여 JEUS SSL 리스너와함께인증과정을거치도록한다. 여기의간단한예에서는 truststore를처음부터생성하여자체적으로서명한서버인증서 (keystore로부터) 에포함시킨다. 이것은직접생성한인증서를신뢰하겠다는의미이다. 그러기위해서는다음의명령어들을실행시켜야한다. 1. 먼저, keystore로부터자제적으로서명한인증서를 jeusssl.cer 라는파일에 export 한다. C:\>keytool -export -alias jeusssl -keystore d:\jeus\config\johan \keystore -rfc -file jeusssl.cer Enter keystore password: jeus123 Certificate stored in file <jeusssl.cer> 2. 그인증서를 JEUS_HOME\config\<node-name>\truststore의 JEUS SSL truststore로 import 한다. C:\>keytool -import -alias jeussslcert -file c:\jeusssl.cer -keys tore d:\jeus\config\johan\truststore Enter keystore password: jeus123 Owner: CN=localhost, OU=RND, O=TmaxSoft, L=Seoul, ST=Kyoungi, C= KR Issuer: CN=localhost, OU=RND, O=TmaxSoft, L=Seoul, ST=Kyoungi, C =KR Serial number: 3e Valid from: Sat Feb 08 11:58:56 KST 2004 until: Sat Feb 15 11:58: 56 KST 2004 Certificate fingerprints: 제 4 장웹서버연결과클러스터링 107

126 MD5: B4:53:FE:B6:00:EB:FB:0F:04:7F:D2:F6:FA:9A:A0:3B SHA1: DE:C8:26:5F:D0:06:9B:3C:F8:E2:7E:3A:26:B7:78:83:9 3:2D:5E:1C Trust this certificate? [no]: yes Certificate was added to keystore C:\> 3. 위의과정이완료되면새로운 JEUS_HOME\config\<node-name>\truststore 파일이생성된다. 이것은 1개의신뢰된인증서를가지고있고클라이언트인증서가상호인증과정에서신뢰될수있을것인지를결정할때사용된다. 위와같이설정하면실제상황에서는직접생성한인증서를제출하는클라이언트는자동적으로신뢰되지않을것이다. 참고 1. 보안리스너는상호인증을지원하지않기때문에위의과정을실제로구현할수는없다. 2. truststore 의위치를변경할수있다 보안리스너속성설정 보안리스너를시작하기전에 SSL keystore와 truststore 파일의위치, 그리고이파일에접근할때사용하는암호들에대한정보를제공해야한다. 다음은 D 옵션을사용하여설정할수있는 JEUS 특정속성들에대한설명이다. jeus.ssl.keystore SSL keystore를포함하고있는파일의경로이다. 불필요. 설정되지않으면기본으로 JEUS_HOME\config\<node-name>\keystore가설정된다. jeus.ssl.keypass SSL keystore의암호이다. 설정되지않으면기본으로 jeuskeypass 가설정된다. jeus.ssl.truststore SSL truststore를포함하고있는파일의경로이다. 불필요. 설정되지않으면기본으로 JEUS_HOME\config\<node-name>\truststore가설정된다. jeus.ssl.trustpass SSL truststore의암호이다. 설정되지않으면기본으로 jeustrustpass 가설정된다. 108 JEUS Web Container 안내서

127 위의속성들은 JEUSMain.xml의 <engine-container> 의 <command-option> 태그에지정된다. [ 예 4.29] <<JEUS_HOME\config\<node-name>\JEUSMain.xml>> <?xml version="1.0"?> <jeus-system xmlns=" <node> <name>[node name]</name> <engine-container> <name>mycontainer</name> <command-option> -Djeus.ssl.keypass=jeus123 -Djeus.ssl.trustpass=jeus123 </command-option> <engine-command> <type>servlet</type> <name>engine1</name> </engine-command> <!-- Other engine start commands go here --> <command-option> 값은한줄에설정하는것에주의하고, JEUSMain.xml 의편집이끝나면저장한다 보안리스너시작하기 위의모든과정을거친후에 JEUS 노드를재시작한다 (down을하고 boot을한다 ). 이렇게하면보안리스너가시작된다. JEUS 노드의재시작과정은 "JEUS Server 안내서 " 를참고한다 보안리스너에연결하기 다음은보안리스너에연결하는과정에대한설명이다. 1. 로컬호스트의웹브라우저를열고다음의 URL을요청한다. 만약에 443 외의다른포트를설정했다면 또한 https 의 s 를유의한다. 2. 브라우저에서는다음그림과같이 Security Alert 대화창이나타난다. 이대화창은 SSL 연결은시도되었으나보안리스너에서제공되는인증서가신뢰되지않았다는것을알려준다. 브라우저가그자체의 truststore에우리가자체적으로서명한인증서를포함하고있지않기때문이다. [Yes] 버튼을클릭하여진행하고연결과인증서를수용한다 제 4 장웹서버연결과클러스터링 109

128 [ 그림 4.8] Internet Explorer 에서의인증서보안경고창 3. 보안 SSL 연결을사용하는보안리스너를통하여 hello.html 을받을수있다. 다음그림의작은자물쇠모양은 SSL 보안연결이수행되고있다는것을의미한다. [ 그림 4.9] 보안된 SSL 연결 주의 [ 그림 4.9] 에서는 1567 포트를이용하여보안리스너에접근하고있다. 일반적으로 443 포트가사 용됨을유의한다. 110 JEUS Web Container 안내서

129 4.7. 리스너튜닝 최적의성능을위하여리스너를설정할때, 다음의사항을고려한다. 시스템자원을많이사용하거나대기시간을길게하여출력버퍼의크기를증가시킨다. 일반적으로 Worker Thread Pool의 min, max, step값을크게부여하면웹컨테이너에많은클라이언트가접근할때 Pool이좋은성능을가지게된다. 시스템메모리를적게사용하기위해서는이들의값을낮게설정한다. Server Access Control 옵션을비활성화하면성능개선을기대할수있다. WebtoB 리스너에서는앞에서언급했던공식에따라 WEBMain.xml과 http.m의값들을동일하게설정한다. 이렇게해야가장좋은성능을기대할수있다. WebtoB와웹컨테이너사이의통신은항상 Pipe 통신을이용하는것을권장한다. WebtoB 서버와웹컨테이너가동일머신에존재하면이와관련된옵션을기본값인 false 로설정한다. 다른머신에존재하면 Pipe 통신을할수없으므로, <disable-pipe> 태그를 true 로설정한다. 웹컨테이너에의해필요한설정이자동적으로설정된다. 그러므로설정이반드시필요하지는않다. 제 4 장웹서버연결과클러스터링 111

130

131 제 5 장 Session Tracking 본장에서는 Session Tracking 의주요기능과설정방법, 튜닝에대해서설명한다 개요 Session Tracking에관련된기본적인개념에대한소개부터시작한다. 각주제들은 Session, Session ID, Session Cookie, URL rewriting등에대한정의를내리고 JEUS 웹컨테이너에 Session Tracking을어떻게구현하는지에대해설명한다. 또한보다복잡한분산환경인웹서버클러스터링환경에서는어떻게 Session Tracking이구현되고설정되는지도살펴본다. 이러한클러스터링환경에서 Session Tracking을지원하는메커니즘에는 Session Routing과 Session Server의사용 2가지가있다. Session Server를사용하는방법에는동작방식에따라중앙집중식, 분산식두가지방식이있다 Session Tracking 의주요기능 본절에서는 Session Tracking이무엇이고 JEUS 웹컨테이너에서어떻게지원되는지에대하여알아본다. 매우간단한설명만이제공되기때문에익숙하지않은사용자들은본절의내용을이해하려고시도하기전에 Servlet과 Session Tracking에대한서적을참고한다. 다음그림은 Session Tracking과 Session 관리에관련된웹컨테이너의컴포넌트를보여주고있다. Session 에관련된부분들이강조되어있다. [ 그림 5.1] JEUS 웹컨테이너의구조중 Session에관련된부분들 JEUS Web Container Context Group A Client A Web Server A Web server connection/list ener Virtual Host A Misc. context group settings Default Virtual Host Monitoring thread Context/Web app A Context/Web app B Misc. container settings Client B Web Server B Context Group B Web server connection/list ener Virtual Host B Misc. context group settings Default Virtual Host Session handling settings Session Server Context/Web app C Context/Web app D 제 5 장 Session Tracking 113

132 참고 웹서버도 Session Tracking 에관련되어있음을주의한다. (HTTP) Session은동일한클라이언트 ( 예를들면웹브라우저 ) 의 HTTP 요청과연관된일련의작업들이다. 여러클라이언트가이런요청을표준 HTTP를통하여보낼때웹서버는이클라이언트들을구별할수없다. 이문제는기본적으로 HTTP 헤더에유일한 Client ID 가없기때문이다. 따라서웹서버는관련된사용자요청을하나의 Session으로 Tracking할수없다. 이것은 HTTP가 state less( 무상태 ) 와 connectionless( 무연결 ) 프로토콜이기때문이다. 이것은기본적으로다음과같이작동한다. 1. 클라이언트는웹서버에연결을한다. 2. 클라이언트는무상태 HTTP 요청을생성한다. 3. 클라이언트는응답을받는다. 4. HTTP 연결이끊어진다. Client ID나지속적인 Session의개념은 HTTP 프로토콜에포함되어있지않다. 따라서웹서버는 HTTP 연결이끊어지거나요청에대한응답수신을종료한순간, 각요청에대한사항들을잃어버린다 ( 단일요청을하는경우발생 ). 복잡한웹애플리케이션에서사용자가지속적으로서로연관된요청을수행하는경우에는사용할수없는것이다. 이문제를극복하기위하여, Session ID라는특수 string을각 HTTP 요청에추가한다. 이유일한 ID는클라이언트가최초요청을할때필요에따라생성되어클라이언트에전달된다. 이후클라이언트의요청에이 Session ID가지속적으로붙여진다. 이렇게함으로써, 웹컨테이너는각요청의근원을파악할수있기때문에사용자가거래를하는동안에대화성상태 (Conversational state) 를유지할수있게된다. 따라서 Session의기능이없는 HTTP 프로토콜을이용하여 Session의개념을지원할수있는것이다. Session ID는 Cookie 또는클라이언트에게반환되는 HTML 페이지의각 URL 링크의파라미터로자동으로추가 ( 이것을 URL rewriting이라고한다 ) 된다. 또다른옵션은 hidden field로 HTML 폼에 Session ID를저장하는방법이있다. 물론, Servlet 프로그래머의관점에서봤을때, 이논점들은강력한 Servlet API에의해모두구현되는것들이다 기본기능 JEUS 웹컨테이너는 URL rewriting과 Cookie를모두지원하여 Session Tracking을가능하게하기위해서기본적으로 Cookie가사용된다. Session ID를운반할때사용되는 Cookie를 Session Cookie라고한다. 웹컨테이너에서하나의 Session은하나의 Servlet API인 HttpSession 클래스의인스턴스로표현된다. 이인스턴스는 Session Cookie( 또는 URL rewriting의결과로생긴 URL 파라미터 ) 의 Session ID와연관되어있다. HttpSession 객체는기본적으로그것을생성하는웹컨테이너에존재하고이것은사용자선호성향이나사용자가전자상거래사이트에서구매하고싶은물품의목록등과같은사용자에대한데이터를가지고있다. 114 JEUS Web Container 안내서

133 지금부터 JEUS의웹컨테이너에서어떻게 Session Cookie와 HttpSession 객체가사용되어 Session을 Tracking하는지에대하여알아보자. URL rewriting은여기서설명한기술의개념과유사한것임을알아두자. 단, Session ID가 HTML 페이지의 URL 링크에포함되어있다는것이별도의 Cookie header에담겨진다는것과다르다. 다음은한클라이언트가 JEUS 웹컨테이너가관리하는리소스를요청하는과정에대한설명이다. [ 그림 5.2] 웹컨테이너가 Session Cookie를발급하는과정 1. First HTTP request 2. First HTTP request Web Container A Client A 6. Web browser stores cookie 'A' for later use. 5. HTTP response Cookie A Web Server A 4. HTTP response Cookie A HTTPSession object A 3. Web container A creates a new session object 'A' and returns session ID cookie 'A' 1. 클라이언트는웹서버에초기요청을한다. 2. 웹서버는웹컨테이너에게요청을전달한다. 3. 웹컨테이너는해당클라이언트를위한 HttpSession 객체와해당 HttpSession의 Session ID를지닌 Session Cookie를생성한다. 이 ID는동일한클라이언트가지속적인요청을할때메모리에서생성한 HttpSession 객체를가져오기위해사용된다. 4. 응답데이터와 Session Cookie는웹서버에전달된다. 5. Session Cookie는클라이언트의웹브라우저에응답과함께전달되고 HTTP 연결은끊어진다. 6. SessionID를포함하는 Session Cookie는클라이언트의웹브라우저에저장된다. 이제클라이언트는 Session Cookie를지니고있고, 같은웹컨테이너에또다른요청할때 Cookie를포함해서보낼수있다. 웹컨테이너는클라이언트를인식할수있고 (Cookie의 Session ID를보고 ), 클라이언트의 HttpSession 객체를가져올수있다. 다음은이과정에대한설명이다. [ 그림 5.3] Session ID Cookie로웹컨테이너에두번째요청을보내는과정 Cookie A Client A Cookie A 1. Second HTTP request 5. HTTP response Cookie A 2. Second HTTP request 4. HTTP response 3. Web container A associates cookie 'A' with the stored HTTPSession object A Web Container A HTTPSession object A Web Server A 제 5 장 Session Tracking 115

134 1. 클라이언트는같은웹서버에게또다른요청을보낸다. 이번에는전에받은 Session Cookie를웹브라우저에서받아요청에첨부한다. 2. 웹서버는요청을받아처음의요청과같이동일한웹컨테이너에요청 (Cookie도포함하여 ) 을전달한다. 3. 웹컨테이너는요청과 Session Cookie를받는다. Session Cookie에서발견된 Session ID에해당하는 HttpSession 객체를자신의메모리영역에서찾아온다. 웹컨테이너는그 HttpSession 데이터를사용하여요청을처리한다. 4. 응답데이터와 Session Cookie는웹서버에전달된다. 5. HTTP 응답이웹브라우저에게전달된다. 그리고 HTTP 연결은끊어진다. 이응답에 Cookie가같이전달될필요는없다. Cookie는처음연결이생성될때만응답에포함되어전달되면된다 클러스터환경에서 Session Tracking 이전절에서는단하나의클라이언트, 하나의웹서버, 하나의웹컨테이너가연계된간단한상황에서 Session Tracking이이루어지는것을살펴보았다. 그러나, 실제운영환경에서는이러한간단한구조는충분하지않은경우가많다. 많은양의사용자요청을수용하기위해서는부하분산과웹서버클러스터링이구현되어야한다. 어떻게클러스터가구성되는지에대한자세한내용은 제4장웹서버연결과클러스터링 을참고한다. 웹서버클러스터에있어서 Session Tracking 메커니즘을구성하고설정할때에는특별한주의가필요하다. 분산된클러스터에서 Session을관리할때에는 3가지의주요사항들이쟁점이된다. 1. Session Cookie를가지는요청을처음요청했던웹컨테이너에게어떻게전달되게할까? 2. Session으로제한적인요청을모든웹컨테이너가처리할수있게하기위해서어떻게하나의컨테이너에서생성된 HttpSession 객체를다른웹컨테이너에서도사용할수있게할까? 3. 내부또는외부적인장애로웹컨테이너가다운되었을때어떻게 Session 데이터를백업할까? 첫번째논점은 Session Routing(Sticky Session) 이라는기능으로대처가능하고나머지 2가지논점들은 Session Server로대처가능하다. 지금부터이 3가지의문제와해결방법에대하여설명한다. 참고 위의 1, 2 번은근본적으로같은문제이지만 2 가지방법으로해결한다 Session Routing(Sticky Session) Session Routing(Sticky Session) 은클러스터된환경에서 Client ID뿐만아니라웹컨테이너 ID와함께 Session ID Cookie로꼬리표를붙이기위해사용된다. Container ID는 Session Cookie를처음생성했던컨테이너에의해추가되고, 웹서버가원래의웹컨테이너에게요청을전달해줄수있게한다. 116 JEUS Web Container 안내서

135 예를들면, 2 개의웹컨테이너 A, B 가하나의웹서버에연결된클라이언트요청상황을고려해보자. 이과정은다음과같이나타낼수있다. [ 그림 5.4] Session ID Cookie 를이용하여 2 개의웹컨테이너와 Session 을시작하는경우 2. Web server arbitrarily selects Web container A to handle the request 4. Web container A creates a new session object 'A' and returns session ID cookie 'A' 1. First HTTP request 3. First HTTP request Web Container A Client A 7. Web browser stores cookie 'A' for later use. 6. HTTP response Cookie A Web Server A 5. HTTP response Cookie A HTTPSession object A Web Container B 1. 클라이언트는웹서버에게초기요청을한다. 2. 웹서버는임의적으로요청전달을위해 1개의웹컨테이너를선택한다. 여기서는웹컨테이너 A가선택되었다. 3. 요청은웹컨테이너 A로전달된다. 4. 웹컨테이너 A는 HttpSession 객체를생성하고응답과함께 SessionID Cookie를돌려보낸다. 이 ID는다음에오는같은클라이언트의요청을처리할 HttpSession 객체를메모리에서불러올때사용된다. 5. 웹컨테이너는응답을하고웹서버에 Session Cookie가반환된다. 6. Session Cookie는응답과함께클라이언트의웹브라우저로전달된다. HTTP 연결은이제끊겼다. 지금까지모든것이정상적이었다. 심각한문제는두번째요청이같은클라이언트로부터생성될때발생 하기시작한다. 이문제의시나리오는다음과같이그림으로표현이가능하다. [ 그림 5.5] Session Routing 이없는경우클라이언트 Session 삭제 Cookie A 2. Web server arbitrarily selects Web container B to handle the second request Cookie A Client A 1. Second HTTP request Cookie A 3. Second HTTP request Web Container A HTTPSession object A Web Server A 4. Web container B tries to find HTTPSession object A. It fails! No such object. Web Container B 제 5 장 Session Tracking 117

136 1. 클라이언트는같은웹서버에또다른요청을한다. 이번에는이전에반환된 Session Cookie가웹브라우저로부터가져와요청에붙여진다. 2. 웹서버는요청을받아들인다. 웹서버는임의로 2개중 1개의웹컨테이너를선택한다. 이번에는웹컨테이너 B가선택되었다. 3. 그요청과 Session Cookie는웹컨테이너 B에전달된다. 4. 웹컨테이너 B는요청과 Session Cookie를받는다. 이것은자신의메모리영역에서 Cookie에대응하는 HTTPSession을가져오려고시도한다. 웹컨테이너 B는그러한 HTTPSession 객체가없기때문에가져올수없다. 따라서웹컨테이너 B는클라이언트 Session을유지할수없고새로운 Session을강제로생성하거나또는오류메시지를반환한다 ( 물론두옵션모두권장하지않는다 ). 이문제를해결하기위하여처음에 HttpSession 객체를생성했던동일한웹컨테이너에게 Session으로제한된요청을올바르게 Routing해줄방법이필요하다. 이것은 Session Cookie에게추가의웹컨테이너 ID를부여함으로써해결된다. 다음은이해결과정을그림으로나타낸것이다. [ 그림 5.6] Session Cookie에추가의웹컨테이너 ID 부여 Client A 7. Web browser stores cookie 'A' for later use. 1. First HTTP request 6. HTTP response Cookie A CID:A Web Server A 2. Web server arbitrarily selects Web container A to handle the request 3. First HTTP request 5. HTTP response Cookie A CID:A 4. Web container A creates a new session object 'A' and returns session ID cookie 'A'. It also adds a container ID, CID, 'A' to the cookie. Web Container A HTTPSessio n object A Web Container B 1. 클라이언트는웹서버에초기요청을맺는다. 2. 웹서버는임의의웹컨테이너를선택한다. 여기서는웹컨테이너 A가선택된다. 3. 요청은웹컨테이너 A에전달된다. 4. 웹컨테이너 A는 HttpSession, Session ID Cookie를생성하고웹컨테이너 ID(CID) 를 Cookie에삽입한다. 5. 웹서버에응답과 Session Cookie를반환한다. 6. 웹브라우저에응답과 Session Cookie를반환한다. 7. 웹컨테이너ID(CID) 를포함하는 Session Cookie는웹브라우저에저장된다. 118 JEUS Web Container 안내서

137 이렇게함으로써 Routing 문제가쉽게해결된다. 다음은 Session Routing 의작동에대한그림이다. [ 그림 5.7] Session Routing 의작동 Cookie A CID:A Client A Cookie A CID:A 1. Second HTTP request 6. HTTP response 2. Web server inspects the cookie Web container ID 'A' and routes the request to Web container A. Cookie A CID:A 3. Second HTTP request 5. HTTP response 4. Web container A associates cookie 'A' with the stored HTTPSession object A Web Container A HTTPSession object A Web Server A Web Container B 두번째요청에웹서버는 Session Cookie와 Container ID 값 (CID) 을찾아낸다. 웹서버는해당 HttpSession 이존재하는원래의웹컨테이너로요청을 Routing시킨다. 웹서버에서표준이아닌 Container ID를식별하기위해서 Apache, IIS, SunOne(Iplanet) 과같은다른웹서버의경우에는 mod_jk 모듈을설치해야한다. WebtoB 웹서버에게는이기능은내장되어있다. 자세한내용은 4.4. 리스너연동과클러스터링을위한웹서버설정 부분의설명을참고한다. 참고 Session Routing 기능을위해서는모든웹서버가모든웹컨테이너와연결을맺어야한다. 부하분산기를사용할경우, 여러대의웹서버중에서요청을받은웹서버가해당웹컨테이너에접속을하지못하면 Session이끊길수있기때문이다. 그러나부하분산기가 Session Routing을자체적으로지원하고있다면, 위처럼서로간에모두연결될필요가없다. 예를들어 WebtoB를부하분산기로사용하고있다면, Session Routing은클러스터링이완벽하게연결되어있지않아도사용할수있다 Session Server 간단한 Session Routing을사용하는것보다한층더강력한것이 Session Server를사용하는것이다. Session Server를사용할때에는, 모든웹컨테이너가클러스터내의모든웹서버에연결될필요는없다. 또한, Session Server는클러스터내의모든 Session 데이터에게신뢰적인백업기능을제공한다. 따라서특정웹컨테이너에장애가발생하더라도 Session 데이터는저장되고다른정상적인웹컨테이너가장애가발생한웹컨테이너의요청을대신처리한다. 다음그림에는장애가발생한웹컨테이너의문제가표현되어있다. 이시나리오에서는웹컨테이너에존재하는모든사용자 Session 데이터가소멸된다. 이런상황은운영환경에서는반드시피해야하는것이다. 제 5 장 Session Tracking 119

138 [ 그림 5.8] 장애가발생한웹컨테이너의문제 Cookie A Client A Cookie A 1. Second HTTP request 2. Web server selects Web container A to handle the second request Web Server A Cookie A 3. Second HTTP request 4. Before or during processing of the request, Web container A is downed due to an internal failure. HTTPSession A is lost forever! Web Container A HTTPSession object A Web Container B 이와같이특정웹컨테이너에장애가발생하는상황에서도 Session을지속시키기위해서 Session Server 가클러스터에추가되었다. 이런 Session Server가사용될경우에는클라이언트의첫 HTTP 요청이다음과같은방법으로처리된다. [ 그림 5.9] Session Server가사용될경우클라이언트의첫 HTTP 요청처리 1. First HTTP request 2. Web server arbitrarily selects Web container A to handle the request 3. First HTTP request 4. Web container A creates a new session object 'A' and a corresponding session ID cookie 'A' Web Container A Client A 7. HTTP response 6. HTTP response HTTPSession object A 8. Web browser stores cookie 'A' for later use. Cookie A Web Server A Session Server Cookie A Web Container B Cookie A HTTPSession object A 5. The Web container stores both the cookie ID (A) and the HTTPSession object on the session server. It then returns the HTTP response. 1. 클라이언트는웹서버에게요청을보낸다. 2. 웹서버는웹컨테이너 A를클러스터내에서선택하여요청을처리하게한다. 3. 웹서버는웹컨테이너 A에게요청을전달한다. 4. 웹컨테이너는 HttpSession 객체와 Session Cookie를생성한다. 이 ID는다음에같은클라이언트로부터요청이왔을때 Session Server로부터생성된 HttpSession 객체를꺼내기위해사용된다. 5. 요청에대한처리가완료되면웹컨테이너는 HttpSession 객체와 SessionID를 Session Server에저장한다. 6. 응답데이터와 Session Cookie는웹서버로전달된다. 120 JEUS Web Container 안내서

139 7. SessionIDCookie 는응답과함께웹브라우저로전달되고 HTTP 연결이끊긴다. 8. 웹브라우저는이 Session Cookie 를저장한다. 후에웹컨테이너 B 가무작위로웹서버에의해클라이언트 A 의요청을처리하도록선택되거나웹컨테이 너 A 에장애가발생하더라도 Session 데이터는 Session Server 에서가져올수있다. [ 그림 5.10] Session 데이터의요청처리 Cookie A 2. Web server arbitrarily selects Web container B to handle the second request Cookie A Client A 1. Second HTTP request 6. HTTP response Cookie A Web Server A Cookie A 3. Second HTTP request Cookie 5. HTTP A response Web Container A Web Container B Session Server Cookie A HTTPSession object A 4. Using cookie ID 'A', Web container B fetches HTTPSession A (previously created by container A) from the session server and then processes the resquest in a normal manner using the HTTPSession data. 게다가, Session 데이터저장소를좀더안정적으로만들기위하여백업 Session Server가설정될수있다. 자세한내용은 5.3. Session Tracking 설정 에서간략하게다시설명한다. 실제로 Session Server는 JEUSMain.xml에서설정하며특정 Context가 Session Server를사용할지의여부는 Context 레벨의웹애플리케이션의설정즉, jeus-web-dd.xml에서설정한다. 일반적으로 Context 레벨에서설정을하지만 WEBMain.xml에서 Web Container 레벨, Context Group 레벨의설정도가능하다. 이와관련된자세한내용은 Session 을참고한다. 참고 중앙집중식 Session 클러스터링설정에대한자세한내용은 JEUS Server 안내서 의 중앙세 션서버 를참고한다 혼합모드 위에서설명한 Session Routing 방법과 Session Server 방법이혼합된것이혼합모드이다. Session Routing(Sticky Session) 방법은웹컨테이너의 Session 객체를접근하므로빠르다. 그러나, 문제가발생할경우에웹컨테이너의모든 Session 데이터는소멸되고복구가불가능하게될것이다. Session Server를사용하면 Session Server에모든 Session 객체가서버에저장되므로특정웹컨테이너에문제가생기더라하더라도 Session 객체의소멸은없다. 특정웹컨테이너에문제가발생하더라도 제 5 장 Session Tracking 121

140 Session Server는 Session을유지할수있다. 그러나이기술은 Session이필요한요청이들어왔을경우에 Session 객체를 Session Server로부터가져와야하는부담이있다. 또한 HTTPSession 객체가변경되었을경우 Session Server에다시저장되어야한다. 그러므로, Session Server를사용하는단점은 Session Routing의방법보다처리속도가늦다는것이다. 혼합방식을사용함으로써 2가지방식의장점을모두살릴수있다. 만약에 2가지방법이혼합되면 Session 객체는 Session Server와 Session 객체를생성한웹컨테이너에모두존재한다. 혼합방식을사용하여웹컨테이너는필요할때만 Session Server에서 HTTP Session 객체를꺼내서변경한다. 따라서, 혼합방식을사용할경우에는사용되는네트워크대역폭도 Session Server만을사용하는방식에비해거의절반가량줄이고모든 Session 데이터의안전한백업도보장받을수있다. 이때문에클러스터환경에서는혼합방식의 Session 관리의사용을권장한다 분산 Session Server Session Server를사용하면특정웹컨테이너에장애가발생하더라도지속적으로 Session을유지할수있는장점이있다. 그러나, Session Server를사용하는경우소규모의클러스터링환경에서는좋은성능을유지할수있으나클러스터링규모가커질수록 Session Server에부담이가중되어선형적인성능향상을얻을수없는단점이있다. 분산 Session Server는대규모클러스터링환경에서성능향상을위해고안된 Session Server이다. 분산 Session Server란각웹컨테이너마다 Session Server를두는방식을말한다. 기본적으로 Session Routing 기술 (Sticky Session) 을사용하며 ( 물론 Session Routing(StickySession) 이적용되지않는환경에서도이상없이동작한다 ) Session Server와마찬가지로 Session 데이터백업을설정할수있어웹컨테이너에장애가발생하여도지속적으로 Session을유지할수있다. 소규모클러스터링환경에서는중앙 Session Server를사용하고대규모클러스터링환경에서는분산 Session Server를사용하기를권장한다. 분산 Session Server 설정은 JEUSMain.xml를통해서이루어지며, 특정 Context가 Session Server를사용할지의여부는 Context 레벨의웹애플리케이션의설정즉, jeusweb-dd.xml에서설정한다. 일반적으로 Context 레벨에서설정을하지만 WEBMain.xml에서웹컨테이너, Context Group 레벨의설정도가능하다. 이와관련된자세한내용은 Session 을참고한다. 참고 분산식 Session 클러스터링설정에대한자세한내용은 JEUS Server 안내서 의 분산세션서 버 를참고한다 URL Rewriting 과 Cookie 기본적으로웹컨테이너는클라이언트의 Session ID를지속되는요청동안유지하기위하여 Cookie를사용한다. 한가지문제점은대부분의웹브라우저가새로운요청에대하여 Cookie가원래생성된곳의도메인이름과다른도메인이름을가지고요청을하면 SessionID Cookie를보내지않는다는것이다. 122 JEUS Web Container 안내서

141 이런이유로, jeus-web-dd.xml deployment descriptor에특수한태그가필요한데, <url-rewriting> 태그가그것이다. 이태그가사용되면, Session ID는웹브라우저가 Cookie를지원하여도 URL rewriting을사용하여유지된다. 이런방법으로, Session Tracking은다른도메인이름이몇개의요청에사용되어도작동한다. 이와관련된설정에대해서는 Session 설정인 Session 및 제6장 Web Context( 웹애플리케이션 ) 를참고한다 Shared Session 데이터 일반적으로 Session은같은 Context에서만관리된다. 하지만같은 Session을다른 Context 간에공유를하기를원한다면 Session 설정의 <shared> 를 "true" 로설정한다. 이와관련된자세한설정은 Session 의 <shared> 부분을참고한다. 참고 Session Server를사용한다고해서모든 Session이공유되는것은아니다. Session Server를사용하더라도서로다른 Context 간에 Session을공유하려면 Session 설정의 <shared> 를반드시설정해야한다 Session Tracking 설정 본절에서는 JEUS에서 Session Tracking을위한설정파일들과각설정방법에대해서설명한다. 또한 Apache 웹서버는어떻게설정이되어야 Session Routing(Sticky Session) 이지원되는지에대해서도설명한다. 참고 Session Tracking 에대한설정은 WebAdmin 을이용하여도동일하게설정이가능하다. Session Tracking을위해서는 Session Routing(Sticky Session) 과 Session Server를사용하는방법이있다고위에서설명하였다. Sticky Session 사용방법 JEUS6에서는기본적으로 Session Routing(Sticky Session) 을지원하므로웹서버에서 Session Rout ing(sticky Session) 이지원된다면특별한설정을하지않아도된다. Session Server 사용방법위에서언급한혼합모드를위해서는 JEUS가제공하는중앙 Session Server 또는분산 Session Server 를설정하고웹컨테이너의 Session 설정의 <distributable> 을 "true" 로설정해야한다. Session 설정은 WEBMain.xml에서 Web Container 레벨, Context Group 레벨로설정하거나 jeus-web-dd.xml에서 Context 레벨로설정할수있다. 이부분에서는 Context 레벨의설정만설명한다. 좀더자세한내용을위해서는 Session 부분을참고한다. 제 5 장 Session Tracking 123

142 중앙 Session Server 설정 중앙 Session Server를사용하는경우 JEUSMain.xml에중앙 Session Server 설정을하고 JEUS 노드를재시작해야한다. 중앙식 Session Server는사용한 Session 클러스터링이노드클러스터링상태와아닐때모두가능하다. 2가지경우에따라설정방법은다르며구체적인설정방법은다음과같다. 참고만약중앙 Session Server와분산 Session Server 설정이동시에 JEUSMain.xml에존재한다면중앙 Session Server를사용한다. 중앙 Session Server의설정방법은 JEUS Server 안내서 의 중앙세션서버 를참고한다. 노드클러스터링상태일때설정 노드클러스터링상태일때는웹컨테이너설정을위해 WEBMain.xml에서다음의예제와같이 Session Server 사용여부를설정해주기만하면된다. 다음은 Session Tracking 설정에대한예이다. [ 예 5.1] Session Tracking 설정 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container xmlns=" <session-config> <distributable>true</distributable> </session-config> </jeus-web-dd> 노드클러스터링상태가아닐때설정 노드클러스터링상태가아닐경우에는웹컨테이너설정인 WEBMain.xml에해당컨테이너가사용할 Session Server의정보를설정해야한다. 그리고 Session Server 사용여부를 [ 예 5.1] 과같이설정한다. 노드클러스터링을하지않은상태에서중앙 Session Server를사용하기위해서는 WEBMain.xml의 Session Server 설정은다음과같이한다. [ 예 5.2] 노드클러스터링을하지않은상태에서중앙 Session Server 사용 : <<WEBMain.xml>> <?xml version="1.0"?> <web-container> <session-server> <primary-server>node1</primary-server> <backup-server>node2</backup-server> <connect-timeout>120000</connect-timeout> 124 JEUS Web Container 안내서

143 <read-timeout>12000</read-timeout> <check-level>set</check-level> </session-server> </web-container> 다음은설정태그에대한설명이다. <session-server> 태그 <primary-server> <backup-server> 설명주중앙 Session Server의 JEUS 노드이름이다. 이노드에대한물리적인호스트정보는 vhost.properties에명시되어있어야한다. 백업 Session Server의 JEUS 노드이름이다. 주 Session Server 가다운되었을때웹컨테이너는백업 Session Server 로 take over 를실행한다. 이노드에대한물리적인호스트정보는 vhost.properties 에명시되어있어야한다. <connect-timeout> <read-timeout> <check-level> Session Server와웹컨테이너사이의연결을맺을때기다리는최대시간을나타낸다.( 기본값 : 20초, 단위 : millisecond) Session Server와웹컨테이너사이의통신에있어서응답을기다리는최대시간을나타낸다.( 기본값 : 20초, 단위 : millisecond) Session Server로 Session을업데이트하기위한 Session 객체의수정정도를설정한다.( 기본값 : set) all : getsession 후에 Session 객체의수정과관련없이모든 Session을 Session Server로업데이트한다. modified : getsession 후에 Session 객체의수정사항을검사해서변경된경우에업데이트한다. set : 해당 Session의 setattribute/putvalue/removaattribute/removeval ue/setmaxinactiveinterval을호출한경우에만 Session을업데이트한다. WEBMain.xml를설정할때 <primary-server> 와 <backup-server> 에설정되는 JEUS 노드정보를설정하는 vhost.properties의설정예는다음과같다. [ 예 5.3] <<vhost.properties>> jeus.vhost.enable=true node1=xxx.xxx.xxx.xxx:10003 node2=yyy.yyy.yyy.yyy:10004 제 5 장 Session Tracking 125

144 각설정값들의의미는다음과같다. 항목 jeus.vhost.enable 노드정보 설명 true 로설정한다. 노드의실제물리적설정으로 node1 과 node2 의설정을한예이다. IP : port 형식으로작성한다 분산 Session Server 설정 분산 Session Server 를사용하고자할때에도 JEUSMain.xml 에설정을하고 JEUS 노드를재시작한다. 자 세한설정방법은 JEUS Server 안내서 의 분산세션서버 를참고한다. 참고여러분산 Session Server가클러스터링되는환경을위해서는 JEUS의노드클러스터링이전제되야한다. 만약중앙 Session Server와분산 Session Server 설정이동시에 JEUSMain.xml에존재한다면중앙 Session Server를사용한다 Session Tracking 튜닝 클러스터된환경에서최적의성능을위해다음과같이수행한다. 항상 Session Routing(Sticky Session) 과 Session Server를혼합하여사용하도록노력한다. 이는좋은성능과안정적인운영을보장한다. 웹서버연결들이잘설정되고튜닝되어있어야한다. 사용자의요청이폭주하는사이트에서는분산 Session Server를사용할것을권장한다. 126 JEUS Web Container 안내서

145 제 6 장 Web Context( 웹애플리케이션 ) 본장에서는 JEUS 웹컨테이너내의 Java EE Web 모듈 (Web Application, Context) 을조립, 등록, 모니터 링하는모든방법에대하여설명한다 개요 본장과나머지장들에서는 Web Application 과 Context 의의미가완벽하게같은의미로통하지만후자 를주로사용할것이다 Web Context 의기본개념과구조 본절에서는 Context 에관련된기본개념과디렉터리구조, 관련파일에대해서설명한다 기본구조 다음그림은 Context/Web application 에관련된웹컨테이너의그림이다. [ 그림 6.1] JEUS 웹컨테이너에 context/web application JEUS Web Container Context Group A Client A Web Server A Web server connection/list ener Virtual Host A Misc. context group settings Default Virtual Host Monitoring thread Context/Web app A Context/Web app B Misc. container settings Client B Web Server B Context Group B Web server connection/list ener Virtual Host B Misc. context group settings Default Virtual Host Session handling settings Session Server Context/Web app C Context/Web app D 제 6 장 Web Context( 웹애플리케이션 ) 127

146 웹애플리케이션은클라이언트의요청에의한웹기반의서비스 ( 예를들면, 장바구니에물품을추가하거나, 장바구니안의물품을구매하거나웹기반의경매사이트에서물건을사기위해브라우징하는등 ) 를수행하기위한 static과 dynamic content의집합이라고할수있다. Static Content Static Content는사전에제작되어서, 더이상어떤처리도하지않고단순히반환되는모든종류의데이터들을의미한다. 다음은그예이다. HTML 페이지 단순텍스트파일 이미지파일 (GIF, JPEG) 비디오 (MPEG) 기타 Dynamic Content 변하지않는정적과는반대로 Dynamic Content는클라이언트요청에대한응답으로생성한모든종류의데이터를말한다. 이러한 Dynamic Content는클라이언트와상호연동하기위해또는사용자의선택과선호에따라응답페이지를생성할때사용한다. JEUS 웹컨테이너를설명할때 Java EE 웹애플리케이션에초점이맞춰진다. Static 부분뿐만아니라이런애플리케이션의패키징과개발규칙들까지모두 Java EE 5 스펙, Servlet 2.5스펙, JSP 2.1 스펙에정의되고기술되어있다. Context는논리적으로 Context Group 또는가상호스트하위에존재한다. 가상호스트는 Context Group 의서브컴포넌트이다. 등록된 Context는묵시적기본가상호스트로작동한다. 본장에서는간략하게기본가상호스트의일부로 Context Group 아래에 Context를설정한다고가정한다. 가상호스트의더자세한사항은 제7장가상호스트 를참고한다 WAR 파일구조 Java EE 웹애플리케이션은 Java EE 웹컨테이너에배포되고등록되기전에특수한 Archive( 라이브러리 ) 파일에패키징하여포함시켜야한다. 이애플리케이션들을패키지할때사용하는 Archive들은 JAR/ZIP 파일들로 '.war' 확장자를가지고있다. 이들은 JAR 유틸리티를사용하여다른 JAR Archive를생성하는방법과동일하게생성된다. WAR 파일의구조는다음과같다. 128 JEUS Web Container 안내서

147 [ 그림 6.2] WAR 파일구조 WEB WAR T index.html static\ T.html jsp\ T.jsp images\ T.jps,.gif Legend: 0I: binary or executable file X: XML document J: JAR file T: Text file C: Class file V: java source file DD: deployment descriptor META-INF\ T MANIFEST.MF WEB-INF\ X X web.xml jeus-web-dd.xml classes\ C Servlet.class lib\ J Library JAR tlds\ T.tld META-INF\ 이디렉터리는선택사항이고, 존재하면 JAR 포맷에정의된 Descriptor 파일인 "MANIFEST.MF" 파일을포함한다. WEB-INF\ 이디렉터리는필수사항이고, 웹애플리케이션의 Servlet, Java 유틸리티클래스들, JAR/ZIP 라이브러리들이포함되어있다. 이디렉터리바로하위에는다음과같은컴포넌트들이존재한다. 파일 web.xml 설명 Java EE 표준웹애플리케이션 Deployment Descriptor 파일로웹애플리케이션의모든메타정보를가지고있다. 그리고, 클라이언트에의해접근가능한모든 Servlet과 JSP들의목록을가지고있어야한다. 그렇지않으면웹컨테이너는파일들의위치를알수없다. jeus-web-dd.xml classes\ JEUS 의웹애플리케이션 Deployment Descriptor 로자세한설명은 De ployment Descriptor 파일설정 을참고한다. Servlet 클래스들과유틸리티클래스들이하위디렉터리에포함되어있다. 제 6 장 Web Context( 웹애플리케이션 ) 129

148 파일 설명 표준 Java 패키지구조로정리되어있다. lib\ 웹애플리케이션에필요한 Java 라이브러리들을포함한다. 라이브러리들은 JAR 또는 ZIP 파일들로패키지되어이경로에저장된다. 이파 일들의내용들은자동적으로모든 Servlet 의클래스경로에추가된다. tlds\ JSP 페이지들을위한 custom tag library descriptor 들을포함한다. 기타 HTML, JSP, 이미지파일들과같은 content 들을포함하고있는임의의이름의디렉터리이다 디렉터리구조 다음그림은 Context 와그상위컴포넌트들의기본디렉터리구조이다. [ 그림 6.3] Web Context 디렉터리의구조 JEUS_HOME\ config\ <node-name>\ T index.html static\ X JEUSMain.xml <node-name>_servlet_ <engine-name>\ T jsp\.html X WEBMain.xml T.jsp webhome\ app_home\ MyContext\ images\ T.jps,.gif META-INF\ T MANIFEST.MF WEB-INF\ Legend: 0I: binary or executable file X: XML document J: JAR file T: Text file C: Class file V: java source file DD: deployment descriptor X X web.xml jeus-web-dd.xml classes\ C Servlet.class lib\ J Library JAR tlds\ T.tld 130 JEUS Web Container 안내서

149 6.3. Web Context 등록 본절에서는 Java EE Web Context( 웹애플리케이션 ) 가 JEUS 웹컨테이너에어떻게등록되는지에대해설명한다. 여기에서 등록 은 디플로이 와 설치 라는의미와동일하다. 등록은앞에서간단히설명한바와같이, 모든 Java EE 웹애플리케이션을 JEUS 웹컨테이너에서요청을받고수행할수있도록준비하는과정을의미한다. WAR 파일등록 모든 Java EE 호환 WAR 파일은 JEUS 웹컨테이너에등록 ( 즉, 설치또는디플로이라고도한다 ) 될수있다. 그러므로몇개의 WAR/context는 Context Group 안에그룹화된다 ( 제3장 Context Group 참조 ). WAR 파일이정상적으로등록되면 Context(WAR 파일을가진 ) 는클라이언트요청을서비스할준비가되었다는것이다. WAR 파일등록에는다음과같은하위작업들이포함된다. 1. 임의의위치에새로운 Context 디렉터리를생성한다음 WAR 파일의내용을풀어놓는다. 새롭게생성된 Context의디렉터리구조는 WAR 파일의구조와동일하다. 사용상의편의를위해서 JEUS_HOME\webhome\app_home\<contextName> 으로디렉터리를생성할것을권장한다. 2. 새로운웹애플리케이션 Deployment Descriptor파일을작성한다. 이파일은 jeus-web-dd.xml로명명되며, WEB-INF 디렉터리에 web.xml과같이위치시킨다. 3. web.xml에서발견할수있는특정레퍼런스 (EJB 레퍼런스또는보안역할 ) 를실제시스템자원에매핑한다. 예를들어, 이것은 Symbolic EJB 레퍼런스 (web.xml에서발견할수있는 ) 를실제의 EJB JNDI 이름에프로그래머가정의한보안역할을실제시스템의사용자로매핑하는것을포함한다. 이러한모든매핑정보는 jeus-web-dd.xml 파일에입력된다. 4. 다른웹컨테이너특정설정을새로운 Context에맞춰설정한다. 이런설정의예에는사용자로그작동방식등이있다 ( jeus-web-dd.xml 에도설정됨 ) Context 등록 을참조하여웹애플리케이션을등록한다. 6. 선택적으로처음 JSP를호출할때, 보다빠르게실행하기위해서미리컴파일한 JSP 파일을사용할수도있다. 7. 웹애플리케이션이디플로이할때 JEUSMain.xml의 <application> 태그로등록되었다면웹컨테이너를재시작한다. 이모든작업들은편집기를이용하여할수도있지만 WebAdmin을이용할것을권장한다. 제 6 장 Web Context( 웹애플리케이션 ) 131

150 Context 디렉터리생성 우선디플로이할웹애플리케이션을위해 jeus-web-dd.xml의 <context-path> 에설정할다음과같은작업디렉터리를생성한다. 여기서는 <context-path> 가 /MyContext 라고가정한다. JEUS_HOME\webhome\app_home\MyContext Context 디렉터리는임의의위치에생성하여도무방하다. 그임의의위치에서관련파일작업을한후에 exploded 또는 archive 형태로 JEUSMain.xml의 <application> 등록, archive 형태로 autodeploy에위치시켜서재기동하거나직접 jeusadmin 콘솔툴에서디플로이가가능하다. webhome\app_home을 Context 디렉터리의루트디렉터리로권장하는이유는 jeusadmin 콘솔툴이나웹관리자 (WebAdmin) 의사용에있어서편리함을제공하기때문이다. 예를들어 jeusadmin 콘솔툴에서디플로이이후인자로 Context 이름만입력하여도 app_home의웹애플리케이션을찾아서디플로이해주며, WebAdmin에서는 app_home의웹애플리케이션의목록을자동으로출력한다. Context 디렉터리를생성한후에는웹애플리케이션디렉터리구조 [ 그림 6.3] 을따라서관련파일을생성하여위치시킨다 Deployment Descriptor 파일설정 Context 디렉터리생성이완료되면그 context를위해 JEUS 전용의 Deployment Descriptor( 이하 DD) 를생성한다. Well-formed DD를작성할때에는 JEUS_HOME\lib\schemas\jeus\jeus-web-dd.xsd을준수하여작성한다. 생성할 DD파일의위치는다음과같다. 여기에는 web.xml이같이위치한다. JEUS_HOME\webhome\app_home\MyContext\WEB-INF Web DD파일이생성되면내용을작성한다. 다음에서이파일에포함될설정요소들에대해서설명한다. 좀더자세한정보는 JEUS_HOME\docs\reference\schema\index.html에서 jeus-web-dd.xml 레퍼런스를참조한다. 다음은 JEUS Web Context 설정파일의예로몇몇항목들은생략되어있다. [ 예 6.1] Web Context 설정파일 : <<jeus-web-dd.xml>> <jeus-web-dd xmlns=" version="6.0"> <context-path>/examples</context-path> <enable-jsp>true</enable-jsp> <auto-reload> <enable-reload>true</enable-reload> <check-on-demand>true</check-on-demand> </auto-reload> <max-instance-pool-size>20</max-instance-pool-size> <added-classpath> 132 JEUS Web Container 안내서

151 <class-path>c:\mylib\lib.jar</class-path> </added-classpath> <allow-indexing> <directory>/images/</directory> </allow-indexing> <deny-download> <file>/data/secret.dat</file> <extension>dat</extension> <directory>/data/</directory> </deny-download> <aliasing> <alias> <alias-name>/images/</alias-name> <real-path>c:\web\images\</real-path> </alias> </aliasing> <file-caching> <max-idle-time>1800</max-idle-time> <max-cache-memory>10</max-cache-memory> <directory>/images/</directory> </file-caching> <jsp-engine> </jsp-engine> <session-config> </session-config> <fast-deploy>true</fast-deploy> <library-ref> <library-name>mylibrary</library-name> <specification-version>2.0</specification-version> </library-ref> <properties> <property> <key>jeus.servlet.jsp.print.null.as.emptystring</key> <value>true</value> </property> </properties> </jeus-web-dd> 제 6 장 Web Context( 웹애플리케이션 ) 133

152 다음은설정태그에대한설명이다. 태그 <context-path> <user-log> <auto-reload> 설명 context를접근하기위해사용되는기본url이다. 이것은반드시 / 로시작해야하고, 하나의가상호스트나 Context Group 내에서유일한것이어야한다. 예를들면, URL의 context 경로는 /examples 가된다. context group의 user log 설정과같다 Logging 설정 을참고한다. 디스크의 Servlet 클래스가변경되었을때자동적으로로딩이되는지에대한설정이다. 이는 Container의클래스리로딩을모니터링하는 thread 에설정된시간주기에따라정기적으로확인된다. 이하위태그에는클래스리로딩이새로운요청이들어왔을때만발생 하도록하는것도있다. <enable-jsp> false 로설정했을때, JSP 기능을완전히사용하지않는다. 기본은 JSP 를지원한다. <max-instance-pool-size> <added-classpath> SingleThreadedModel을 implement한 Servlet은한번에하나의 thread 에의해서만수행된다. 이러한 Servlet을여러개동시에수행하려면 SingleThreadedModel의 Pool이생성되어야한다. 이설정은재사용가능한 Pool의최대크기를설정한다 (Pool 크기이상생성은가능 ). 참고로 SingleThreadModel은 deprecated된스펙이므로사용을권장하지않는다. Servlet들이컴파일되고실행될때접근가능하게해야할 Java 클래스디렉터리또는 JAR 파일들의리스트들이다. 기본적으로 classes\ 디렉터리의클래스파일들, WEB-INF\ 디렉터 리의 lib\ 디렉터리의 JAR 파일들은접근가능한위치들이다. <allow-indexing> 클라이언트가요청했을때, 실제디렉터리목록이출력되는 URL 경로 의목록이다. 디렉터리의목록이출력되는경우는클라이언트에서요청 한파일이디렉터리에없을때이다. 대신에디렉터리목록의파일을하나선택하면, 그파일의내용이출력 된다. <deny-download> 어떤경우에라도직접적으로다운로드받거나접근할수없는자원들을 규정하기위한필터이다. 이필터들은파일이름의확장자로, 파일이름 과함께경로로지정할수있다. 필터의파일이름과디렉터리들은 context document base 디렉터리의 상대적인경로로주어진다. <aliasing> Custom URL 경로에대한디렉터리매핑을의미한다. 134 JEUS Web Container 안내서

153 태그 설명 다른위치의디렉터리를 URL 요청경로에매핑을시킬필요가있는경 우에 aliasing 기능을사용한다. <file-caching> Container 의응답속도향상을위해런타임메모리에어떤 Static Con tent(html, GIF, JPEG 등 ) 가 Caching 이되어야할지결정한다. 이항목의하위설정들은 Cache 메모리의최대크기 ( 단위 : Megabytes), 요청되지않을때 Cache 내에머무를수있는 Static Content 의최대크 기, Caching 되어야할콘텐츠가있는경로가있다. <jsp-engine> 현재컨텍스트의 JSP 페이지에대한설정이다. 이 element 는 WEB Main.xml 의 JSP Engine 설정과동일하다. 만약에 jeus-web-dd.xml 파일에 JSP Engine 설정이되어있다면, 여기에설정된내용이 WEBMain.xml에설정된해당컨텍스트의 JSP Engine 설정보다우선한다. 이 element에대한설정정보는 JSP 엔진설정 을참고한다. <session-config> Context 레벨의 Session 을설정한다. 현 Context 에적용되는 Session 과 관련하여여러가지설정을할수있다. Context 레벨에서정의된 Session 설정은 Web Container 레벨, Context Group 레벨에서정의된설정을반복한다. 다만 Context 레벨에서설정한설정은웹컨테이너, Context Group에서설정한것보다높은우선순위를가지고적용된다. Session 설정의자세한부분은 Session 을참고한다. <webinf-first> <attach-stacktrace-on-error> 클래스로딩우선순위에관한옵션으로 true로설정되면이애플리케이션에한해서는다른설정과관계없이 WEB-INF 하위의클래스를우선적으로로딩하게된다. 서버에문제가발생하였을때오류의상세내역을브라우저로보여줄것인지에대한설정이다. 이메시지는개발하는경우에는유용하지만운영하는경우에는제거하 는것이좋다. ContextGroup 에서도설정이가능하지만전체적으로설 정하지않고특정 Context 만설정할때는여기에서설정한다. <encoding> request, response 에대한인코딩설정이다. 이설정은 ContextGroup 의 설정과동일하며동시에설정될경우여기의설정이우선적용된다. 자 세한내용은 3.3. Context Group 설정 을참조한다. - Request encoding : HTTP 요청의질의문, 쿠키및 postdata Block을위한인코딩 - Response encoding : 웹컨테이너로부터받은전체응답 HTTP 메시지에적용되는인코딩 제 6 장 Web Context( 웹애플리케이션 ) 135

154 Shared Library 에대한레퍼런스추가 Shared Library는애플리케이션별로필요한라이브러리를 WEB-INF\lib가아닌, JEUS_HOME\lib\shared 아래에추가한후에여러애플리케이션에서공유하여사용할수있도록해준다. JEUS 재기동없이도 li braries.xml 파일수정후모듈을다시디플로이하면변경된라이브러리가반영된다. Shared Library를추가하기위해서는다음과같이 JEUS_HOME\lib\shared\libraries.xml 파일에서 JSF, JSTL 라이브러리는변경하지않고 <library> 태그를추가하고공유할 jar 파일들을지정한다. 버전은스펙버전과구현체버전을각각지정할수있다. 다음은스펙버전에대한예이고, 구현체버전에대한설명은 "JSF1.2, JSTL1.2 라이브러리설정 " 을참고한다. [ 예 6.2] Shared Library 레퍼런스추가 : <<libraries.xml>> <libraries xmlns=" <!-- DO NOT MODIFY JSF1.2 and JSTL1.2 libraries!!! --> <library> <library-name>jsf</library-name> <specification-version>1.2</specification-version> <implementation-version>1.2_06</implementation-version> <files dir="."> <include name="jsf-injection-provider.jar"/> </files> <files dir="jsf_ri_1.2_06"/> </library> <library> <library-name>jstl</library-name> <specification-version>1.2</specification-version> <implementation-version>1.2</implementation-version> <files dir="jstl_1.2"/> </library> <!-- Add user libraries from here --> <library> <library-name>mylibrary</library-name> <specification-version>2.0</specification-version> <implementation-version>2.1</implementation-version> <files dir="."> <include name="commons-logging.jar"/> <include name="commons-util.jar"/> </files> <files dir="mylib-2.1"/> </library> </libraries> 136 JEUS Web Container 안내서

155 Shared Library를참조하기위해서는 jeus-web-dd.xml에다음과같이 <library-ref> 를설정하면된다. 버전이명시되지않은경우는 libraries.xml에등록된동일한이름의라이브러리중에서최상위버전을참조한다. <library-ref> <library-name>mylibrary</library-name> <specification-version>2.0</specification-version> </library-ref> JSF1.2, JSTL1.2 라이브러리설정 [ 예 6.2] 에설명한 libraries.xml 파일에는 JSF1.2와 JSTL1.2가 Shared Library로이미추가되어있음을확인할수있다. Java EE 5 스펙은 JSF1.2와 JSTL1.2를포함하고있기때문에 WEB-INF\lib 아래에 JSF, JSTL 라이브러리없이도정상적으로디플로이가되어야한다. JEUS_HOME\lib\system 아래에 JSF와 JSTL 구현체를두면 Java EE 5 스펙을만족할수있지만이경우에는하나의 JSF, JSTL 구현체만사용할수있는문제가발생한다. JSF 구현체는 1.2 뿐만아니라 1.1 버전도있고 SUN RI가아닌 Apache의 myfaces도있기때문에 JEUS에서는여러가지버전의구현체를사용할수있도록 Shared Library 형태로 JSF, JSTL을제공한다. 구현체의위치, 종류에따라사용되는구현체의경우는다음과같이나누어진다. WEB-INF\lib 아래에 JSF나 JSTL 구현체가있을경우이들구현체가우선사용된다. WEB-INF\lib 아래에 JSF나 JSTL 구현체가없을경우 lib\shared 아래의 JSF RI 1.2, JSTL 1.2가사용된다. JSF와 JSTL은 Java EE 5에포함되어있기때문에예외적인경우로 jeus-web-dd.xml에 <library-ref> 설정없이도사용할수있다. WEB-INF\lib 아래에 myfaces1.1 구현체가있을경우 myfaces가우선사용된다. WEB-INF\lib 아래에 JSF 구현체가없다면 lib\shared 아래의 JSF RI 1.2가사용된다. JSF 구현체간에는호환성문제가있기때문에개발하는경우와다른 JSF 구현체가사용된다면문제가발생할수있다. 특정버전의 JSF나 JSTL을사용하기위해서는 libraries.xml에 library를등록하고 jeus-web-dd.xml에서 <library-ref> 로참조하도록할수도있다. 가장간단한방법은기존 J2EE1.4의웹모듈처럼 WEB-INF\lib 아래에 JSF, JSTL 구현체를위치시키면된다. JSF1.2의경우는 같은 annotation으로 WAS가제공하는리소스에접근할수있고 WAS는 annotation으로명시된리소스들을 injection할수있어야한다. JEUS에서는 JSF1.2 RI에 JEUS Injection을지원하기위해서 Shared Library로 'jsf-injection-provider.jar' 를제공하고있다. 제 6 장 Web Context( 웹애플리케이션 ) 137

156 하위호환성을위한 Context 레벨의추가옵션설정 JEUS 5에서는사용자의편의성과 Servlet 2.3 이전에개발된애플리케이션을위해서표준이아닌기능도제공하고 JSP Parsing에문법체크도최신스펙에비해서엄격하지않게적용하였다. Servlet 2.3 이전에는 Servlet과 JSP를직접사용해서웹애플리케이션을개발했지만현재는웹프레임워크를점차사용하는추세이고 Java EE 5에서는표준웹프레임워크로 JSF1.2와 JSTL1.2가추가되었다. 웹프레임워크는 Servlet, JSP 스펙에대한참조구현체인 Tomcat을사용해서주로개발하고테스트하기때문에스펙과다른비표준기능지원시다양한호환성문제가발생할수있다. 그래서 JEUS 6에서는 JEUS 5에대한하위호환성을위해서기존의 JSP Parser도지원하지만디폴트는 Jasper 기반의 JSP Parser로변경하였다. JEUS 5에서문제가없었던웹모듈도 JEUS 6에디플로이하면여러가지에러가발생할수있다. JEUS 6에서 Servlet 2.5, JSP 2.1, JSF 1.2, JSTL 1.2의최신스펙을사용하기위해서는 JSP 컴파일할때발생하는에러메시지와 JSP 라인을확인후수정해서업그레이드해야한다. 디플로이할때다음과같은형태로에러가발생한다면 '/jsp/customtag12/date.jsp' 의 2번째라인의 62번째컬럼에서어떤문제가있는지확인해야한다. [ :02:29][2][b029] [mycontainer-12] [WEB-5697] [examples#examples] par sing 35 jsp file(s) [ :02:33][1][b029] [mycontainer-12] fail to parse jsp file : /jsp/cust omtag12/date.jsp << Exception >> jeus.servlet.jsp2.jsp2engineexception: file:c:/jeus6/webhome/johan_mycontainer/examples/examples_war /jsp/customtag12/d ate.jsp(2,62) Failed to load or instantiate TagExtraInfo class: customtag12.showdatetei at jeus.servlet.jsp2.compiler.defaulterrorhandler.jsperror(defaulterrorhandler.java:59) at jeus.servlet.jsp2.compiler.errordispatcher.dispatch(errordispatcher.java:46 7) at jeus.servlet.jsp2.compiler.errordispatcher.jsperror(errordispatcher.java:29 8) 만약최신스펙이필요하지않고기존에개발된모듈을그대로 JEUS6에서사용하기위해서는다음과같이 jeus-web-dd.xml에 JEUS5 호환의 JSP Parser가이 Context에만적용되도록설정할수있다. <properties> <property> <key>jeus.servlet.jsp.modern</key> <value>false</value> </property> </properties> jeus-web-dd.xml에설정한옵션은이 Context에만적용되고 WEBMain.xml에서는 ContextGroup이나 Vir tualhost 단위로도옵션을설정할수있다. Container 레벨에서옵션을적용하기위해서는다음과같은 VM 옵션을설정할수있다. 138 JEUS Web Container 안내서

157 -Djeus.servlet.jsp.modern=false VM 옵션은 ContextGroup, VirtualHost, Context에서 Override되기때문에 jeus-web-dd.xml에설정한옵션이최종적으로적용된다. jeus-web-dd.xml에옵션설정이없다면상위의디폴트설정이적용된다. 나머지옵션들은 JEUS Reference Book 의 1.7. 서블릿 / 웹시스템프로퍼티 에서확인할수있다. 추가옵션은하위호환성이필요한경우만적용하고신규개발은추가적인옵션없이표준에따라개발할것을권장한다 보안 Role 매핑 본절에서는 web.xml에정의된보안 Role을실제시스템사용자와사용자그룹에어떻게지정하는지살펴보겠다. 이매핑은 jeus-web-dd.xml 에기술된다개발자가다음의내용을 Deployment Descriptor(web.xml) 에정의하였다고가정하자. [ 예 6.3] 보안 Role 매핑 : <<web.xml>> <web-app> <security-role> <role-name>manager</role-name> </security-role> <security-role> <role-name>developer</role-name> </security-role> <servlet> </servlet> <security-constraint> <web-resource-collection> <web-resource-name> MyResource </web-resource-name> <url-pattern>/jsp/*</url-pattern> <http-method>get</http-method> <http-method>post</http-method> </web-resource-collection> <auth-constraint> <role-name>manager</role-name> </auth-constraint> </security-constraint> </web-app> 위의예제에서는굵은글씨로두개의보안 Role이선언되어있다. 세번째굵은글자라인은 manager role 이 <security-constraint> 태그에어떻게사용되어지는지를보여주고있다. 웹애플리케이션이실제의시스템에디플로이될때, manager와 developer Role을시스템의특정한사용자로바인딩해야한다. 이매핑은 <context><role-mapping> 에정의되어있다. <role-mapping> 태그는 제 6 장 Web Context( 웹애플리케이션 ) 139

158 0 개이상의 <role-permission> 태그들을가지고있다. 이태그를이용하여 <principal-to-role> 매핑을정의 한다. 다음의하위태그들과함께바인딩된다. 태그 <role>(1 개, 필수 ) <principal>(0 개이상 ) 설명 web.xml에정의된 role name이며, 위의예에서는 role name이 manager 이다. role name과연계되어야할 JEUS가관리하는사용자의이름이다. 더자세한사항은 JEUS Security 안내서 의 3.3. 웹모듈보안설정 을참고한다. 2개의 Role manager 와 developer 가 Peter 와 Linda 로각각매핑되어있다. [ 예 6.4] 보안 Role 매핑 : <<jeus-web-dd.xml>> <jeus-web-dd xmlns=" version="6.0"> <role-mapping> <role-permission> <principal>peter</principal> <role>manager</role> </role-permission> <role-permission> <principal>linda</principal> <role>developer</role> </role-permission> </role-mapping> </jeus-web-dd> Symbolic 레퍼런스매핑 Role이실제사용자에매핑되듯이 EJB 레퍼런스, 자원레퍼런스, 관리되는객체의레퍼런스를실제시스템자원에매핑할필요가있다. 다음은 Symbolc 레퍼런스매핑의예이다. [ 예 6.5] Symbolc 레퍼런스매핑 : <<web.xml>> <web-app> <ejb-ref> <ejb-ref-name>ejb/account</ejb-ref-name> <ejb-ref-type>entity</ejb-ref-type> <home>com.mycompany.accounthome</home> <remote>com.mycompany.account</remote> </ejb-ref> <resource-ref> 140 JEUS Web Container 안내서

159 <res-ref-name>jdbc/employeeappdb</res-ref-name> <res-type>javax.sql.datasource</res-type> <res-auth>container</res-auth> <res-sharing-scope>shareable</res-sharing-scope> </resource-ref> <resource-env-ref> <resource-env-ref-name> jms/stockqueue </resource-env-ref-name> <resource-env-ref-type> javax.jms.queue </resource-env-ref-type> </resource-env-ref> </web-app> 이웹애플리케이션을등록하기위하여, web.xml에있는 <ejb-ref>, <resource-ref>, <resource-env-ref> 아래의모든 Symbolc 레퍼런스이름들이실제의도하는자원의 JNDI 이름과매핑되어야한다. 이매핑은 jeus-web-dd 에서해당 <ejb-ref>, <res-ref>, <res-env-ref> 를추가하면완성된다. 이태그들은다음과같은하위태그들을가지는 <jndi-info> 태그가있다. <jndi-info> 태그 <ref-name> <export-name> 설명 reference name(ref name) 은 web.xml 과 Servlet 코드에정의된것과같은것이다. JNDI export name 은레퍼런스이름이뜻하는실제의자원 export-name 이다. 다음은 JNDI 이름이위의 3개의레퍼런스와매핑된 jeus-web-dd.xml의예이다. [ 예 6.6] Symbolc 레퍼런스매핑 : <<jeus-web-dd.xml>> <jeus-web-dd xmlns=" version="6.0"> <ejb-ref> <jndi-info> <ref-name>ejb/account</ref-name> <export-name>accountejb</export-name> </jndi-info> </ejb-ref> <res-ref> <jndi-info> <ref-name>jdbc/employeeappdb</ref-name> <export-name>employeedb</export-name> </jndi-info> </res-ref> 제 6 장 Web Context( 웹애플리케이션 ) 141

160 <res-env-ref> <jndi-info> <ref-name>jms/stockqueue</ref-name> <export-name>stockqueue</export-name> </jndi-info> </res-env-ref> </jeus-web-dd> Context 등록 웹애플리케이션을디플로이하는방법은다음과같은 3가지방법이있다. jeusadmin 콘솔툴이용웹애플리케이션을디플로이하는자세한내용은 "JEUS Server 안내서 " 를참고한다. WebAdmin 이용웹애플리케이션을디플로이하는자세한내용은 "JEUS WebAdmin 안내서 " 를참고한다. JEUSMain.xml의 <application> 등록본절에서예제를사용해서설명한다. Context를등록한후컨테이너를재기동해야한다. 다음은 JEUSMain.xml의 <application> 등록하는예제이다. JEUS_HOME은 c:\jeus6로가정하고 Examples 와 MyApp 라는 2개의 Context를등록한다. 두 Context 의요청 URL은 /examples 와 /myapp 라고지정되어있다. 예를들어, dex.html를요청하면 Examples context의 index.html 을반환한다 ( 웹컨테이너의 context group의 HTTP 리스너의포트가 80으로설정되어있다고가정한다 ). [ 예 6.7] Context 등록 : <<JEUSMain.xml>> <jeus-system xmlns=" <node> <name>tmax1</name>... </node> <application> <name>examples</name> <path> c:\jeus6\webhome\app_home\examples </path> <deployment-target> <target> <engine-container-name> tmax1_container1 </engine-container-name> 142 JEUS Web Container 안내서

161 <web-context-group> <name>mygroup</name> <virtual-host-name> </virtual-host-name> </web-context-group> </target> </deployment-target> <deployment-type>component</deployment-type> <web-component/> </application> <application> <name>myapp</name> <path> c:\jeus6\webhome\app_home\myapp </path> <deployment-target> <target> <engine-container-name> tmax1_container1 </engine-container-name> <web-context-group> <name>mygroup</name> <virtual-host-name> </virtual-host-name> </web-context-group> </target> </deployment-target> <deployment-type>component</deployment-type> <web-component/> </application> </jeus-system> 배치컴파일러를사용한 JSP 프리컴파일 등록의마지막과정으로웹애플리케이션의 JSP 페이지들을프리컴파일할수있다. 이것은 JEUS_HOME\bin\ 의 JSP 배치컴파일러 appcompiler, jspc 툴로한다. appcompiler는 JEUS와관계없이오프라인상태에서 JSP 프리컴파일이가능하고, jspc는 JEUS가기동되고디플로이가완료된모듈에대해서프리컴파일을수행할수있다. 이툴들에대해서는 JEUS Reference Book 의 4.4. appcompiler 와 JEUS Reference Book 의 4.7. jspc 의설명을참고한다. JSP 배치컴파일러를이용하면, JSP가처음요청되었을때의성능을향상시킬수있다. 배치컴파일러는새로운웹애플리케이션이등록되었을때각 JSP를수동으로요청해야하는번거로움을없애주므로시스템관리자에게는편리성을제공한다. 제 6 장 Web Context( 웹애플리케이션 ) 143

162 등록확인 위의과정을거친후등록이정확이되었는지수동으로확인하기위해서 jeusadmin 툴을사용하여웹컨테이너를재시작한다. 다음의예에서 JEUS 노드이름은 johan 이라고가정한다. 1. 웹컨테이너를재시작하기위해서는해당 container 를정지하고다시시작해야한다. 해당 Container 이름이 "johan_container1" 이라고가정한다. 사용자이름과암호를입력한다. johan> downcon johan_container1 2. 웹컨테이너가시작하고운영환경에새롭게등록한 context 가반영되는것을확인할수있다. johan> startcon johan_container1 3. jeusadmin을시작한다. C:\jeusadmin johan_container1 사용자이름과암호를입력한다. 4. info 명령을수행한다. johan> info Context Group과 Context에대한정보가출력된다. 추가한 Context ( TestContext ) 가목록에조회되면등록이성공적으로된것이다 Web Context 요청 다음과같이예를들어보자. WEBMain.xml의 Context Group에 /Test 경로를가진 Context를등록하였다 ( 여기서는명시적인가상호스트가사용되지않는것으로가정한다 ). 이 Context는 web.xml에 HeaderTest 라는 Servlet을가진다. 이 Context가소속된 Context Group은 HTTP 리스너가설정되어있다. 이리스너는 8088포트를로컬머신에서사용하고있다. 위의내용을가정하고 Context의 HeaderTest Servlet을다음과같은 URL을웹브라우저에서실행한다. 다음과같은페이지가나타난다. 144 JEUS Web Container 안내서

163 [ 그림 6.4] 웹브라우저에서 Servlet 요청하기 그러므로, Servlet( 또는 JSP) 를요청할때에는다음과같은 URL 포맷을이용한다. request path>/<servlet/jsp name> Static Content에대해서는다음과같은 URL 포맷을사용한다. request path>/<directory path>/<file name> 예를들어, /Test 요청경로를가진 Context의 static 디렉터리아래에있는 hello.html 을호출하기위해서는다음과같은 URL을사용한다. URL 경로의파일이름을지정하지않으면기본페이지인 index.html 이사용된다. 요청된파일또는자원이발견되지않을경우에는다음과같은기본오류페이지가반환된다. [ 그림 6.5] JEUS 웹컨테이너에의해생성되는기본오류페이지 참고 제 7 장가상호스트 에는 Context 요청에대한자세한내용과가상호스트에대해서설명한다. 제 6 장 Web Context( 웹애플리케이션 ) 145