jeus web container 안내서 - tmaxsoft · 2019-04-09 · [그림 1.3] jeus web 모듈에 관련된...

JEUS

Web Container 안내서

JEUS v6.0 Fix#8

Copyright © 2011 TmaxSoft Co., Ltd. All Rights Reserved.

Copyright Notice

Copyright © 2011 TmaxSoft Co., Ltd. All Rights Reserved.

대한민국 경기도 성남시 분당구 서현동 272-6 우) 463-824

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 안내서

발행일: 2011-11-04

소프트웨어 버전: JEUS v6.0 Fix #8

안내서 버전: v2.1.3

내용 목차

안내서에 대하여 ......................................................................................................................... xiii

제1장 JEUS 웹 ........................................................................................................................... 1

1.1. 개요 ............................................................................................................................ 1

1.2. JEUS 웹 구조와 주요 기능 ............................................................................................ 1

1.2.1. 웹 컨테이너와 JEUS 시스템 ............................................................................... 1

1.2.2. 웹 컨테이너의 기본 컴포넌트 .............................................................................. 4

1.3. JEUS Web 디렉터리 구조 ............................................................................................. 5

1.4. JEUS 웹 툴 .................................................................................................................. 6

1.5. JEUS Web 환경설정 ..................................................................................................... 7

1.5.1. 환경변수 ........................................................................................................... 7

1.5.2. XML 설정 파일 .................................................................................................. 8

제2장 웹 컨테이너 ....................................................................................................................... 9

2.1. 개요 ............................................................................................................................ 9

2.2. 웹 컨테이너 주요 기능과 구조 ....................................................................................... 9

2.2.1. 주요 기능 ........................................................................................................ 10

2.2.2. 디렉터리 구조 .................................................................................................. 11

2.3. 웹 컨테이너 설정 ........................................................................................................ 12

2.3.1. 개요 ................................................................................................................ 12

2.3.2. 기본 설정 ........................................................................................................ 12

2.3.3. 자동 모니터링 .................................................................................................. 13

2.3.4. stdout과 stderr Redirection ............................................................................... 14

2.3.5. Context Group ................................................................................................. 15

2.3.6. Database Connection Pool ............................................................................... 16

2.3.7. Session ........................................................................................................... 16

2.3.8. Logging ........................................................................................................... 20

2.3.9. Shutdown Timeout ........................................................................................... 20

2.4. Logging 설정 .............................................................................................................. 21

2.4.1. 공통 설정 항목 ................................................................................................. 21

2.4.2. Access log 관련 설정 항목 ................................................................................ 26

2.4.3. User log 관련 설정 항목 ................................................................................... 30

2.5. 웹 컨테이너 제어와 모니터링 ...................................................................................... 30

2.5.1. 웹 컨테이너 제어 ............................................................................................. 30

2.5.2. 웹 컨테이너 모니터링 ....................................................................................... 31

제3장 Context Group ............................................................................................................... 33

3.1. 개요 ........................................................................................................................... 33

3.2. Context Group 주요 기능과 구조 .................................................................................. 33

3.2.1. 주요 기능 ........................................................................................................ 35

3.2.2. 디렉터리 구조 .................................................................................................. 36

3.3. Context Group 설정 .................................................................................................... 37

JEUS iii

3.3.1. 기본 설정 ........................................................................................................ 39

3.3.2. 인코딩 설정 ..................................................................................................... 39

3.3.3. JSP 엔진 설정 ................................................................................................. 42

3.3.4. Logging 설정 ................................................................................................... 44

3.3.5. Session 설정 ................................................................................................... 45

3.3.6. Response Header 설정 .................................................................................... 46

3.4. Context Group 모니터링 ............................................................................................. 47

3.5. Context Group 튜닝 .................................................................................................... 47

제4장 웹 서버 연결과 클러스터링 ............................................................................................... 49

4.1. 개요 ........................................................................................................................... 49

4.2. 웹 서버 연결 ............................................................................................................... 50

4.2.1. 리스너 ............................................................................................................ 50

4.2.2. Worker Thread와 Worker Thread Pool ............................................................... 52

4.2.3. Thread Pool의 Active-Management와 상태 통보 ................................................ 52

4.2.4. 여러 개의 웹 컨테이너와 웹 서버 클러스터링 ..................................................... 53

4.3. 리스너 설정 ................................................................................................................ 54

4.3.1. HTTP, TCP, HTTPS 리스너 설정 ....................................................................... 55

4.3.2. WebtoB 리스너 설정 ........................................................................................ 59

4.3.3. AJP13 리스너 설정 .......................................................................................... 62

4.3.4. Tmax 리스너 설정 ............................................................................................ 64

4.3.5. 자동 Thread Pool 관리 설정(Thread 상태 통보) .................................................. 66

4.4. 리스너 연동과 클러스터링을 위한 웹 서버 설정 ............................................................ 68

4.4.1. Apache 웹 서버 설정과 클러스터링 ................................................................... 69

4.4.2. IIS 웹 서버 설정과 클러스터링 .......................................................................... 76

4.4.3. SunOne(Iplanet) 웹 서버 설정과 클러스터링 ...................................................... 78

4.4.4. WebtoB 웹 서버 설정과 클러스터링 .................................................................. 80

4.5. TCP 리스너 사용 ........................................................................................................ 85

4.5.1. 맞춤 통신 프로토콜 정의 .................................................................................. 87

4.5.2. Dispatcher 설정 클래스 구현 ............................................................................ 87

4.5.3. TCP Handler 구현 ............................................................................................ 89

4.5.4. 맞춤 프로토콜 코드를 위한 TCP 리스너 설정 ..................................................... 92

4.5.5. TCP 클라이언트 구현 ....................................................................................... 95

4.5.6. TCP 클라이언트 컴파일과 실행 ........................................................................ 98

4.6. 보안(SSL) 리스너 사용 ................................................................................................ 99

4.6.1. 개요 ................................................................................................................ 99

4.6.2. 디렉터리 구조 .................................................................................................. 99

4.6.3. 보안 리스너 설정 ........................................................................................... 102

4.6.4. SSL Keystore 설정 ......................................................................................... 106

4.6.5. SSL Truststore 설정 ....................................................................................... 107

4.6.6. 보안 리스너 속성 설정 .................................................................................... 108

4.6.7. 보안 리스너 시작하기 ..................................................................................... 109

4.6.8. 보안 리스너에 연결하기 ................................................................................. 109

iv JEUS Web Container 안내서

4.7. 리스너 튜닝 .............................................................................................................. 111

제5장 Session Tracking ......................................................................................................... 113

5.1. 개요 ......................................................................................................................... 113

5.2. Session Tracking의 주요 기능 .................................................................................... 113

5.2.1. 기본 기능 ...................................................................................................... 114

5.2.2. 클러스터 환경에서 Session Tracking ............................................................... 116

5.2.3. Session Routing(Sticky Session) .................................................................... 116

5.2.4. Session Server .............................................................................................. 119

5.2.5. 혼합 모드 ...................................................................................................... 121

5.2.6. 분산 Session Server ...................................................................................... 122

5.2.7. URL Rewriting과 Cookie ................................................................................ 122

5.2.8. Shared Session 데이터 .................................................................................. 123

5.3. Session Tracking 설정 ............................................................................................... 123

5.3.1. 중앙 Session Server 설정 ............................................................................... 124

5.3.2. 분산 Session Server 설정 ............................................................................... 126

5.4. Session Tracking 튜닝 ............................................................................................... 126

제6장 Web Context(웹 애플리케이션) ...................................................................................... 127

6.1. 개요 ......................................................................................................................... 127

6.2. Web Context의 기본 개념과 구조 ............................................................................... 127

6.2.1. 기본 구조 ...................................................................................................... 128

6.2.2. WAR 파일 구조 .............................................................................................. 128

6.2.3. 디렉터리 구조 ................................................................................................ 130

6.3. Web Context 등록 .................................................................................................... 131

6.3.1. Context 디렉터리 생성 ................................................................................... 132

6.3.2. Deployment Descriptor 파일 설정 .................................................................... 132

6.3.3. Shared Library에 대한 레퍼런스 추가 .............................................................. 136

6.3.4. 하위 호환성을 위한 Context 레벨의 추가 옵션 설정 .......................................... 138

6.3.5. 보안 Role 매핑 ............................................................................................... 139

6.3.6. Symbolic 레퍼런스 매핑 ................................................................................. 140

6.3.7. Context 등록 .................................................................................................. 142

6.3.8. 배치 컴파일러를 사용한 JSP 프리컴파일 ......................................................... 143

6.3.9. 등록 확인 ...................................................................................................... 144

6.4. Web Context 요청 ..................................................................................................... 144

6.5. Web Context 모니터링 .............................................................................................. 146

6.6. Web Context 튜닝 ..................................................................................................... 146

제7장 가상 호스트 ................................................................................................................... 147

7.1. 개요 ......................................................................................................................... 147

7.2. 가상 호스트의 기본 개념 ........................................................................................... 147

7.2.1. 기본 개념 ...................................................................................................... 148

7.2.2. 기본 가상 호스트 ........................................................................................... 150

7.2.3. ServletContext 객체와 가상 호스트에 대한 주의 사항 ....................................... 150

7.3. 가상 호스트 설정 ...................................................................................................... 151

JEUS v

7.3.1. 도메인 이름 등록 ........................................................................................... 151

7.3.2. WEBMain.xml에 가상 호스트 설정 .................................................................. 151

7.4. 가상 호스트를 통한 Context 요청 ............................................................................... 153

7.4.1. URL 매칭에 관한 기본 규칙 ............................................................................ 153

7.4.2. URL 매칭의 예 ............................................................................................... 153

제8장 JEUS WebCache .......................................................................................................... 159

8.1. 개요 ......................................................................................................................... 159

8.2. JSP Caching ............................................................................................................ 160

8.2.1. 기본 내용 ...................................................................................................... 160

8.2.2. <cache> 태그 ................................................................................................ 161

8.2.3. jeus:cache 사용 예 ......................................................................................... 163

8.2.4. flush 기능 사용 .............................................................................................. 164

8.2.5. refresh 기능 사용 ........................................................................................... 165

8.3. HTTP Response Caching .......................................................................................... 165

8.3.1. 필터 설정 ...................................................................................................... 165

제9장 Reverse Proxy .............................................................................................................. 169

9.1. 개요 ......................................................................................................................... 169

9.1.1. 적용 예시 ...................................................................................................... 169

9.2. 사용 방법 ................................................................................................................. 170

9.2.1. Proxy 서버 설정 ............................................................................................. 170

9.2.2. Context-path 설정 .......................................................................................... 172

9.2.3. Proxy Filter 설정 ............................................................................................ 172

9.2.4. Deploy .......................................................................................................... 174

9.3. 설정 예 .................................................................................................................... 174

제10장 따라하기 ..................................................................................................................... 177

용어해설 ................................................................................................................................... 179

색인 .......................................................................................................................................... 183

vi JEUS Web Container 안내서

그림 목차

[그림 1.1] 웹 컨테이너와 JEUS 시스템 ......................................................................................... 2

[그림 1.2] 웹 컨테이너의 기본 컴포넌트 ........................................................................................ 4

[그림 1.3] JEUS Web 모듈에 관련된 기본 디렉터리 구조 ............................................................... 5

[그림 2.1] 웹 컨테이너 구조 ........................................................................................................ 9

[그림 2.2] JEUS 웹 컨테이너 관련 디렉터리 ................................................................................ 11

[그림 3.1] 웹 컨테이너에 연관된 Context Group .......................................................................... 34

[그림 3.2] Context Group의 상세 모습과 그 하위 컴포넌트들 ........................................................ 34

[그림 3.3] Context Group 디렉터리 구조 ..................................................................................... 36

[그림 4.1] JEUS 웹 컨테이너 중 웹 서버 연결 부분 컴포넌트 ........................................................ 50

[그림 4.2] 웹 컨테이너의 웹 서버와 클라이언트 리스너 ................................................................ 50

[그림 4.3] 2개의 웹 서버가 2개의 웹 컨테이너에 각각 연결되어 있는 작은 클러스터 ...................... 53

[그림 4.4] 2개의 WebtoB 웹 서버가 2개의 웹 컨테이너와 연결된 경우 .......................................... 80

[그림 4.5] 2개의 WebtoB 리스너가 1개의 WebtoB에 연결된 경우 ................................................. 81

[그림 4.6] 복잡한 WebtoB 웹 서버 구성 ....................................................................................... 85

[그림 4.7] 보안 리스너의 초기 디렉터리 .................................................................................... 100

[그림 4.8] Internet Explorer에서의 인증서 보안 경고창 ............................................................... 110

[그림 4.9] 보안된 SSL 연결 ...................................................................................................... 110

[그림 5.1] JEUS 웹 컨테이너의 구조 중 Session에 관련된 부분들 ............................................... 113

[그림 5.2] 웹 컨테이너가 Session Cookie를 발급하는 과정 ......................................................... 115

[그림 5.3] Session ID Cookie로 웹 컨테이너에 두 번째 요청을 보내는 과정 ................................. 115

[그림 5.4] Session ID Cookie를 이용하여 2개의 웹 컨테이너와 Session을 시작하는 경우 ............. 117

[그림 5.5] Session Routing이 없는 경우 클라이언트 Session 삭제 .............................................. 117

[그림 5.6] Session Cookie에 추가의 웹 컨테이너 ID 부여 ........................................................... 118

[그림 5.7] Session Routing의 작동 ............................................................................................ 119

[그림 5.8] 장애가 발생한 웹 컨테이너의 문제 ............................................................................ 120

[그림 5.9] Session Server가 사용될 경우 클라이언트의 첫 HTTP 요청 처리 ................................ 120

[그림 5.10] Session 데이터의 요청 처리 .................................................................................... 121

[그림 6.1] JEUS 웹 컨테이너에 context/Web application ............................................................ 127

[그림 6.2] WAR 파일 구조 ........................................................................................................ 129

[그림 6.3] Web Context 디렉터리의 구조 ................................................................................... 130

[그림 6.4] 웹 브라우저에서 Servlet 요청하기 ............................................................................. 145

[그림 6.5] JEUS 웹 컨테이너에 의해 생성되는 기본 오류 페이지 ................................................. 145

[그림 7.1] JEUS 웹 컨테이너의 가상 호스트 컴포넌트 ................................................................ 147

[그림 7.2] 가상 호스트의 기본적인 개념 .................................................................................... 148

[그림 7.3] Context Group과 가상 호스트, Context 간의 유효한 관계의 예 .................................... 149

[그림 7.4] 웹 컨테이너에서 DNS 이름으로 같은 경로를 가진 Context 사용 .................................. 150

[그림 8.1] 엔트리 캐싱에 사용되는 자료구조 ............................................................................. 160

JEUS vii

표 목차

[표 1.1] JEUS Web 모듈 환경변수 ................................................................................................ 7

JEUS ix

예 목차

[예 2.1] 웹 컨테이너 기본 설정 : <<JEUSMain.xml>> ................................................................... 12

[예 2.2] 자동 모니터링 설정 : <<WEBMain.xml>> ........................................................................ 14

[예 2.3] stdout과 stderr redirection 설정 : <<WEBMain.xml>> ....................................................... 14

[예 2.4] Context Group 설정 : <<WEBMain.xml>> ....................................................................... 15

[예 2.5] Session 설정 : <<WEBMain.xml>> ................................................................................. 17

[예 2.6] 웹 컨테이너 Logging 설정 : <<WEBMain.xml>> ............................................................... 22

[예 2.7] <access-log>에 필터 등록 : <<WEBMain.xml>> .............................................................. 29

[예 3.1] Context Group 설정 : <<WEBMain.xml>> ....................................................................... 38

[예 3.2] Context Group 기본 설정 : <<WEBMain.xml>> ................................................................ 39

[예 3.3] Context Group 인코딩 설정 : <<WEBMain.xml>> ............................................................ 41

[예 3.4] JSP 엔진 설정 : <<WEBMain.xml>> ............................................................................... 42

[예 3.5] Context Group 레벨에서 Session 설정 : <<WEBMain.xml>> ............................................ 45

[예 3.6] Response Header 설정 : <<WEBMain.xml>> .................................................................. 46

[예 4.1] 리스너 설정 : <<WEBMain.xml>> ................................................................................... 54

[예 4.2] HTTP, TCP, HTTPS 리스너 설정 : <<WEBMain.xml>> ..................................................... 55

[예 4.3] WebtoB 리스너 설정 : <<WEBMain.xml>> ...................................................................... 59

[예 4.4] AJP13 리스너 설정 : <<WEBMain.xml>> ........................................................................ 63

[예 4.5] Tmax 리스너 설정 : <<WEBMain.xml>> .......................................................................... 64

[예 4.6] 자동 Thread Pool 관리 설정 : <<WEBMain.xml>> ............................................................ 66

[예 4.7] Apache 웹 서버 설정 : <<WEBMain.xml>> ...................................................................... 69

[예 4.8] AJP13 프로토콜을 사용 : <<workers.properties>> ........................................................... 70

[예 4.9] <<httpd.conf>> .............................................................................................................. 75

[예 4.10] <<uriworkermap.properties>> ...................................................................................... 77

[예 4.11] <<magnus.conf>> ....................................................................................................... 79

[예 4.12] <<magnus.conf>> ....................................................................................................... 80

[예 4.13] 웹 컨테이너 A : <<WEBMain.xml>> .............................................................................. 82

[예 4.14] 웹 컨테이너 B : <<WEBMain.xml>> .............................................................................. 83

[예 4.15] http.m of WebtoB 웹 서버 A (IP address 111.111.111.111) ............................................. 84

[예 4.16] <<SampleConfig.java>> ............................................................................................... 87

[예 4.17] <<SampleServlet.java>> .............................................................................................. 90

[예 4.18] <<web.xml>> .............................................................................................................. 93

[예 4.19] <<WEBMain.xml>> ..................................................................................................... 93

[예 4.20] <<JEUSMain.xml>> ..................................................................................................... 94

[예 4.21] <<jeus-web-dd.xml>> .................................................................................................. 95

[예 4.22] <<Client.java>> ........................................................................................................... 96

[예 4.23] JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name>\WEBMain.xml . 100

[예 4.24] JEUS_HOME\config\<node-name>\JEUSMain.xml ...................................................... 100

[예 4.25] JEUS_HOME\webhome\app_home\webapps\MyContext\WEB-INF\jeus-web-dd.xml ..... 101

[예 4.26] JEUS_HOME\webhome\app_home\webapps\MyContext\WEB-INF\web.xml ................. 101

[예 4.27] JEUS_HOME\webhome\app_home\webapps\MyContext\hello.html .............................. 101

JEUS xi

[예 4.28] 보안 리스너 설정 : <<WEBMain.xml>> ........................................................................ 102

[예 4.29] <<JEUS_HOME\config\<node-name>\JEUSMain.xml>> .............................................. 109

[예 5.1] Session Tracking 설정 : <<WEBMain.xml>> .................................................................. 124

[예 5.2] 노드 클러스터링을 하지 않은 상태에서 중앙 Session Server 사용 : <<WEBMain.xml>> .... 125

[예 5.3] <<vhost.properties>> ................................................................................................... 125

[예 6.1] Web Context 설정 파일 : <<jeus-web-dd.xml>> ............................................................. 132

[예 6.2] Shared Library 레퍼런스 추가 : <<libraries.xml>> .......................................................... 136

[예 6.3] 보안 Role 매핑 : <<web.xml>> ...................................................................................... 139

[예 6.4] 보안 Role 매핑 : <<jeus-web-dd.xml>> ......................................................................... 140

[예 6.5] Symbolc 레퍼런스 매핑 : <<web.xml>> ......................................................................... 140

[예 6.6] Symbolc 레퍼런스 매핑 : <<jeus-web-dd.xml>> ............................................................. 141

[예 6.7] Context 등록 : <<JEUSMain.xml>> ............................................................................... 142

[예 7.1] 가상 호스트 설정 : <<WEBMain.xml>> ......................................................................... 151

[예 7.2] 가상 호스트의 설정 : <<WEBMain.xml>> ...................................................................... 153

[예 7.3] 가상 호스트의 설정 : <<JEUSMain.xml>> ..................................................................... 154

[예 7.4] vhost1ctx1 : <<jeus-web-dd.xml>> ............................................................................... 157



[예 7.7] vhost2ctx2 :<<jeus-web-dd.xml>> ................................................................................ 157

[예 7.8] default1 : <<jeus-web-dd.xml>> .................................................................................... 158

[예 7.9] default2 :<<jeus-web-dd.xml>> ..................................................................................... 158

[예 7.10] default3 : <<jeus-web-dd.xml>> .................................................................................. 158

[예 8.1] <cache> 태그 설정 : <<jeuscache.tld>> ........................................................................ 161

[예 8.2] <<cache.jsp>> ............................................................................................................ 163

[예 8.3] <<main.jsp>> .............................................................................................................. 164

[예 8.4] 필터 설정 : <<web.xml>> ............................................................................................. 166

[예 9.1] <<proxy-config.dtd>> ................................................................................................... 171

[예 10.1] <<JEUSMain.xml>> ................................................................................................... 177

[예 10.2] <<WEBMain.xml>> .................................................................................................... 178

xii JEUS Web Container 안내서

안내서에 대하여

안내서의 대상

본 안내서는 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 스펙이나 http://www.ora

cle.com/technetwork/java/index.html을 참고한다.

안내서에 대하여 xiii

http://www.oracle.com/technetwork/java/index.html

http://www.oracle.com/technetwork/java/index.html

안내서 구성

본 안내서는 총 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 안내서

안내서 규약

의미표기

프로그램 소스 코드의 파일명<<AaBbCc123>>

Ctrl과 C를 동시에 누름<Ctrl>+C

GUI의 버튼 또는 메뉴 이름[Button]

강조진하게

다른 관련 안내서 또는 안내서 내의 다른 장 및 절 언급" "(따옴표)

화면 UI에서 입력 항목에 대한 설명'입력항목'

메일계정, 웹 사이트하이퍼링크

메뉴의 진행 순서>

하위 디렉터리 또는 파일 있음+----

하위 디렉터리 또는 파일 없음|----

참고 또는 주의사항참고

주의할 사항주의

그림 이름[그림 1.1]

표 이름[표 1.1]

Java 코드, XML 문서AaBbCc123

옵션 파라미터[ command argument ]

‘<’와 ‘>’ 사이의 내용이 실제 값으로 변경됨< xyz >

선택 사항. 예) A|B: A나 B 중 하나|

파라미터 등이 반복되어서 나옴…

안내서에 대하여 xv

시스템 사용 환경

본 안내서는 모든 예제와 환경 구성을 Microsoft Windows™의 스타일을 따랐다. UNIX와 같은 다른 환경

에서 작업하는 사람은 몇 가지 사항만 고려하면 별 무리없이 사용할 수 있다. 대표적인 것이 구분자인데,

Windows 스타일인 “\”를 UNIX 스타일인 “/”로 바꿔서 사용하면 무리가 없다. 이외에 환경변수도 UNIX 스

타일로 변경해서 사용하면 된다.

그러나 Java 표준을 고려해서 문서를 작성했기 때문에, 대부분의 내용은 동일하게 적용된다.

관련 안내서

설명안내서

JEUS 시스템과 서버의 개요와 시스템 관리를 위한 안내서이다.JEUS Server 안내서

JEUS 내의 웹 서비스에 대해 기술한 안내서이다.JEUS Web Service 안내서

JEUS의 웹 관리 툴인 WebAdmin을 사용한 JEUS 의 설정 및 제어, 모니

터링, 클러스터링, 리소스 설정 및 관리에 대해 기술한 안내서이다.

JEUS WebAdmin 안내서

JEUS를 사용할 때 도움이 되는 Reference를 기술한 안내서이다.JEUS Reference Book

참고 자료

● 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 안내서

연락처

Korea

TmaxSoft Co., Ltd

272-6, Seohyeon-dong, Bundang-gu,

Seongnam-si, Gyeonggi-do, 463-721

South Korea

Tel: +82-31-8018-1000

Fax: +82-31-8018-1115

Email: [email protected]

Web (Korean): http://www.tmax.co.kr

기술지원: http://technet.tmaxsoft.com

USA

TmaxSoft, Inc.

560 Sylvan Avenue Englewood Cliffs, NJ 07632

U.S.A

Tel: +1-201-567-8266

Fax: +1-201-567-7339


Web (English): http://www.tmaxsoft.com

Japan

TmaxSoft Japan Co., Ltd.

5F Sanko Bldg, 3-12-16 Mita, Minato-Ku, Tokyo, 108-0073

Japan

Tel: +81-3-5765-2550

Fax: +81-3-5765-2567


Web (Japanese): http://www.tmaxsoft.co.jp

안내서에 대하여 xvii

http://www.tmax.co.kr

http://technet.tmaxsoft.com

http://www.tmaxsoft.com

http://www.tmaxsoft.co.jp

China

TmaxSoft China Co., Ltd.

Beijing Silver Tower, RM 1508, 2# North Rd Dong San Huan,

Chaoyang District, Beijing, China, 100027

China

Tel: +86-10-6410-6145~8

Fax: +86-10-6410-6144


Web (Chinese): http://www.tmaxsoft.com.cn

xviii JEUS Web Container 안내서

http://www.tmaxsoft.com.cn

제1장 JEUS 웹

본 장에서는 JEUS 웹 모듈에 대한 가장 상위의 컴포넌트인 JEUS 웹 컨테이너에 대한 기본 개념과 웹 모

듈을 관리할 수 있는 툴과 환경설정을 위한 기본 정보를 설명한다.

1.1. 개요JEUS 웹 모듈은 복잡하지만 JEUS 시스템 중에서 실용성 있는 컴포넌트 중의 하나이다. 이 모듈은 사용

자에게 다이내믹하고 고성능이며 안정적인 Java 기반의 웹 콘텐츠를 제공하기 위해 만들어진 JSP, Servlet,

정적 HTML과 같은 수십 개의 하위 컴포넌트들로 구성되어 있다.

본 장의 나머지 부분에서는 웹 모듈의 주요 컴포넌트들에 대하여 살펴보고 어떻게 이들이 연계되어 있는

지 알아본다. 이후 장에서는 운영환경에서 어떻게 이 하위 컴포넌트들을 설정하고 제어하며 모니터링하

는지에 대하여 기술적으로 상세히 설명한다.

1.2. JEUS 웹 구조와 주요 기능JEUS 웹 모듈 관련 컴포넌트 중 가장 기본적이면서도 최상위 레벨의 컴포넌트가 JEUS 웹 컨테이너(이하

웹 컨테이너)이다. 웹 컨테이너는 Java EE 5, Servlet 2.5, JSP 2.1을 준수하고 Servlet과 JSP뿐만 아니라

HTML과 같은 정적 내용까지도 효과적으로 수행할 수 있다.

참고

JEUS 시스템의 설정 파일들과 툴에서는 웹 컨테이너(Web Container)를 웹 엔진(Web Engine)이라

고 부르기도 한다.

1.2.1. 웹 컨테이너와 JEUS 시스템

다음은 JEUS 시스템 구조체 내에서 웹 컨테이너가 어떻게 연관되어 있는지 보여주고 있다.

컴포넌트들은 웹 컨테이너들의 외부에 존재하고 웹 애플리케이션과 웹 컨테이너를 운영하기 위한 환경과

기본 인프라를 제공한다.

제1장 JEUS 웹 1

[그림 1.1] 웹 컨테이너와 JEUS 시스템

EIS Layer

Node

Engine Container

EJB Engine

Servlet/JSP Engine

JMS Engine

Load balancer/

Web Server

Databa

se

HTML

Browser

Applet

JNLP

Client

Java

Corba

Application

HTTP

HTTP/

RMI

JNLP

RMI/II

OP

Client

TP

Monitor

Directory

Server

Other

ORB

Legacy

EIS

JEUS/WAS LayerWeb/Internet

LayerClient Layer

Other JEUS Nodes

WS Engine

Other Services

Java

ApplicationRMI

JEUS Manager

Security Service

Other Services

JNDI Service

주요 컴포넌트들은 다음과 같다.

● 클라이언트

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 안내서

● 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

1.2.2. 웹 컨테이너의 기본 컴포넌트

지금까지 웹 컨테이너가 JEUS 시스템 내부의 다른 컴포넌트들과 어떻게 연계되는지 살펴보았고, 지금부

터는 각각의 컴포넌트들을 구성하며 웹 컨테이너 자체에 포함된 컴포넌트들에 대해 자세히 설명한다.

물리적으로 웹 컨테이너는 다음의 컴포넌트들로 구성되어 있다.

[그림 1.2] 웹 컨테이너의 기본 컴포넌트

Client A

Client C

Client B

JEUS Web Container

Session

handling

settings

Misc. container

settings

Monitoring

threadWeb Server A

Session ServerWeb Server B

Context Group B

Web server

connection/list

ener

Misc. context

group settings

Virtual Host B

Context/Web

app C

Default Virtual Host

Context/Web

app D

Context Group A

Web server

connection/list

ener

Misc. context

group settings

Virtual Host A

Context/Web

app A


Context/Web

app B

주요 컴포넌트들은 다음과 같다.

● 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”을 참고한다.


● 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(웹

애플리케이션)”를 참고한다.

위에서 제시한 모든 기능들이 본 안내의 전체적인 구성이 된다.

1.3. JEUS Web 디렉터리 구조다음은 JEUS Web 모듈에 관련된 기본 디렉터리 구조이다.

[그림 1.3] JEUS Web 모듈에 관련된 기본 디렉터리 구조

JEUS_HOME\

config\

<node-name>\

<node-name>_servlet_<engine-name>\

X WEBMain.xml

webhome\bin\0I jeusadmin

0I jspc

logs\X JEUSMain.xml

X web.xml

X webcommon.xml

servlet\

<node-name>_<cotainer-name>\

<node-name>\

app_home\

autodeploy\

<node-name>_<container-name>\

Legend:0I: binary or executable fileX: XML documentJ: JAR fileT: Text fileC: Class fileV: jaVa source fileDD: deployment descriptor

주의 깊게 살펴봐야 할 디렉터리는 다음과 같다.

JEUS_HOME

JEUS 제품을 설치할 때 선택된다(예. c:\jeus6\).

bin\

jeusadmin, jspc를 포함하고 있는 디렉터리이다.

제1장 JEUS 웹 5

config\<node-name>\

JEUS 시스템에 설정되어 있는 각 웹 컨테이너에 해당하는 하위 디렉터리들을 가지고 있다.

● <node-name>_servlet_<engine-name>\

이 디렉터리는 웹 컨테이너의 XML 기반 설정 파일을 가지고 있다(WEBMain.xml).

설명파일

자신만의 web.xml 파일을 가지고 있지 않은 웹 애플리케이션을 위한 기본

web.xml 파일이다.

web.xml

모든 웹 애플리케이션들에 적용되는 공통 설정 파일이다. 이 파일은 표준을

따르는 web.xml과 동일한 파일이다.

webcommon.xml

Java EE XSD인 “web-app_2_5.xsd”에는 이 파일들에 대한 정의가 포함되어

있다.

logs\<node-name>\<node-name>_<container-name>\servlet

웹 컨테이너의 Logging 데이터를 저장하고 있다.

webhome\

웹 애플리케이션을 위한 Home 디렉터리로서 다음과 같은 작업 디렉터리를 가지고 있다.

설명디렉터리

엔진 로딩 후에 디플로이 대상이 되는 웹 애플리케이션이 존재하며 그

형태는 archive 타입과 exploded 타입 모두 가능하다.

app_home\

jeusadmin 콘솔 툴이나 WebAdmin을 통해서 디플로이를 할 경우 이 작

업 디렉터리를 사용한다.

엔진을 기동(Booting)하는 경우 archive 타입의 웹 애플리케이션을 엔진

이 자동으로 디플로이시킨다.

autodeploy\

웹 애플리케이션이 디플로이될 경우 사용하는 작업 디렉터리이다.<nodeName_containerName>\

만일 JSP와 관련해서 생성되는 파일에 위치를 지정하고 싶을 경우

WEBMain.xml 이나 jeus-web-dd.xml의 <jsp–engine> 요소를 통해서 설

정 가능하다.

1.4. JEUS 웹 툴JEUS 웹 모듈에 관련된 툴들은 다음과 같다.

● WebAdmin

웹 컨테이너를 대상으로 작업할 수 있는 가장 좋은 툴이다.

이 툴의 사용법은 "JEUS WebAdmin 안내서"를 참고한다.


● jeusadmin 콘솔 툴

명령창에서 웹 엔진을 제어할 수 있는 툴로, 웹 컨테이너에 대한 기본 제어와 모니터링 기능을 제공한

다. 이 툴에 대한 사용법은 “JEUS Reference Book”의 “4.2.5. 서블릿 엔진 관련 명령어”와 "JEUS Server

안내서"를 참고한다.

● JSP batch compiler

처음 접근하는 JSP에 대한 빠른 수행 능력을 위해 JSP를 미리 컴파일 할 수 있는 기능을 제공한다.

batch compiler에 대한 사용법은“JEUS Reference Book”의 “4.4. appcompiler”와 “JEUS Reference Book”

의 “4.7. jspc”를 참고한다.

1.5. JEUS Web 환경설정웹 컨테이너를 사용하기 위해서 환경변수와 XML 파일에 필요한 정보를 설정해야 한다. 본 절에서는 JEUS

Web 모듈에서 사용하는 환경변수와 XML 설정 파일에 대해서 설명한다.

1.5.1. 환경변수

JEUS Web 모듈에서 사용하는 환경변수들은 JEUS JVM에 시스템 설정을 전달하기 위해 사용된다.

이 시스템과 JVM 사이의 변수 매핑은 JEUS_HOME\bin\ 디렉터리에 위치한 다양한 JEUS 스크립트에 존

재한다. 어떤 시스템 변수들은 스크립트에 직접 반영이 되지 않은 것도 있다. 즉, 이 값들을 OS 환경변수

값을 수정함으로 또는 스크립트 외부에서 수정하는 것이 실제로 적용되지 않을 수도 있다는 것을 의미한

다. 그러므로, 이 값들은 항상 JEUS_HOME/config의 xml 파일에서 설정하도록 한다.

대부분의 환경변수 값들은 JEUS를 설치할 때 자동으로 설정된다. 환경변수는 수정 가능하지만 일반적으

로 권장하지는 않는다. 반드시 필요한 경우에만 XML 설정 파일에서 이 환경변수들을 수정하는 것이 더 일

반적이다.

다음은 JEUS Web 모듈에 관련된 시스템 환경변수에 대한 설명이다.

[표 1.1] JEUS Web 모듈 환경변수

설명환경변수

JEUS가 설치된 기본 위치를 설정한다. 예) C:\Jeus6 (반드시 설정되어야 한다)JEUS_HOME

JEUS 웹 서버(WebtoB)의 홈 디렉터리이다. 예) C:\Jeus6\webserver (기본값)JEUS_WSDIR

참고

이 시스템 값들을 설정하는 방법은 OS에 따라 각기 다르다. 설정 방법에 대한 내용은 해당 OS 매뉴

얼을 참고한다.

제1장 JEUS 웹 7

1.5.2. 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 파일이다.목적


● webcommon.xml (web-app_2_5.xsd)

JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name>\위치

웹 컨테이너의 모든 Context에 적용되는 공통되는 설정 파일이다.목적



제2장 웹 컨테이너

본 장에서는 JEUS 웹 컨테이너의 하위 모듈과 주요 기능, 기본적인 설정 방법에 대해서 설명한다.

2.1. 개요JEUS 시스템의 웹 컨테이너는 Servlet 2.5와 JSP 2.1 스펙으로 생성된 Java 기술 기반의 동적인 웹 페이

지를 실행하기 위한 환경과 운영 기반을 제공한다. 또한 웹 컨테이너는 HTML과 이미지 파일들과 같은

Static Content(정적 콘텐츠)들도 서비스할 수 있다.

웹 컨테이너는 JEUS 웹 모듈의 최상위 컴포넌트이다. 여기에는 많은 수의 하위 모듈들과 설정할 수 있는

기능들이 존재한다. 예를 들어 여러 개의 웹 컨테이너들은 부하 분산과 Fail-Over 기능을 제공하기 위하여

클러스터로 구성될 수도 있고, WebtoB나 Apache 웹 서버와 같은 웹 서버와 연결될 수도 있다.

2.2. 웹 컨테이너 주요 기능과 구조다음은 웹 컨테이너 컴포넌트로 본 장에서 주로 설명할 부분을 타원으로 표시하고 나머지 부분들은 다음

장에서 설명한다.

[그림 2.1] 웹 컨테이너 구조

Client A

JEUS Web Container

Session

handling

settings

Misc. container

settings

Monitoring

threadWeb Server A


Context Group B

Web server

connection/list

ener

Misc. context

group settings

Virtual Host B

Context/Web

app C


Context/Web

app D

Context Group A

Web server

connection/list

ener

Misc. context

group settings

Virtual Host A

Context/Web

app A


Context/Web

app B

Client B

다음에 설명하는 하위 절에서는 웹 컨테이너의 가장 중요한 하위 모듈들을 설명한다. 이 모듈들은 각자가

많은 기능들을 포함하고 있지만 여기서 모두 설명하지 않고 별도의 장들에서 설명하도록 한다.

제2장 웹 컨테이너 9

2.2.1. 주요 기능

웹 컨테이너의 하위 모듈들과 기능들은 다음과 같다.

● 자동 모니터링

웹 컨테이너 자체 감시의 가장 중요한 부분은 자동 모니터링을 이용하는 것이다. 이 기능은 컨테이너 내

의 모든 자원과 Pool들의 상태를 감시하고 문제가 발생하였을 때 대응할 수 있다. 설정에 대한 자세한

내용은 “2.3.3. 자동 모니터링”을 참고한다.

● stdout와 stderr redirection

설정 여부에 따라 stdout과 stderr를 사용해서 로그를 남긴다. 설정에 대한 자세한 내용은 “2.3.4. stdout

과 stderr Redirection”을 참고한다.

● Context Group

각 웹 컨테이너는 하나 이상의 Context Group을 포함할 수 있다. Context Group은 여러 개의 리스너, 가

상 호스트, Context를 관리한다. 설정에 대한 자세한 내용은 “2.3.5. Context Group”을 참고한다.

● Database Connection Pool

웹 애플리케이션에서는 Database Connection Pool을 생성하여 사용한다. 설정에 대한 자세한 내용은

“2.3.6. Database Connection Pool”을 참고한다.

● Session 관리

웹 컨테이너의 Session 관리에 대한 여러 가지 사항을 설정한다. Session 클러스터링의 참여 여부,

Session 객체의 공유 여부, Session Cookie 설정, timeout 등 웹 컨테이너의 Session과 관련된 모든 설

정을 할 수 있다. 설정에 대한 자세한 내용은 “2.3.7. Session”을 참고한다.

● Shutdown Timeout

Shutdown Timeout 기능으로 관리자가 “down” 명령을 내렸을 때 웹 컨테이너가 실제로 종료되기까지

웹 컨테이너가 기다리는 시간을 지정한다. 설정에 대한 자세한 내용은 “2.3.9. Shutdown Timeout”을 참

고한다.

위에서 열거된 목록은 JEUS 웹 컨테이너의 최상위 뷰를 표현하고 있다. 이들은 웹 컨테이너의 주요 하위

모듈인 Context Group과 Context가 사용할 수 있는 모듈들과 서비스들을 의미한다.


2.2.2. 디렉터리 구조

다음은 JEUS 웹 컨테이너를 다룰 때 가장 많이 사용되는 디렉터리들이다.

[그림 2.2] JEUS 웹 컨테이너 관련 디렉터리

JEUS_HOME\

config\

<node-name>\

<node-name>_servlet_<engine-name1>\

X WEBMain.xml

webhome\

X JEUSMain.xml


<node-name>_servlet_<engine-name2>\

X WEBMain.xml

app_home\


autodeploy\

JEUS_HOME\

JEUS가 설치된 최상위 디렉터리이다.

config\<node-name>\

JEUS Manager 및 컨테이너에 대한 설정 파일인 JEUSMain.xml을 가지고 있다.

config\<node-name>\<node-name>_servlet_<engine-name>\

웹 컨테이너의 모든 설정이 포함된 WEBMain.xml 파일이 포함되어 있다.

webhome\

웹 애플리케이션을 위한 home 디렉터리로서 다음과 같은 작업 디렉터리를 가지고 있다.

설명디렉터리

엔진 로딩 후에 디플로이 대상이 되는 웹 애플리케이션이 존재하며 그

형태는 archive 타입과 exploded 타입 모두 가능하다. jeusadmin 콘솔

app_home\

툴이나 WebAdmin을 통해서 디플로이를 할 경우 이 작업 디렉터리를

사용한다.

엔진을 기동(Booting)하는 경우 archive 타입의 웹 애플리케이션을 엔진

이 자동으로 디플로이한다.

autodeploy\

웹 애플리케이션이 디플로이될 경우 사용하는 작업 디렉터리이다.<nodeName_containerName>\


설명디렉터리

만일 JSP 관련해서 생성되는 파일에 위치를 지정하고 싶을 경우 WEB

Main.xml 이나 jeus-web-dd.xml의 <jsp–engine> 요소를 통해서 설정이

가능하다.

로그는 웹 컨테이너를 통해 직접적으로 생성되지 않고 Context Group 레벨에서 설정하고 생성된다. 자세

한 내용은 “제3장 Context Group”을 참고한다.

2.3. 웹 컨테이너 설정본 절에서는 JEUS 웹 컨테이너의 주요 기능에 대한 설정 방법에 대해서 설명한다.

2.3.1. 개요

웹 컨테이너 설정하기 위해서는 기본 설정 파일인 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 안내서"의 엔진 컨테이너와 서블릿 엔진 부분을 참고한다.

2.3.2. 기본 설정

다음은 웹 컨테이너의 기본 설정 파일인 JEUSMain.xml의 예이다.

[예 2.1] 웹 컨테이너 기본 설정 : <<JEUSMain.xml>>

<?xml version="1.0"?>

<jeus-system xmlns="http://www.tmaxsoft.com/xml/ns/jeus">

. . .

<node>

. . .

<engine-container>

. . .

<engine-command>


<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>

다음은 디렉터리명을 설정하는 항목에 대한 설명이다.

설명항목

JEUS의 노드명이다.<node-name>

JEUSMain.xml의 <engine-command>의 하위 태그인 <name>에 설정된 값이어야

한다. 위의 예제에서 “hostname”이 “johan”이라면 <engine-name>은 “jo

han_servlet_engine1”이 된다.

<engine-name>

JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name> 아래에는 반드시 WEBMain.xml

이라는 파일이 존재해야 한다.

참고

각 엔진 컨테이너에는 단 한 개의 웹 컨테이너가 존재할 수 있다.

2.3.3. 자동 모니터링

웹 컨테이너 자체 감시의 가장 중요한 부분은 자동 모니터링을 이용하는 것이다. 자동 모니터링은 웹 컨테

이너의 자동 관찰 시스템이다. 이 기능은 컨테이너 내의 모든 자원과 Pool들의 상태를 감시하고 문제가 발

생하였을 때 대응할 수 있는 기능을 한다.

자동 모니터링에는 3가지의 모니터링이 존재한다.

● Thread Pool Monitor

컨테이너의 Worker Thread Pool을 모니터링한다. 자세한 내용은 “제4장 웹 서버 연결과 클러스터링”을

참조한다.

● Class-reloading Monitor

웹 컨테이너에 등록된 Servlet 클래스들의 변경을 모니터링한다. 자세한 내용은 “제6장 Web Context(웹

애플리케이션)”를 참조한다.


● 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>>


<web-container xmlns="http://www.tmaxsoft.com/xml/ns/jeus">

<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 설정 부분에서 따로 설정한

다.

2.3.4. 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>>




<monitoring>

. . .

</monitoring>

<redirect-stdout>true</redirect-stdout>

<redirect-stderr>true</redirect-stderr>

. . .

</web-container>

설정 정보는 <redirect-stdout>과 <redirect-stderr> 태그에 Boolean 값인 “true” 또는 “false”로 설정한다.

2.3.5. 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>>



<monitoring>

. . .

</monitoring>

. . .

<context-group>

. . . 

</context-group>

<context-group>

. . .

</context-group>

. . .

</web-container>

웹 컨테이너 레벨에서 정의된 설정들은 모든 Context Group과 웹 컨테이너의 하위 Context에 글로벌하게

적용된다.

2.3.6. 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을 획득하는 전통적인 방법 역시 가능하다.

2.3.7. 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 설정 부분이 적용된다.


참고

Web Container 레벨, Context Group 레벨, Context 레벨의 설정이 중복되었을 경우 하위 레벨의 세

부적인 설정에 가장 높은 우선순위를 부여한다. 즉, 세 군데 모두 설정을 하였다면 Context 레벨 >

Context Group 레벨 > Web Container 레벨 순으로 설정값이 적용된다.

만약 하위 레벨에서 특정 설정을 하지 않았다면 상위 레벨의 설정값을 적용하고 모든 레벨에서 설정

하지 않은 값은 엔진 내부적인 기본값으로 동작한다.

다음은 Web Container 레벨의 Session 설정의 예이다. Session 설정은 <web-contianer> 하위 <session-

config>에 구성한다.

[예 2.5] Session 설정 : <<WEBMain.xml>>



. . .

<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 클러스터링에 참여할지의 여부를 설정한다.

설명설정값

Session 클러스터링에 참여한다.true

Session 클러스터링에 참여하지 않는다.(기본값 : false)false

– JEUS 웹 컨테이너는 크게 2가지 방식의 Session 클러스터링 방식을 지원한다. 중앙 집중 방식과 분

산 방식이다.


Session 정보를 관리하는 환경에 대한 보다 자세한 내용은 “제5장 Session Tracking”, 중앙 집중식

Session 클러스터링의 경우 “JEUS Server 안내서”의 “10.2. 중앙 세션 서버”, 분산식 Session 클러스

터링의 경우 “JEUS Server 안내서”의 “10.3. 분산 세션 서버”를 각각 참고한다.

● <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 쿠키 정보를 보내지 않는다는 것이다.

설명설정값

쿠키에 의존하는 대신에 URL rewriting을 강제로 대신 사용하게 한다.true


설명설정값

이렇게 함으로써, Session Tracking이 다른 도메인 이름이 사용되어 몇 번의 요

청이 들어와도 가능하게 된다. URL rewriting이라 함은 context에 의해 반환되는

모든 URL에 유일한 JSESSIONID URL 파라미터를 붙이는 것을 의미한다.

이 기능은 사용되지 않고, 기본적인 쿠키 기반만 사용된다.(기본값: false)false

● <session-cookie>

– 사용자의 Session을 추적하는 기본 기술은 모든 클라이언트 응답에 반환되는 이 Session 쿠키를 이

용한다. 자세한 내용은 “제5장 Session Tracking”을 참고한다.

웹 컨테이너에서 Response를 내보낼 때 HTTP 헤더의 Session 쿠키에 대한 설정을 여기서 한다. 일

반적으로 엔진에서 쿠키를 구성하나, 특별한 쿠키 정보를 구성하고 싶을 때 사용한다.

– 다음과 같은 세부 항목을 설정할 수 있다.

설명태그

Session 쿠키의 이름으로 표준 이름인 "JSESSIONID"을 사용하지 않고 다른 이

름을 사용할 때 이 설정을 사용한다. String 형식의 설정이며, 설정을 하지 않았

을 경우 기본값으로 "JSESSIONID"가 주어진다.

<jsessionid-name>

쿠키의 버전을 설정한다. Int 형식의 설정으로 다음의 값 중에 하나를 설정한다.<version>

- 0 : NS 쿠키 유형을 가진다.(기본값 : 0)

- 1 : RFC 스펙의 쿠키 유형을 가진다.

Session 쿠키가 보내질 때 서버의 도메인 이름을 설정한다. 쿠키는 이 도메인 요

청에 대해서만 되돌아 온다. 하나의 적합한 도메인 이름은 "."으로 시작되어야 하

<domain>

며 <host_name>을 지정해서는 안 된다. 이에 대한 자세한 내용은 RFC-2109 스

펙을 확인한다.

String 형식의 설정이며, 설정을 하지 않았을 경우 쿠키에 도메인 정보를 포함하

지 않도록 한다.

Session 쿠키가 보내질 도메인 내의 URL 경로를 설정한다. 쿠키는 도메인이 적

합할 때 해당 URL의 어떤 요청과 더불어 보내진다.

<path>

예를 들어 만일 "/examples"란 경로가 설정되고, 도메인은 ".foo.com"으로 설정

되었다고 가정할 때, 클라이언트의 요청들은 "www.foo.com/examples"의 형식

에 맞을 때만 해당 쿠키를 포함하여 서버로 요청한다. 이 또한 위의 도메인 설정

과 더불어 RFC-2109 스펙을 확인한다.

String 형식의 설정이며, 설정을 하지 않았을 경우 엔진 내부에서 적절한 path를

선택하고 설정을 하였을 경우 일반적으로 설정된 고정 path 정보를 쿠키에 포함

한다. path를 설정할 경우 설정한 고정 값이 항상 쿠키의 정보로 포함된다.

path의 최상위 값인 "/"가 아닌 다른 값으로 설정을 할 경우는 애플리케이션들의

Session 공유 특성들을 고려하여 주의 깊게 값을 설정한다.


설명태그

Session 쿠키의 expires 속성을 설정한다. 이 시간 주기가 되면 쿠키는 클라이언

트로부터 제거되고 더 이상 보내지지 않는다.

<max-age>

Int 형식의 설정이며 초단위 시간을 설정한다. 설정을 하지 않았을 경우 기본값

으로 -1이 주어진다. -1 값의 의미는 쿠키의 "expires"속성을 사용하지 않겠다는

것을 의미한다. 즉, 브라우저의 Lifecycle을 따르겠다는 의미로서 브라우저가 닫

힐 때 쿠키는 사용자의 Session이 끝남과 동시에 끝난다.

Session 쿠키의 "secure" 속성을 설정한다. 만일 "true"로 설정되면 Session 쿠키

는 오직 secure http connection인 HTTPS 위에서만 보내진다.

<secure>

Boolean 형식이며, 설정을 하지 않았을 경우 기본값으로 "false"가 주어진다.

2.3.8. 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 설정”에서 설명한다.

2.3.9. Shutdown Timeout

Shutdown Timeout 기능으로 관리자가 “down” 명령을 내렸을 때 웹 컨테이너가 실제로 종료되기까지 웹

컨테이너가 기다리는 시간을 지정한다. 이 설정은 관리자가 웹 컨테이너는 Worker Thread들이 작업을 모

두 마치기까지 기다리도록 한다.

“down” 명령을 수행했을 때 어떤 Worker Thread도 실행되고 있지 않으면 컨테이너는 이 설정을 무시하고

바로 종료를 수행한다.

다음은 Shutdown Timeout 설정에 대한 예로 <web-container>태그에 <shutdown-timeout> 하위에 구

성한다.



. . .

<shutdown-timeout>10000</shutdown-timeout>

</web-container>


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

2.4.1. 공통 설정 항목

본 절에서는 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> 설정보다 우선한다.


참고

<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>>



<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>

[email protected]

</from-address>

<to-address>

[email protected]

</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>


<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 설정만

가지고 있다.

설명태그

handler가 툴에서 보여질 때 사용할 이름을 지정한다. 만약 지정되어 있지 않으

면 class name과 hash code로 이름이 대체된다.

<name>


설명태그

handler가 출력할 메시지의 레벨을 지정한다. 즉, Logger를 통과한 로그 메시지

가 이 Logger가 사용하는 각각의 handler에게 전달되는데 이 handler의 레벨에

부합하는 로그 메시지만 이 handler에 의해 출력된다.

<level>

기본값은 FINEST로 Logger를 통과하는 모든 로그 메시지가 handler에 의해 출

력되도록 되어 있다. 단, Access log 일 경우, INFO 레벨 이상에서는 Access Log

를 출력하지 않는다.

handler가 출력하는 문자열의 인코딩을 지정한다. 한글 querystring의 출력을 지

원하기 위해서 기본값은 system encoding이 아닌 'ISO-8859-1'로 설정되어 있

<encoding>

다. HttpServletRequest.getQueryString()은 스펙에 따라 WEBMain.xml에 인코

딩 설정이 있어도 디코딩 처리를 하지 않기 때문에 'ISO-8859-1'로 디코딩해야

access log에 한글 querystring이 정상적으로 출력된다.

handler가 로그 메시지를 출력하기 전에 수행할 필터링에 이용되는 클래스이다.

Logger의 <filter-class>와 마찬가지로 lib\application에 이 클래스를 포함한 jar

파일이 존재해야 한다.

<filter-class>

• <file-handler>

파일로 로그 메시지를 출력하는 handler로 <console-handler>의 설정 이외에 다음과 같은 설정을

가지고 있다.

설명태그

handler가 출력할 파일의 이름을 지정한다.<file-name>

절대 경로로 되어 있다면 그 경로로 파일이 생기고 상대 경로라면 각 Logger의

기본 경로를 기준으로 한 상대 경로로 인식한다. 이 설정을 하지 않으면 각 Logger

별로 지정된 path로 파일을 생성해서 로그 메시지를 출력한다.

handler가 출력할 파일을 시간마다 따로 생성할 경우에 사용한다. 둘 중 하나만

사용할 수 있는데, valid-day는 날짜별로 valid-hour는 시간별로 파일을 변경한다.

<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)

<buffer-size>

파일로 출력할 때 이미 파일이 존재하면 덮어쓸지 파일끝에 추가할지를 결정한

다.(기본값 : true)

<append>

“JEUS Server 안내서”의 “11.3.2. 로그 파일 Rotation 설정”을 참고한다.<log rotation>

• <smtp-handler>


로그 메시지를 e-mail로 전송하는 handler이다. 하나의 로그 메시지가 하나의 e-mail로 전송된다.

<console-handler>의 설정 이외에 다음과 같은 설정을 가지고 있다.

설명태그

e-mail을 보낼 호스트의 주소를 지정한다.<smtp-host-address>

e-mail을 보내는 사람의 주소를 지정한다.<from-address>

e-mail을 받는 사람의 주소를 지정한다.<to-address>

e-mail을 참조하는 사람의 주소를 지정한다.<cc-address>

e-mail을 숨은 참조하는 사람의 주소를 지정한다.<bcc-address>

모든 메시지를 smtp-handler로 보낼지를 결정한다.<send-for-all-mes

sages> false인 경우 JEUS 시스템에서 e-mail로 전송하기로 결정되어 있는 메시지만 이

handler를 사용해서 보내진다. 이 설정은 jeus.systemuser logger에만 유효하다.

• <socket-handler>

로그 메시지를 소켓으로 전송하는 handler로 <console-handler>의 설정 이외에 다음과 같은 설정

을 가지고 있다.

설명태그

handler가 접속할 머신의 IP 주소를 지정한다.<address>

handler가 접속할 머신의 port를 지정한다.<port>

• <user-handler>

사용자가 생성한 handler 클래스를 지정하는 항목으로 <console-handler>의 설정 이외에 다음과

같은 설정을 가지고 있다.

설명태그

사용자가 생성한 handler의 클래스를 지정한다.<handler-class>

이 클래스는 lib\application 디렉터리의 jar 파일에 포함되어 있어야 한다. 또한

이 클래스는 Logging API의 java.util.logging.Handler를 상속받고 jeus.util.log

ging.JeusHandler를 구현해야 한다.

jeus.util.logging.JeusHandler의 setProperty()에 사용되는 Map 객체에 들어갈

프로퍼티를 지정한다.

<handler-property>

handler가 사용할 formatter 클래스를 지정한다. 이 클래스도 lib\application 디렉

터리의 jar 파일에 포함되어 있어야 한다. 또한 jeus.util.logging.JeusFormatter

<formatter-class>

interface를 구현해야 한다. 기본값은 JEUS에서 사용하는 jeus.util.logging.Sim

pleFormatter이다.

jeus.util.logging.JeusFormatter의 setProperty()에 사용되는 Map 객체에 들어갈

프로퍼티를 지정한다.

<formatter-property>


2.4.2. Access log 관련 설정 항목

다음은 Access log에만 사용되는 설정에 대한 설명이다.

● <access-log>

설명태그

Access log 관련하여 아무것도 설정하지 않을 경우 기본 파일에 기본 형식으로 Access

log를 남긴다. 이 설정은 Access log를 남기는 것을 원치 않을 경우 사용한다.

<enable>

Access log에 남길 로그의 형식을 지정한다. 설정하지 않을 경우 기본 형식으로 로그

를 남긴다. 자세한 설명은 "<access-log>의 <format> 설정" [26]을 참고한다.

<format>

특정 확정자들을 ","로 구분하여 설정한다.<exclude-ext>

<access-log>의 <format> 설정<access-log>의 하위 요소인 <format>을 사용하여 사용자 정의 Access log format을 지정하는 것이 가능

하다. <format>에 넣을 값은 임의의 String 값이 가능하다. 단 “%” 기호는 특수 기호로 인식된다. 즉, “%”를

접두사로 사용하는 다음에 열거하는 단어들은 runtime에 여러 가지 request/response property로 대체되

어 Access log에 남게 된다.

● Runtime에 대체되는 특수 단어들1

설명단어

Remote IP address%a

Local IP address%A

HTTP header를 제외한 response body의 총 길이(‘-‘는 0을 나타낸다)%b

HTTP header를 제외한 response body의 총 길이%B

Remote host name 또는 IP address%h

Request protocol%H

Request method (GET, POST…)%m

Local port number%p

Query string(앞에 ‘?’가 붙음)%q

method 와 request URI%r

HTTP response status code%s

User session ID%S

Date and time(기본 시간 형식. 후술함)%t

Remote user name%u

Request URL%U

Local server name%v


설명단어

processing time(단위 : millisecond)%D

processing time(단위 : 초)%T

● Runtime에 대체되는 특수 단어들2

request cookie, header, attribute, session attribute 등에서 특정 값을 가져와 표시할 수 있다.

설명단어

request header에서 key가 “xxx”인 값을 표시한다.{xxx}I

request cookie에서 key가 “xxx”인 값을 표시한다.{xxx}c

request attribute에서 key가 “xxx”인 값을 표시한다.{xxx}r

Session 정보에서 key가 “xxx”인 값을 표시한다.{xxx}s

“xxx”를 JDK standard DateFormat으로 기술하면 access-log의 시간 형식을 바꿀 수

있다.

{xxx}t

● 기본 <format>

[%{yyyy.MM.dd HH:mm:ss}t] %a "%m %U%q" %s %Dms

Access log 필터 설정

사용자의 특별한 설정이 없을 경우, 다음과 같은 기본 형식의 모든 Access log를 기록한다.

[2010.06.22 14:42:57] 127.0.0.1 "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)}안에서 다양하게 필터링 정책을

정하도록 가이드 한다.


*/

public interface AccessLoggerFilter extends Filter {

/**

* 서버에 접속한 remote client의 address 정보를 반환한다.

*

* @param record a LogRecord

* @return remote client의 address. 만약 올바른 값을 얻지 못할 경우 null을 반환한다.

*/

public String getRemoteAddr( LogRecord record );

/**

* 요청의 메소드를 반환한다. ex) GET, POST, PUT, etc...

*


* @return request method. 만약 올바른 값을 얻지 못할 경우 null을 반환한다.

*/

public String getMethod( LogRecord record );

/**

* 요청의 uri를 반환한다.

*


* @return request uri. 만약 올바른 값을 얻지 못할 경우 null을 반환한다.

*/

public String getRequestURI( LogRecord record );

/**

* 응답의 status값을 반환한다. ex) 200, 404

*


* @return status.

*/

public int getStatus( LogRecord record );

/**

* 요청에 따른 처리시간을 ms단위로 반환한다.


* @return processing time. 만약 올바른 값을 얻지 못할 경우 -1을 반환한다.

*/

public long getProcessingTimeMillis( LogRecord record );

}

사용자가 Access log의 특정 패턴에 대해 필터링하는 경우 위의 AccessLoggerFilter 인터페이스 및 Abstrac

tAccessLoggerFilter 추상 클래스를 이용하여 쉽게 필터를 구현, 적용할 수 있다.


사용자의 필터 클래스는 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>>



<context-group>

. . .

<logging>

. . .

<access-log>

<enable>true</enable>

. . .

<filter-class>

sample.SimpleAccessLoggerFilter

</filter-class>


<handler>

<file-handler>

<name>fileHandler</name>

<valid-hour>1</valid-hour>

</file-handler>

</handler>

</access-log>

</logging>

</context-group>

. . .

</web-container>

2.4.3. User log 관련 설정 항목

User log에만 해당하는 별도의 하위 요소는 없다. User log는 다음에 별도로 설명할 Context deployment

descriptor에서 설정하여 특정 Context 단독으로 사용하는 것이 가능하다. 그러한 경우에는 Context deploy

ment descriptor 내의 <user-log> 설정이 우선 순위를 갖는다.

2.5. 웹 컨테이너 제어와 모니터링본 절에서는 웹 컨테이너 제어와 모니터링하는 방법에 대해서 설명한다.

2.5.1. 웹 컨테이너 제어

웹 컨테이너를 제어한다는 것은 웹 컨테이너의 시작과 종료를 제어한다는 의미와 같다. 이 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 명령창이 나타난다.


● 노드 시작

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 제어 설명을 참고한다.

2.5.2. 웹 컨테이너 모니터링

모니터링은 근본적으로 특정 웹 컨테이너의 수행하는 경우 데이터와 상황 정보를 수집하는 것을 의미한

다.

주의

웹 컨테이너를 모니터링하기 위해서는 콘솔 툴 보다는 보다 상세하고 완전한 엔진 상태 정보를 제공

하는 WebAdmin의 사용을 권장한다.

콘솔 툴을 통한 웹 컨테이너 모니터링

‘jeusadmin’ 콘솔에서는 웹 컨테이너에 대한 기초 정보를 얻을 수 있는 기능을 제공한다. 자세한 내용은

"JEUS Server 안내서"와 “JEUS Reference Book”의 “4.2.5. 서블릿 엔진 관련 명령어”를 참고한다.

WebAdmin을 통한 웹 컨테이너 모니터링

WebAdmin을 통하여 웹 컨테이너를 모니터링할 수 있다. WebAdmin의 엔진 컨테이너 통계 부분과 Session

서버 통계 부분을 이용한다.


제3장 Context Group

본 장에서는 Context Group에 대해 상세하게 설명한다.

3.1. 개요JEUS 내부에서 웹 애플리케이션(또는 Context)은 Context Group으로 그룹핑 되어 있다. 또한, 여러 개의

Context Group들도 JEUS 웹 컨테이너에 존재할 수 있다. 관련 내용은 “제2장 웹 컨테이너”를 참고한다.

Context Group은 웹 애플리케이션에 많은 중요한 서비스들을 제공한다. 이러한 서비스들의 예는 웹 서버

연결, JSP 컴파일, Logging, active management, response header 설정 등이 있다. 즉, Context Group의

설정과 서비스들은 종속되어 있는 모든 웹 애플리케이션(Context)에 적용된다. JEUS 시스템에 웹 애플리

케이션을 성공적으로 디플로이하기 위해서는 이 개념을 반드시 이해해야 한다.

3.2. Context Group 주요 기능과 구조개념적으로, Context Group은 “웹 컨테이너 내의 웹 컨테이너”로 생각할 수 있다. 그뿐만 아니라 Context

Group은 복수 개의 웹 애플리케이션(Context)를 호스팅할 수 있는 Virtual Server라고 생각할 수 있다.

각 Context Group에는 그에 등록된 웹 애플리케이션들이 사용할 별도의 설정과 하위 컴포넌트들이 존재

한다. 많은 서비스들과 설정들이 최상위 웹 컨테이너로부터 상속된다는 사실도 매우 중요하다.

앞에서 설명했듯이, 이러한 서비스들에는 Session 처리 설정(Session 처리 설정이 Context Group에 설정

되어 있으면 웹 컨테이너의 설정은 무시된다)이 있다.

제3장 Context Group 33

다음은 “제1장 JEUS 웹”에서 제시한 웹 컨테이너 구조이다. 본 장에서 주로 설명할 부분은 타원으로 표시

되어 있다.

[그림 3.1] 웹 컨테이너에 연관된 Context Group

Client A

JEUS Web Container

Session

handling

settings

Misc. container

settings

Monitoring

threadWeb Server A


Context Group B

Web server

connection/list

ener

Misc. context

group settings

Virtual Host B

Context/Web

app C


Context/Web

app D

Context Group A

Web server

connection/list

ener

Misc. context

group settings

Virtual Host A

Context/Web

app A


Context/Web

app B

Client B

다음 그림은 Context Group의 상세 확대한 모습으로 본 장에서 주로 설명할 부분은 타원으로 표시되어 있

다.

[그림 3.2] Context Group의 상세 모습과 그 하위 컴포넌트들


3.2.1. 주요 기능

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에 의해 사용될 수 있는 인코딩 설정을 가지고 있다. 설정에 대한

자세한 내용은 “3.3.2. 인코딩 설정”을 참고한다.

● JSP Engine

각 Context Group은 JSP 엔진을 포함하고 있다고도 볼 수 있다. JSP 엔진은 “jsp” 자원을 클라이언트가

요청하였을 때 JSP페이지들을 컴파일 하여 Servlet 코드로 만드는 작업을 한다.

설정에 대한 자세한 내용은 “3.3.3. JSP 엔진 설정”을 참고한다.

● logging

logging 옵션을 <web-container>절에 설정하면 모든 Context Group에 공통으로 적용되고, <context-

group>절에 설정하면 설정한 Context Group에만 적용된다. 설정에 대한 자세한 내용은 “3.3.4. Logging

설정”을 참고한다.


● Session 관리(웹 컨테이너에서의 설정을 재설정)

Context Group에 Session 관련 설정을 할 수 있다. 설정에 대한 자세한 내용은 “3.3.5. Session 설정”을

참고한다.

● Response Header

사용자 임의의 HTTP Header Response 이름과 값의 짝으로 정의해서 사용한다. 설정에 대한 자세한

내용은 “3.3.6. Response Header 설정”을 참고한다.


다음은 Context Group과 관계된 JEUS 시스템 디렉터리에 대한 설명이다.

[그림 3.3] Context Group 디렉터리 구조

JEUS_HOME\

config\

<node-name>\


X WEBMain.xml

webhome\


logs\

<node-name>\


T acess_MMDDYYYY.log

T error_MMDDYYYY.log

userlog\

acesslog\

errorlog\

servlet\

T user_MMDDYYYY.log

app_home\

autodeploy\

JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name>\

Context Group을 설정하기 위한 WEBMain.xml을 가지고 있다. Context는 별도의 파일에 설정된다

(“jeus-web-dd.xml”).


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”와 같은 이름의 파일이 생성된다.

3.3. 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> 태그 아래에 <context-

group> 태그를 추가하고 수정한다.


[예 3.1] Context Group 설정 : <<WEBMain.xml>>



...

<context-group>

. . .

</context-group>

<context-group>

...

</context-group>

...

</web-container>

다음은 위의 컴포넌트들의 설정 사항들이 포함된 WEBMain.xml 파일의 예이다. 이 예는 XML 규칙과 순서

만 보여주지만, 뒤이어 설명될 하위 절에서는 각 XML 부분들이 구체적으로 어떻게 설정되는지 보여줄 것

이다.



. . .

<context-group>

<group-name>MyGroup</group-name>

<virtual-host>



</virtual-host>

<webserver-connection>



</webserver-connection>

<attach-stacktrace-on-error>...</attach-stacktrace-on-error>

<encoding>



</encoding>

<jsp-engine>



</jsp-engine>

<logging>



</logging>

<session-config>



</session-config>

<response-header>



</response-header>

</context-group>

. . .

</web-container>

3.3.1. 기본 설정

Context Group의 기본 설정은 WEBMain.xml의 <context-group> 태그 바로 하위에 설정되고 다음과 같

이 정의된다.

[예 3.2] Context Group 기본 설정 : <<WEBMain.xml>>



. . .

<context-group>


. . .

<attach-stacktrace-on-error>true</attach-stacktrace-on-error>

. . .

</context-group>

. . .

</web-container>

다음은 설정 항목에 대한 설명이다.

설명항목

내부적으로 통용되는 Context Group의 식별자이다.<group-name>

서버에 문제가 발생하였을 때 오류의 상세 내역을 브라우저로 보여줄

것인지에 대한 설정이며, Boolean 값으로 설정한다. 이 메시지는 개발

할 때는 유용하지만 운영할 때는 제거하는 것이 바람직하다.

<attach-stacktrace-on-error>

다음의 하위 절들은 <context grpup> 하위 컴포넌트들이 어떻게 설정되는지에 대해 설명한다.

3.3.2. 인코딩 설정

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와 다른 특별한 경우이

다.


– Request Url encoding은 다음의 순서에 따라 결정된다.

1. WEBMain.xml에 정의된 “forced” 인코딩

2. HTTP header의 “Accept-Language” 필드 값에 해당하는 인코딩

3. WEBMain.xml에 정의된 “default” 인코딩

4. 위의 어떤 것도 적용되지 않으면 기본적으로 “ISO-8859-1”로 설정된다.

위의 목록에서 첫 번째 설정이 가장 높은 우선순위를 가지며 첫 번째 설정이 없을 경우 두 번째 설정

이 적용되는 식으로 순차적으로 우선순위를 갖는다. 단, 사용자가 Request 객체에 setCharacterEn

coding()으로 설정한 경우, query string 및 쿠키에 대해서는 사용자가 설정한 인코딩이 최우선적으로

적용된다.

따라서 관리자는 WEBMain.xml에 “default”와 “forced” 요청 인코딩을 정의할 수 있다. default와 forced

를 동시에 설정하는 것은 의미가 없으므로 하나만 설정하도록 한다.

● Request encoding

– HTTP Request header의 query string,쿠키 및 postdata에 사용되는 인코딩이다. 이 인코딩은 jeus-

web-dd.xml에서도 설정이 가능하며 jeus-web-dd.xml의 설정이 우선적으로 적용된다.

– Request 인코딩은 다음의 순서에 따라 결정된다.

1. 애플리케이션(Servlet/JSP)에서의 설정

(request.setCharacterEncoding()으로 설정한 인코딩)


3. HTTP요청의 Content-Type의 charset에 의한 인코딩

4. HTTP header의 “Accept-Language” 필드 값에 해당하는 인코딩

5. WEBMain.xml에 정의된 “default”인코딩



이 적용되는 식으로 순차적으로 우선순위를 갖게 된다.

– 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” 값을 설정하고 웹 컨테이너의 응답에 어떤 인코딩을 사용


할지 결정한다. 이 인코딩도 역시 jeus-web-dd.xml에서도 설정이 가능하며 jeus-web-dd.xml의 설정

이 우선적으로 적용된다.

– Response encoding은 다음의 우선순위 목록에 따라 결정된다.


2. Servlet에서의 설정(Servlet에서는 response.setContentType (”text/html;charset=XXX”), JSP에서

는 <%@ page contentType=”text/html;charset=XXX”%>로 프로그래머가 설정한 XXX 값의 인코

딩)

3. WEBMain.xml에 정의된 “default” 인코딩



이 적용되는 식으로 순차적으로 우선순위를 갖게 된다.

위의 내용처럼 관리자는 WEBMain.xml에 “default”와 “forced” response encoding을 정의할 수 있다.

다음은 Context Group에서 인코딩을 설정한 예로 WEBMain.xml에 <request url-encoding>, <request-

encoding>, <response-encoding> 태그를 이용하여 설정할 수 있다.

[예 3.3] Context Group 인코딩 설정 : <<WEBMain.xml>>



. . .

<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”로 설정 가능하다. 전자는 어떤 인코딩도 없을 경우에 기본 값으로 사용하

고 후자는 모든 경우에 항상 강제적으로 사용하도록 한다.


다음 목록은 Servlet/JSP 프로그래머나 JEUS 관리자가 WEBMain.xml에 흔히 설정할 수 있는 인코딩 값

들이다.

● ISO-8859-1(웹 컨테이너에서 기본으로 사용하고 있는 인코딩, ISO Latin)

● UTF-8(UCS 변환 포맷)

● EUC-KR(한국어)

● EUC-JP(일본어)

3.3.3. 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> 태그 내의 <jsp-

engine>에 설정한다.

[예 3.4] JSP 엔진 설정 : <<WEBMain.xml>>



. . .

<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>



● <java-compiler>, <compile-output-dir>, <compiler-option>, <compiler-encoding>

– Java compiler options으로 JSP에서 생성된 java 소스코드를 Servlet 클래스 파일로 컴파일할 때 필요

한 컴파일러를 설정한다.

– 다음과 같은 옵션을 포함한다.

설명항목

java compiler 실행 명령어이다. 예) “javac”<java-compiler>

JSP에서 생성된 클래스 파일의 위치이다.<compile-output-dir>

java compiler 실행 옵션이다. 예) “-verbose –g:none”<compiler-option>

이 설정은 웹 컨테이너가 적당한 인코딩을 알아서 지정하므로 많이 사용되지

않는다. 예) “UTF8”

<compiler-encoding>

● <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.3.4. 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


Context Group에 관련하여 마지막으로 설정할 수 있는 것은 Logging이다. 여기에는 2가지 종류의 Logging

메시지가 있다.

설명Logging 메시지

ServletContext.log() 메소드 호출로 Servlet 프로그래머에 의해 지정된 Logging 데이

터이다.

User 메시지

Context Group과 그 Context의 모든 클라이언트 요청을 레코딩한다.Access 로그

이 설정들은 WEBMain.xml의 <context-group><logging> 태그의 각기 다른 태그(<user-log>, <access-log>)

로 설정된다.

공통 설정 항목, Access log 및 User log 관련 설정 항목에 대한 설명은 각각 “2.4.1. 공통 설정 항목”, “2.4.2.

Access log 관련 설정 항목”, “2.4.3. User log 관련 설정 항목”을 참고한다.

3.3.5. Session 설정

Context Group에 Session 관련 설정을 할 수 있다. 이 설정은 웹 컨테이너에서 설정한 것과 동일하다. 다

만 Context Group에서의 설정은 웹 컨테이너에서의 설정보다 높은 우선순위를 가지고 적용된다. 자세한

내용은 “2.3.7. Session”을 참고한다.

다음은 Context Group 레벨에서 Session을 설정한 예이다.

[예 3.5] Context Group 레벨에서 Session 설정 : <<WEBMain.xml>>



. . .

<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>

. . .


</context-group>

. . .

</web-container>

3.3.6. Response Header 설정

사용자 임의의 HTTP Response Header를 이름과 값의 짝으로 정의할 수 있다.

Custom Response Header는 각 Context Group 하위의 <response-header><custom-header> 태그에

설정된다. 이 태그가 존재하면 다음의 두 항목과 함께 복수 개의 <header-field> 태그가 포함 될 수 있다.

다음은 Response Header 설정을 한 예이다.

[예 3.6] Response Header 설정 : <<WEBMain.xml>>



. . .

<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>

설명태그

<custom header> 필드의 이름을 지정한다.<field-name>

<field name>과 함께 전달될 값을 지정한다.<field-value>


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에 대한

정보를 조회할 수 있다.

3.5. Context Group 튜닝Context Group의 최적화된 성능을 주기 위해서는 다음의 2가지를 반드시 고려해야 한다.

● 일반적으로 JSP 엔진의 컴파일러는 변경 할 필요가 없다. “sun.tools.javac” 설정으로 그대로 유지하여

또 다른 외부 프로세스가 JSP 페이지를 컴파일할 때 필요하지 않도록 한다.

● <check-included-jspfile>는 include된 JSP들이 자주 변경되지 않는다면 설정을 “false”로 그대로 유지한

다. 이것은 include 된 JSP 파일들에 대한 변경 점검을 하지 않기 때문에 성능 향상에 도움이 된다.

● 모든 종류의 로그는 성능 향상을 위하여 다음의 설정을 사용한다.

– "fatal" 로그 레벨과 “file” 타겟

– 큰 버퍼 사이즈


제4장 웹 서버 연결과 클러스터링

본 장에서는 웹 컨테이너의 앞 단에서 사용할 수 있는 1개 이상의 웹 서버를 설정할 때 알아야 할 사항들

과 자체적으로 가지고 있는 웹 서버를 최대한 이용하는 방법에 대하여 설명한다.

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

4.2. 웹 서버 연결본 절에서는 웹 컨테이너, 웹 서버, 클라이언트 간의 기본적인 구조를 설명하고 웹 컨테이너와 연결할 수

있는 여러 종류의 웹 서버 리스너들에 대하여 설명한다.

다음은 웹 서버 연결에 관련된 웹 컨테이너의 주요 부분을 보여주고 있다.

[그림 4.1] JEUS 웹 컨테이너 중 웹 서버 연결 부분 컴포넌트

Client A

JEUS Web Container

Session

handling

settings

Misc. container

settings

Monitoring

threadWeb Server A


Context Group B

Web server

connection/list

ener

Misc. context

group settings

Virtual Host B

Context/Web

app C


Context/Web

app D

Context Group A

Web server

connection/list

ener

Misc. context

group settings

Virtual Host A

Context/Web

app A


Context/Web

app B

Client B

4.2.1. 리스너

우선 “리스너”가 어떤 의미를 가지고 있는지에 대하여 분명히 이해해야 한다.

리스너는 일반적으로 웹 서버나 HTTP 클라이언트가 직접 접근 할 수 있는 웹 컨테이너 측의 소켓이라고

생각할 수 있다. 이 리스너(소켓)는 웹 서버(또는 HTTP 클라이언트)로부터 요청을 받고 웹 컨테이너에서

처리한 static 또는 dynamic content를 반환한다. dynamic content는 JSP 나 Servlet과 같은 Java 기반의

콘텐츠를 의미하고 static content는 HTML 페이지나 이미지 파일과 같은 이미 생성된 데이터를 의미한다.

리스너에는 2가지 종류가 존재한다.

[그림 4.2] 웹 컨테이너의 웹 서버와 클라이언트 리스너

JEUS Node A

Web Container A

Context Group A

Client B

Web Server Listener A

Context Group B

Client (HTTP) Listener A

Web Server A

Client A

HTTP protocol

HTTP protocol

Custom protocol

Port 9900

Port 8088

Port 80


● 웹 서버 리스너

외부의 웹 서버들과 연결되고 이들과 통신을 위해서 맞춤 프로토콜을 사용한다. 클라이언트는 이 웹 서

버를 통하여 웹 컨테이너와 통신한다.

● 클라이언트 리스너

주로 클라이언트와 직접 연결되고 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.3. 리스너 설정”과 “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 통신을 함으로


써 월등한 성능 향상을 기대할 수 있다. Pipe 통신은 UNIX(LINUX) 계열의 장비에만 사용이 가능하다

(Windows 계열의 장비에는 일반 소켓만 사용 가능하다).

“4.3. 리스너 설정”과 “4.4. 리스너 연동과 클러스터링을 위한 웹 서버 설정”에서 자세히 설명한다.

참고

JEUS 내부적으로 제공하는 WS 엔진은 노드당 하나만을 사용할 수 있다.

Ajp13 리스너

위에서 언급한 WebtoB 이외의 다른 웹 서버, 예를 들면 Apache, IIS, SunOne(Iplanet)등을 사용할 경우에

도 JEUS 웹 애플리케이션과의 상호 연동이 가능하도록 해주는 프로토콜이다. mod_jk module을 통해 지

원을 하며 AJP1.3 프로토콜을 사용한다.

“4.3. 리스너 설정”과 “4.4. 리스너 연동과 클러스터링을 위한 웹 서버 설정”에서 자세히 설명한다.

Tmax 리스너

Tmax는 분산 환경에서 이질적인 자원을 통합해 주는 시스템 소프트웨어이다.

Tmax 리스너는 Tmax와 연동하기 위한 특수한 리스너로 WebtoB 리스너와 마찬가지로 활동적인 리스너

이기 때문에 웹 컨테이너를 구동시키기 전에 Tmax가 먼저 구동되어 있어야 한다. Tmax 리스너는 JEUS

와 Tmax 간의 정보를 주고받거나, http 요청을 Tmax의 게이트웨이를 통해 받음으로써 통신 채널을 일원

화 하는 등의 용도로 사용될 수 있다.

4.2.2. 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의 일정한 사양도 같이 설정해야 한다.

4.2.3. Thread Pool의 Active-Management와 상태 통보

각 리스너에 설정되는 Thread Pool은 Active-Management에 관한 설정도 포함되어 있다.


Active-Management는 관리자가 설정된 상태가 되면 웹 컨테이너가 경고성 e-mail 통지하거나 웹 컨테이

너가 자동으로 재시작하도록 설정할 수 있다.

설정되어야 할 조건은 Servlet Worker Thread가 Block되었다고 판단하는 기준 시간에 대한 설정이며, 설

정한 시간에 따라가 Servlet Worker Thread가 Block되었다고 판단을 한다. 경고 e-mail 통보 또는 컨테이

너 재시작같은 특정 작업이 시작되기 전에 몇 개까지의 Block된 Thread들이 존재할 수 있는지를 설정한

다.

주의

재시작 옵션은 임시적인 해결책이고, 재시작이 발생할 경우에는 관리자가 원인을 찾아 반드시 문제

를 해결해야 한다. 그리고 Active-Management 기능을 설정할 때 너무 자주 발생하지 않도록 유의해

야 한다.

4.2.4. 여러 개의 웹 컨테이너와 웹 서버 클러스터링

여러 개의 웹 서버와 리스너들을 연결시키는 것을 클러스터링이라 하고 이 과정에서 생성된 조직체를 클

러스터라고 한다. 거대한 사이트에서는 많은 양의 클라이언트 요청을 처리하기 위하여 “부하 분산”이라는

기술과 함께 반드시 사용되어야 하는 기술이다.

부하 분산은 기본적으로 클러스터 내의 어떤 서버에게 요청을 처리하도록 지정할 것인지를 정의하여 클

러스터 내의 서버들에게 골고루 요청이 전달되어 처리되도록 한다. 부하 분산기는 모든 클라이언트 요청

을 받아 그 순간 가장 여유로운 웹 서버에게 지정해 주는 소프트웨어이다.

다음은 2개의 웹 서버(WebtoB 또는 Apache)가 각각 2개의 웹 컨테이너에 연결되어 있는 작은 클러스터

구조를 보여주고 있다.

[그림 4.3] 2개의 웹 서버가 2개의 웹 컨테이너에 각각 연결되어 있는 작은 클러스터

JEUS Node A

Web Container A

JEUS Node B

Web Container B

Context Group A

JEUS Node C

JEUS Node D

Context Group B

Web Server B

Web Server A

Lo

ad

Ba

lan

ce

r

ClientRequests

Web Server Listener B

Web Server Listener A

Web Container C

Context Group C

Web Server Listener C

Web Container D

Context Group D

Web Server Listener D


참고

위 그림과 같은 설정은 각 웹 컨테이너에 동일한 Context Group 과 Context를 가지고 있어야 한다(즉,

Context A, B, C, D는 모두 같은 것이어야 한다).

또한, 웹 서버와 리스너의 연동과 클러스터링에서 중요한 것은 클라이언트 Session을 어떻게 Tracking하

는지에 대한 것이다. 클라이언트 Session 데이터가 여러 개의 웹 컨테이너(Context)에 정확하게 분배되는

지에 대한 사항은 클러스터 규모가 커질수록 더 중요해 진다. 이 중요한 사항에 대해서는 “제5장 Session

Tracking”에서 설명한다. 본 장에서는 Session 데이터의 존재에 대하여 무시하고 진행한다.

이러한 웹 서버 클러스터를 실제로 어떻게 설정하는지에 대하여 본 장의 “4.4. 리스너 연동과 클러스터링

을 위한 웹 서버 설정”에서 자세히 설명한다.

4.3. 리스너 설정리스너를 설정하는 작업은 매우 간단하다. 그러나, 웹 서버 리스너를 실제 웹 서버(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>>



. . .

<context-group>

. . .


<webtob-listener>

. . .

</webtob-listener>

<http-listener>


. . .

</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>

. . .


. . .

</context-group>

. . .

</web-container>

4.3.1. 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>>



. . .

<context-group>

. . .


<http-listener>


<listener-id>WebListener1</listener-id>

<ip>190.0.1.2</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>

. . . 

</thread-state-notify>

</thread-pool>

<postdata-read-timeout>

40000

</postdata-read-timeout>

<scheme>http</scheme>

<back-log>100</back-log>

<server-access-control>

true

</server-access-control>

<allowed-server>127.0.0.1</allowed-server>

</http-listener>


. . .

</context-group>

. . .

</web-container>

위 태그들의 하위 태그(설정)들은 다음과 같다.

● <listener-id>

– 리스너의 유일한 식별자이다. 이름은 WEBMain.xml 파일 내부에서 유일한 것이어야 한다.

● <ip>

– 클라이언트가 연결되어 있는 IP 주소이다. 보통의 경우에는 이 설정을 하지 않아도 머신의 IP 주소가

사용되므로 설정할 필요가 없고, IP 주소가 2개 이상이어서 그 중 하나를 지정해야 하는 등의 특별한

경우에만 설정한다.

– HTTP 리스너에서 설정 가능한 태그이다.

● <port>

– 클라이언트가 연결되어 있는 포트 번호이다.

– HTTP를 위해서는 기본적으로 80번을 사용하고 SSL을 위해서는 443을 사용한다.

(IANA, http://www.iana.org/에서 정의)

– JEUS 설정에서는 어떤 포트도 기본으로 설정되어 있지 않으므로 이 태그는 모든 리스너에서 반드시

지정해야 한다.

● <output-buffer-size>

– Servlet 결과가 임시적으로 저장되는 내부 Cache 버퍼의 크기를 결정한다. 버퍼가 가득 찼을 때에는

한 번에 클라이언트에게 모두 보내진다.

– 이 옵션은 성능 향상을 위해 사용되지만 일반적으로 사용되지 않는다.

● <thread-pool>

– 각 리스너의 Worker Thread Pool의 크기와 행동 방식을 결정짓는다.

Worker Thread가 클라이언트 요청을 처리하기 위해서 사용되며 Pool 크기가 크면 클수록 더 많은 요

청이 동시에 처리될 수 있다(시스템 리소스를 많이 사용한다).

– 다음의 하위 태그를 이용해서 Thread Pool 정보를 설정한다.

설명태그

Pool에서 관리할 최소 및 최대 Worker Thread의 개수이다.<min>, <max>

Pool의 크기가 증가할 때 Thread가 몇 개씩 증가할 것인지를 지정한다.<step>

Pool 내에 존재하던 Thread가 제거되기 전까지의 사용되고 있지 않은 시간

을 지정한다(결과로 시스템 자원은 늘어난다).

<maximum-idle-time>

각 Worker Thread Pool은 request wait queue를 가지고 있다. 이 Queue는 실

제 가용한 Worker Thread보다 많은 요청이 들어 올 때 사용된다. 이 Queue

는 소켓 리스너에 의해 유지되는 낮은 레벨의 Backlog Queue보다 상위 레벨

의 Queue이다. 다음의 두 태그는 이 Queue와 관련된 것들이다.

더 많은 Worker Thread가 Pool에 생성되기 전에 얼마나 많은 요청들이 Re

quest Wait Queue에 존재할 수 있는지에 대해 결정한다(몇 개의 Thread가

증가될지는 step 설정에서 정의된다).

<max-wait-queue>

단, NIO(Non-blocking I/O) 방식의 리스너에서는 이 설정값은 무시된다.

설정은 Queue에 대기할 수 있는 최대 요청 값을 설정한다.<max-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을 사용한다.


http://www.iana.org/

참고

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 수보다 작을 수 밖에 없는 문제점을 해

결할 수 있다.


● <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 리스너 사용”을 참고한다.

4.3.2. WebtoB 리스너 설정

WebtoB 리스너는 다른 종류의 리스너와는 다르다. 그래서 본 절에서 그 차이점에 대해 별도로 설명한다.

다음은 WebtoB 리스너 설정의 예로 WEBMain.xml 파일 내 <webserver-connection>의 <webtob-listener>

태그에서 설정한다.

[예 4.3] WebtoB 리스너 설정 : <<WEBMain.xml>>



. . .

<context-group>

. . .


<webtob-listener>


<port>9900</port>


<thread-pool>

<min>10</min>

<max>10</max>

<step>4</step>




<max-thread-active-time>

150000

</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-pool>


40000



<hth-count>2</hth-count>

<request-prefetch>true</request- prefetch>

<disable-pipe>false</disable-pipe>

<webtob-address>

111.111.111.111

</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>

16384

</output-buffer-size>

<thread-pool>

. . .

</thread-pool>

. . .

<webtob-address>

111.111.111.112

</webtob-address>

. . .

</webtob-backup>

</webtob-listener>


. . .

</context-group>


. . .

</web-container>


설명태그

“4.3.1. HTTP, TCP, HTTPS 리스너 설정”에서 설명한 유일한 이름이다.<listener-id>

WebtoB 서버와 연결할 포트로, 포트 값은 WebtoB 설정 파일 내의 JSVPORT

설정 값과 일치해야 한다.

<port>

“4.3.1. HTTP, TCP, HTTPS 리스너 설정”에서 설명한 것과 같다.<output-buffer-size>

“4.3.1. HTTP, TCP, HTTPS 리스너 설정”에서 설명한 것과 같다.<thread-pool>

WebtoB에서 다른 점은 <min>, <max> 값이 WebtoB 설정 파일의 *SERVER

절에 지정된 MinProc, MaxProc 값과 일치해야 한다.

<min>과 <max> 값을 설정하기 전에 “4.4. 리스너 연동과 클러스터링을 위한

웹 서버 설정”을 먼저 읽어 보길 바란다. 또한, <max-queue> 크기 설정은 사

용하지 않지만 WebtoB 설정 파일에서 MaxQCount 값으로 설정될 수 있다.

“4.3.1. HTTP, TCP, HTTPS 리스너 설정”을 참고한다.<postdata-read-timeout>

“4.3.1. HTTP, TCP, HTTPS 리스너 설정”을 참고한다.<scheme>

WebtoB 설정 파일의 *NODE 절에 지정된 HTH 프로세스 개수와 일치해야

한다. “4.4. 리스너 연동과 클러스터링을 위한 웹 서버 설정”을 참조한다.

<hth-count>

웹 컨테이너 측에서 요청을 처리하는 동안 다음 요청을 WebtoB로부터 미리

받아올 것인지 정한다(Boolean값).

<request-prefetch>

기능이 활성화되면, 웹 컨테이너는 각 WebtoB Worker Thread 마다 하나의

Queue를 할당한다.

Queue는 Worker Thread가 현재 요청을 처리하는 동안 WebtoB로 부터오는

요청을 버퍼링한다. 따라서 웹 컨테이너는 WebtoB로부터 다음 요청을 받는

시간을 단축할 수 있다. 이 기능의 단점은 요청을 처리하는 도중 웹 컨테이너

에 심각한 문제가 발생하면, Queue에 축적된 요청들을 잃어버릴 수 있다는

점이다.

설정이 "true"로 설정되어 있으면 WebtoB와 웹 컨테이너의 효율적인 Pipe 통

신을 불가능하게 한다. WebtoB 서버와 웹 컨테이너가 다른 머신에서 수행되

고 있으면 필요한 항목이다.

<disable-pipe>

웹 컨테이너와 연결을 맺을 WebtoB의 IP 주소 항목이다.<webtob-address>

WebtoB 설정 파일의 *SERVER 값과 일치해야 한다. 설정하지 않은 경우 기

본값으로 이 값은 Context Group의 이름과 같은 값으로 설정된다.

<registration-id>

JEUS_WSDIR이라는 환경변수로 정의된 WebtoB의 기본 WebtoB Home과

다를 경우에 설정한다(또는 그 환경변수가 설정되어 있지 않을 때).

<webtob-home>


설명태그

2개 이상의 WebtoB 인스턴스가 로컬 머신에서 운영되고 있고 웹 컨테이너가

이 2개 이상의 WebtoB 인스턴스에 연결될 필요가 있을 때 유용하다.

WebtoB 웹 서버는 지속적으로 웹 컨테이너에게 WebtoB의 설정 파일에 정의

된 “svrchktime” 변수 값의 간격으로 “ping”메시지를 보낸다.

<read-timeout>

웹 컨테이너는 여기에서 정의한 시간 간격으로 WebtoB의 ping을 체크한다.

WebtoB의 ping이 여기에서 설정된 시간 간격 내에서 발견되지 않으면 통신

연결은 끊어진 것으로 간주되어 다시 설정된다.

그러므로, 여기의 값은 “svrchktime”보다 커야 한다.

WebtoB 서버와 WebtoB 리스너 사이의 연결들이 운영도중 끊어지는 경우가

발생할 수 있다. reconnect-timeout은 이러한 경우에 재연결 시도를 위한 제

한시간이다.

<reconnect-timeout>

제한된 시간이 지나면 현재의 모든 WebtoB 연결은 끊어지고, 만약 WebtoB

백업이 지정되어 있으면 웹 컨테이너는 다음 WebtoB 서버에 Fail-over를 시

도한다. 다음 WebtoB 백업마저 장애가 발생한다면 그 다음의 것을 시도한다.

최후의 WebtoB 마저 장애가 발생하면 주 WebtoB 리스너에 시도하게 된다.

“-1”은 무한대 반복 시도, “0”은 재연결 시도를 하지 않음을 의미한다.

WebtoB 리스너의 설정과 비슷하다.<webtob-backup>

하지만 WebtoB backup 태그는 Automatic Connection Recovery기능을 수행

하기 위해서 주 서버가 심각한 장애 상태가 되었을 때, 두 번째 WebtoB 서버

에 연결하기 위한 연결 정보를 정의한다. 따라서 Backup WebtoB의 설정은

Main WebtoB 장애가 발생하면 Backup WebtoB로 연결하기 때문에 무장애

시스템 구현을 가능하게 한다.

여기서 주의할 것은 백업 서버에 Thread Pool에 대한 설정이 없다면 주 WebtoB

리스너의 설정에서 상속 받는다는 것이다.

참고

“4.4.4. WebtoB 웹 서버 설정과 클러스터링”에서는 어떻게 실제의 WebtoB 서버가 설정되어 이 리스

너에게 연결되는지 설명한다. 또한 리스너 설정과 WebtoB의 설정 파일 간의 관계도 설명한다.

4.3.3. AJP13 리스너 설정

AJP13 리스너는 WEBMain.xml 파일 내 <webserver-connection> 태그 아래의 <ajp13-listener> 태그에

서 설정한다.

다음은 AJP13 리스너의 XML 설정 예이다.


[예 4.4] AJP13 리스너 설정 : <<WEBMain.xml>>



. . .

<context-group>

. . .


<ajp13-listener>


<port>9901</port>


<thread-pool>

<min>10</min>

<max>10</max>

</thread-pool>

</ajp13-listener>


. . .

</context-group>

. . .

</web-container>


설명태그


클라이언트가 연결되어 있는 IP 주소이다. 보통의 경우에는 이 설정을 하지

않아도 머신의 IP 주소가 사용되므로 설정할 필요가 없고, IP 주소가 2개 이

<ip>

상이어서 그 중 하나를 지정해야 하는 등의 특별한 경우에만 설정한다. AJP13

리스너에서 설정 가능한 태그이다.

특정 웹 서버와 연결할 포트를 설정한다. 이 값은 특정 웹 서버 설정 파일내의

JEUS에 해당하는 서버에 대한 설정 값과 일치해야 한다. 특정 웹 서버 설정

<port>

과 관련된 사항은 “4.4. 리스너 연동과 클러스터링을 위한 웹 서버 설정”을 참

고한다.


다만 AJP13 리스너의 경우 이 설정 값을 mod_jk module의 workers.properties

파일의 max_packet_size와 일치시킨다. mod_jk module의 설정에 대해서는

“4.4. 리스너 연동과 클러스터링을 위한 웹 서버 설정”을 참고한다.

“4.3.1. HTTP, TCP, HTTPS 리스너 설정”에서 설명한 것과 같다. 다만 AJP13

리스너의 경우 min, max 값을 서로 다르게 줄 특별한 이유가 없다.

<thread-pool>


설명태그

특별한 상황이 아닌이상 min, max를 일치시킨 후 이 값을 mod_jk module의

workers.properties 파일의 connection_pool_size, connec

tion_pool_size_min_size와 일치시킨다.

mod_jk module의 설정에 대해서는 “4.4. 리스너 연동과 클러스터링을 위한

웹 서버 설정”을 참고한다.

“4.3.1. HTTP, TCP, HTTPS 리스너 설정”에서 설명한 것과 같다.<postdata-read-timeout>

4.3.4. Tmax 리스너 설정

각 Tmax 리스너는 WEBMain.xml 파일 내 <webserver-connection> 태그 아래의 <tmax-listener> 태그

에서 설정한다.

다음은 Tmax 리스너의 XML 설정예이다.

[예 4.5] Tmax 리스너 설정 : <<WEBMain.xml>>



. . .

<context-group>

. . .


<tmax-listener>


<port>9902</port>


<thread-pool>

<min>10</min>

<max>10</max>

<step>4</step>





150000


<notify-threshold>100</notify-threshold>

<restart-threshold>

18


<notify-subject>


</notify-subject>

<restart-subject>



</restart-subject>


</thread-pool>


40000


<tmax-address>111.111.111.111</tmax-address>

<reconnect-timeout>60000</reconnect-time>

<server-group-name>TmaxGroup</server-group-name>

<server-name>SVR1</server-name>

<tmax-backup-address>

111.111.111.112

</tmax-backup-address>

<tmax-backup-port>9902</tmax-backup-port>

</tmax-listener>


. . .

</context-group>

. . .

</web-container>


설명태그


Tmax 서버와 연결할 포트로, 이 포트 값은 Tmax 설정 파일내의 JEUS에 해

당하는 서버에 대한 설정 값과 일치해야 한다.

<port>


“4.3.1. HTTP, TCP, HTTPS 리스너 설정”에서 설명한 것과 같다. Tmax 리스

너의 경우도 WebtoB 리스너와 동일하게 동작한다.

<thread-pool>

“4.3.1. HTTP, TCP, HTTPS 리스너 설정”에서 설명한 것과 같다.<postdata-read-timeout>

웹 컨테이너와 연결을 맺을 Tmax 서버의 IP 주소 항목이다.<tmax-address>

Tmax 서버와 Tmax 리스너 사이의 연결 중 일부가 운영도중 끊어질 경우가

생길 수 있다. <reconnect-timeout>은 이러한 경우에 재연결 시도를 위한 제

<reconnect-timeout>

한 시간이다. 역시 WebtoB와 동일하나 Tmax 리스너의 경우는 Backup을 하

나만 설정할 수 있다는 것이 차이점이다.

Tmax 리스너를 설정하여 Tmax와 연결할 때에 Tmax에 어떤 서버와 연결할

것인지를 설정해야 한다. <server-group-name>은 연결할 서버가 속해 있는

그룹을 설정한다. 이 설정은 반드시 해야 하는 설정이다.

<server-group-name>

실제로 Tmax 리스너가 연결할 Tmax의 서버 이름을 설정한다. 이 설정은 반

드시 해야 하는 설정이다.

<server-name>


설명태그

Tmax 서버에 장애가 발생했을 때 backup으로 동작하는 서버의 주소이다.

WebtoB Backup Server 설정과 동일하나 Tmax 리스너의 경우는 주소와 포

트만 설정하고 나머지는 primary server의 설정을 그대로 가져간다.

<tmax-backup-address>

Tmax 서버에 장애가 발생했을 때 backup으로 동작하는 서버에 연결할 포트

번호를 설정한다. tmax-backup-address가 설정되어 있다면 tmax-backup -

port도 함께 설정되어야 한다.

<tmax-backup-port>

true로 할 경우 NIO(Non-blocking I/O) Tmax 리스너로 동작하게 된다.<use-nio>

NIO 방식을 사용하면 커넥션을 담당하는 Thread와 Worker Thread가 분리되

어 있어서 기존 방식에서 동시에 처리할 수 있는 커넥션 개수가 Worker Thread

수보다 작을 수 밖에 없는 문제점을 해결할 수 있다.

설정하지 않았을 경우 기본값을 false이다.

NIO를 사용할 때(use-nio=true) Selector의 개수를 지정하는 설정이다.<selector-count>

기본으로 1개로 설정이 되며 커넥션의 개수가 많아 성능이 저하될 경우 Se

lector 개수를 적절히 증가시켜 주면 성능이 향상될 수 있다.

4.3.5. 자동 Thread Pool 관리 설정(Thread 상태 통보)

<thread-state-notify> 태그는 e-mail 통지나 자동 재시작의 실행을 위해 필요한 최소의 Worker Thread 수

와 관련된 “오류” 조건을 정의한다.

다음은 e-mail 알림자를 포함하고 있는 설정 예이다. <thread-state-notify> 태그는 웹 서버 리스너의

<thread-pool> 태그 아래에 설정된다.

[예 4.6] 자동 Thread Pool 관리 설정 : <<WEBMain.xml>>



. . .

<context-group>

. . .


<http-listener>


<port>8007</port>


<thread-pool>

<min>10</min>

<max>20</max>

<step>2</step>




<max-queue>50</max-queue>



150000


<notify-threshold>100</notify-threshold>

<restart-threshold>

18


<notify-subject>


</notify-subject>

<restart-subject>


</restart-subject>

<thread-interrupt-execution>

true

</thread-interrupt-execution>

<restart-engine-execution>

true

</restart-engine-execution>

<active-timeout-notificatio>

true

</active-timeout-notificatio>


</thread-pool>


40000





true

</server-access-control>

<allowed-server>127.0.0.1</allowed-server>

</http-listener>


. . .

</context-group>

. . .

</web-container>


다음과 같은 항목들이 반드시 설정되어야 한다.

설명태그

Block되기 전까지 Worker Thread가 사용될 수 있는 최대시간 값을 말한다.<max thread active time>

이 시간은 Worker Thread가 클라이언트 요청을 서비스할 때부터 측정된다

(Servlet이 수행될 때). 여기서 정한 시간이 초과되었거나 또는 thread가 자유

롭게 되어 worker Pool로 되돌아 갈 때 만료된다(thread가 Block되지 않는 상

황). 설정 값이 0이거나 음수이면 무시된다.

존재할 수 있는 Block된 Thread의 최대 비율을 설정한다. 전체 thread 개수

대비 Block된 Thread의 비율이 초과되면, 오류 조건으로 결정되어 e-mail 알

림자를 통하여 e-mail 통보가 전송된다.

<notify-threshold-ratio>

1보다 작은 소숫점으로 설정하며 0이거나 음수이면 무시된다.

존재할 수 있는 Block된 Thread의 최대 비율을 설정한다. 전체 thread 개수

대비 Block된 Thread의 비율이 초과되면, 오류 조건으로 결정되어 e-mail 알

<restart-threshold-ratio>

림자를 통하여 e-mail 통보가 전송된다. 그 후에 restart-engine-execution에

의해 웹 컨테이너가 재시작될 수 있다.

1보다 작은 소숫점으로 설정하며 0이거나 음수이면 이 설정이 무시된다.

경고 e-mail을 전송할 때 사용된다.<notify-subject>

컨테이너 로그 및 통보할 때 사용하는 e-mail에 사용된다.<restart-subject>

active-timeout 발생할 때 해당 Thread의 interrupt 발생 유무를 결정한다. true

인 경우 interrupt를 발생시키며, 기본값은 false이다.

<thread-interrupt-execu

tion>

thread 비율이 <restart-threshod-ratio>를 넘어선 경우 해당 엔진의 재시작 여

부를 결정한다.

<restart-engine-execu

tion>

true인 경우 엔진이 재시작되며, 기본값은 false이다.

active-timeout 발생이 email notificatin 유무를 결정한다.<active-timeout-notifica

tion> true인 경우 e-mail 전송이 이루어지며, 기본값은 false이다.

4.4. 리스너 연동과 클러스터링을 위한 웹 서버 설정본 절에서는 어떻게 여러 웹 서버를 설정하여 해당 리스너와 연동할 수 있는지에 대해 설명한다.

여러 개의 웹 서버와 리스너들이 서로 연결되어 클러스터를 형성하는 상황 및 설정하는 방법에 대해 살펴

보도록 하겠다. 클러스터링에 대한 자세한 내용은 “4.2.4. 여러 개의 웹 컨테이너와 웹 서버 클러스터링”,

Session이 어떻게 관리되는지에 대한 설명은 “제5장 Session Tracking”을 참고한다.


4.4.1. Apache 웹 서버 설정과 클러스터링

Apache 웹 서버를 웹 컨테이너 앞단에서 사용하기 전에 다음과 같은 과정이 선행되어야 한다.

1. 컨테이너 리스너와 Apache Server 간의 통신을 위하여 mod_jk 라이브러리를 설치한다.

2. WEBMain.xml에서 AJP13 리스너를 설정한다. (“4.3.3. AJP13 리스너 설정” 참조)

3. workers.properties 파일을 생성하고 편집한다.

4. Apache 웹 서버의 httpd.conf 파일에 연동 구절을 삽입한다.

5. Apache 웹 서버를 재시작한다.

참고

Apache의 경우 Apache HTTP Server 2.2.4, mod_jk의 경우 1.2.20을 기준으로 설명한다.

mod_jk 라이브러리 설치하기

Apache 웹 서버를 웹 컨테이너의 앞 단에서 사용하기 위해서는 “mod_jk”라는 모듈을 Apache 설치 모듈

에 추가해야 한다. “mod_jk” 모듈은 서버와 컨테이너 간의 통신 프로토콜을 구현한 것이다. 이 프로토콜은

Apache JServ Protocol 1.3(AJP 1.3)이다.

다음의 URL을 통해 해당 binary를 down받을 수 있으며 적절한 위치에 복사한다.

http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/

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>>



. . .

<context-group>

. . .





<ajp13-listener>


<port>9901</port>


<thread-pool>

<min>10</min>

<max>10</max>

</thread-pool>

</ajp13-listener>


. . .

</context-group>

. . .

</web-container>

위의 예에서는 9901번 포트가 설정되어 있고 output-buffer-size는 16384 bytes, Thread Pool은 10개로 설

정되어 있다. 이 값들은 다음의 workers.properties 설정과 같아야 한다.

workers.properties 설정

workers.properties 파일은 mod_jk module을 위한 설정 파일이며, AJP13 프로토콜을 사용할 때 가장 중

요한 설정이다.

mod_jk module에는 여러 버전이 존재하나 현 시점에서 가장 최신 버젼인 1.2.20을 기준으로 설명한다. 먼

저 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


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.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으로 정의한다.


● 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 주소를 입력한다.



"johan_servlet_engine1" worker는 <host_name>이 johan이다.

● worker.<worker_name>.port

– JEUS의 AJP13 리스너의 포트 번호를 설정한다.



"johan_servlet_engine1" worker는 포트를 9901을 사용한다. 이는 johan_servlet_engine1에 해당하

는 WEBMain.xml의 AJP13 리스너의 포트와 동일한 값을 입력한 것이다.

● worker.<worker_name>.lbfactor

– load balancer worker에 해당하는 worker에만 의미가 있다. 해당 worker가 얼마나 많은 일을 할지를

정의하는 것으로 쉽게 worker의 priority를 지정한다고 생각해도 된다.


만약 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


– JEUS의 리스너와 mod_jk간의 커넥션을 cache하는 최소의 크기(size)를 의미한다.

– JEUS AJP13 리스너의 min, max 값과 일치시켜 설정한다.

(JEUS AJP13에서는 min, max를 동일한 값으로 설정할 것을 권장한다)

● worker.<worker_name>.max_packet_size

– 최대 크기의 AJP packet size를 byte단위로 설정한다. 최대 65536 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 리스너에서 동일하다고 가정한 것이다. 만약 다를 경우 해당 설정 값들을 재정의하여 사

용한다.


다음은 위의 예제에 항목 외의 의미있는 항목에 대한 설명들이다.

● 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

. . .

설명항목

위에서 down받은 mod_jk.so를 Apache 웹 서버에 load한다. mod_jk.so의 경우

"c:/ajp13/lib"위치에 저장하였다고 가정하였다.

LoadModule

workers.properties파일이 위치한 경로를 지정한다. 위에서 작성한 workers.prop

erties의 경우 "c:/ajp13/conf"위치에 저장하였다고 가정하였다.

JkWorkersFile

로그 파일들이 남을 경로를 지정한다. 로그들은 "c:/log"위치에 "mod_jk.log"란

이름으로 저장할 것임을 설정하였다. 저장 로그 레벨은 "debug"로 하였다. "de

bug"이외에 "error", "info"등으로 설정 가능하다.

JkLogFile

로그를 저장할 때의 적절한 레벨을 설정한다. 저장 로그 레벨은 "debug"로 하였

다. "debug"이외에 "error", "info"등으로 설정 가능하다.

JkLogLevel

가장 중요한 설정으로, 어떤 URL요청이 들어 왔을때 어떤 worker로 분배할지를

선택한다. workers.properties에서 설정한 특정 worker를 지정하면 된다.

JkMount

여기서는 /examples의 하위 모든 요청을 workers.properties에서 설정한 load

balancer worker인 "jeus_load_balancer_workers"로 보낸다. "jeus_load_bal

ancer_workers"는 또 다른 4명의 다른 worker들로 구성되고 웹 서버로 요청이

들어오면 4명의 worker에게 적절히 load balance될 것이다.


4.4.2. IIS 웹 서버 설정과 클러스터링

IIS 웹 서버를 웹 컨테이너 앞단에서 사용하기 전에 다음의 과정이 선행되어야 한다.

1. 컨테이너 리스너와 IIS 웹 서버 간의 통신을 위하여 mod_jk 라이브러리(ISAPI Redirector)를 설치한다.

2. WEBMain.xml에서 AJP13 리스너를 설정한다(“4.3.3. AJP13 리스너 설정” 참조).


4. uriworkermap.properties 파일을 생성하고 편집한다.

5. IIS 웹 서버의 환경을 설정한다.

6. IIS 웹 서버를 재시작한다.

참고

IIS의 경우 IIS 6, mod_jk의 경우 1.2.20을 기준으로 설명한다.

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 설정

“4.4.1. Apache 웹 서버 설정과 클러스터링”의 "WEBMain.xml 설정 [69]"과 동일하다.


“4.4.1. Apache 웹 서버 설정과 클러스터링”의 "workers.properties 설정" [70]과 동일하다.




uriworkermap.properties 설정

uriworkermap.properties 설정은 매우 간단하다. 웹 서버로 들어온 요청들에 대해 URI 패턴을 검사하여

JEUS로 forwarding하는 rule mapping을 정의하는 설정 파일이며, 형식은 다음과 같다.

/<application_name>=<worker_name>

만약 /examples의 하위 모든 요청을 worker1에게 매핑하려면 "/examples/*=worker1"과 같이 설정한다.

“4.4.1. 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"


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"로 등록한 웹 서비스 확

장의 상태가 허용됨으로 되어 있음을 확인한다.

4.4.3. SunOne(Iplanet) 웹 서버 설정과 클러스터링

SunOne(Iplanet) 웹 서버를 웹 컨테이너 앞 단에서 사용하기 전에 다음과 같은 과정이 선행되어야 한다.

1. 컨테이너 리스너와 SunOne(Iplanet) 웹 서버 간의 통신을 위하여 mod_jk 라이브러리(NSAPI Redirector)

를 설치한다.

2. WEBMain.xml에서 AJP13 리스너를 설정한다(“4.3.3. AJP13 리스너 설정” 참조).


4. SunOne 웹 서버 설정(magnus.conf, obj.conf파일)을 수정한다.

5. SunOne 웹 서버를 재시작한다.

참고

SunOne(iplanet)의 경우 Sun ONE 웹 서버 6.1, mod_jk의 경우 1.2.20을 기준으로 설명한다.

mod_jk 라이브러리 설치하기

SunOne(Iplanet) 웹 서버를 웹 컨테이너의 앞 단에서 사용하기 위해서는 "nsapi_redirect"라는

SunOne(Iplanet) plugin을 SunOne(Iplanet) 웹 서버에 추가해야 한다.


"http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/"에서 Windows용 binary를 down받을

수 있으며 일반적으로 "nsapi_redirect.dll"를 이름으로 설정하여 사용한다.

참고

만약 위의 URL과 JEUS에서도 특정 OS의 적절한 binary를 구하지 못할 경우는 source code를 다운

받아 새로 컴파일해야 한다.

"nsapi_redirect.dll"이 "c:\ajp13"에 위치한다고 가정하고 이를 복사한다.

c:\ajp13\nsapi_redirect.dll

WEBMain.xml 설정

“4.4.1. Apache 웹 서버 설정과 클러스터링”의 "WEBMain.xml 설정 [69]"과 동일하다.


“4.4.1. 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.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>

. . .

4.4.4. WebtoB 웹 서버 설정과 클러스터링

본 절에서는 2개의 예를 통하여 간단한 WebtoB 클러스터 환경을 구성해 보겠다.

각 컨테이너가 각각의 WebtoB 서버를 가지는 간단한 평행 구조 설정과 각 Context Group과 컨테이너가

클러스터 내의 모든 WebtoB 서버와 연결되는 설정이다.

간단한 구성의 경우

첫 번째의 간단한 예에서는 2개의 WebtoB 서버가 각각 2개씩의 전용 웹 컨테이너에 각각 연결된다(총 4

개의 컨테이너). 다음은 간단한 평행 구조 설정을 표현한 그림이다.

[그림 4.4] 2개의 WebtoB 웹 서버가 2개의 웹 컨테이너와 연결된 경우

JEUS Node B

Web Container B

JEUS Node D

JEUS Node C

JEUS Node A

Context Group B

WebToB Server B

WebToB Server A

Third-party L

oad B

ala

ncer

ClientRequests

WebToB Listener B

Web Container A

Context Group A

WebToB Listener A

Web Container C

Context Group C

WebToB Listener C

Web Container D

Context Group D

WebToB Listener D

Session server (necessary).


따라서, 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에 연결된 경우

Load balancer JEUS Node B

Web Container B

JEUS Node A

WebToB Server A

HTH 1

HTH 2

MinProc = 6MaxProc =

25

MinProc = 6MaxProc =

25

HTH =2

Web Container A

Context Group A

Context Group B

WebToB Server Listener A

min threads = 2

max threads = 10

10

15

10

15

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 프로세스 개수와 동일해야 한다.


다음은 WebtoB 리스너 A와 B가 해당 WEBMain.xml에 어떻게 설정되어야 하는지에 대한 예이다.

[예 4.13] 웹 컨테이너 A : <<WEBMain.xml>>



. . .

<context-group>

. . .


<webtob-listener> 

<listener-id>WebListenerA</listener-id>

<port>9900</port>


<thread-pool>

<min>2</min>

<max>10</max>

<step>2</step>



</thread-pool>


40000





<webtob-address>

111.111.111.111

</webtob-address>





<webtob-backup>

. . .

</webtob-backup>

</webtob-listener>


. . .

</context-group>

. . .

</web-container>

[예 4.14] 웹 컨테이너 B : <<WEBMain.xml>>



. . .

<context-group>

. . .


<webtob-listener> 

<listener-id>WebListenerB</listener-id>

<port>9900</port>


<thread-pool>

<min>4</min>

<max>15</max>

<step>2</step>



</thread-pool>


40000





<webtob-address>

111.111.111.111

</webtob-address>





<webtob-backup>

. . .

</webtob-backup>

</webtob-listener>


. . .

</context-group>

. . .

</web-container>

다음은 WebtoB Server A가 [그림 4.5]에 있는 간단한 예와 같이 설정되기 위해 http.m 파일에 어떻게 설정

되는지를 보여주는 예이다.

[예 4.15] http.m of WebtoB 웹 서버 A (IP address 111.111.111.111)

*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 서버에 연결된다.


[그림 4.6] 복잡한 WebtoB 웹 서버 구성

JEUS Node D

JEUS Node C

JEUS Node B

JEUS Node A

WebToB Server B

WebToB Server A

Th

ird-p

art

y L

oa

d B

ala

nce

r

ClientRequests

Session server (optional,

session routing possible).

Web Container A

Context Group A

WebToB Listener A1

WebToB Listener A2

Web Container B

Context Group B

WebToB Listener B1

WebToB Listener B2

Web Container C

Context Group C

WebToB Listener C1

WebToB Listener C2

Web Container D

Context Group D

WebToB Listener D1

WebToB Listener D2

위 그림에서는 특별한 설정 사항을 볼 수 없다. 각 웹 서버와 각 웹 서버 리스너에서 위의 예와 동일한 방

법으로 설정한다.

한 가지 차이점은 각 Context Group이 모든 웹 서버에 연결되어 있고, Session Routing을 이용할 수 있다

는 것이다. 이런 환경에서 Session Server를 사용하는 것은 선택 사항이다. 하지만, 높은 안정성을 위해서

는 Session Routing과 함께 Session Server의 사용을 권장한다.

Session Server는 웹 컨테이너의 장애가 발생하는 경우 기본적으로 세션 데이터를 복구하는 기능을 가진

다.

4.5. TCP 리스너 사용TCP 리스너는 내부 HTTP 리스너가 동작하는 것과 같은 방식으로 동작한다. 그러나, 주목해야 할 점은

TCP 리스너는 HTTP프로토콜을 지원하지 않는다는 것이다. 대신에, 개발자는 표준 HTTP 프로토콜 대신

에 맞춤 통신 프로토콜을 구현할 수 있다.

“TCP”라는 개념은 이 리스너가 통신 프로토콜 구조의 낮은 레벨에서 작업할 수 있다는 것을 강조하게 된

다. 즉, 이것은 애플리케이션 레벨에서 보다는 전송 레벨에서 동작한다고 볼 수 있다(HTTP 리스너는 애플

리케이션 레벨의 리스너이다). 그러므로, TCP 리스너가 동작하기 위해서는 애플리케이션 레벨의 통신 프

로토콜의 구현이 요구된다.

본 절에서는 이러한 맞춤 프로토콜 제공자를 구현하는 방법과 그것을 어떻게 TCP 리스너와 함께 등록하

는지, 그리고 TCP 리스너에 접속하는 클라이언트를 작성하고 맞춤 프로토콜을 사용하여 통신하는 방법

에 대하여 알아본다.


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 리스너가 중간역할) 교환되

는 메시지의 구조와 내용을 정의한다.

프로토콜(통신 프로토콜)

TCP 클라이언트와 TCP Handler 사이에서 교환되는 데이터이다. 프로토콜

에서 정의한 구조에 맞아야 한다.

메시지

TCP 리스너와 교신하며 메시지를 주고받는 외부의 애플리케이션(TCP Handler

에 의해 처리된다)이다. 메시지를 주고받는 것은 표준 소켓을 사용한다.

TCP 클라이언트

TCP 리스너를 통하여 메시지를 받고 구현된 방법대로 메시지를 처리한다.

TCP Handler는 jeus.servlet.tcp.TCPServlet의 하위 클래스의 형태로 구현되

TCP Handler

고 웹 컨테이너에 보통 서블릿처럼 등록된다. TCP Handler는 TCP 프로토콜

위에 존재하는 맞춤 프로토콜의 “제공자” 또는 “구현체” 처럼 동작한다고 말

할 수 있다.

TCP 설정 “dispatcher” 클래스는 jeus.servlet.tcp.TCPDispatcherConfig를 확

장한 클래스이다. 이 클래스는 맞춤 프로토콜에 대한 정보를 TCP 리스너로

전달하여 이 non-HTTP 메시지를 해석하여 처리하도록 한다.

TCP dispatcher configu

ration class

이 클래스는 JEUS_HOME\lib\application 디렉터리 아래에 놓아두고, WEB

Main.xml의 TCP 리스너 설정 항목 중 <dispatcher-config-class> 태그에 설정

한다(“4.3. 리스너 설정” 참조).

맞춤 메시지에 대한 해석과 라우팅 인프라를 제공한다. TCP 클라이언트와

TCP Handler 사이에서 non-HTTP 중간 매개체로 역할을 한다.

TCP 리스너

이것은 다른 HTTP 리스너와 마찬가지로 웹 컨테이너 내에 존재한다.


4.5.1. 맞춤 통신 프로토콜 정의

TCP 리스너는 TCP 클라이언트와 TCP Handler 간에 통신되는 모든 메시지들을 두 부분으로 나누는데,

헤더와 바디가 그것이다. 일반적으로 헤더는 기본적이면서도 표준 정보를 전달하고 크기도 정해져 있다.

바디는 전송될 임의의 사용자 데이터가 포함된다(예, HTTP 응답의 HTML 코드).

TCP 리스너가 어떻게 사용되는지 설명하기 위하여 여기에서 간단한 프로토콜(메시지 구조)을 정의한다.

이것은 나중에 사용할 것이다.

맞춤 통신 프로토콜(맞춤 메시지 구조)은 다음과 같은 내용을 가진다.

● 헤더

1. 헤더는 4 Bytes의 magic 수로 시작한다. 이는 사용되는 프로토콜을 식별한다. “7777”로 설정한다.

2. 1 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의 하위 클래스)를 구현한다.

4.5.2. 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.*;


/*

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


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;

}

}

4.5.3. TCP Handler 구현

TCP Handler는 항상 jeus.servlet.tcp.TCPServlet의 하위 클래스이다. 여기에는 항상 overridden되는 abstract

void service(TCPServletRequest req, TCPServletResponse, res) 메소드가 존재한다.


이 서비스 메소드는 맞춤 프로토콜에 준하는 메시지를 처리할 수 있도록 구현되어야 한다. 메시지는

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();


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) {


result1 = msg1.getBytes();


}

} else {



}

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() {

}

}

4.5.4. 맞춤 프로토콜 코드를 위한 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


Context Group에 대한 설명은 “제3장 Context Group”을, Context 등록은 “제6장 Web Context(웹 애플

리케이션)”를 참고한다.

4. 간단한 web.xml을 생성하고 SampleServlet에 대한 정보를 다음과 같이 설정한다.

[예 4.18] <<web.xml>>


<web-app xmlns=”http://www.tmaxsoft.com/xml/ns/jeus”>

<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”이라는 서비스 이름을

명시한다. “4.5.1. 맞춤 통신 프로토콜 정의”를 참고한다.

서비스 이름은 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>>


<web-container xmlns=”http://www.tmaxsoft.com/xml/ns/jeus”>

. . .

<context-group>

<group-name>TCPGroup</group-name>



<tcp-listener>

<listener-id>TCPListener1</listener-id>

<port>5555</port>

<thread-pool>

<min>25</min>

<max>30</max>

<step>2</step>


</thread-pool>

<dispatcher-config-class>

sample.config.SampleConfig

</dispatcher-config-class>

</tcp-listener>


</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>>



<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>


</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>>


<jeus-web-dd xmlns=”http://www.tmaxsoft.com/xml/ns/jeus”>

<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() 메소드를 호출한다.

4.5.5. TCP 클라이언트 구현

여기의 TCP 클라이언트는 아주 간단 명료하다. TCP 리스너와 소켓 연결을 맺고 이 연결을 통하여 메시지

를 전송한다. 이 메시지는 “4.5.1. 맞춤 통신 프로토콜 정의”에서 정의한 맞춤 통신 프로토콜에 준하는 바

이트 스트림이다.

설정된 TCP 리스너는 메시지를 받을 것이고 SampleConfig 클래스에 dispatch 정보를 물을 것이다. 이 정

보는 SampleServlet 구현 코드의 service() 메소드의 호출을 암시하고 있다. SampleServlet은 클라이언트


로부터 전달된 데이터를 출력하고 응답을 생성하여 전송한다. 이 응답은 클라이언트가 받아 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);


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.5.6. 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\<node-

name>_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


4.6. 보안(SSL) 리스너 사용본 절에서는 JEUS 웹 컨테이너에서 보안 리스너를 설정하는 방법에 대해 설명한다.

또한 WEBMain.xml에 기본 리스너를 설정하는 방법과 필수 keystore, truststore 파일을 설정하고 보안 리

스너에게 위치나 이 파일들의 암호를 알려주는 방법, 마지막으로 보안된 SSL 연결을 통하여 HTML 파일

을 가져오도록 보안 리스너를 시작하고 연결하는 방법에 대하여 설명한다.

4.6.1. 개요

JEUS 웹 컨테이너의 보안 리스너는 직접적인 클라이언트 대 컨테이너의 HTTPS 요청을 지원한다. HTTPS

프로토콜은 SSL(Secure Socket Layer) 기술을 사용하여 인증, 메시지 기밀, 메시지 무결성 서비스를 제공

한다. 최근에는, 민감한 정보(신용카드 번호)가 교환되는 대부분의 온라인 서비스들은 SSL을 사용한다.

JEUS 보안 리스너는 JSSE(Java Secure Socket Extensions) API 기반의 HTTPS/SSL 연결을 지원한다.

이 기능은 사용은 가능하지만, 실제 많은 운영 환경이 웹 컨테이너 보다는 웹 서버에서 지원하는 SSL 기

능에 의존한다. http://java.sun.com/products/jsse에 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(웹 애플리케이션)”를 참조한다.


다음은 보안 리스너의 초기 디렉터리 구조이다.


http://java.sun.com/products/jsse

[그림 4.7] 보안 리스너의 초기 디렉터리

JEUS_HOME\

config\

<node-name>\


X WEBMain.xml

webhome\

app_home\

MyContext\

X jeus-web-dd.xml

T hello.html

WEB-INF\

X web.xml


파일에는 다음과 같은 항목들이 존재한다.

[예 4.23] JEUS_HOME\config\<node-name>\<node-name>_servlet_<engine-name>\WEBMain.xml



. . .

<context-group>


. . .

</context-group>

. . .

</web-container>

[예 4.24] JEUS_HOME\config\<node-name>\JEUSMain.xml



<node>

<name>tmax1</name>

. . .

</node>

<application>

<name>TestContext</name>

<path>

c:\jeus6\webhome\app_home\MyContext

</path>

<deployment-target>


<target>


tmax1_container1


<web-context-group>



</target>



<web-component/>

</application>

</jeus-system>

[예 4.25] JEUS_HOME\webhome\app_home\webapps\MyContext\WEB-INF\jeus-web-dd.xml


<jeus-web-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus">

<context>

<context-path>/Test</context-path>

</context>

</jeus-web-dd>

[예 4.26] JEUS_HOME\webhome\app_home\webapps\MyContext\WEB-INF\web.xml


<web-app xmlns="http://www.tmaxsoft.com/xml/ns/jeus">

<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)를 참고한다.


Context에 대해서 알지 못하면, 여기의 내용을 모두 이해하지 못할 수도 있다. 본 절에서는 설명을 목적으

로 할 뿐이며, 제시된 예제를 실행하기 위해서는 위에서 제시한 설정이 필요하다.

4.6.3. 보안 리스너 설정

다음은 <enable-secure>를 true로 설정하여 모든 보안 설정 정보를 기본값으로 사용하고 있는 예이다.

[예 4.28] 보안 리스너 설정 : <<WEBMain.xml>>



. . .

<context-group>



<http-listener>

<listener-id>SecureListener1</listener-id>

<port>443</port>


<thread-pool>

<min>2</min>

<step>1</step>



<max-queue>-1</max-queue>

</thread-pool>


30000</postdata-read-timeout>



false</server-access-control>

<scheme>https</scheme>

<ssl-config>

<enable-secure>true</enable-secure>

</ssl-config>

</http-listener>


<group-docbase>webapps</group-docbase>

. . .

</context-group>

. . .

</web-container>

보안 리스너 설정과 관련된 요소는 다음과 같다.

● <enable-secure>

– SSL(Secure Socket Layer) 통신 지원 여부를 결정한다.


– true이면 설정된 값에 따라 SSL 통신을 지원하고, false이면 지원하지 않는다.(기본값: false)

● <client-auth>

– 클라이언트의 인증 여부를 설정한다.

설명설정값

서버가 클라이언트에게 인증서를 요청하여 클라이언트에 대한 인증을 수행한다.true

클라이언트에 대한 인증 과정을 수행하지 않는다. 일반적으로 B2B를 제외한 보통의

경우에는 클라이언트 인증을 수행하지 않는다.(기본값: false)

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 옵션


– 기본값은 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 이다.


● <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.6.4. 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를 구현한 프로그램)에 의해 사용되어 클라이언트에게 자신을 인증하게 된다.


참고

“first and last name”에 “localhost”를 포함한 이유는 인증서는 개인보다는 머신(Server)을 대상으로

발급되기 때문이다. 실제 환경에서는 IP 주소나 DNS 이름을 넣는다. keystore의 위치는 바꿀 수 있

다. 이에 대한 자세한 내용은 “4.6.5. SSL Truststore 설정”에서 설명한다.

4.6.5. 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


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


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: 3e447270

Valid from: Sat Feb 08 11:58:56 KST 2004 until: Sat Feb 15 11:58:

56 KST 2004

Certificate fingerprints:


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의 위치를 변경할 수 있다.

4.6.6. 보안 리스너 속성 설정

보안 리스너를 시작하기 전에 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”가 설정된다.


위의 속성들은 JEUSMain.xml의 <engine-container>의 <command-option> 태그에 지정된다.

[예 4.29] <<JEUS_HOME\config\<node-name>\JEUSMain.xml>>



<node>

<name>[node name]</name>

. . .

<engine-container>

<name>mycontainer</name>

<command-option>

-Djeus.ssl.keypass=jeus123

-Djeus.ssl.trustpass=jeus123

</command-option>

<engine-command>



</engine-command>



. . .

<command-option> 값은 한 줄에 설정 하는 것에 주의하고, JEUSMain.xml의 편집이 끝나면 저장한다.

4.6.7. 보안 리스너 시작하기

위의 모든 과정을 거친 후에 JEUS 노드를 재시작한다(down을 하고 boot을 한다). 이렇게 하면 보안 리스

너가 시작된다.

JEUS 노드의 재시작 과정은 "JEUS Server 안내서"를 참고한다.

4.6.8. 보안 리스너에 연결하기

다음은 보안 리스너에 연결하는 과정에 대한 설명이다.

1. 로컬 호스트의 웹 브라우저를 열고 다음의 URL을 요청한다.

https://localhost/Test/hello.html

만약에 443 외의 다른 포트를 설정했다면 https://localhost:<Port>/Test/hello.html와 같이 요청해야 한

다. 또한 “https”의 “s”를 유의한다.

2. 브라우저에서는 다음 그림과 같이 Security Alert 대화창이 나타난다. 이 대화창은 SSL 연결은 시도되

었으나 보안 리스너에서 제공되는 인증서가 신뢰되지 않았다는 것을 알려준다. 브라우저가 그 자체의

truststore에 우리가 자체적으로 서명한 인증서를 포함하고 있지 않기 때문이다. [Yes] 버튼을 클릭하여

진행하고 연결과 인증서를 수용한다

[그림 4.8] Internet Explorer에서의 인증서 보안 경고창

3. 보안SSL 연결을 사용하는 보안 리스너를 통하여 “hello.html”을 받을 수 있다.

다음 그림의 작은 자물쇠 모양은 SSL 보안 연결이 수행되고 있다는 것을 의미한다.

[그림 4.9] 보안된 SSL 연결

주의

[그림 4.9]에서는 “1567” 포트를 이용하여 보안 리스너에 접근하고 있다. 일반적으로 “443”포트가 사

용됨을 유의한다.


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”로 설정한다. 웹 컨테이

너에 의해 필요한 설정이 자동적으로 설정된다. 그러므로 설정이 반드시 필요하지는 않다.


제5장 Session Tracking

본 장에서는 Session Tracking의 주요 기능과 설정 방법, 튜닝에 대해서 설명한다.

5.1. 개요Session Tracking에 관련된 기본적인 개념에 대한 소개부터 시작한다. 각 주제들은 Session, Session ID,

Session Cookie, URL rewriting등에 대한 정의를 내리고 JEUS 웹 컨테이너에 Session Tracking을 어떻게

구현하는지에 대해 설명한다. 또한 보다 복잡한 분산 환경인 웹 서버 클러스터링 환경에서는 어떻게 Session

Tracking이 구현되고 설정되는지도 살펴본다.

이러한 클러스터링 환경에서 Session Tracking을 지원하는 메커니즘에는 Session Routing과 Session

Server의 사용 2가지가 있다. Session Server를 사용하는 방법에는 동작 방식에 따라 중앙 집중식, 분산식

두 가지 방식이 있다.

5.2. Session Tracking의 주요 기능본 절에서는 Session Tracking이 무엇이고 JEUS 웹 컨테이너에서 어떻게 지원되는지에 대하여 알아본다.

매우 간단한 설명만이 제공되기 때문에 익숙하지 않은 사용자들은 본 절의 내용을 이해하려고 시도하기

전에 Servlet과 Session Tracking에 대한 서적을 참고한다.

다음 그림은 Session Tracking과 Session 관리에 관련된 웹 컨테이너의 컴포넌트를 보여주고 있다. Session

에 관련된 부분들이 강조되어 있다.

[그림 5.1] JEUS 웹 컨테이너의 구조 중 Session에 관련된 부분들

Client A

JEUS Web Container

Session

handling

settings

Misc. container

settings

Monitoring

threadWeb Server A


Context Group B

Web server

connection/list

ener

Misc. context

group settings

Virtual Host B

Context/Web

app C


Context/Web

app D

Context Group A

Web server

connection/list

ener

Misc. context

group settings

Virtual Host A

Context/Web

app A


Context/Web

app B

Client B

제5장 Session Tracking 113

참고

웹 서버도 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에

의해 모두 구현되는 것들이다.

5.2.1. 기본 기능

JEUS 웹 컨테이너는 URL rewriting과 Cookie를 모두 지원하여 Session Tracking을 가능하게 하기 위해서

기본적으로 Cookie가 사용된다. Session ID를 운반할 때 사용되는 Cookie를 Session Cookie라고 한다.

웹 컨테이너에서 하나의 Session은 하나의 Servlet API인 HttpSession 클래스의 인스턴스로 표현된다. 이

인스턴스는 Session Cookie(또는 URL rewriting의 결과로 생긴 URL 파라미터)의 Session ID와 연관되어

있다. HttpSession 객체는 기본적으로 그것을 생성하는 웹 컨테이너에 존재하고 이것은 사용자 선호 성향

이나 사용자가 전자 상거래 사이트에서 구매하고 싶은 물품의 목록 등과 같은 사용자에 대한 데이터를 가

지고 있다.


지금부터 JEUS의 웹 컨테이너에서 어떻게 Session Cookie와 HttpSession 객체가 사용되어 Session을

Tracking하는지에 대하여 알아보자. URL rewriting은 여기서 설명한 기술의 개념과 유사한 것임을 알아두

자. 단, Session ID가 HTML 페이지의 URL 링크에 포함되어 있다는 것이 별도의 Cookie header에 담겨진

다는 것과 다르다.

다음은 한 클라이언트가 JEUS 웹 컨테이너가 관리하는 리소스를 요청하는 과정에 대한 설명이다.

[그림 5.2] 웹 컨테이너가 Session Cookie를 발급하는 과정

Web Server A

Web

Container A

Client A

1. First HTTP

request

Cookie

A

5. HTTP response

Cookie

A

4. HTTP

response

3. Web container A creates a new session object 'A' and returns session ID cookie 'A'

2. First HTTP

request

HTTPSession object A

6. Web browser stores cookie 'A'

for later use.

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

Web Server A

Web

Container A

Client A

Cookie

A

1. Second HTTP request

4. HTTP response

3. Web container A associates cookie 'A'

with the stored HTTPSession object A

HTTPSession

object A

5. HTTP response

Cookie

A



1. 클라이언트는 같은 웹 서버에게 또 다른 요청을 보낸다. 이번에는 전에 받은 Session Cookie를 웹 브라

우저에서 받아 요청에 첨부한다.

2. 웹 서버는 요청을 받아 처음의 요청과 같이 동일한 웹 컨테이너에 요청(Cookie도 포함하여)을 전달한

다.

3. 웹 컨테이너는 요청과 Session Cookie를 받는다. Session Cookie에서 발견된 Session ID에 해당하는

HttpSession 객체를 자신의 메모리 영역에서 찾아온다. 웹 컨테이너는 그 HttpSession 데이터를 사용

하여 요청을 처리한다.

4. 응답 데이터와 Session Cookie는 웹 서버에 전달된다.

5. HTTP 응답이 웹 브라우저에게 전달된다. 그리고 HTTP 연결은 끊어진다. 이 응답에 Cookie가 같이 전

달될 필요는 없다. Cookie는 처음 연결이 생성될 때만 응답에 포함되어 전달되면 된다.

5.2.2. 클러스터 환경에서 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가지 방법으로 해결한다.

5.2.3. Session Routing(Sticky Session)

Session Routing(Sticky Session)은 클러스터된 환경에서 Client ID뿐만 아니라 웹 컨테이너 ID와 함께

Session ID Cookie로 꼬리표를 붙이기 위해 사용된다. Container ID는 Session Cookie를 처음 생성했던

컨테이너에 의해 추가되고, 웹 서버가 원래의 웹 컨테이너에게 요청을 전달해 줄 수 있게 한다.


예를 들면, 2개의 웹 컨테이너 A, B가 하나의 웹 서버에 연결된 클라이언트 요청 상황을 고려해보자.

이 과정은 다음과 같이 나타낼 수 있다.

[그림 5.4] Session ID Cookie를 이용하여 2개의 웹 컨테이너와 Session을 시작하는 경우

Web Server A

Web

Container A

Client A

1. First HTTP request

Web

Container B

Cookie A

6. HTTP response

Cookie A

5. HTTP response

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'


HTTPSession

object A


for later use.

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 삭제

Web

Container B

Cookie A

Web Server A

Web

Container A

Client A

Cookie A


4. Web container B tries to find

HTTPSession object A. It fails! No such object.

HTTPSession

object A

Cookie A


2. Web server arbitrarily

selects Web container B

to handle the second

request


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 부여


for later use.

Cookie

A

CID:AWeb Server A

Web

Container A

Client A


Web

Container B

6. HTTP response

Cookie

A

CID:A

5. HTTP response

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'. It also adds a container ID,

CID, 'A' to the cookie.


HTTPSessio

n object A

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는 웹 브라우저에 저장된다.


이렇게 함으로써 Routing 문제가 쉽게 해결된다. 다음은 Session Routing의 작동에 대한 그림이다.

[그림 5.7] Session Routing의 작동

Cookie A

CID:A

Cookie A

CID:A

Cookie A

CID:A

Web Server A

Web

Container A

Client A


5. HTTP response

4. Web container A associates cookie 'A'

with the stored HTTPSession object A

HTTPSession

object A

6. HTTP response


2. Web server inspects

the cookie Web

container ID 'A' and

routes the request to

Web container 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은 클러스터

링이 완벽하게 연결되어 있지 않아도 사용할 수 있다.

5.2.4. Session Server

간단한 Session Routing을 사용하는 것보다 한 층 더 강력한 것이 Session Server를 사용하는 것이다.

Session Server를 사용할 때에는, 모든 웹 컨테이너가 클러스터 내의 모든 웹 서버에 연결될 필요는 없다.

또한, Session Server는 클러스터 내의 모든 Session 데이터에게 신뢰적인 백업 기능을 제공한다. 따라서

특정 웹 컨테이너에 장애가 발생하더라도 Session 데이터는 저장되고 다른 정상적인 웹 컨테이너가 장애

가 발생한 웹 컨테이너의 요청을 대신 처리한다.

다음 그림에는 장애가 발생한 웹 컨테이너의 문제가 표현되어 있다. 이 시나리오에서는 웹 컨테이너에 존

재하는 모든 사용자 Session 데이터가 소멸된다. 이런 상황은 운영 환경에서는 반드시 피해야 하는 것이

다.


[그림 5.8] 장애가 발생한 웹 컨테이너의 문제

Web Container A


Cookie A

Web Server A

Client A

Cookie A


4. Before or during processing of the

request, Web container A is

downed due to an internal failure.

HTTPSession A is lost forever!

Cookie A


2. Web server selects

Web container A to

handle the second

request

Web

Container B

이와 같이 특정 웹 컨테이너에 장애가 발생하는 상황에서도 Session을 지속시키기 위해서 Session Server

가 클러스터에 추가되었다. 이런 Session Server가 사용될 경우에는 클라이언트의 첫 HTTP 요청이 다음

과 같은 방법으로 처리된다.

[그림 5.9] Session Server가 사용될 경우 클라이언트의 첫 HTTP 요청 처리

Session Server

Web Server A

Web Container A

Client A


Web

Container B

Cookie A

7. HTTP response

Cookie A

6. HTTP response

2. Web server arbitrarily selects Web container A to handle the request

4. Web container A creates a new session

object 'A' and a corresponding session

ID cookie 'A'




for later use.

Cookie 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는 웹 서버로 전달된다.


7. SessionIDCookie는 응답과 함께 웹 브라우저로 전달되고 HTTP 연결이 끊긴다.

8. 웹 브라우저는 이 Session Cookie를 저장한다.

후에 웹 컨테이너 B가 무작위로 웹 서버에 의해 클라이언트 A의 요청을 처리하도록 선택되거나 웹 컨테이

너 A에 장애가 발생하더라도 Session 데이터는 Session Server에서 가져올 수 있다.

[그림 5.10] Session 데이터의 요청 처리

Session Server

Cookie A

Cookie A

Web Server A

Client A

Cookie 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.

Cookie A


2. Web server arbitrarily

selects Web container B

to handle the second

request

Web

Container B

Cookie A


Web

Container A

5. HTTP response

Cookie A

6. HTTP response

게다가, 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 레

벨의 설정도 가능하다. 이와 관련된 자세한 내용은 “2.3.7. Session”을 참고한다.

참고

중앙 집중식 Session 클러스터링 설정에 대한 자세한 내용은 “JEUS Server 안내서”의 “10.2. 중앙 세

션 서버”를 참고한다.

5.2.5. 혼합 모드

위에서 설명한 Session Routing 방법과 Session Server 방법이 혼합된 것이 혼합 모드이다.

Session Routing(Sticky Session) 방법은 웹 컨테이너의 Session 객체를 접근하므로 빠르다. 그러나, 문제

가 발생할 경우에 웹 컨테이너의 모든 Session 데이터는 소멸되고 복구가 불가능하게 될 것이다.

Session Server를 사용하면 Session Server에 모든 Session 객체가 서버에 저장되므로 특정 웹 컨테이너

에 문제가 생기더라 하더라도 Session 객체의 소멸은 없다. 특정 웹 컨테이너에 문제가 발생하더라도


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 관리의 사용을 권장한다.

5.2.6. 분산 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 레벨의 웹 애플리케이션의 설정 즉, jeus-

web-dd.xml에서 설정한다. 일반적으로 Context 레벨에서 설정을 하지만 WEBMain.xml에서 웹 컨테이너,

Context Group 레벨의 설정도 가능하다. 이와 관련된 자세한 내용은 “2.3.7. Session”을 참고한다.

참고

분산식 Session 클러스터링 설정에 대한 자세한 내용은“JEUS Server 안내서”의 “10.3. 분산 세션 서

버”를 참고한다.

5.2.7. URL Rewriting과 Cookie

기본적으로 웹 컨테이너는 클라이언트의 Session ID를 지속되는 요청동안 유지하기 위하여 Cookie를 사

용한다. 한 가지 문제점은 대부분의 웹 브라우저가 새로운 요청에 대하여 Cookie가 원래 생성된 곳의 도

메인 이름과 다른 도메인 이름을 가지고 요청을 하면 SessionID Cookie를 보내지 않는다는 것이다.


이런 이유로, jeus-web-dd.xml deployment descriptor에 특수한 태그가 필요한데, <url-rewriting> 태그가

그것이다. 이 태그가 사용되면, Session ID는 웹 브라우저가 Cookie를 지원하여도 URL rewriting을 사용

하여 유지된다. 이런 방법으로, Session Tracking은 다른 도메인 이름이 몇 개의 요청에 사용되어도 작동

한다. 이와 관련된 설정에 대해서는 Session 설정인 “2.3.7. Session” 및 “제6장 Web Context(웹 애플리케

이션)”를 참고한다.

5.2.8. Shared Session 데이터

일반적으로 Session은 같은 Context에서만 관리된다. 하지만 같은 Session을 다른 Context 간에 공유를

하기를 원한다면 Session 설정의 <shared>를 "true"로 설정한다. 이와 관련된 자세한 설정은 “2.3.7. Session”

의 <shared> 부분을 참고한다.

참고

Session Server를 사용한다고 해서 모든 Session이 공유되는 것은 아니다. Session Server를 사용하

더라도 서로 다른 Context 간에 Session을 공유하려면 Session 설정의 <shared>를 반드시 설정해야

한다.

5.3. 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 레벨의 설정만 설명한다. 좀 더 자세한 내용을 위해서는 “2.3.7. Session”부분을

참고한다.


5.3.1. 중앙 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 안내서”의 “10.2. 중

앙 세션 서버”를 참고한다.

노드 클러스터링 상태일 때 설정

노드 클러스터링 상태일 때는 웹 컨테이너 설정을 위해 WEBMain.xml에서 다음의 예제와 같이 Session

Server 사용 여부를 설정해 주기만 하면 된다. 다음은 Session Tracking 설정에 대한 예이다.

[예 5.1] Session Tracking 설정 : <<WEBMain.xml>>



. . .

<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>>


<web-container>

. . .

<session-server>

<primary-server>node1</primary-server>

<backup-server>node2</backup-server>

<connect-timeout>120000</connect-timeout>



<check-level>set</check-level>

</session-server>

. . .

</web-container>


● <session-server>

설명태그

주 중앙 Session Server의 JEUS 노드 이름이다. 이 노드에 대한 물리적인 호

스트 정보는 vhost.properties에 명시되어 있어야 한다.

<primary-server>

백업 Session Server의 JEUS 노드 이름이다.<backup-server>

주 Session Server가 다운되었을 때 웹 컨테이너는 백업 Session Server로

take over를 실행한다. 이 노드에 대한 물리적인 호스트 정보는 vhost.properties

에 명시되어 있어야 한다.

Session Server와 웹 컨테이너 사이의 연결을 맺을 때 기다리는 최대시간을

나타낸다.(기본값: 20초, 단위: millisecond)

<connect-timeout>

Session Server와 웹 컨테이너 사이의 통신에 있어서 응답을 기다리는 최대

시간을 나타낸다.(기본값: 20초, 단위: millisecond)

<read-timeout>

Session Server로 Session을 업데이트하기 위한 Session 객체의 수정 정도

를 설정한다.(기본값: set)

<check-level>

– 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


각 설정값들의 의미는 다음과 같다.

설명항목

true로 설정한다.jeus.vhost.enable

노드의 실제 물리적 설정으로 node1과 node2의 설정을 한 예이다.

IP : port 형식으로 작성한다.

노드 정보

5.3.2. 분산 Session Server 설정

분산 Session Server를 사용하고자 할 때에도 JEUSMain.xml에 설정을 하고 JEUS 노드를 재시작한다. 자

세한 설정 방법은 “JEUS Server 안내서”의 “10.3. 분산 세션 서버”를 참고한다.

참고

여러 분산 Session Server가 클러스터링되는 환경을 위해서는 JEUS의 노드 클러스터링이 전제되야

한다. 만약 중앙 Session Server와 분산 Session Server 설정이 동시에 JEUSMain.xml에 존재한다면

중앙 Session Server를 사용한다.

5.4. Session Tracking 튜닝클러스터된 환경에서 최적의 성능을 위해 다음과 같이 수행한다.

● 항상 Session Routing(Sticky Session)과 Session Server를 혼합하여 사용하도록 노력한다.

이는 좋은 성능과 안정적인 운영을 보장한다.

● 웹 서버 연결들이 잘 설정되고 튜닝되어 있어야 한다.

● 사용자의 요청이 폭주하는 사이트에서는 분산 Session Server를 사용할 것을 권장한다.


제6장 Web Context(웹 애플리케이션)

본 장에서는 JEUS 웹 컨테이너 내의 Java EE Web 모듈(Web Application, Context)을 조립, 등록, 모니터

링하는 모든 방법에 대하여 설명한다.

6.1. 개요본 장과 나머지 장들에서는 “Web Application”과 “Context”의 의미가 완벽하게 같은 의미로 통하지만 후자

를 주로 사용할 것이다.

6.2. Web Context의 기본 개념과 구조본 절에서는 Context에 관련된 기본 개념과 디렉터리 구조, 관련 파일에 대해서 설명한다.

6.2.1. 기본 구조

다음 그림은 Context/Web application에 관련된 웹 컨테이너의 그림이다.

[그림 6.1] JEUS 웹 컨테이너에 context/Web application

Client A

JEUS Web Container

Session

handling

settings

Misc. container

settings

Monitoring

threadWeb Server A


Context Group B

Web server

connection/list

ener

Misc. context

group settings

Virtual Host B

Context/Web

app C


Context/Web

app D

Context Group A

Web server

connection/list

ener

Misc. context

group settings

Virtual Host A

Context/Web

app A


Context/Web

app B

Client B

제6장 Web Context(웹 애플리케이션) 127

웹 애플리케이션은 클라이언트의 요청에 의한 웹 기반의 서비스(예를 들면, 장바구니에 물품을 추가하거

나, 장바구니 안의 물품을 구매하거나 웹 기반의 경매 사이트에서 물건을 사기 위해 브라우징하는 등)를

수행하기 위한 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장 가상 호스트”를 참고한다.

6.2.2. WAR 파일 구조

Java EE 웹 애플리케이션은 Java EE 웹 컨테이너에 배포되고 등록되기 전에 특수한 Archive(라이브러리)

파일에 패키징하여 포함시켜야 한다. 이 애플리케이션들을 패키지할 때 사용하는 Archive들은 JAR/ZIP

파일들로 '.war' 확장자를 가지고 있다. 이들은 JAR 유틸리티를 사용하여 다른 JAR Archive를 생성하는

방법과 동일하게 생성된다.

WAR 파일의 구조는 다음과 같다.


[그림 6.2] WAR 파일 구조

WEB

WAR

META-INF\

T MANIFEST.MF

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

WEB-INF\

classes\

lib\

tlds\

X web.xml

C Servlet .class

J Library JAR

images\

jsp\

static\

T .html

T .jsp

T .jps, .gif

T index.html

T .tld

X jeus-web-dd.xml

META-INF\

이 디렉터리는 선택 사항이고, 존재하면 JAR 포맷에 정의된 Descriptor 파일인 "MANIFEST.MF" 파일

을 포함한다.

WEB-INF\

이 디렉터리는 필수 사항이고, 웹 애플리케이션의 Servlet, Java 유틸리티 클래스들, JAR/ZIP 라이브

러리들이 포함되어 있다. 이 디렉터리 바로 하위에는 다음과 같은 컴포넌트들이 존재한다.

설명파일

Java EE 표준 웹 애플리케이션 Deployment Descriptor 파일로 웹 애플리케이션

의 모든 메타 정보를 가지고 있다. 그리고, 클라이언트에 의해 접근 가능한 모든

Servlet과 JSP들의 목록을 가지고 있어야 한다.

web.xml

그렇지 않으면 웹 컨테이너는 파일들의 위치를 알 수 없다.

JEUS의 웹 애플리케이션 Deployment Descriptor로 자세한 설명은 “6.3.2. De

ployment Descriptor 파일 설정”을 참고한다.

jeus-web-dd.xml

Servlet 클래스들과 유틸리티 클래스들이 하위 디렉터리에 포함되어 있다.classes\


설명파일

표준 Java 패키지 구조로 정리되어 있다.

웹 애플리케이션에 필요한 Java 라이브러리들을 포함한다.lib\

라이브러리들은 JAR 또는 ZIP 파일들로 패키지되어 이 경로에 저장된다. 이 파

일들의 내용들은 자동적으로 모든 Servlet의 클래스 경로에 추가된다.

JSP 페이지들을 위한 custom tag library descriptor들을 포함한다.tlds\

기타

HTML, JSP, 이미지 파일들과 같은 content들을 포함하고 있는 임의의 이름의 디렉터리이다.


다음 그림은 Context와 그 상위 컴포넌트들의 기본 디렉터리 구조이다.

[그림 6.3] Web Context 디렉터리의 구조

META-INF\

T MANIFEST.MF


WEB-INF\

classes\

lib\

tlds\

X web.xml

C Servlet .class

J Library JAR

images\

jsp\

static\

T .html

T .jsp

T .jps, .gif

T index.html

T .tld

JEUS_HOME\

config\

<node-name>\


X WEBMain.xml

X jeus-web-dd.xml

X JEUSMain.xml

webhome\

app_home\

MyContext\


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”에도 설정됨).

5. “6.3.7. Context 등록”을 참조하여 웹 애플리케이션을 등록한다.

6. 선택적으로 처음 JSP를 호출할 때, 보다 빠르게 실행하기 위해서 미리 컴파일한 JSP 파일을 사용할 수

도 있다.

7. 웹 애플리케이션이 디플로이할 때 JEUSMain.xml의 <application> 태그로 등록되었다면 웹 컨테이너를

재시작한다.

이 모든 작업들은 편집기를 이용하여 할 수도 있지만 WebAdmin을 이용할 것을 권장한다.


6.3.1. 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]을 따라서 관련 파일을 생성

하여 위치시킨다.

6.3.2. 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="http://www.tmaxsoft.com/xml/ns/jeus" 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>


<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-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>



설명태그

context를 접근하기 위해 사용되는 기본URL이다. 이것은 반드시 “/”로

시작해야 하고, 하나의 가상 호스트나 Context Group 내에서 유일한 것

<context-path>

이어야 한다. 예를 들면, http://www.foo.com/examples/index.html과 같

은 URL의 context 경로는 “/examples”가 된다.

context group의 user log 설정과 같다. “3.3.4. Logging 설정”을 참고한

다.

<user-log>

디스크의 Servlet 클래스가 변경되었을 때 자동적으로 로딩이 되는지에

대한 설정이다. 이는 Container의 클래스 리로딩을 모니터링 하는 thread

에 설정된 시간 주기에 따라 정기적으로 확인된다.

<auto-reload>

이 하위 태그에는 클래스 리로딩이 새로운 요청이 들어왔을 때만 발생

하도록 하는 것도 있다.

false로 설정했을 때, JSP 기능을 완전히 사용하지 않는다.<enable-jsp>

기본은 JSP를 지원한다.

SingleThreadedModel을 implement한 Servlet은 한 번에 하나의 thread

에 의해서만 수행된다. 이러한 Servlet을 여러 개 동시에 수행하려면

<max-instance-pool-size>

SingleThreadedModel의 Pool이 생성되어야 한다. 이 설정은 재사용 가

능한 Pool의 최대 크기를 설정한다(Pool 크기 이상 생성은 가능). 참고

로 SingleThreadModel은 deprecated된 스펙이므로 사용을 권장하지 않

는다.

Servlet들이 컴파일되고 실행될 때 접근 가능하게 해야할 Java 클래스

디렉터리 또는 JAR 파일들의 리스트들이다.

<added-classpath>

기본적으로 “classes\” 디렉터리의 클래스 파일들 ,”WEB-INF\” 디렉터

리의 “lib\” 디렉터리의 JAR파일들은 접근 가능한 위치들이다.

클라이언트가 요청했을 때, 실제 디렉터리 목록이 출력되는 URL 경로

의 목록이다. 디렉터리의 목록이 출력되는 경우는 클라이언트에서 요청

한 파일이 디렉터리에 없을 때이다.

<allow-indexing>

대신에 디렉터리 목록의 파일을 하나 선택하면, 그 파일의 내용이 출력

된다.

어떤 경우에라도 직접적으로 다운로드 받거나 접근할 수 없는 자원들을

규정하기 위한 필터이다. 이 필터들은 파일 이름의 확장자로, 파일 이름

과 함께 경로로 지정할 수 있다.

<deny-download>

필터의 파일 이름과 디렉터리들은 context document base 디렉터리의

상대적인 경로로 주어진다.

Custom URL 경로에 대한 디렉터리 매핑을 의미한다.<aliasing>


설명태그

다른 위치의 디렉터리를 URL 요청 경로에 매핑을 시킬 필요가 있는 경

우에 aliasing 기능을 사용한다.

Container의 응답 속도 향상을 위해 런타임 메모리에 어떤 Static Con

tent(HTML, GIF, JPEG등)가 Caching이 되어야 할지 결정한다.

<file-caching>

이 항목의 하위 설정들은 Cache 메모리의 최대 크기(단위: Megabytes),

요청되지 않을 때 Cache 내에 머무를 수 있는 Static Content의 최대 크

기, Caching 되어야 할 콘텐츠가 있는 경로가 있다.

현재 컨텍스트의 JSP 페이지에 대한 설정이다. 이 element는 WEB

Main.xml의 JSP Engine 설정과 동일하다.

<jsp-engine>

만약에 jeus-web-dd.xml 파일에 JSP Engine 설정이 되어 있다면, 여기

에 설정된 내용이 WEBMain.xml에 설정된 해당 컨텍스트의 JSP Engine

설정보다 우선한다. 이 element에 대한 설정 정보는 “3.3.3. JSP 엔진 설

정”을 참고한다.

Context 레벨의 Session을 설정한다. 현 Context에 적용되는 Session과

관련하여 여러 가지 설정을 할 수 있다.

<session-config>

Context 레벨에서 정의된 Session 설정은 Web Container 레벨, Context

Group 레벨에서 정의된 설정을 반복한다. 다만 Context 레벨에서 설정

한 설정은 웹 컨테이너, Context Group에서 설정한 것보다 높은 우선 순

위를 가지고 적용된다. Session 설정의 자세한 부분은 “2.3.7. Session”

을 참고한다.

클래스 로딩 우선 순위에 관한 옵션으로 true로 설정되면 이 애플리케이

션에 한해서는 다른 설정과 관계없이 WEB-INF 하위의 클래스를 우선

적으로 로딩하게 된다.

<webinf-first>

서버에 문제가 발생하였을 때 오류의 상세 내역을 브라우저로 보여줄

것인지에 대한 설정이다.

<attach-stacktrace-on-error>

이 메시지는 개발하는 경우에는 유용하지만 운영하는 경우에는 제거하

는 것이 좋다. ContextGroup에서도 설정이 가능하지만 전체적으로 설

정하지 않고 특정 Context만 설정할 때는 여기에서 설정한다.

request, response에 대한 인코딩 설정이다. 이 설정은 ContextGroup의

설정과 동일하며 동시에 설정될 경우 여기의 설정이 우선 적용된다. 자

세한 내용은 “3.3. Context Group 설정”을 참조한다.

<encoding>

- Request encoding : HTTP 요청의 질의문, 쿠키 및 postdata Block을

위한 인코딩

- Response encoding : 웹 컨테이너로부터 받은 전체 응답 HTTP 메시

지에 적용되는 인코딩


6.3.3. 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="http://www.tmaxsoft.com/xml/ns/jeus">



<library>

<library-name>jsf</library-name>


<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>


<implementation-version>1.2</implementation-version>

<files dir="jstl_1.2"/>

</library>



<library>



<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>

Shared Library를 참조하기 위해서는 jeus-web-dd.xml에 다음과 같이 <library-ref>를 설정하면 된다. 버

전이 명시되지 않은 경우는 libraries.xml에 등록된 동일한 이름의 라이브러리 중에서 최상위 버전을 참조

한다.

<library-ref>



</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의 경우는 Managed Bean에서 @EJB나 @Resource 같은 annotation으로 WAS가 제공하는 리소

스에 접근할 수 있고 WAS는 annotation으로 명시된 리소스들을 injection할 수 있어야 한다.

JEUS에서는 JSF1.2 RI에 JEUS Injection을 지원하기 위해서 Shared Library로 'jsf-injection-provider.jar'를

제공하고 있다.


6.3.4. 하위 호환성을 위한 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번째

컬럼에서 어떤 문제가 있는지 확인해야 한다.

[2007.01.15 10:02:29][2][b029] [mycontainer-12] [WEB-5697] [examples#examples] par

sing 35 jsp file(s)

[2007.01.15 10: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

옵션을 설정할 수 있다.


-Djeus.servlet.jsp.modern=false

VM 옵션은 ContextGroup, VirtualHost, Context에서 Override되기 때문에 jeus-web-dd.xml에 설정한 옵션

이 최종적으로 적용된다. jeus-web-dd.xml에 옵션 설정이 없다면 상위의 디폴트 설정이 적용된다. 나머지

옵션들은 “JEUS Reference Book”의 “1.7. 서블릿/웹 시스템 프로퍼티”에서 확인할 수 있다.

추가 옵션은 하위 호환성이 필요한 경우만 적용하고 신규 개발은 추가적인 옵션 없이 표준에 따라 개발할

것을 권장한다.

6.3.5. 보안 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> 태그는


0개 이상의 <role-permission> 태그들을 가지고 있다. 이 태그를 이용하여 <principal-to-role> 매핑을 정의

한다. 다음의 하위 태그들과 함께 바인딩된다.

설명태그

web.xml에 정의된 role name이며, 위의 예에서는 role name이 “manager”이다.<role>(1개, 필수)

role name과 연계되어야 할 JEUS가 관리하는 사용자의 이름이다. 더 자세한 사

항은 “JEUS Security 안내서”의 “3.3. 웹 모듈 보안 설정”을 참고한다.

<principal>(0개 이상)

2개의 Role “manager”와 “developer”가 “Peter”와 “Linda”로 각각 매핑되어 있다.

[예 6.4] 보안 Role 매핑 : <<jeus-web-dd.xml>>


. . .

<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>

6.3.6. 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>


<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>

설명태그

reference name(ref name)은 web.xml과 Servlet 코드에 정의된 것과 같은 것이다.<ref-name>

JNDI export name은 레퍼런스 이름이 뜻하는 실제의 자원 export-name이다.<export-name>

다음은 JNDI 이름이 위의 3개의 레퍼런스와 매핑된 jeus-web-dd.xml의 예이다.

[예 6.6] Symbolc 레퍼런스 매핑 : <<jeus-web-dd.xml>>


. . .

<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>


<res-env-ref>

<jndi-info>

<ref-name>jms/StockQueue</ref-name>

<export-name>StockQueue</export-name>

</jndi-info>

</res-env-ref>

. . .

</jeus-web-dd>

6.3.7. 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”라고 지정되어 있다. 예를 들어, http://www.foo.com/examples/in

dex.html를 요청하면 “Examples” context의 “index.html”을 반환한다(웹 컨테이너의 context group의 HTTP

리스너의 포트가 80으로 설정되어 있다고 가정한다).

[예 6.7] Context 등록 : <<JEUSMain.xml>>


<node>

<name>tmax1</name>

...

</node>

<application>

<name>Examples</name>

<path>

c:\jeus6\webhome\app_home\examples

</path>

<deployment-target>

<target>


tmax1_container1



<web-context-group>


<virtual-host-name>

www.foo.com

</virtual-host-name>


</target>



<web-component/>

</application>

<application>

<name>MyApp</name>

<path>

c:\jeus6\webhome\app_home\myapp

</path>

<deployment-target>

<target>


tmax1_container1


<web-context-group>


<virtual-host-name>

www.foo.com

</virtual-host-name>


</target>



<web-component/>

</application>

</jeus-system>

6.3.8. 배치 컴파일러를 사용한 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.3.9. 등록 확인

위의 과정을 거친 후 등록이 정확이 되었는지 수동으로 확인하기 위해서 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”)가 목록에 조회되면

등록이 성공적으로 된 것이다.

6.4. Web Context 요청다음과 같이 예를 들어보자.

● WEBMain.xml의 Context Group에 “/Test” 경로를 가진 Context를 등록하였다(여기서는 명시적인 가상

호스트가 사용되지 않는 것으로 가정한다).

● 이 Context는 web.xml에 “HeaderTest”라는 Servlet을 가진다.

● 이 Context가 소속된 Context Group은 HTTP 리스너가 설정되어 있다. 이 리스너는 8088포트를 로컬

머신에서 사용하고 있다.

위의 내용을 가정하고 Context의 HeaderTest Servlet을 다음과 같은 URL을 웹 브라우저에서 실행한다.

http://localhost:8088/Test/HeaderTest

다음과 같은 페이지가 나타난다.


[그림 6.4] 웹 브라우저에서 Servlet 요청하기

그러므로, Servlet(또는 JSP)를 요청할 때에는 다음과 같은 URL 포맷을 이용한다.

http://<hostname>:<port>/<context request path>/<Servlet/JSP name>

Static Content에 대해서는 다음과 같은 URL 포맷을 사용한다.

http://<hostname>:<port>/<context request path>/<directory path>/<file name>

예를 들어, ”/Test” 요청 경로를 가진 Context의 “static” 디렉터리 아래에 있는 “hello.html”을 호출하기 위해

서는 다음과 같은 URL을 사용한다.

http://localhost:8088/Test/static/hello.html

URL 경로의 파일 이름을 지정하지 않으면 기본 페이지인 “index.html”이 사용된다.

요청된 파일 또는 자원이 발견되지 않을 경우에는 다음과 같은 기본 오류 페이지가 반환된다.

[그림 6.5] JEUS 웹 컨테이너에 의해 생성되는 기본 오류 페이지

참고

“제7장 가상 호스트”에는 Context 요청에 대한 자세한 내용과 가상 호스트에 대해서 설명한다.


6.5. Web Context 모니터링jeusadmin과 WebAdmin을 통하여 Context와 Servlet을 모니터링할 수 있다. 모니터링은 WebAdmin을

이용할 것을 권장한다.

jeusadmin 콘솔 툴을 사용

jeusadmin에서 디플로이된 Context Group의 정보를 조회하려면 ‘info’를 수행한다.

다음은 특정 Context Group에 대한 정보를 조회하는 방법이다.

info <context group name>

다음은 특정 Context의 정보를 조회하는 방법이다(특정 Servlet에 대한 정보는 조회하지 못한다).

info <context group name> <context name>

더 자세한 정보는 “JEUS Reference Book”의 “4.2.5. 서블릿 엔진 관련 명령어”를 참고한다.

WebAdmin을 사용

WebAdmin에서 Context 모니터링과 Servlet 모니터링에 관련된 내용을 조회하려면 다음과 같은 방법으로

원하는 Web Context의 상태를 모니터링할 수 있다.

● JEUS 노트 트리에서 노드 >엔진 컨테이너 > container name >어플리케이션 모듈 > context를 선택

한 후 [통계] 탭을 클릭

● JEUS 노트 트리에서 노드 > JEUS모니터링을 선택하면 나타나는 MBean 모니터링 화면에서 MBean

> JeusManager > J2EEServer > WebModule을 선택한 후 [통계] 탭을 클릭

6.6. Web Context 튜닝최대한의 성능을 위해 context의 설정(jeus-web-dd.xml)을 튜닝할 때 다음 같은 사항들을 고려해야 한다.

● User log은 버퍼의 크기를 증가시키고 “stdout”의 사용을 자제한다.

● JSP Engine은 사용하지 않으면 OFF시킨다.

● <enable-reload>와 <check-on-demand> 옵션은 항상 OFF시킨다. 이 옵션은 클래스 변경이 잦은 개발

환경에서만 사용한다.

● <max-instance-pool-size>를 “-1”로 하여 SingleThread 된 Servlet에게 최적의 동시성을 제공한다(그러

나 잠재적으로 시스템 자원을 낭비하게 된다).

● 가능하면 파일 Caching 기능을 사용한다. 최대한 많은 Static Content 디렉터리를 파일 Caching 태그에

설정한다. Cache의 <max-idle-time>과 <max-cache-memory>의 값을 크게 설정한다(무한대로 설정해

도 무방하다).


제7장 가상 호스트

본 장에서는 가상 호스트에 대한 기본 개념, 기본 규칙과 구조, 기본 가상 호스트의 개념 등에 대해 설명한

다.

7.1. 개요JEUS 웹 컨테이너의 새로운 기능은 가상 호스팅이다.

기본적으로, 가상 호스트는 웹 사이트가 다른 Context에게 주어진 Context 경로뿐만 아니라 요청 주소에

있는 도메인 이름에 의해서도 연결될 수 있도록 한다. 이렇게 함으로써 2개 이상의 DNS 이름(예,

“www1.foo.com” and “www2.foo.com”)을 하나의 웹 컨테이너에 설정하여 다른 Web Context를 서비스할

수 있다.

가상 호스트는 보기에 따라서 별도의 웹 컨테이너로 보일 수 있다.

7.2. 가상 호스트의 기본 개념다음 그림은 웹 컨테이너에서 가상 호스트에 관련된 컴포넌트들을 보여주고 있다.

[그림 7.1] JEUS 웹 컨테이너의 가상 호스트 컴포넌트

Client A

JEUS Web Container

Session

handling

settings

Misc. container

settings

Monitoring

threadWeb Server A


Context Group B

Web server

connection/list

ener

Misc. context

group settings

Virtual Host B

Context/Web

app C


Context/Web

app D

Context Group A

Web server

connection/list

ener

Misc. context

group settings

Virtual Host A

Context/Web

app A


Context/Web

app B

Client B

제7장 가상 호스트 147

7.2.1. 기본 개념

가상 호스트의 기본적인 개념은 사용자 요청에 포함된 도메인 이름들(예, www.foo.com, www.bar.com)이

나 IP 주소(예, 111.111.111.1, 111.111.111.2)에 따라 사용자 요청을 분기하는 것이다. DNS 이름을 사용

한 가상 호스트와 IP 주소를 사용한 가상 호스트는 DNS 이름을 통해서 라우팅이 되는지, IP 주소를 통해

서 라우팅이 되는지의 차이점을 갖지만, 궁극적인 동작 방법은 동일하다.

가상 호스트 개념의 도입으로 하나의 웹 컨테이너는 여러 도메인 이름을 가진 요청을 처리할 수 있고, 이

요청을 원하는 Context로 보낼 수 있다.

다음 그림은 가상 호스트의 기본 개념을 보여준다.

[그림 7.2] 가상 호스트의 기본적인 개념

JEUS Web Container

Virtual host 1: www1.foo.com

Virtual host 2: www2.foo.com

Context 1

Context 2

Context 3

HTTP Client

HTTP requests

Request domain:

www1.foo.com

Request domain:

www2.foo.com

Response

Response

HTTP requests

가상 호스트의 규칙

가상 호스트를 구성할 때 적용되어야 할 기본적인 규칙은 다음과 같다.

● 하나의 가상 호스트는 1개 이상의 DNS 이름이나 IP 주소를 가질 수 있다.

이것을 우리는 가상 호스트의 네트워크 이름이라고 한다.

● 가상 호스트에는 유일한 값의 가상 호스트 ID 이름을 부여한다.

이 이름은 설정 파일 내에서 가상 호스트를 참조하기 위해서 내부적으로 사용되는 이름이다.

● 가상 호스트는 웹 컨테이너의 Context Group에 설정된다.

Context Group당 여러 개의 가상 호스트가 존재할 수 있지만, 한 Context Group의 모든 가상 호스트들

은 유일한 네트워크 이름(DNS 이름이나 IP 주소)을 가져야 한다.

● 각각의 가상 호스트는 반드시 하나 이상의 Context와 연계되어 있어야 한다.

같은 가상 호스트 내의 모든 Context들은 각각 유일한 Context 이름과 경로(URI 요청 경로)를 가지고 있

어야 한다. 그러나, 하나의 Context가 다른 여러 개의 가상 호스트에 존재하면 그 경로는 그 모든 가상호

스트에서 동일하게 사용할 수도 있다.


다음은 위 규칙을 나타낸 그림이다.

[그림 7.3] Context Group과 가상 호스트, Context 간의 유효한 관계의 예

Context Group A

Virtual Host A

www.foo.com

Context A

URL: /contextA

Context B

URL: /contextB

Context

Group B

Virtual Host B

www.bar.com

Virtual Host C

www.bar.com

www.foo.com

Context C

URL: /contextC

Context D

URL: /contextD

HTTP Client

JEUS Web container

위 그림에서 주의깊게 봐야 할 것은 다음과 같다.

● 2개의 유일한 Context Group이 설정되어 있다.

클라이언트는 이 2개의 Group을 소켓 포트 번호로 구분한다. 즉, Group “A”는 “80” 포트를 Group “B”는

“9999” 포트를 사용한다. Context Group의 웹 서버 리스너는 유일한 포트 번호를 가진다는 것에 유의한

다. 자세한 내용은 “제4장 웹 서버 연결과 클러스터링”을 참조한다.

● Context Group “A”는 2개의 가상 호스트가 추가되어 있다.

2개의 가상 호스트는 유일한 네트워크 이름을 가지고 있다. Group “B”에는 1개의 가상 호스트(“C”)가 추

가되어 있다. 이 가상 호스트는 2개의 네트워크 이름을 가지고 있다. "www.bar.com"과 "www.foo.com"이

다. 이것은 Context Group 내의 다른 가상 호스트가 동일한 네트워크 이름을 가지고 있지 않기 때문이

다.

● 가상 호스트 “A”는 가상 호스트 “B”와 함께 context “B”를 공유한다.

이것은 같은 가상 호스트 내에서, Context들이 같은 URI 경로를 가지고 있지 않으면 되기 때문에 올바

른 설정이다.

위의 규칙을 통해서 각 Context는 서로 구분되어 설정되었다는 것을 알 수 있다.

가상 호스트의 주된 사용

가상 호스트는 Context가 Context 경로에 의해서가 아닌 실제 DNS 이름이나 IP주소에 의해 구분되어 사

용될 때 사용되어야 한다.

예를 들어, 2개의 다른 Context가 하나의 웹 컨테이너에 있고 모두 기본 Context 경로인 “/”에 의해서만 접

근 가능해야 한다면, 가상 호스트를 사용하여 하나의 DNS 이름을 첫 번째 Context로, 다른 DNS 이름을

두 번째 Context로 설정하면서, 같은 웹 컨테이너가 2개의 Context를 관리하게 할 수 있다.


다음은 위 개념을 나타낸 그림이다.

[그림 7.4] 웹 컨테이너에서 DNS 이름으로 같은 경로를 가진 Context 사용

Context Group A

Virtual Host A

www.foo.com

Context A

URL: /

Virtual Host B

www.bar.comHTTP Client

JEUS Web container

Context B

URL: /

위의 그림에서는, 2개의 context A, B를 가지고 있다. 2개 모두 하나의 웹 컨테이너에 존재하고 동일한

Context Group과 리스너 그리고 경로(“/”)를 가지고 있다. 차이점은 Context A는 URL http://www.foo.com/

이 요청될 때 context B는 URL http://www.bar.com/이 요청될 때 사용된다는 것이다.

7.2.2. 기본 가상 호스트

기본 가상 호스트(Default virtual host)라는 묵시적인 가상 호스트가 존재한다. 이것은 비록 WEBMain.xml

에 설정되어 있지 않지만 항상 존재한다. 명시적으로 Context를 가상 호스트에 할당하지 않으면, 이 기본

가상 호스트로 할당된다.

“제6장 Web Context(웹 애플리케이션)”에서 미리 봤듯이, 가상 호스트의 관계를 설정하지 않고 Context를

선언하는 것은 일반적인 일이다. 이런 모든 Context들은 기본 가상 호스트에 속한다고 생각할 수 있다.

기본 가상 호스트의 존재는 JEUS 사용자에게는 보이지 않는다.

7.2.3. ServletContext 객체와 가상 호스트에 대한 주의 사항

Servlet API를 보면 javax.servlet.ServletContext.getContext(java.lang.StringcontextPath)라는 메소드를

볼 수 있다. 이것은 “contextPath” URI에 의해 주어진 Servlet Context 를 리턴한다.

이 메소드는 그 Servlet이 속하는 현재 가상 호스트에 존재하는 Context만을 리턴한다. 유효한 Context가

이 가상 호스트 내에서 존재하지 않으면 기본 가상 호스트에서 찾는다.

이 사항은 Servlet 스펙의 요구 사항이다.


7.3. 가상 호스트 설정가상 호스트는 WEBMain.xml에 설정된다. 이것을 작동시키기 위해서는 도메인 이름을 등록해야 한다. 그

리고 가상 호스트와 Context와의 관계 설정은 JEUSMain.xml의 <application> 태그를 통해서 이루어진

다.

참고

자세한 내용은 "JEUS Server 안내서"를 참조한다. WebAdmin을 사용하여 WEBMain.xml에 가상 호

스트를 설정하려면 "JEUS WebAdmin 안내서"의 Context Group 설정 장을 참고한다.

7.3.1. 도메인 이름 등록

복수의 DNS 이름 또는 IP 주소를 가상 호스트에 사용하기 위해서는 DNS 이름을 등록해야 한다.

등록 방법에는 2가지 선택 사항이 있다.

● DNS 서버에 웹 컨테이너의 리스너 또는 웹 서버 IP 주소 아래의 모든 DNS 이름을 등록한다.

예) www.foo.com과 www.bar.com

● 서버의 “hosts” 파일에 네트워크 이름과 IP 주소를 추가한다.

Windows 2000에서는 c:\WINNT\system32\drivers\etc\hosts에 hosts 파일이 있다. UNIX의 경우는 /etc

에 hosts 파일이 있다. 이 파일에 www.foo.com과 www.bar.com 호스트를 다음과 같이 등록한다.

111.111.111.1 www.foo.com

111.111.111.2 www.bar.com

7.3.2. WEBMain.xml에 가상 호스트 설정

WEBMain.xml에 가상 호스트를 설정하기 위하여 <context-group>에 <virtual-host> 태그를 추가한다.

다음은 “7.2. 가상 호스트의 기본 개념”의 [그림 7.3]을 설정한 예이다.

다음의 예제에서 Context Group “B”의 가상 호스트 “C”가 어떻게 2개의 hostname을 가지는지 주의깊게

확인한다.

[예 7.1] 가상 호스트 설정 : <<WEBMain.xml>>


. . .

<context-group>

<group-name>A</group-name>

<virtual-host>

<virtual-host-name>A</virtual-host-name>

<host-list>www.foo.com</host-list>

</virtual-host>


<virtual-host>

<virtual-host-name>B</virtual-host-name>

<host-list>www.bar.com</host-list>

</virtual-host>


. . .


. . .

</context-group>

<context-group>

<group-name>B</group-name>

<virtual-host>

<virtual-host-name>C</virtual-host-name>

<host-list>www.foo.com</host-list >

<host-list>www.bar.com</host-list >

</virtual-host>


. . .


. . .

</context-group>

. . .

</web-container>


● <virtual-host>

설명태그

가상 호스트를 참조하기 위해 내부적으로 사용하는 이름이다.<virtual-host-name>

여기에 "__DEFAULT_HOST__"를 사용해서는 안 된다. 이것은 기본 가상 호

스트를 위해 사용되는 것이기 때문이다.

DNS 이름 또는 IP 주소를 포함하는 복수 개의 태그이다. 같은 Context Group

에는 유일한 hostname만이 올 수 있다.

<host-list>

참고

이름 “A”, “B”, “C”는 간략성을 위해 표현되었다. 실제 환경에서는 의미 있는 이름이 사용되어야 한다.


7.4. 가상 호스트를 통한 Context 요청본 절에서는 가상 호스트 내에 존재하는 Context를 접근하기 위해 URL을 요청하는 방법에 대해서 설명한

다. URL 매칭에 대한 일반적인 규칙에 대해 알아보고 예를 들어 이를 설명한다.

7.4.1. URL 매칭에 관한 기본 규칙

가상 호스트를 통한 Context 요청을 하기 위해서 URL의 매칭 정보를 생성해야 한다.

다음의 4가지 규칙은 사용자가 제공하는 요청 내의 URL이 가상 호스트가 존재하는 환경에서의 특정

Context와 매칭되는지 결정한다.

1. 사용자의 URL 요청 경로가 실제 Context에 매칭되는 기본적인 규칙은(가상 호스트의 사용 여부에 상

관없이) 다음과 같다.

도메인 이름(예, www.foo.com) 이후의 URI 부분을, 등록된 Context 중에서 가장 긴 Context URI 경로

에 매칭한다. 만약 매칭이 발견되면 그 Context를 사용한다.

2. 가상 호스트가 설정되어 있으면, 먼저 사용자의 URL에 있는 도메인 이름을 등록된 모든 가상 호스트의

네트워크 이름에 매칭시킨다. 그 후에 이 가상 호스트에 설정된 모든 Context들을 찾는다. 마지막으로,

위의 규칙 1을 이 Context에 적용시킨다.

3. 규칙 2에서 Context가 발견되지 않았으면 기본 가상 호스트에 규칙 1을 적용시킨다.

4. 기본 가상 호스트에도 Context가 발견되지 않으면, 기본 Context가 규칙 1에 적용된다.

7.4.2. URL 매칭의 예

다음은 WEBMain.xml의 가상 호스트 설정의 예이다.

[예 7.2] 가상 호스트의 설정 : <<WEBMain.xml>>


. . .

<context-group>


<virtual-host>

<virtual-host-name>vhost1</virtual-host-name>

<host-list>www1.foo.com</host-list>

</virtual-host>

<virtual-host>


<host-list >www2.foo.com</host-list>

<host-list >www3.foo.com</host-list>

</virtual-host>


. . .



. . .

</context-group>

. . .

</web-container>

다음은 JEUSMain.xml의 가상 호스트 설정의 예이다. JEUS_HOME은 c:\jeus6로 가정한다.

[예 7.3] 가상 호스트의 설정 : <<JEUSMain.xml>>


<node>

<name>tmax1</name>

. . .

</node>

<application>

<name>vhost1ctx1</name>

<path>

c:\jeus6\webhome\app_home\vhost1ctx1

</path>

<deployment-target>

<target>


tmax1_container1


<web-context-group>




</target>



<web-component/>

</application>

<application>


<path>


</path>

<deployment-target>

<target>


tmax1_container1


<web-context-group>





</target>



<web-component/>

</application>

<application>


<path>


</path>

<deployment-target>

<target>


tmax1_container1


<web-context-group>




</target>



<web-component/>

</application>

<application>


<path>


</path>

<deployment-target>

<target>


tmax1_container1


<web-context-group>




</target>



<web-component/>


</application>

<application>

<name>default1</name>

<path>

c:\jeus6\webhome\app_home\default1

</path>

<deployment-target>

<target>


tmax1_container1


<web-context-group>



</target>



<web-component/>

</application>

<application>


<path>


</path>

<deployment-target>

<target>


tmax1_container1


<web-context-group>



</target>



<web-component/>

</application>

<application>


<path>


</path>

<deployment-target>

<target>



tmax1_container1


<web-context-group>



</target>



<web-component/>

</application>

</jeus-system>

마지막으로 각각의 애플리케이션에 따른 jeus-web-dd.xml 파일에 대한 예이다.

[예 7.4] vhost1ctx1 : <<jeus-web-dd.xml>>



<context-path>/vpath1</context-path>


</jeus-web-dd>






</jeus-web-dd>






</jeus-web-dd>

[예 7.7] vhost2ctx2 :<<jeus-web-dd.xml>>



<context-path>/vpath3/subdir</context-path>


</jeus-web-dd>


[예 7.8] default1 : <<jeus-web-dd.xml>>



<context-path>/default1</context-path>


</jeus-web-dd>

[예 7.9] default2 :<<jeus-web-dd.xml>>



<context-path>/default2</context-path>


</jeus-web-dd>

[예 7.10] default3 : <<jeus-web-dd.xml>>





</jeus-web-dd>

다음의 예는 위의 설정을 기반으로 하였을 때 어떤 context(“default1”, “default2”, “default3”, “vhost1ctx1”,

“vhost1ctx2”, “vhost2ctx1”, “vhost2ctx2”, default context)가 주어진 URL 요청에 매칭되는지 보여준다.

http://www1.foo.com/vpath2/test.jsp

vhost1ctx2

http://www1.foo.com/default2/test.jsp

default2 (in default virtual host)

http://www.foo.com/vpath3/test.jsp


http://www2.foo.com/vpath3/test.jsp

vhost2ctx1

http://www3.foo.com/vpath3/subdir/test.jsp

vhost2ctx2

http://www.foo.com/default1/test.jsp


참고

위의 예는 단지 개념을 설명하기 위한 것이다. 실제 설정에서는 좀 더 주의해야 한다.


제8장 JEUS WebCache

본 장에는 웹 애플리케이션의 성능 향상을 위한 JEUS WebCache를 적용하는 방법을 설명한다.

8.1. 개요동시 요청자 수의 증가로 인하여 응답 속도가 떨어지는 등의 웹 애플리케이션 성능 저하 문제가 발생한다

면 하드웨어 측면과 소프트웨어 측면의 해결 방법이 있을 것이다.

하드웨어 측면의 해결책은 서버를 증설하여 계속 들어오는 요청(request)을 로드 밸런싱(load balancing)

하여 부하를 분산하여 응답 속도를 높이는 방법이다. 그러나 이 방법은 서버 추가에 대한 비용 증가와 클

러스터링 등으로 인한 서버 운용 및 관리의 복잡함을 야기시킬 것이다.

소프트웨어 측면의 해결책은 서버 증설없이 웹 애플리케이션에서 많이 사용되는 데이터를 캐싱하는 것이

다. 그러면 다음 요청에서는 데이터의 재생산없이 캐싱된 데이터를 이용함으로써 웹 애플리케이션의 응

답시간을 줄여서 성능을 향상시킬수 있다.

본 절에서는 JEUS 시스템에서 웹 애플리케이션의 성능 향상을 위해서 JEUS WebCache를 어떻게 적용

할 수 있는지에 대해서 알아 볼 것이다. 제공되는 캐싱 방법은 다음과 같다.

● JSP Caching

태그 라이브러리(Tag Libarary)를 사용하여 JSP 내의 일부분을 캐싱한다. 전체 페이지 중에서 부분 변

경이 발생하는 JSP 페이지 요청하는 경우에 적합하다.

● HTTP Response Caching

HTTP 응답 전체를 캐싱한다. Static Content에 대한 요청에 적합하다.

JEUS WebCache에 캐싱되는 엔트리는 SoftReference로 구현되어있다. 그래서 심각한 메모리 증가로 인

한 OutOfMemory 에러를 미연에 방지할 수 있다.

캐싱 기능을 효과적으로 사용하기 위해서 빈번하게 요청되거나, 수행 로직이 복잡해서 또는 DB로부터 데

이터를 가져오는 시간이 오래 걸려 응답시간이 길어질수 있는 웹 페이지를 캐싱 대상으로 선택하는 것이

바람직하다.

제8장 JEUS WebCache 159

8.2. JSP CachingJSP Caching은 JSP 태그 라이브러리를 사용하여 JSP 페이지 내의 일부분을 JEUS WebCache에 저장함

으로써 웹 애플리케이션의 성능을 향상시키는 방법이다.

8.2.1. 기본 내용

JEUS WebCache에서는 사용자 정의(custom) 태그로 jeus:cache를 사용한다. JSP 페이지 내에서 캐싱

을 원하는 콘텐츠가 있는 부분을 이 태그로 감싸면 첫 번째 요청에서 태그 내의 바디 콘텐츠(body contents)

가 생성되어 브라우저에 전송되고 이 콘텐츠는 캐싱된다. 다음 요청부터는 메모리에 캐싱된 콘텐츠가 브

라우저로 보내진다.

jeus:cache태그를 사용하는 기본적인 형식은 다음과 같다.

<%@ taglib uri=”http://www.tmaxsoft.com/jeuscache” prefix=”jeus” %>

<jeus:cache name=”...” key=”...” scope=”...” timeout=”...”

size=”...” async=”...” df=”...”>

. . . Body content to be cached. . .

</jeus:cache>

위 설명에서 제외된 flush 속성은 닫힌 태그(/>)를 사용하는데 이 후 절에서 설명된다.

JSP 캐싱에서 사용하는 알고리즘은 LRU이다. 그래서 JEUS WebCache 최대 허용 개수를 초과하면 LRU

알고리즘에 의해서 기존에 캐싱된 엔트리가 제거된다.

그리고 TLD(Tag Libarary Descriptor) 파일은 'jeus.jar' 파일에 포함되어 배포되며 그 위치는

'jeus/servlet/cache/resource/jeuscache.tld이다. jeuscache.tld' 파일에 대한 URI 정보를 JSP Engine에 전

달하기 위해서 jeus:cache 태그 내의 taglib URI를 반드시 'http://www.tmaxsoft.com/jeuscache'으로 명시

해야 한다.

다음은 "name속성", "name속성 + key속성"을 사용하여 엔트리를 캐싱할 때 사용하는 자료 구조이다.

[그림 8.1] 엔트리 캐싱에 사용되는 자료구조

Key1

Key2

Key3

Entry

Entry

Entry

Name1

Name2

Name3

Entry

Entry

위 그림에서 Name1, Name3은 key 속성 없이 name 속성만으로 태그를 사용할 때 엔트리가 캐싱되는 방

식이며 key 속성은 물론 name속성까지도 사용되지 않을 때도 이 방식이 사용된다. 그러나 name 속성과

key 속성 모두가 사용되는 태그에서는 Name2와 같은 방식으로 엔트리가 캐싱된다.


이제부터 jeus:cache사용자 정의 태그 내에서 사용할 수 있는 속성들에 대해서 알아보자.

8.2.2. <cache> 태그

다음은 jeus:cache 사용자 태그를 정의한 jeuscache.tld로, 이 파일은 jeus.jar 내에 'jeus/servlet/cache/re

source/jeuscache.tld'에 위치한다.

[예 8.1] <cache> 태그 설정 : <<jeuscache.tld>>

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag

Library 1.2//EN" "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd">

<taglib>

<tlib-version>1.0</tlib-version>

<jsp-version>1.2</jsp-version>

<short-name>jeuscache</short-name>

<uri>http://www.tmaxsoft.com/jeuscache</uri>

<display-name>JEUSCache Tag Library</display-name>

<tag>

<name>cache</name>

<tag-class>jeus.servlet.cache.web.tag.CacheTag</tag-class>

<body-content>JSP</body-content>

<description>JEUS WebCache</description>

<attribute>

<name>flush</name>

<required>false</required>

<rtexprvalue>true</rtexprvalue>

</attribute>

<attribute>

<name>timeout</name>



</attribute>

<attribute>

<name>scope</name>



</attribute>

<attribute>

<name>name</name>



</attribute>

<attribute>


<name>size</name>



</attribute>

<attribute>

<name>key</name>



</attribute>

<attribute>

<name>async</name>



</attribute>

</tag>

</taglib>

다음은 각 태그의 속성에 대한 설명이다.

● <name>

– 여러 페이지에서 캐싱된 데이터를 공유하기 위해서 사용되며 해당 scope 내에서 유일해야 한다.

– name 속성을 지정하지 않았을 때는 HTTP URI 정보 등을 사용하여 내부적으로 생성하여 관리된다.

jeus:cache 내 바디 콘텐츠가 공유될 필요가 없다면 이 속성을 설정하지 않는 것이 바람직하다.

● <key>

– 캐싱되는 엔트리를 식별하는 추가적인 값이다. 이 속성은 name 속성과 반드시 함께 사용되어야 한다.

그래서 엔트리를 식별할 때는 name + key 값이 유일한 식별자로 사용된다.

– key 속성은 다음과 같은 scope를 지정하는 나열 형식으로 설정 가능하다.

<jeus:cache name=”. . . ”

key=”[parameter|page|session|request|application].keyname” . . . >

● <scope>

– Cache되는 엔트리의 운용 범위를 나타낸다. 유효한 값으로는 ‘application’과 ‘session’이다.

– 기본값: ‘application’

● <timeout>

– 콘텐츠가 캐싱될 기간을 설정하며 Simple Date Format 형식으로 명시된다.(기본값: 1시간)

– 숫자와 시간을 나타내는 한 문자의 결합으로 표시한다. 기간을 명시하는 유효한 문자는 ‘s’(seconds),

‘m’(minutes), ‘h’(hours), ‘d’(days), ‘w’(weeks)이다.

예를 들어 10s는 10초를 , 10d는 10일을, 그리고 4w는 4주는 나타낸다. 그리고 문자 없이 숫자만 설

정하면 초(second) 단위로 인식한다. 그리고 0으로 설정하면 매번 바디 콘텐츠를 생성하여 refresh 효

과를 낼수 있다. -1이 설정된다면 강제로 flush되지 않는 한 콘텐츠는 expire되지 않는다.


● <size>

– 캐싱할 수 있는 객체의 최대 개수를 설정한다. 설정된 값을 초과했을 경우에는 LRU 알고리즘에 따라

서 Cache에 저장된 객체가 제거된다. 이 값은 웹 애플리케이션 상황에 맞게 적절하게 설정되어야 한

다.

– 기본값: Integer.MAX_VALUE

● <async>

– 하나의 thread가 엔트리를 업데이트하고 있을 경우(아직 완료되지 않은 상태)에서 동일한 엔트리를

요구하는 다른 thread에 대해서 blocking 여부를 설정한다.

설명설정값

thread는 blocking되지 않고 이전 엔트리 즉, 업데이트되지 않은 엔트리를 가져간다.true

(기본값 : true)

엔트리가 업데이트될 때까지 기다린(blocking)후 최신 엔트리를 가져간다.false

● <df>

– overflow가 발생했을 경우 공간확보를 위해서 엔트리를 제거한다. 이때 제거되는 victim 개수를 설정

된 "size 속성"에 대한 비율을 "df 속성"으로 설정할 수 있다. 유효한 값의 범위는 '0.0 <= factor <= 1.0'

사이의 실수값이다.

예를들어 factor 1.0는 메모리에 Cache되어 있는 모든 엔트리를 제거한다는 의미이며, factor 0.0은

overflow가 발생할 경우 추가 요청에 대해 더 이상 Cache하지 않는다는 의미이다.

– 기본값: 0.25

● <flush>

– Cache내 엔트리를 제거하기 위해서 사용한다. 특정 엔트리를 제거하기 위해서는 반드시 "name 속

성"이나 "name 속성 + key 속성"을 지정해야 된다.

– 한 가지 주의할 것은 "name 속성"에 "key속성"을 이용해서 다수의 엔트리를 캐싱한 경우 "name 속

성"만을 사용하여 "flush 속성"을 수행할 때 "key 속성"을 식별자로 하는 모든 엔트리가 제거된다. 그

리고 이 속성은 다른 속성과는 다르게 바디 콘텐츠가 없는 닫힌 태그(/>)를 사용한다.

8.2.3. jeus:cache 사용 예

본 절에서는 jeus:cache 태그 속성의 사용법에 대하여 설명한다.

다음은 cache.jsp 페이지를 요청하는 경우 현재 날짜와 캐싱된 날짜를 비교해보는 간단한 예제이다.

[예 8.2] <<cache.jsp>>

<%@ taglib uri=”http://www.tmaxsoft.com/jeuscache” prefix=”jeus” %>

<HTML>


<BODY>

Current time: <%= new Date() %><br>

<jeus:cache timeout=”60s”>

Cached time: <%= new Date() %>

</jeus:cache>

</BODY>

</HTML>

jeus:cache 태그의 첫 번째 요청에서는 현재 날짜를 구하여 화면에 출력되고 JEUS WebCache에 저장된

다. 다음 호출부터는 캐싱된 날짜가 출력될 것이다. 60초가 지난 다음에는 갱신된 날짜가 출력된다.

다음은 jsp:include를 사용하여 다른 페이지를 포함할 때 jeus:cache 태그를 사용하는 예이다.

[예 8.3] <<main.jsp>>

<HTML>

<BODY>

<jsp:include page="cache.jsp"/>

</BODY>

</HTML>

Main.jsp에 include된 cache.jsp 내의 jeus:cache 태그의 내용은 cache.jsp만 사용하는 첫 번째 예제와 동

일한 수행 결과를 출력한다.

8.2.4. flush 기능 사용

flush 기능은 캐싱된 엔트리를 강제로 제거하는 기능이다. 대상이 되는 엔트리를 지정하는 "name 속성" 또

는 "name 속성 + key 속성"을 반드시 명시해야 한다.

예를 들어서 다음과 같이 "name 속성 + key 속성"을 사용해서 stock content를 캐싱했다고 가정하자.

<jeus:cache name=“stock” key=”parameter.company” scope=”application”>

. . . stock content . . .

</jeus:cache>

캐싱된 parameter.company에 해당하는 stock content를 제거하기 위해서는 다음과 같이 설정한다.

<jeus:cache name=“stock” key=”parameter.company” scope=”application”

flush=”true”/>

위와 같이 flush 기능을 성공적으로 수행했다면 다음번 jeus:cache 태그 내의 stock content를 요청하는 경

우에는 갱신된 stock content를 보게 된다. 만일 위 flush 속성을 다음과 같이 "key 속성" 없이 "name 속

성"만을 사용한다면 parameter.company key 속성으로 저장된 모든 엔트리가 제거될 것이다.

<jeus:cache name=“stock” scope=”application” flush=”true”/>

물론 key 속성을 사용하지 않고 name 속성만으로 엔트리를 캐싱했다면 당연히 name 속성만 사용하면 된

다.


8.2.5. refresh 기능 사용

모든 jeus:cache 태그를 호출할 때마다 바디 콘텐츠를 생성하게 하는 refresh기능을 제공한다.

이 기능은 jeus:cache 태그 속성을 사용하지 않는다. 대신 ‘_jeuscache_refresh’를 키로, true를 값으로 해

서 원하는 scope에 설정할 수 있다.

애플리케이션과 session scope의 모든 엔트리를 refresh하기 위해서는 다음과 같이 각각 작성한다.

<% application.setAttribute(“_jeuscache_refresh”, “true”); %>

<% session.setAttribute(“_jeuscache_refresh”, “true”); %>

이 기능은 jeus:cache 태그에 접근했을 때 각각의 scope에 '_jeuscahe_refresh' 값을 조사하여 true일 경

우 그 바디 콘텐츠를 갱신한다. 그리고 더 이상 refresh 기능을 사용하지 않기를 원한다면 '_jeuscahe_re

fresh'을 false로 지정한다.

timeout 속성, flush 속성을 사용하면 하나 또는 일부분의 갱신된 엔트리를 볼 수 있는 반면, refresh기능을

사용하면 설정한 scope 내의 모든 바디 콘텐츠가 매번 갱신된다.

8.3. HTTP Response CachingJEUS WebCache는 servlet filter를 사용하여 HTTP 응답 전체를 캐싱하는 방법을 제공한다.

페이지 내용이 동적으로 변하는 웹 페이지에는 적절하지 않으며 Static Content에 대한 HTTP 요청에 적합

한 방법이다. 이미지 파일, PDF 등의 바이너리 콘텐츠를 요구하는 HTTP 요청이 여기에 해당 된다. 물론

일정시간 동안 웹 페이지의 내용이 변경되지 않거나 변경사항이 반영되지 않아도 되는 웹 페이지에도 이

방법을 사용할 수 있다.

주의할 것은 HTTP 응답의 상태가 200 OK(HttpServletResponse.SC_OK)인 경우에만 해당 HTTP 응답이

캐싱된다는 것이다. HTTP response를 JEUS WebCache에 저장할 때 사용되는 엔트리 키로 HTTP URI가

사용된다.

http://www.sample.com/filter/respcacheTest.jsp?key=value

위와 같이 key, value를 포함해서 전체 HTTP URI가 엔트리 키로 적용된다. 만일 key, value 값이 다양하게

변화한다면 각각의 URI에 해당하는 HTTP response가 캐싱된다.

이제부터 HTTP response Caching을 웹 애플리케이션에 어떻게 적용하는지 살펴보자.

8.3.1. 필터 설정

웹 애플리케이션에서 HTTP response Caching을 사용하기 위해서는 다음과 같이 web.xml에 필터를 등록

한다. 다음은 <url-pattern>이 '/filter/'인 모든 HTTP 요청에 대한 HTTP 응답을 10분 동안 캐싱하는 예제이

다. 주의할 것은 <filter-class>로 반드시 jeus.servlet.cache.web.filter.CacheFilter 클래스를 사용해야 된

다.


[예 8.4] 필터 설정 : <<web.xml>>

<web-app>

. . .

<filter>

<filter-name>CacheFilter</filter-name>

<filter-class>jeus.servlet.cache.web.filter.CacheFilter </filter-class>

<init-param>

<param-name>timeout</param-name>

<param-value>600</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>CacheFilter</filter-name>

<url-pattern>/filter/*</url-pattern>

</filter-mapping>

. . .

</web-app>

다음은 필터 클래스에 전달하는 초기화 파라미터에 대한 설명이다.

● timeout

– HTTP response를 캐싱하고 있을 시간을 설정한다. 단위는 초(second)이며 기본 값은 1시간이다.

– JSP Caching에서 사용하는 timeout속성과 설정 방법이 동일하다. 단 HTTP response Caching에서는

flush기능이 제공되지 않기 때문에 timeout을 ‘-1’로 설정하면 웹 애플리케이션이 UnDeploy되지 않는

한 expire되지 않기 때문에 주의한다.

● lastModified

– HTTP 응답으로 Last-Modified 헤더를 보낼지를 결정하기 위해서 사용된다. 이는 웹 컨테이너의 부

하를 줄이는 목적으로 사용된다.

– 브라우저는 자신이 Cache하고 있는 콘텐츠가 마지막 요청 이후에 변경되었는지 웹 컨테이너에 요청

할 수 있다. 그러면 웹 컨테이너는 HTTP 요청에서 If-Modified-Since 헤더 정보와 현재 엔트리의 최

종 변경시간을 비교하여 엔트리에 변경사항이 없다는 304 상태코드(HttpServletRe

sponse.SC_NOT_MODIFIED)를 브라우저로 전송한다.

– 유효한 값은 ‘on’, ‘off’, 그리고 ‘initial’이다.

‘off’로 설정하면 HTTP 응답으로 304 상태코드를 보내지 않는다. ‘on’과 ‘initial’은 304 상태코드를 보

내는데, ‘initial’은 최종 변경시간을 현재시간으로 하고 ‘on’은 filter chain 수행 중에 결정될 것이다. 기

본값은 ‘initial’이다.

● expires

– HTTP 응답으로 Expires 헤더 정보를 전송할지를 결정하기 위해서 사용된다. 브라우저에서 Cache

기능을 사용하고 있다면 Cache된 콘텐츠는 사용 기간이 만료될 때까지 유효하며 이후에 계속적인

HTTP 요청에 대해서는 브라우저 Cache에 저장된 콘텐츠를 사용할 것이다.


– 그런데 만일 JEUS WebCache의 엔트리가 업데이트되었다고 했을 때 새로운 엔트리는 브라우저

Cache에 저장된 콘텐츠와 다른 문제가 발생한다. 이런 경우에 웹 컨테이너에서 Expires 헤더 정보를

설정하여 브라우저 Cache에 저장된 콘텐츠를 기간만료시키고, JEUS WebCache의 업데이트된 엔트

리를 사용하도록 해야한다.

– 유효한 값으로 ‘on’, ‘off’, 그리고 ‘time’이 있다.

‘off’는 Expires 헤더정보를 전송하지 않기 위해서 사용한다. ‘on’과 ‘time’은 Expires 헤더 정보를 전송

한다. ‘on’은 filter chain에서 값이 설정된다면 헤더 정보를 전송하고, ‘time’은 HTTP 응답의 last-modified

값에 상기에 기술한 time 파라미터 값이 더해져서 Expires 헤더 정보로 설정되어서 클라이언트로 전

송된다.

여기에 scope, size, async, df 들을 설정할 수 있는데 이들은 “8.2. JSP Caching”에서 설명한 것과 동일

한 의미를 가지고 있으므로 해당 부분을 참조한다.


제9장 Reverse Proxy

본 장에서는 Reverse Proxy의 기본 개념과 사용 방법을 예제를 통해서 설명한다.

9.1. 개요Reverse Proxy는 실제 요청을 처리하는 서버의 앞 단에 존재하며, 실제 서버로 들어오는 요청을 대신 받

아서 해당 서버에 전달해 주고 그 결과를 받아서 요청한 곳으로 전달해주는 역할을 하는 서버를 말한다.

Reverse Proxy는 보안(실제 서버를 외부에 숨길 때) 및 부하 분산(여러 서버에서 요청을 처리할 때) 등의

이유로 필요하다.

9.1.1. 적용 예시

example.com이라는 회사가 인터넷을 통해 접근가능한 public IP 주소와 DNS 엔트리를 가진 www.exam

ple.com이라는 웹 사이트를 가지고 있다고 하자.

이 회사는 또한 방화벽 내에 private IP 주소와 등록되지 않은 DNS 엔트리를 가진 여러 애플리케이션 서버

를 가지고 있다. 이런 해당 네트워크 내의 애플리케이션 서버로 "internal1.example.com"과 "internal2.ex

ample.com" 이 있다고 하자. 이 서버들은 public DNS 엔트리를 갖지 않으므로, 회사 외부로 부터 inter

nal1.example.com으로 접근이 안되고 "no such host" 에러가 발생할 것이다.

그런데, 이 애플리케이션 서버로 웹 접근을 해야 된다고 결론이 난 것이다. 당연히 인터넷을 통해 직접적

으로 Export할 수는 없고, 해당 웹 서버로 통합되긴 해야 하므로, 내부적으로 다음과 같이 매핑한다.

● http://www.example.com/app1/any-path-here → http://internal1.example.com/any-path-here 매핑

● http://www.example.com/app2/other-path-here → http://internal2.example.com/other-path-here 매핑

다음은 Reverse Proxy 사용을 위해 작성해야 하는 주요 파일에 대한 설명이다.

설명파일명

Reverse Proxy 기능을 하는 필터를 설정한다. 서버 내용이 있는 파일을

지정한다.

WEB-INF/web.xml

<jeus-web-dd><context-path> 설정에 서비스를 제공하는 경로를 지정

한다.

WEB-INF/jeus-web-dd.xml

Reverse Proxy를 하는 서버를 지정한다.WEB-INF/config/data.xml

data.xml 파일 작성을 위한 샘플 파일이다.WEB-INF/config/sample.xml

제9장 Reverse Proxy 169

9.2. 사용 방법본 절에서는 JEUS의 Reverse Proxy를 사용하기 위한 방법을 설명한다.

Reverse Proxy를 사용하기 위해서는 webhome\app_home에 ReverseProxy 기능을 활성화시키는 애플리

케이션을 디플로이해야 한다. 여기에서는 애플리케이션의 이름을 ReverseProxy라고 가정한다.

Reverse Proxy 기능을 사용하기 위한 설정 과정은 다음과 같다.

1. Proxy 서버 설정

2. Context Path 설정

3. Proxy Filter 설정

4. 디플로이

9.2.1. Proxy 서버 설정

Reverse Proxy 사용을 위해 먼저, ReverseProxy\WEB-INF\config\ 아래에 proxy될 서버의 내용을 담은

data.xml 파일을 생성한다. 이 파일에서 설정하는 내용은 proxy해야 할 실제적인 서버의 내용이다. Proxy

할 서버의 주소와 이 서버로 서비스할 규칙(rule)을 설정할 수 있다.

서버의 종류는 다음 2가지이다.

● <server>

– 특정 요청에 대해서 하나의 서버를 proxy할 때 설정한다.

– <server>는 다음과 같은 하위 설정 항목을 가진다.

• <domain-name>

실제 서버의 호스트명이다. host name:port 혹은 ip address:port 등으로 설정할 수 있다.

www.remote.com:8088

• <path>

실제 서버의 특정 디렉터리 하위의 항목을 proxy하고 싶을 때 설정한다. <path>/content</path>라

고 설정하면 www.remote.com:8088/content 가 proxy된다.

• <rewrite>

절대 주소를 rewrite할지 여부를 결정한다(true|false).

• <rule>

서버에 적용될 요청을 정의할 수 있다. 이 규칙에 해당하는 요청에 대해서 해당 서버의 내용을 proxy

하게 된다.

다음은 요청을 구분하는 proxy 규칙이다. JEUS는 다음 2가지 규칙을 지원한다.


설명항목

특정 디렉터리 요청에 적용되는 규칙이다. www.proxy.com이 proxy 서버이

고, www.proxy.com/remote/라는 요청에 대해서 특정 서버를 proxy하고 싶을

때 사용한다.

<directory-rule>

<directory-rule>에서 정의된 규칙 이외의 모든 요청에 적용되는 규칙이다. 각

규칙들은 위에서 순서대로 적용되기 때문에 이 규칙은 가장 마지막 항목에

넣어야 한다.

<accept-everthing-rule>

● <cluster-server>

같은 요청에 대해서 여러 서버가 proxy할 경우에 설정한다. 이 태그 하위에 <server>라는 태그를 가지

고, 이것의 설정은 <server>와 비슷하다.

각 설정은 “9.3. 설정 예”를 참고하여 조금 수정해서 작성한다.

data.xml은 다음과 같은 내용의 문법 정의를 ReverseProxy\WEB-INF\config\proxy-config.dtd에 가지고 있

어야 한다. 이 파일의 목적은 data.xml 파일의 정형성을 검증하는 것이다.

[예 9.1] <<proxy-config.dtd>>

<?xml version="1.0" encoding="UTF-8"?>

<!ELEMENT config (single-server*, cluster-server*)>



<!ELEMENT

single-server

(domain-name, rewriting?, path?, (directory-rule|accept-everything-rule))>



<!ELEMENT cluster-server (server*, (directory-rule|accept-everything-rule))>



<!ELEMENT server (domain-name, rewriting?, path?)>



<!ELEMENT directory-rule (path)>



<!ELEMENT path (#PCDATA)>



<!ELEMENT accept-everything-rule EMPTY>

<!ELEMENT domain-name (#PCDATA)>



<!ELEMENT rewriting (#PCDATA)>

9.2.2. Context-path 설정

WEB-INF/jeus-web-dd.xml 파일의 <jeus-web-dd><context-path>를 수정하면 proxy 서비스를 제공할

<context-path>를 설정할 수 있다. "/"로 주면 해당 서버의 아래의 모든 요청에 대해서 적용된다.

9.2.3. Proxy Filter 설정

JEUS는 Reverse Proxy 기능을 다음의 2가지 Filter Class를 통해서 제공하고 있다.

● ProxyFilter

data.xml에 정의된 요청을 받아서 해당 서버의 결과를 전달해주는 역할을 한다.

● RewriteFilter

해당 서버에서 받은 결과물에서 링크를 자신의 주소로 rewrite해 주는 역할을 한다.

예를 들어서 www.proxy.com/remote/index.html 라는 요청에 www.server1.com/index.html를 요청자에

게 준다고 할 때 실제 페이지 내용에 href="www.server1.com/links.html"과 같은 절대 주소나

href="/contents.html"와 같은 "/"로 시작하는 주소 등은 proxy 서버의 주소에 알맞게

"www.proxy.com/remote/links.html" 과 "/remote/contents.html"로 변경되어야 한다. 이렇게 html, javascript,

css와 같은 문서 내의 주소를 변경해 주는 역할을 한다.

JEUS에서는 Proxy Filter만 사용하거나 ProxyFilter와 Rewriter Filter를 함께 사용할 수 있다.

각 경우에 따라서 WEB-INF/web.xml 파일을 다음과 같이 설정해야 한다.

● Proxy Filter만 사용할 때


<web-app xmlns="http://java.sun.com/xml/ns/j2ee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee

http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"

version="2.4">

<display-name>j2ep</display-name>

<description>

A J2EE application implementing a reverse proxy.

</description>

<filter>

<filter-name>Proxy</filter-name>

<filter-class>jeus.servlet.reverseproxy.ProxyFilter</filter-class>

<init-param>

<param-name>dataUrl</param-name>

<param-value>/WEB-INF/config/data.xml</param-value>

</init-param>

</filter>

<filter-mapping>


<url-pattern>/*</url-pattern>

</filter-mapping>

</web-app>

● Proxy Filter와 Rewrite Filter를 함께 사용할 때


<web-app xmlns="http://java.sun.com/xml/ns/j2ee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee

http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"

version="2.4">

<display-name>j2ep</display-name>

<description>

A J2EE application implementing a reverse proxy.

</description>

<filter>

<filter-name>Rewriter</filter-name>

<filter-class>jeus.servlet.reverseproxy.RewriteFilter</filter-class>

<init-param>

<param-name>dataUrl</param-name>

<param-value>/WEB-INF/config/data.xml</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>Rewriter</filter-name>


</filter-mapping>


<filter>


<filter-class>jeus.servlet.reverseproxy.ProxyFilter</filter-class>

</filter>

<filter-mapping>



</filter-mapping>

</web-app>

9.2.4. Deploy

위의 설정이 끝난 애플리케이션을 JEUS에 디플로이한다. 디플로이는 “제6장 Web Context(웹 애플리케

이션)”를 참조한다.

9.3. 설정 예다음은 몇 가지 경우에 대한 Reverse Proxy WEB-INF/config/data.xml의 설정 예이다.

CASE 1

Proxy 서버의 호스트명이 www.proxy.com이고 모든 요청에 대해서 www.server1.com/content 을 proxy하

고 싶을 경우 www.proxy.com/index.html을 요청하면 www.server1.com/content/index.html의 내용을 출력

한다.

<config>

<single-server>

<domain-name>www.server1.com</directory>

<path>/content</path>

<rewriting>true</rewriting>

<accept-everything-rule/>

</single-server>

</config>


CASE 2

www.proxy.com/remote로의 요청은 www.server1.com을 proxy하고 www.proxy.com/interna로의 요청은

www.server2.com:8080을 proxy한다.

위 두 경우 이외의 다른 요청에 대해서 www.server3.com을 proxy한다.

<config>

<single-server>

<domain-name>www.server1.com</domain-name>


<directory-rule>

<path>/remote</path>

</directory-rule>

</single-server>

<single-server>

<domain-name>www.server2.com:8080</domain-name>


<directory-rule>

<path>/internal</path>

</directory-rule>

</single-server>

<single-server>

<domain-name>www.server3.com</domain-name>


<accept-everything-rule/>

</single-server>

</config>


제10장 따라하기

다음의 단계를 따라하면 JEUS를 간단하게 체험해 볼 수 있다.

다음의 예에서는 JEUS의 노드명이 “johan”이라고 가정한다. 사용자는 이 노드명을, JEUS가 설치된 머신

의 이름으로 변경해야 한다.

1. JEUS가 시스템에 올바르게 설치되었고 경로와 시스템 변수들이 적절히 설정되어 있는지 확인한다(특

히 시스템 경로에 “JEUS_HOME\bin\“ 디렉터리가 포함되어 있는지 확인한다).

JEUS의 설치는 "JEUS 설치 및 시작하기"를 참고한다.

참고

본 안내서에서는 “JEUS_HOME”이라는 지시어를 사용할 때마다 실제 JEUS의 설치 루트 디렉터리

를 일컫는다고 생각해야 한다(예, “c:\jeus6”).

2. 적어도 1개의 웹 컨테이너(Servlet 엔진)가 시스템에 설정되어 있어야 한다.

“JEUS_HOME\config\johan\” 디렉터리의 JEUSMain.xml 파일에는 다음의 굵은 글씨체와 같은 설정을

포함해야 한다.

[예 10.1] <<JEUSMain.xml>>



<node>

<name>johan</name>

<sequential-start>false</sequential-start>

<engine-container>

<name>mycontainer</name>

<sequential-start>true</sequential-start>

<engine-command>



</engine-command>

</engine-container>

</node>

</jeus-system>

3. JEUSMain.xml 파일에 선언되어 있는 웹 컨테이너와 대응하는 웹 컨테이너 디렉터리가 존재하는지도

확인한다. 즉, 위에서 제시한 “engine1”으로 명명된 웹 컨테이너가 “JEUS_HOME\config\johan\jo

han_servlet_engine1\”와 함께 존재해야 한다.

제10장 따라하기 177

4. “JEUS_HOME\config\johan\johan_servlet_engine1\” 디렉터리에는 WEBMain.xml 파일이 존재해야 한

다. 이 파일은 각 웹 컨테이너의 설정 파일이다.

이 파일은 다음과 같은 항목들을 포함해야 하고, “MyGroup”이라는 Context Group을 웹 컨테이너에 추

가하고 내부 HTTP 리스너가 8088 포트를 사용하도록 설정한다(굵은 글씨 참조).

[예 10.2] <<WEBMain.xml>>



<context-group>



<http-listener>

<port>8088</port>

<thread-pool>

<min>25</min>

<max>30</max>

<step>2</step>

</thread-pool>

</http-listener>


</context-group>

</web-container>

5. 위와 비슷한 설정들이 존재한다고 했을 때 명령창을 실행하고 'jeus' 명령을 입력하면 JEUS Manager

가 실행될 것이다.

6. 다른 명령창을 열고, 이번에는 ‘jeusadmin johan’ 명령을 실행한다(여기서 다시 한 번 “johan”은 사용

자 시스템의 설치 환경에 따라서 달라질 수 있다).

7. 관리자 이름과 패스워드를 입력한다(JEUS를 설치할 때 설정한 정보와 동일하다).

8. jeusadmin이 시작된다. ‘boot’라고 입력한다. JEUS 노드가 엔진 컨테이너들의 엔진들과 함께 기동

(Booting)된다. 이렇게 해서 웹 컨테이너(JEUSMain.xml에 설정된 “engine1”)도 함께 시작된다.

9. 'help' 명령을 실행하면 웹 컨테이너를 모니터링하고 제어할 수 있는 명령어들의 목록이 출력된다.

10.다른 명령창을 열어 ‘jeusadmin johan’ 명령을 실행한다.

11.사용자 이름과 패스워드를 입력한다.

12. jeusadmin의 명령창에서 ‘help’ 명령을 실행한다. 웹 컨테이너를 모니터링하고 제어하기 위한 명령어

들의 목록이 출력된다. 예로 'info' 명령을 수행해 본다.

13. WebAdmin에서 위와 동일한 작업을 하려면 "JEUS WebAdmin 안내서"의 WebAdmin의 시작 및 종료에

대한 설명을 참고한다.

위의 과정에서 문제가 발생했다면, "JEUS 설치 및 시작하기"와 "JEUS Server 안내서"를 참고하여 올바르

게 JEUS 환경을 설정해야 한다. 문제점의 원인을 좀 더 자세히 알아보려면 JEUS 관리자 콘솔 윈도우 로

그에 남겨진 정보를 참고하는 것도 좋은 방법이다.


용어해설

가상 호스트

Virtual Host. 클라이언트 요청을 HTTP 헤더의 도메인 이름에 따라 라우팅되게 한다.

웹 애플리케이션

context를 참조한다.

쿠키

HTTP 요청에 포함된 적은 양의 헤더 정보이다. HTTP 요청할 때 쿠키는 클라이언트를 웹 컨테이너가 식별할

수 있는 정보를 지닌다. 쿠키는 Session ID와 Session Tracking을 구현하기 위하여 기본적으로 사용된다.

클라이언트

JEUS 웹 컨테이너가 이해할 수 있는 프로토콜로 말하고 있는 모든 종류의 소프트웨어 컴포넌트가 “client”로

지칭될 수 있다. 이러한 클라이언트들은 HTTP 웹 브라우저와 지원되는 웹 서버들이 있을 수 있다(Apache와

WebtoB).

클라이언트 요청

클라이언트의 리소스 요청은 웹 서버나 웹 컨테이너에서 받는다. 모든 클라이언트의 요청은 웹 환경일 때 HTTP

프로토콜을 사용한다.

클러스터링

서로 간에 연결된 컴포넌트의 그룹이다. 시스템을 더 안정적이고 효율적으로 만들 때 사용된다.

Apache

Open-source Web Server이다.

context

연관 있는 Servlet들과 JSP들 등 웹 자원을 지칭하는 용어이다. 그러므로, Context는 클라이언트에 의해 요청

되는 각각의 application이 된다.

context group

여러 개의 Context들을 묶고 이들에게 운영시의 기반을 제공한다. “Web Container 내의 Web Container”로 볼

수 있다.

HTTP

Hypertext Transfer Protocol. Web에서 사용되는 프로토콜이다.

HTTPS

HTTP 위에 보안성이 첨가된 SSL 연결을 말한다.

JEUS

Java Enterprise User Solution의 약자이다. 본 안내서에서 소개하는 JEUS 버전 6는 JavaEE 5 호환 WAS이다.

용어해설 179

jeusadmin

JEUS와 엔진을 관리하기 위한 콘솔 툴이다.

jeus-web-dd.xml

JEUS에서만 사용되는 웹 애플리케이션(컨텍스트)을 위한 설정 파일이다.

JEUS Web Server

기능이 제한된 WebtoB 웹 서버이다. 이 버전은 JEUS 6.0에 기본으로 탑재되어 있고 JEUS 웹 컨테이너의 내

부 HTTP 리스너로 사용된다. 상세한 설명은 "JEUS Web Server 안내서"를 참조한다.

JSP

JavaServer Pages의 약자이다. Java 형식의 태그가 포함된 웹 콘텐츠 파일이다(HTML 또는 다른 markup 언

어로 쓰여진다). JSP는 Servlet의 ”반대”로 볼 수 있다. 실행되기 전에 JSP는 Servlet 클래스로 전환이 된다.

jspc

JSP 컴파일러이다. JSP 파일을 Servlet클래스로 미리 컴파일 하기 위해 사용된다.

listener

JEUS에서 사용되는 웹 컨테이너 내부의 작은 모듈을 일컫는다. 이 모듈은 웹 컨테이너와 외부 시스템 간의 통

신을 담당한다. “Listener”라는 용어는 클라이언트로부터의 요청을 듣는다는 의미에서 사용된 것이다. 이 클라

이언트에는 Web Server도 될 수 있고, Web 브라우저도 될 수 있다(Listener의 종류에 따라 다름).

servlet

동적인 웹 콘텐츠(HTML을 동적으로 생성하는 것 같은)를 제공하는 Java 클래스이다.

servlet container

web container를 참고한다.

servlet engine

Servlet과 JSP를 위한 infrastructure을 제공한다. web container 참고한다.

session

동일한 클라이언트에 의해 제한된 시간 내에 수행된 관련 있는 동작들의 집합이다.

session ID

Session을 정의하는 ID이고 따라서 특정 Session에 소속된 클라이언트도 구별하게 된다.

session routing

클라이언트의 요청을 클러스터 내의 해당 웹 컨테이너에게 전달해 줄 수 있는 기능이다.

session server

JEUS에서 사용되는 클라이언트 Session 데이터의 안정적인 공급 저장소이다.

session tracking

한 클라이언트의 Session 데이터(식별자)를 여러 개의 HTTP 요청 중 식별할 수 있는 기능이다.

SSL

Secure Socket Layer이다. 소켓 기반 연결(HTTP와 같은)로 전달된 메시지의 인증과 기밀성, 정합성을 보장한

다.


URL rewriting

Session Tracking을 위해 쿠키를 사용하는 대신 사용할 수 있는 방법이다. HTTP 헤더에 클라이언트 정보를

담는 대신에 클라이언트에 전달되는 웹 문서의 HTTP 링크에 URL 파라미터로 첨가된다.

WAR 파일

Web Archive 파일이다. Context(웹 애플리케이션)를 가지고 있는 표준 JAR 파일이다. 이 용어는 Java EE 스

펙에 정의되어 있다.

WAS

웹 애플리케이션 서버(Web Application Server)의 약자로, 복잡한 웹 애플리케이션을 실행하고 관리하는 미들

웨어이다.

web

본 안내서에서는 HTTP, HTML, Servlet, JSP 등에 관련된 것들을 일컫는다(실제 정의는 HTTP 프로토콜을 의

미한다).

web container

웹 애플리케이션을 실행시키기 위한 최상위의 주요 소프트웨어 컴포넌트이다. 이 컴포넌트는 “Servlet engine”

과 “Servlet Container”와 동격이다.

WEBMain.xml

JEUS 웹 컨테이너의 주 설정 파일이다. 이 파일은 XML 포맷으로 되어 있다.

WebtoB

TmaxSoft의 고성능 웹 서버(HTTP Server)이다.

용어해설 181

색인

Symbols<access-log>, 26

<enable>, 26

<exclude-ext>, 26

<format>, 26

<access-log>의 <format> 설정, 26

<enable-secure>, 102

<jeus-web-dd

<context-path>, 134

<logging>

<filter-class>, 23

<handler>, 23

<level>, 23

<use-parent-handlers>, 23

<session-config>

<distributable>, 17

<reload-persistent>, 18

<session-cookie>, 19

<shared>, 18

<timeout>, 18

<url-rewriting>, 18

<webserver-connection><ajp13-listener>

<ip>, 63

<listener-id>, 63

<output-buffer-size>, 63

<port>, 63

<postdata-read-timeout>, 64

<thread-pool>, 63

<webserver-connection><http-listener>

<allowed-server>, 58

<back-log>, 58

<dispatcher-config-class>, 59

<ip>, 56

<listener-id>, 56


<port>, 56


<scheme>, 58

<selector-count>, 59

<server-access-control>, 58

<thread-pool>, 57

<use-nio>, 58

<webserver-connection><thread-pool>

<active-timeout-notification>, 68

<max thread active time>, 68

<notify-subject>, 68

<notify-threshold-ratio>, 68

<restart-engine-execution>, 68

<restart-subject>, 68

<restart-threshold-ratio>, 68

<thread-interrupt-execution>, 68

<webserver-connection><tmax-listener>

<listener-id>, 65


<port>, 65


<reconnect-timeout>, 65

<selector-count>, 66

<server-group-name>, 65

<server-name>, 65

<thread-pool>, 65

<tmax-address>, 65

<tmax-backup-address>, 66

<tmax-backup-port>, 66

<use-nio>, 66

<webserver-connection><webtob-listener>

<disable-pipe>, 61

<hth-count>, 61

<listener-id>, 61


<port>, 61


<read-timeout>, 62

<reconnect-timeout>, 62

<registration-id>, 61

<request-prefetch>, 61

<scheme>, 61

<thread-pool>, 61

<webtob-address>, 61

색인 183

<webtob-backup>, 62

<webtob-home>, 61

AAccess log, 21

Access log 기본 위치, 21

Access log 필터 설정, 27

Ajp13 리스너, 52

CContext Group, 33

Context Group Architecture, 34

Context Group 디렉터리 구조, 36

Context Group 모니터링, 47

Context Group 설정, 37

Context Group 튜닝, 47

DDefault virtual host, 150

DNS, 151

Hhosts, 151

HTTP/HTTPS 리스너, 51

JJEUS log home (JEUS_LOGHOME), 21

JEUS 시스템, 1

JEUS_HOME, 7

JEUS_WSDIR, 7

jeus.ssl.keypass, 108

jeus.ssl.keystore, 108

jeus.ssl.trustpass, 108

jeus.ssl.truststore, 108

jeusadmin, 7

MMixed Mode, 121

RRequest encoding, 40

Request Url encoding, 39

Response encoding, 40

Response Header 설정, 46

SSession Cookie, 114

Session Tracking, 113

Session Tracking 설정, 123

Session Tracking 튜닝, 126

Shared Session Data, 123

TTCP Handler, 86

TCP 리스너, 51

TCP 클라이언트, 86

Tmax Listener, 52

UURL Rewriting, 122

User log, 21

User log 기본 위치, 21

WWeb Context, 127

Web Context 등록, 131

Web Context 모니터링, 146

Web Context 요청, 144

Web Context 튜닝, 146

Web 디렉터리 구조, 5

WEBMain.xml, 12

WebtoB 리스너, 51

Worker Thread Pool, 52

worker.<node-name>_servlet_<engine-name>.host, 75

worker.<node-name>_servlet_<engine-name>.port, 75

worker.<worker_name>.balance_workers, 72

worker.<worker_name>.connection_pool_minsize, 73

worker.<worker_name>.connection_pool_size, 73

worker.<worker_name>.connection_pool_timeout, 73

worker.<worker_name>.host, 72

worker.<worker_name>.lbfactor, 72

worker.<worker_name>.max_packet_size, 74

worker.<worker_name>.port, 72


worker.<worker_name>.reference, 74

worker.<worker_name>.retries, 74

worker.<worker_name>.socket_timeout, 73

worker.<worker_name>.sticky_session, 72

worker.<worker_name>.type, 71

worker.list, 71

ㄱ

가상 호스트 ID 이름, 148

가상 호스트의 규칙, 148

기본 가상 호스트, 150, 153

ㄴ

네트워크 이름, 148, 153

ㄹ

리스너, 50

리스너 튜닝, 111

ㅂ

분산 Session Serve, 122

ㅇ

웹 애플리케이션, 127

웹 컨테이너 구조, 9

웹 컨테이너 모니터링, 31

ㅈ

자동 모니터링, 13

색인 185

jeus web container 안내서 - tmaxsoft · 2019-04-09 · [그림 1.3] jeus web 모듈에 관련된...

Documents