JEUS Applications & Deployment 안내서

(1)

JEUS Applications & Deployment 안내서

JEUS v6.0 Fix#8

(2)

Copyright Notice

대한민국 경기도 성남시 분당구 서현동 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 Applications & Deployment 안내서 발행일: 2011-11-04

소프트웨어 버전: JEUS v6.0 Fix #8 안내서 버전: v2.1.3

(3)

내용 목차

안내서에 대하여... xi

제1장 애플리케이션... 1

1.1. 모듈과 애플리케이션... 1

1.1.1. 모듈... 2

1.1.2. 애플리케이션... 2

1.2. 공유 라이브러리(Shared Library) ... 4

1.2.1. 개요... 4

1.2.2. 라이브러리 Deploy 및 설정... 4

1.2.3. 애플리케이션에서 라이브러리 참조하기... 6

1.2.4. 클래스 로딩 방식... 7

1.2.5. Version Ordering Rule ... 7

제2장 Deploy ... 9

2.1. Deployment Descriptor ... 9

2.2. 디렉터리 구조... 12

2.3. Deploy 작업과 대상... 13

2.4. 애플리케이션 Deploy ... 14

2.4.1. Runtime Deploy ... 14

2.4.2. Boot-time Deploy ... 14

2.4.3. Auto Deploy ... 14

제3장 애플리케이션 작성 및 Deploy ... 17

3.1. 애플리케이션 작성... 17

3.2. WebAdmin을 이용한 Deploy ... 18

3.2.1. 애플리케이션 관련 메뉴... 18

3.3. jeusadmin을 이용한 Deploy ... 29

3.3.1. 애플리케이션 관련 명령어... 29

3.3.4. AutoDeploy ... 35

3.4. Ant Task를 이용한 Deploy ... 36

3.4.1. build.xml ... 36

3.4.2. build.xml 예제... 37

3.4.3. Ant Task의 실행 과정... 38

3.5. AutoDeploy 설정 방법... 38

3.5.1. 디렉터리에 대한 AutoDeploy ... 38

3.5.2. 애플리케이션에 대한 AutoDeploy 설정... 43

용어해설... 45

색인... 47

(4)

(5)

그림 목차

[그림 1.1] Java EE 모듈 및 애플리케이션 구성... 1

[그림 1.2] .ear archive의 구성... 3

[그림 2.1] JEUS 애플리케이션 디렉터리... 12

[그림 3.1] WebAdmin의 JEUS 노드 트리... 18

[그림 3.2] 어플리케이션 모듈 화면... 19

[그림 3.3] 어플리케이션 모듈 디플로이 화면... 20

[그림 3.4] 영구 모듈 화면... 20

[그림 3.5] WebAdmin을 이용한 Runtime Deploy - 1. 모듈 선택 : 모듈 - 어플리케이션 홈... 21

[그림 3.6] WebAdmin을 이용한 Runtime Deploy - 1. 모듈 선택 : 모듈-디렉토리 선택... 22

[그림 3.7] WebAdmin을 이용한 Runtime Deploy - 1. 모듈 선택 : 절대 경로... 22

[그림 3.8] WebAdmin을 이용한 Runtime Deploy - 1. 모듈 선택 : 파일 업로드... 22

[그림 3.9] WebAdmin을 이용한 Runtime Deploy - 2. 대상 선택... 23

[그림 3.10] WebAdmin을 이용한 Runtime Deploy - 3. 선택 사항... 23

[그림 3.11] WebAdmin을 이용한 Runtime Deploy - 3. 선택 사항 - 컴포넌트별... 24

[그림 3.12] WebAdmin을 이용한 Runtime Deploy - 3. 선택 사항 - 공통 선택 사항... 24

[그림 3.13] WebAdmin을 이용한 Runtime Deploy - 4. 디플로이... 25

[그림 3.14] WebAdmin을 이용한 Boot-time Deploy - 4. 디플로이 : 서버가 종료된 경우... 26

[그림 3.15] 영구 모듈 - 개요... 27

[그림 3.16] 영구 모듈 - 설정... 27

[그림 3.17] 영구 모듈 - 설정 : <application> 설정 보기... 27

[그림 3.18] 영구 모듈 - 설정 : 애플리케이션 대상 설정하기... 28

[그림 3.19] 영구 모듈 - 설정 : 애플리케이션 공통 속성 설정하기... 28

[그림 3.20] 영구 모듈 - 설정 : 각 컴포넌트별 선택 사항 설정하기... 28

[그림 3.21] 애플리케이션 상태... 30

(6)

(7)

표 목차

[표 2.1] Deploy Descriptor(Deployment Descriptor) ... 9 [표 3.1] 애플리케이션 관련 명령어... 29

(8)

(9)

예 목차

[예 1.1] 공유 라이브러리 등록 : <<libraries.xml>> ... 5

[예 1.2] 공유 라이브러리 <files> 태그... 5

[예 2.1] <<jeus-application-dd.xml>> ... 10

[예 3.1] applist 실행 예... 30

[예 3.2] jeusadmin - Runtime Deploy ... 31

[예 3.3] jeusadmin - Boot-time Deploy ... 34

[예 3.4] jeusadmin - Boot-time Deploy 후 <<JEUSMain.xml>>에 애플리케이션 등록... 35

[예 3.5] jeusadmin - AutoDeploy ... 35

[예 3.6] <<build.xml>> ... 37

[예 3.7] <<JEUSMain.xml>>에서 디렉터리에 대한 AutoDeploy 설정... 39

[예 3.8] 특정 엔진 컨테이너에서만 AutoDeploy를 사용하지 않는 경우... 41

[예 3.9] 각 컨테이너 별로 다른 디렉터리를 AutoDeploy로 설정을 한 경우... 42

[예 3.10] 애플리케이션에 대한 AutoDeploy 설정 : <<JEUSMain.xml>> ... 43

(10)

(11)

안내서에 대하여

안내서의 대상

본 안내서는 TmaxSoft의 JEUS 제품군에 포함된 JEUS 서버에 Java EE 애플리케이션 또는 Java EE 모듈 을 Deployment하고 관리하고자 하는 관리자 또는 애플리케이션 개발자를 대상으로 한다.

안내서의 전제 조건

본 안내서를 원활하게 이해하기 위해서는 다음과 같은 사항을 미리 알고 있어야 한다.

● JEUS 서버를 동작시키기 위한 배경 지식

● JEUS 소개

● JEUS Server 안내서

● JEUS 설치 및 시작하기

안내서 구성

본 안내서는 Java EE 애플리케이션과 모듈에 대한 간략한 설명 및 이를 생성하는 방법과 이렇게 생성된 Java EE 애플리케이션과 모듈들을 JEUS 서버에 Deployment할 때 필요한 내용들을 차례로 설명한다.

본 안내서는 총 3개의 장으로 구성되어 있다.

● “제1장 애플리케이션”

모듈과 애플리케이션, 공유 라이브러리(Shared library)에 대해 설명한다.

● “제2장 Deploy”

Deploy의 작업, 대상 등 디플로이와 관련된 전반적인 사항에 대해 설명한다.

● “제3장 애플리케이션 작성 및 Deploy”

Java EE 애플리케이션 파일(EAR)을 작성하고 이를 JEUS에 디플로이하는 방법에 대해 설명한다.

(12)

안내서 규약

의미 표기

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

<<AaBbCc123>>

Ctrl과 C를 동시에 누름

<Ctrl>+C

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

강조 진하게

다른관련안내서또는안내서내의다른장및절언급

" "(따옴표)

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

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

메뉴의 진행 순서

>

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

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

|----

참고 또는 주의사항 참고

주의할 사항 주의

그림 이름 [그림 1.1]

표 이름 [표 1.1]

Java 코드, XML 문서 AaBbCc123

옵션 파라미터 [ command argument ]

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

< xyz >

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

|

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

…

xii JEUS Applications & Deployment 안내서

(13)

시스템 사용 환경

본 안내서는 모든 예제와 환경 구성을 Microsoft Windows™의 스타일을 따랐다. UNIX와 같은 다른 환경 에서 작업하는 사람은 몇 가지 사항만 고려하면 별 무리없이 사용할 수 있다. 대표적인 것이 디렉터리 구 분자인데, Windows 스타일인 “\”를 UNIX 스타일인 “/”로 바꿔서 사용하면 무리가 없다. 이외에 환경변수도 UNIX 스타일로 변경해서 사용하면 된다.

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

연락처

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:info@tmax.co.kr

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

Email:info@tmaxsoft.com

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

Email:info@tmaxsoft.co.jp

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

xiv JEUS Applications & Deployment 안내서

(15)

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

Email:info.cn@tmaxsoft.com

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

(16)

(17)

제 1 장 애플리케이션

본장에서는실제로모듈과애플리케이션이어떻게구성되어있으며, 각각의구성요소에는무엇이있는

지에대해설명한다. 또한이러한구성요소들의 JEUS에서의구조와설정방법, 이렇게작성된애플리케

이션을디플로이하기위해 JEUS에서제공하는기능에대해설명한다.

1.1. 모듈과 애플리케이션

Java EE 애플리케이션은 하나 이상의 모듈로 구성되어 있다. Java EE 모듈은 하나 이상의 동일한 타입인 Java EE 컴포넌트(EJB, 웹 애플리케이션, 애플리케이션 클라이언트, connector)와 Deployment Descrip tor(DD)들로 구성된다. Deployment Descriptor는 Java EE 표준 DD(application.xml 등)와 JEUS DD(jeus- application-dd.xml 등)가 있으며, Java EE 5 이후에서는 표준 DD 없이도 대부분의 설정을 클래스에 Anno tation으로 대체할 수 있다.

다음은 Java EE 모듈 및 애플리케이션 구성이다.

[그림 1.1] Java EE 모듈 및 애플리케이션 구성

(18)

1.1.1. 모듈

Java EE 모듈에는 다음의 4종류가 있다.

● EJB 모듈 (.jar file)

EJB(Enterprise JavaBeans)는 트랜잭션 및 보안 서비스를 이용하는 비즈니스 로직을 구현하기 위한 표 준 서버 측 컴포넌트 모델이다. EJB 모듈은 이러한 EJB들을 표현하고 그룹화하기 위한 개념으로, JEUS 에서는 JEUS EJB 엔진에 배치할 수 있는 가장 작은 단위를 말한다.

따라서 1개의 EJB가 배치된다고 하더라도 반드시 EJB 모듈로 패키지화(.jar file) 되어야 한다. EJB 모 듈의 자세한 내용은 "JEUS EJB 안내서"를 참고한다.

● 웹 애플리케이션(Web application) 모듈 (.war file)

웹 애플리케이션(Web Application) 모듈은 클라이언트의 요청에 의한 웹 기반의 서비스(예를 들면, 장 바구니에 물품을 추가하거나, 장바구니 안의 물품을 구매하거나 웹 기반의 경매 사이트에서 물건을 사 기 위해 브라우징 하는 등)를 실행하기 위한 static content와 dynamic content의 집합이라고 할 수 있다.

웹 애플리케이션 모듈에 대한 자세한 내용은 "JEUS Web Container 안내서"를 참고한다.

● 애플리케이션 클라이언트(Application client) 모듈 (.jar file)

애플리케이션 클라이언트(Application Client)는 별도의 JVM에서 실행되는 클라이언트 프로그램이다.

애플리케이션 클라이언트는 main() 메소드를 호출해서 실행하고, 가상 머신이 종료되면 실행을 마친다.

다른 Java EE 애플리케이션 컴포넌트처럼 애플리케이션 클라이언트는 시스템 서비스를 제공하는 클라 이언트 컨테이너(Client Container) 에서 동작한다. 클라이언트 컨테이너는 다른 Java EE 컨테이너에 비해서 매우 적은 양의 시스템 리소스를 사용한다.

애플리케이션 클라이언트 모듈에 대한 자세한 내용은 "JEUS Application Client 안내서"를 참고한다.

● 리소스 어댑터(Resource adapter) 모듈 (.rar file)

리소스 어댑터(Resource Adapter)는 Java EE 커넥터 아키텍처의 중심 컴포넌트로, 특정 EIS(Enterprise Information System)용으로 개발되어서 EIS와 상호작용하기 위한 API를 제공한다. 또한 Java EE 애플 리케이션 서버와 연동하기 위한 시스템 API도 제공한다. 관리자의 관점에서는 모든 작업이 리소스 어댑 터의 설정과 배치만으로 종료된다.

리소스 어댑터 모듈에 대한 자세한 내용은 "JEUS JCA 안내서"를 참고한다.

1.1.2. 애플리케이션

[그림 1.1]을 보면 Java EE 애플리케이션은 하나 이상의 Java EE 모듈과 2개의 Deployment Descriptor(DD) 로 구성된다. Deployment Descriptor는 Java EE DD(application.xml)와 JEUS DD(jeus-application-dd.xml) 로 구성된다. 이때 Java EE 모듈은 1개 이상의 동일한 타입인 컴포넌트들과 Deployment Descriptor들로 구성되기 때문에 하나의 컴포넌트만으로도 애플리케이션을 만들 수 있다.

Java EE 애플리케이션은 확장자가 '.ear'인 일반적인 jar archive 형식의 파일로, 다음은 EAR 구성의 간단 한 예이다. EAR 파일의 루트 디렉터리에는 애플리케이션에 포함된 각 모듈 archive 파일들과 APP-INF, META-INF 디렉터리가 존재한다.

2 JEUS Applications & Deployment 안내서

(19)

[그림 1.2] .ear archive의 구성

다음은 각 디렉터리에 대한 설명이다.

APP-INF

APP-INF 디렉터리는 공통 라이브러리 디렉터리로 웹 애플리케이션 모듈의 WEB-INF 디렉터리와 비 슷한 기능을 제공한다. WEB-INF와 마찬가지로 APP-INF 또한 하위에 classes와 lib 디렉터리를 가지 고 있으며, 각각 클래스 파일과 '.jar' 파일을 포함한다. 이렇게 APP-INF 아래에 존재하는 classes의 클 래스들과 lib의 jar 파일들은 이 애플리케이션에서 라이브러리로 사용할 수 있다(모든 하위 모듈에서 자동으로 classpath로 인식한다).

또한, Java EE 5에서부터는 JEUS에서 제공하는 APP-INF\lib와 유사한 library directory를 지원하는 데, 이는 application.xml에 <library-directory> 태그로 설정하여 사용할 수 있다. 만약 application.xml 에 <library-directory> 태그를 사용하지 않거나 application.xml 자체가 없는 경우에는 디폴트로 lib라는 이름의 디렉터리를 사용한다.

주의

library directory는 표준이므로 JEUS 6 이후에서는 APP-INF 디렉터리보다는 library directory를 사 용할 것을 권장한다.

META-INF

META-INF 디렉터리에는 2개의 DD가 존재한다. Java EE DD인 application.xml과 JEUS DD인 jeus- application-dd.xml이며, 이 파일들은 없어도 무방하다.

(20)

1.2. 공유 라이브러리 (Shared Library)

본절에서는애플리케이션간에공유되는라이브러리(Shared Library)를추가하고, 사용하는기능에대해 설명한다.

1.2.1. 개요

공유 라이브러리(Shared Library)는 애플리케이션 간에 공유되는 라이브러리로 JEUS 시스템 (JEUS_HOME/lib/system) 또는 애플리케이션(JEUS_HOME/lib/application) 디렉터리에 추가되는 시스템 라이브러리와는 구별된다.

공유 라이브러리(SharedLibrary)는 JEUS 전체 시스템에 영향을 주지 않고 각 애플리케이션에서 해당 라 이브러리를 사용할 것인지 여부를 설정할 수 있으며, JEUS 재기동 없이 동적으로 추가할 수도 있고, 같은 라이브러리를 여러 개의 버전으로 설치하여 선택적으로 사용할 수 있다.

공유 라이브러리는 다음과 같은 특징을 가진다.

● 라이브러리 파일이 애플리케이션 간에 공유될 수 있고 따라서 사용자가 항상 함께 패키징(packaging) 하지 않아도 된다.

● 라이브러리는 JEUS가 구동 중에도 동적으로 추가/삭제될 수 있다.

● 새로운 버전으로 라이브러리를 추가하고 애플리케이션을 ReDeploy해서 업그레이드된 라이브러리를 사용할 수 있다.

● 해당 라이브러리의 여러 버전의 구현체를 등록할 수 있고, 어떤 구현체를 사용할지는 Deployment Time 에 결정할 수 있다.

각 라이브러리는 2개의 버전(specification, implementation)을 가질 수 있다. 이렇게 함으로써 사용자들은 같은 라이브러리의 여러 개의 버전을 설치할 수 있고, 애플리케이션이 필요한 버전을(highest, minimum or exact) Deployment Time에 동적으로 선택하게 한다.

추후에 여러 버전의 라이브러리를 지원하기 위해서는 처음부터 항상 버전을 명기하는 것을 권장하며, 단 순한 use case를 위해서는 버전을 전혀 사용하지 않아도 무방하다. 버전이 명기되지 않았다면 기본적으 로 0라는 버전 값으로 내부적으로 해석한다.

1.2.2. 라이브러리 Deploy 및 설정

하나의 라이브러리는 여러 개의 jar 파일로 구성될 수 있는데 이는 보통 공유 라이브러리 디렉터리인 JEUS_HOME/lib/shared 하위에 위치한다. 그리고 jar 파일들은 JEUS_HOME/lib/shared/libraries.xml 설 정 파일에 다음과 같이 라이브러리로 등록한다.

다음 예에서 'myLibrary'는 2.0 spec을 구현하는 2.1 version의 구현체로 정의하여 등록되었다. 이 라이브 러리는 여러 개의 jar 파일(commons-logging.jar, commons-util.jar, 그리고 myLib -2.1 서브 디렉터리에 있 는 모든 jar 파일)로 구성되어 있다.

(21)

[예 1.1] 공유 라이브러리 등록 : <<libraries.xml>>

<library-name>myLibrary</library-name>

<specification-version>2.0</specification-version>

<implementation-version>2.1</implementation-version>

</files>

</library>

다음은 설정 태그에 대한 설명이다.

● <library-name>, <specification-version>, <implementation-version>

– 애플리케이션이 해당 라이브러리를 참조할 때 사용한다.

– <*-version> 필드는 같은 이름의 라이브러리가 여러 버전으로 관리되는 경우에 사용될 수 있다.

● <files>

실제 라이브러리의 클래스 패스를 명기한다.

<files> 태그는 다음의 예와 같이 여러 가지 방식으로 클래스 패스를 설정할 수 있다.

[예 1.2] 공유 라이브러리 <files> 태그

</files>

– dir 값은 jar 파일이 담긴 디렉터리 또는 classes 디렉터리가 주어질 수 있으며 상대 경로와 절대 경로

모두 사용할 수 있다. 이때, 상대 경로의 경우 기반(base) 디렉터리로 공유 라이브러리 디렉터리인 JEUS_HOME/lib/shared에 대한 상대 경로로 해석된다.

– <include> 서브 태그를 이용하여 어떤 jar 파일들을 포함시킬지 지정할 수 있다. <include> 태그를 전 혀 명기하지 않으면 해당 디렉터리의 모든 jar 파일이 포함된다. 이 경우 해당 디렉터리는 Deploy 시 간에 jar 파일을 동적으로 검색하게 된다. 따라서, 추후에 설정 변경 없이 jar 파일을 디렉터리에 추가 할 수 있다.

jar 파일 디렉터리가 아니라 클래스 디렉터리를 지정하고 싶다면, mode 값을 "classes"로 주어야 한 다.

(22)

– 새로운 애플리케이션이 디플로이될 때 해당 설정이 수정되었다면 다시 읽어서 처리하기 때문에, 라 이브러리는 JEUS가 구동 중에도 동적으로 추가될 수 있다. 따라서, JEUS 재기동 없이도 새로운 라 이브러리 혹은 업그레이드된 버전의 라이브러리를 추가할 수 있다.

참고

위에 설명한 설정은 해당 XML을 직접 수정해서 할 수도 있지만, WebAdmin을 통해서도 설정할 수 있으니, WebAdmin을 사용할 것을 권장한다.

1.2.3. 애플리케이션에서 라이브러리 참조하기

Java EE 애플리케이션이나 standalone 모듈은 jeus-application-dd.xml, jeus-web-dd.xml 또는 jeus-ejb- dd.xml의 Entry를 통해 등록된 공유 라이브러리를 사용할 수 있다.

다음은 공유 라이브러리 'myLibrary'를 참조하는 예이다.

<library-ref>

</library-ref>

위의 예에서, 애플리케이션은 디플로이될 때 라이브러리 이름이 'myLibrary'인 라이브러리를 찾고 해당 클 래스 패스를 애플리케이션 클래스 패스에 추가한다. 여러 버전의 'myLibrary'가 있는 경우, 가장 높은 (highest) 버전을 선택하게 된다.

참조되는 라이브러리 버전이 명기되지 않으면, 항상 “1.2.5. Version Ordering Rule”에 따라 최상위 버전을 찾게 된다. 다음은 최소 버전이 필요한 경우를 보여주는 예이다.

<library-ref>

<specification-version>2.0</specification-version>

<implementation-version>2.0</implementation-version>

</library-ref>

다음은 정확한 버전이 필요한 경우의 예이다.

<library-ref>

<specification-version exact-match="true">2.0</specification-version>

<implementation-version exact-match="true">2.1</implementation-version>

</library-ref>

혹은 정해진 스펙 버전만 명기하고 싶다면 다음과 같이 설정한다. 이렇게 되면 해당 스펙 버전의 최상의 implementation version을 찾게 된다.

<library-ref>

<specification-version exact-match="true">2.0</specification-version>

</library-ref>

(23)

기본적으로 애플리케이션이 디플로이될 때 참조하고 있는 라이브러리를 찾을 수 없다면 WARNING 로그 를 보여주지만, 디플로이는 계속 진행된다. 만약 이런 동작을 원하지 않는다면 다음과 같이 'failonerror' attribute를 설정하여 디플로이를 실패시킬 수 있다.

<library-ref failonerror="true">

</library-ref>

1.2.4. 클래스 로딩 방식

공유 라이브러리의 클래스는 어느 곳에서 라이브러리 레퍼런스(reference)를 정의하고 있느냐에 따라서 애플리케이션 클래스 로더 혹은 모듈 클래스 로더에 의해서 로딩된다.

예를 들어, 'lib1'이 jeus-application-dd.xml에서 레퍼런스로 정의되었다면 EAR 레벨의 애플리케이션 클래 스 로더에 의해서 로딩된다. 하지만 jeus-web-dd.xml에 레퍼런스로 정의되었다면 웹 레벨 클래스 로더에 의해서 로딩된다.

각 애플리케이션 클래스 로더에 의해 로딩된 클래스의 경우 해당 애플리케이션에서만 국한(isolated)되며, 이는 라이브러리도 동일하게 적용된다. 따라서, 클래스 인스턴스는 애플리케이션 간에 공유되지 않는다.

1.2.5. Version Ordering Rule

버전은 "6.2.3-b12"처럼 fraction part(6.2.3)와 non-fraction(string) part(-b12)를가질수있다. Version ::= <fraction_part> | <string_part> | <fraction_part> <string_part>

fraction_part ::= <integer> | <integer> "." <fraction_part>

string_part ::= <non-numeric> <character>*

버전을 Ordering하는 규칙은 다음과 같다.

● <fraction part>를 먼저 수치적으로 비교한다. major, minor 순서로 비교된다.

● <fraction part>가 동일하면 <string part>를 비교한다. 이때 비교는 string 비교 방식을 따른다.

다음은 ordering 규칙에 따른 순서의 예이다.

6.0 < 6.2.3 < 6.2.3-b12 < 6.2.3-beta < 6.2.4

(24)

(25)

제 2 장 Deploy

본장에서는디플로이의작업, 대상등디플로이와관련된전반적인사항에대해설명한다.

2.1. Deployment Descriptor

Java EE 애플리케이션은 EAR(Enterprise ARchive .ear 파일) 형태로 배포된다. 이 파일에는 EJB 모듈(EJB

.jar 파일), 웹 애플리케이션 모듈(.war 파일), 리소스 어댑터 모듈(.rar 파일)과 기타 필요한 Java 클래스를 포함하고 있다. 또한 하나의 모듈로 구성된 standalone 모듈도 Java EE 애플리케이션의 한 종류이다. 이 러한 애플리케이션의 서비스들을 시작하기 위해, JEUS에 모듈 파일을 올리고 제어하는 모든 동작을 De ployment라고 한다.

애플리케이션 서버에 배치를 하기 위한 모듈 또는 애플리케이션을 생성하기 위해서는 Deployment Descriptor 가 필요하다. Deployment Descriptor는 Java EE 표준 DD와 JEUS DD가 있다.

각 모듈과 애플리케이션에 필요한 Deployment Descriptor는 다음과 같다.

[표 2.1] Deploy Descriptor(Deployment Descriptor)

JEUS DD Java EE 표준 DD

jeus-application-dd.xml application.xml

애플리케이션

jeus-ejb-dd.xml ejb-jar.xml

EJB 모듈

jeus-web-dd.xml web.xml

웹 애플리케이션 모듈

jeus-client-dd.xml application-client.xml

애플리케이션 클라이언트

jeus-connector-dd.xml ra.xml

리소스 어댑터 모듈

jeus-webservices-dd.xml webservices.xml

웹 서비스

각 모듈마다 Java EE 표준 DD 이외에 JEUS를 위한 DD를 별도로 가지고 있는 것처럼 Application descriptor 에 대해서도 이에 대응하는 jeus-application-dd.xml이 존재한다. 이 파일은 EAR의 META-INF에 위치한다.

또한 standalone 모듈에서도 존재할 수 있는데, 웹 애플리케이션 모듈에 대해서는 모듈 archive 내의 WEB- INF에 존재하고 다른 모듈에 대해서는 META-INF 내에 존재한다. 이 파일은 애플리케이션에 대한 정교한 설정을 하기 위해 사용한다. 만약 이 파일이 EAR이나 standalone 모듈에 포함되어 있지 않으면 기본 설정 으로 디플로이가 된다.

참고

Java EE 표준 DD에 대한 보다 자세한 내용은 Java EE 5의 스펙을, 각 모듈에 해당하는 JEUS DD 역 시 JEUS의 해당 안내서를 참고한다.

(26)

jeus-application-dd.xml은 jeus-main.xsd의 <application> 항목으로 정의되어 있으며 jeus-application-dd.xml 의 예는 다음과 같다.

[예 2.1] <<jeus-application-dd.xml>>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<name>myApp</name>

<path>myApplication.ear</path>

<deployment-type>EAR</deployment-type>

<ejb-component>

<fast-deploy>true</fast-deploy>

</ejb-component>

<web-component>

<context-root>/web</context-root>

</web-component>

</application>

다음은 <application> 태그의설정항목에대한설명이다.

● 기본 설정

<application> 항목의각설정중기본적인설정을나열하면다음과같다. Element 설명

애플리케이션의 경로를 설정한다.

<path>

상대 경로일 경우 디플로이될 엔진 컨테이너의 webhome 애플리케이션 디 렉터리에서의 상대 경로가 되고, 절대 경로일 경우 절대 경로 그대로 사용 된다. 애플리케이션의 archive 파일 경로가 오거나 그 archive가 풀려진 디 렉터리 경로가 올 수 있다.

애플리케이션의 타입을 지정한다. 이 타입에 따라 EAR 애플리케이션인지 standalone 모듈인지가 결정된다. 이 2가지 기준으로 다음의 2가지 타입이 존재한다.

<deployment-type>

- EAR : EAR 애플리케이션을 디플로이할 때 사용한다.

- COMPONENT : Standalone 모듈을 디플로이할 때 사용한다.

● 모듈 설정

<application> 하위에는애플리케이션에포함된각모듈들의설정이들어간다. 이는 <client-component>,

<ejb-component>, <connector-component>, <web-component> 등으로설정된다. EAR 애플리케이션 을디플로이할때각모듈에대한설정을할필요가없다면이 Element들을설정하지않아도된다. 하지만 standalone 모듈의 경우에는 그 애플리케이션 모듈에 해당하는 Element가 항상 존재해야 한다.

– 공통 설정

(27)

설명 태그

archive 파일 형태로 디플로이될 경우에는 해당 모듈의 archive 파일 이름 이 지정되고 디렉터리 형태로 디플로이될 경우에는 해당 모듈의 디렉터리 이름이 지정된다.

<uri>

Standalone 모듈의 경우에는 uri를 지정할 필요가 없다.

– 세부 설정

설명 태그

애플리케이션에 대해 archive 파일이나 Java EE 표준 DD가 변경되었을 경 우 자동적으로 ReDeploy를 실행한다. 이에 대해서는 “제3장 애플리케이션 작성 및 Deploy”에서 설명한다.

<auto-deploy>

애플리케이션에 포함된 EJB 모듈의 클래스를 class ftp를 통해서 클라이언 트에게 전달할 때의 단위로 CLASS와 JAR의 2가지 단위가 있다.

<class-ftp-unit>

(기본값 : JAR)

애플리케이션에서 사용할 JEUS security domain이다.

<security-domain>

애플리케이션 범위에서 사용할 principal-role mapping을 지정한다.

<role-permission>

J2SE security manager를 사용할 경우 이 애플리케이션에 할당할 permission

들을 지정한다.

<java-security-permission>

standalone 웹 모듈 또는 웹 모듈을 포함한 EAR 애플리케이션을 디플로이 할 경우 <web-component>의 <context-root>를 통하여 <context-path>를

<context-root>

설정할 수 있는 기능을 제공한다. <context-path> 설정은 다음 파일에도 설 정이 가능하고, 나열 순서로 우선 순위를 갖는다.

1. JEUSMain.xml의 <web-component>의 <context-root>

2. jeus-application-dd.xml의 <web-component>의 <context-root>

3. application.xml의 <context-root>

4. jeus-web-dd.xml의 <context-path>

WebAdmin 또는 jeusadmin을 통하여 동적으로 디플로이하는 경우 옵션으 로 <context-root>를 지정할 수 있으며 이는 다른 것보다 우선 순위가 높다.

<context-path>에 대해서는 “JEUS Web Container 안내서”의 “6.3.2. Deploy ment Descriptor 파일 설정”을 참고한다.

참고

1. <security-domain>, <role-permission>, <java-security-permission>에 대한 자세한 설명은 "JEUS Security 안내서"를 참고한다.

2. <application> 하위 태그의 설정에 대한 자세한 설명은 "JEUS Reference Book"을 참고한다.

(28)

2.2. 디렉터리 구조

애플리케이션을디플로이할때사용되는디렉터리구조는다음과같다.

[그림 2.1] JEUS 애플리케이션디렉터리

JEUS_HOME webhome

app_home

J MyAPP.ear

J MyEJB.jar

MyServlet Legend:

X: XML document J: JAR file

autodeploy

J MyAPP.ear

J MyEJB.jar

J MyServlet.war

JEUS가 설치된 JEUS_HOME 디렉터리에는 webhome의 app_home 디렉터리와 autodeploy 디렉터리가 존재한다.

app_home

JEUS가 application(archive 또는 directory)을 찾는 기본 디렉터리이다. -Djeus.apphome으로 대체 경 로 설정이 가능하며 각 컨테이너는 JEUSMain.xml의 관련 설정을 통해 경로 대체 및 확장을 할 수 있 다.

autodeploy

이 디렉터리로 Java EE 애플리케이션을 복사하면 자동으로 디플로이한다. 이 디렉터리는 시스템 프 로퍼티 –Djeus.deploy.autodeploy.dir로 설정된다.

참고

JEUS 5에서 사용하던 deploy_home이 JEUS 6에서는 autodeploy로 변경되었다. 따라서 JEUS 6에 서는 deploy_home을 사용할 수 없다.

(29)

2.3. Deploy 작업과 대상

일반적으로 Deploy 툴에서는다음과같은 Deploy 작업들을지원하고있다. 설명

구분

Deploy에 필요한 파일들을 대상 서버(target server)로 복사하고, 애플리케이션을 실 행시키는 작업이다.

Deploy

대상 서버에 배포(distribute)되어 있는 애플리케이션을 동작시키는 작업이다.

Start

대상 서버에 배치되어 실행 중인 애플리케이션을 일시 정지시키는 작업이다. 이때 애 플리케이션을 대상 서버에서 삭제하지 않는다. 또한 애플리케이션 이름으로 start하 거나 ReDeploy할 수도 있다.

Stop

배치되어 실행 중인 애플리케이션을 정지시키고, 대상 서버에서 애플리케이션을 제 거하는 작업이다.

Undeploy

Deploy되어 실행 중인 애플리케이션을 내용이 변경되었을 경우, 변경된 내용을 현재 애플리케이션에 반영하여 다시 디플로이하는 작업이다. 모든 애플리케이션을 재배치 할 때 디플로이 작업이 하나라도 실패하면, 모든 애플리케이션은 정지된다.

Redeploy

디플로이 대상은 Java EE 애플리케이션이나 standalone 모듈을 배치할 서버이다. JEUS에서의 디플로이 대상은 다음과 같다.

● 엔진 컨테이너

JEUS에서 노드를 구성하는 핵심 요소가 바로 엔진 컨테이너(engine container)이다. 엔진 컨테이너는 Java EE 애플리케이션들의 실행을 책임지는 각 엔진(engine)들을 관리하는 책임이 있다. 따라서, JEUS 에서는 기본적으로 엔진 컨테이너에 애플리케이션이나 standalone 모듈을 배치할 수 있다. 즉, 엔진 컨 테이너가 디플로이 대상(deployment target)이 될 수 있다.

엔진 컨테이너는 JEUSMain.xml의 <node> 태그의 하위 태그인 <engine-container> 태그에 설정한다.

엔진 컨테이너에 대한 자세한 내용은 “JEUS Server 안내서”의 “1.4. 엔진 컨테이너”를 참고한다.

● 클러스터

JEUS에서는 노드(node)가 다른 노드들과 커넥션(connection)을 형성하고 있는 클러스터(Cluster)를 지 원하고 있다. 즉, 각각의 노드에 속한 엔진 컨테이너들도 커넥션을 형성하고 있다. 따라서, 이런 클러스 터 또한 디플로이 대상(deployment target)이 될 수 있다.

JEUS 클러스터링에 대한 자세한 내용은 “JEUS Server 안내서”의 “제4장 JEUS 클러스터링”을 참고한 다.

● 가상 호스트

JEUS에서는 가상 호스트(virtual host)라는 개념을 도입해서 하나의 노드에 여러 개의 JEUS Manager 가 실행되고 이들이 충돌 없이 클러스터링 될 수 있다. 즉, 노드 이름과 base port를 한 쌍의 identity로 사용하여 임의의 가상 노드명(virtual node name)을 지정하고, 이 가상 노드명을 실제 노드명처럼 사용 하는 것이다.

(30)

가상 호스트 내에서 엔진 컨테이너와 엔진을 일반 노드와 마찬가지로 설정할 수 있다. 따라서 가상 호스 트 역시 디플로이 대상(deployment target)이 될 수 있다.

참고

가상 호스트에 대한 자세한 내용은 "JEUS Server 안내서"를 참고한다.

2.4. 애플리케이션 Deploy

JEUS에서는 크게 3가지 형태의 디플로이 방식을 지원하고 있다.

● Runtime Deploy

● Boot-time Deploy

● Auto Deploy

2.4.1. Runtime Deploy

Runtime Deploy는 엔진이 기동되어 있는 상태에서 애플리케이션 또는 모듈을 디플로이하는 것이다. JEUS

의 툴인 jeusadmin과 WebAdmin을 이용하여 Runtime Deploy를 할 수 있다.

Runtime Deploy에 대한 자세한 내용은 “3.2. WebAdmin을 이용한 Deploy”와 “3.3. jeusadmin을 이용한 Deploy”를 참고한다.

2.4.2. Boot-time Deploy

Boot-time Deploy는 애플리케이션을 JEUSMain.xml의 <application> 태그에 등록하여, 각 엔진이 시작할 때 등록된 애플리케이션들이 자동으로 디플로이되는 것을 말한다. JEUS의 툴인 jeusadmin과 WebAdmin 을 이용하여 Boot-time Deploy를 할 수 있다.

Boot-time Deploy에 대한 자세한 내용은 “3.2. WebAdmin을 이용한 Deploy”와 “3.3. jeusadmin을 이용한 Deploy”를 참고한다.

2.4.3. Auto Deploy

Auto Deploy는 지정된 디렉터리 또는 애플리케이션을 주기적으로 검사하면서 변경된 내용이 있을 경우 자동으로 디플로이를 시도하는 기능이다. 이 기능을 사용하면 애플리케이션을 수동적으로 디플로이할 필 요가 없으므로, 애플리케이션을 개발할 때나 잦은 업데이트가 필요한 애플리케이션의 경우 유용하게 사 용할 수 있다. Auto Deploy는 엔진 컨테이너의 Auto Deploy 설정이나 애플리케이션 Deploy 설정의 경우 Auto Deploy 설정에서 주기적인 검사 시간을 지정함으로써 실행된다.

Auto Deploy는다음과같이 2가지의경우로나누어진다.

● 디렉터리에 대한 Auto Deploy

(31)

● 애플리케이션에 대한 Auto Deploy

디렉터리에 대한 Auto Deploy

애플리케이션이 존재하는 디렉터리 전체를 Auto Deploy의 대상으로 설정할 수 있다. 이렇게 하면 설정된 디렉터리 내의 모든 애플리케이션에 대해서 엔진 컨테이너가 추가, 삭제되는 애플리케이션을 감지하여 그 애플리케이션에 대하여 자동으로 Deploy, UnDeploy를 실행한다. 뿐만 아니라, 디렉터리에 존재하는 모든 애플리케이션에 대해 애플리케이션이 변경된 것을 감지하여 자동으로 ReDeploy를 수행하도록 설정 할 수 있다.

JEUS에서는 기본적으로 Auto Deploy(위치 : JEUS_HOME\webhome\autodeploy) 디렉터리가 설정되어 있다. 여기에 추가, 삭제되는 애플리케이션은 자동으로 Deploy, UnDeploy 및 애플리케이션이 변경되었을 경우에는 ReDeploy가 실행된다. 이 디렉터리는 시스템 프로퍼티 jeus.deploy.autodeploy.dir를 설정하 여 사용자가 원하는 디렉터리로 변경할 수 있다. 또한 JEUSMain.xml의 <application> 설정을 통해서 각 컨테이너에 대한 Auto Deploy 디렉터리 설정을 할 수 있다. 이 설정에 대한 자세한 내용은 “3.5. AutoDeploy 설정 방법”에서 설명한다.

애플리케이션에 대한 Auto Deploy

<application> 태그에설정된애플리케이션들에대해 JEUS 서버가주기적으로변경된내용을감지하여,

변경된애플리케이션에대해자동으로 ReDeploy를수행한다.

이때 archive 파일로 된 애플리케이션은 파일이 변경된 시간을 검사하여 ReDeploy를 실행하고, 디렉터리 로 된 애플리케이션의 경우에는 Java 표준 DD 파일의 변경 여부를 검사하여 ReDeploy를 실행한다.

(32)

(33)

제 3 장 애플리케이션 작성 및 Deploy

본장에서는 Java EE 애플리케이션파일(EAR)을작성하고이를 JEUS에디플로이하는방법에대해설명

한다. 또한 JEUS에서제공하는애플리케이션을디플로이할수있는툴을사용하여 JEUS 서버에애플리

케이션을디플로이하는방법과그외관련된작업에대해설명한다.

3.1. 애플리케이션 작성

본 절에서는 작성된 각각의 모듈을 포함하는 애플리케이션 작성 방법에 대해서 설명한다. 'jar' 유틸리티를 사용해서 Java EE 애플리케이션을 직접 작성하는 방법에 대해서만 설명한다.

EAR 파일을 작성하기 전에, 우선 포함될 모듈을 작성해야 한다. EAR 파일에 포함되는 모듈은 EJB 모듈 인 jar 파일과 웹 애플리케이션 모듈인 war 파일, 리소스 어댑터 모듈인 rar 파일 등이 있다. 모듈 파일을 작 성하는 자세한 내용에 대해서는 각 해당 안내서에서 다루고 있으므로, 해당 안내서를 참고한다.

다음은 애플리케이션 작성 환경에 대한 설명이다.

● helloear.ear 이라는 EAR 파일을 작성한다. 이 파일은 ejb.jar라는 EJB 모듈과 web.war라는 웹 애플리케

이션 모듈, appclient.jar 애플리케이션 클라이언트 모듈을 포함하고 있다.

● helloear.ear 파일은 “johan”이라는 노드에 디플로이되며, 엔진 컨테이너의 이름은 “johan_container1”이

다. 이 엔진 컨테이너는 EJB 엔진과 서블릿 엔진을 포함하고 있다.

다음의 순서로 애플리케이션을 작성한다.

1. EAR 파일에 포함될 jar, war, rar 파일을 작성한다.

2. jar, war, rar 파일과 같은 디렉터리에서 META-INF 디렉터리를 생성한다.

3. application.xml 파일을 생성(EAR 파일의 모듈을 포함시킨다)해서 META-INF 디렉터리에 복사한다. 다 음은 application.xml의 예이다.

<?xml version="1.0" encoding="UTF-8"?>

<application version="5"

xmlns="http://java.sun.com/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd">

<description>Application description</description>

<display-name>Sample application</display-name>

</module>

(34)

<web>

<web-uri>web.war</web-uri>

<context-root>hello</context-root>

</web>

</module>

<java>appclient.jar</java>

</module>

</application>

4.다음과 같이 'jar' 유틸리티를 사용해서 명령을 실행하면 helloear.ear 파일이 생성된다.

> jar cf helloear.ear ejb.jar web.war appclient.jar META-INF

주의

META-INF 디렉터리가 대문자인 것에 주의한다. 소문자로 작성할 경우에는 문제가 발생한다.

3.2. WebAdmin을 이용한 Deploy

WebAdmin은 JEUS를 전반적으로 관리하기 위해 제공되는 웹 기반의 관리 툴이다.

3.2.1. 애플리케이션 관련 메뉴

다음은 WebAdmin의 JEUS 노드 트리 화면이다.

[그림 3.1] WebAdmin의 JEUS 노드 트리

(35)

WebAdmin에서 애플리케이션과 관련된 3가지 메뉴는 다음과 같다.

● 어플리케이션 모듈

● 어플리케이션 모듈 디플로이

● 영구 모듈

어플리케이션 모듈

어플리케이션 모듈은 디플로이된 애플리케이션의 정보를 조회한다. JEUS 노드 트리에서 각 엔진 컨테이 너 하위에 존재한다.

다음은 어플리케이션 모듈 화면이다.

[그림 3.2] 어플리케이션 모듈 화면

어플리케이션모듈은다음과같은기능을제공한다. 설명

기능

애플리케이션의 Deploy Descriptor(표준 DD와 JEUS DD)를 확인할 수 있다. xml 형 식의 텍스트로 출력된다.

설정

애플리케이션의 통계 정보를 조회한다.

통계

애플리케이션에 대해 시작(start), 정지(stop), 제거(UnDeploy) 명령을 실행한다.

제어

어플리케이션 모듈 디플로이

어플리케이션모듈디플로이는애플리케이션을디플로이할수있는기능을제공한다. Runtime Deploy와 Boot-time Deploy를지원한다. Runtime Deploy와 Boot-time Deploy에대한자세한내용은각각 “3.2.2.

Runtime Deploy”와 “3.2.3. Boot-time Deploy”를참고한다. 다음은 어플리케이션 모듈 디플로이 화면이다.

(36)

[그림 3.3] 어플리케이션 모듈 디플로이 화면

영구 모듈

영구모듈은어플리케이션모듈디플로이의하위메뉴로, JEUSMain.xml의 <application> 태그에등록되 어있는애플리케이션의설정을조회한다.

[그림 3.4] 영구모듈화면

3.2.2. Runtime Deploy

WebAdmin을 이용하여 애플리케이션을 Runtime Deploy할 수 있다.

WebAdmin에서 디플로이를 실행하려면 JEUS 노드 트리의 어플리케이션 모듈 디플로이를 선택한다.

어플리케이션 모듈 디플로이 화면([그림 3.3])은 다음과 같이 일정한 순서에 의해 구성되어 있는 wizard 형 식의 5개의 탭으로 구성되어 있고, 각 탭의 순서에 따라 Runtime Deploy 과정을 진행한다.

(37)

1.모듈 선택 2.대상 선택 3.선택 사항

4.디플로이

5.결과

[모듈 선택], [대상 선택], [선택 사항], [디플로이] 탭은 디플로이 설정 및 직접 디플로이를 실행하는 과정 이고, [결과] 탭은 디플로이 실행 후 에러 상황에 대해서만 리포트한다.

모듈 선택

디플로이할 애플리케이션 또는 모듈을 선택한다. 애플리케이션은 어플리케이션 모듈 디플로이 화면에서 [모듈], [절대 경로], [파일 업로드] 탭을 이용한 3가지 방법으로 선택할 수 있으며, 반드시 하나 이상의 애 플리케이션을 선택해야 한다.

다음은 모듈 선택 방법에 대한 설명이다.

참고

여러 개의 애플리케이션을 선택하는 경우에는 선택한 애플리케이션을 모두 동일한 설정으로 디플로 이할 경우에 사용된다.

● 모듈

[모듈] 탭에서는 애플리케이션 홈 디렉터리 또는 사용자가 선택한 디렉터리 내에 존재하는 모듈의 리스 트를 보여주고, 사용자가 직접 선택을 할 수 있도록 한다.

모듈 이름과 경로를 확인할 수 있으며, 해당 애플리케이션의 디플로이 여부도 알 수 있다. 모듈 이름란 은 텍스트 박스로 되어있어, 모듈 이름을 별도로 주고 싶을 때는 변경이 가능하다.

– 어플리케이션 홈

JEUS의 APP_HOME에 위치한 애플리케이션을 보여준다.

[그림 3.5] WebAdmin을 이용한 Runtime Deploy - 1. 모듈 선택 : 모듈 - 어플리케이션 홈

– 디렉토리 선택

(38)

표 위에 있는 디렉터리 탐색 기능을 이용하여 특정 디렉터리에 있는 애플리케이션 모듈을 찾아볼 수 있다.

[그림 3.6] WebAdmin을 이용한 Runtime Deploy - 1. 모듈 선택 : 모듈-디렉토리 선택

● 절대 경로

[절대 경로] 탭에서는 사용자가 직접 애플리케이션의 절대 경로를 입력하여 모듈을 선택한다.

[그림 3.7] WebAdmin을 이용한 Runtime Deploy - 1. 모듈 선택 : 절대 경로

● 파일 업로드

[파일 업로드] 탭에서는 로컬에 있는 파일을 JEUS 서버로 업로드 한다. [찾아보기...] 버튼을 클릭하면 탐색창이 나타나면서 쉽게 파일을 찾을 수 있다. 해당 파일은 애플리케이션 홈 라인에 선택된 JEUS 애 플리케이션 디렉터리로 업로드된다.

[그림 3.8] WebAdmin을 이용한 Runtime Deploy - 1. 모듈 선택 : 파일 업로드

(39)

대상 선택

선택한 애플리케이션을 디플로이할 대상을 선택한다. 대상의 단위는 엔진 컨테이너이며, 웹 애플리케이 션 모듈인 경우에는 컨텍스트 및 가상 호스트를 추가로 설정할 수 있다.

[그림 3.9] WebAdmin을 이용한 Runtime Deploy - 2. 대상 선택

선택 가능한 대상에 대한 설명은 다음과 같다.

설명 대상

현재가능한모든대상을선택한다. 모두

해당 노드 전체의 엔진 컨테이너를 대상으로 설정한다.

(노드)

해당 엔진 컨테이너를 대상으로 설정한다.

(엔진컨테이너)

선택 사항

컴포넌트별 선택 사항이나 애플리케이션 또는 모듈에 공통적으로 적용할 값들을 설정한다.

[그림 3.10] WebAdmin을 이용한 Runtime Deploy - 3. 선택 사항

● 컴포넌트별 선택 사항

선택한 모듈 오른쪽의 를 클릭하면 각 컴포넌트 종류별 선택 사항 화면이 나타난다.

각 애플리케이션 또는 모듈에 포함된 컴포넌트별 설정을 할 수 있다. 화면에서는 컴포넌트별로 탭 화면 으로 나누어져 있다. 탭의 상위에는 각 컴포넌트의 타입을 구분하는 아이콘(모듈 아이콘과 동일)과 컴 포넌트의 이름이 표시된다. 원하는 탭을 선택하여 해당 컴포넌트를 설정할 수 있다.

(40)

[그림 3.11] WebAdmin을 이용한 Runtime Deploy - 3. 선택 사항 - 컴포넌트별

● 공통 선택 사항

선택한 모듈 오른쪽의 를 클릭하면 어플리케이션 모듈 선택 사항 화면이 나타난다.

각 애플리케이션 또는 모듈에 공통적으로 적용될 값을 설정할 수 있다.

[그림 3.12] WebAdmin을 이용한 Runtime Deploy - 3. 선택 사항 - 공통 선택 사항

(41)

디플로이

설정한 내용을 바탕으로 애플리케이션 디플로이를 실행한다. 원하는 디플로이 종류를 선택한 후 [다음]

버튼을 클릭하여 디플로이를 진행한다.

[그림 3.13] WebAdmin을 이용한 Runtime Deploy - 4. 디플로이

설명 항목

Runtime Deploy를 선택하면 디플로이를 바로 실행할 수 있다.

런타임 디플로이

Boot-time Deploy를 설정하는 것이다. 자세한 내용은 “3.2.3. Boot-time Deploy”

를 참고한다.

영구적인 디플로이

결과

디플로이할 때 문제가 발생했을 경우에 에러 상황에 대한 stack trace 등이 출력되어, 문제점을 파악할 수 있다. 디플로이가 성공적으로 완료되었다면, 디플로이 성공 메시지와 함께 해당 애플리케이션이 JEUS 노 드 트리의 어플리케이션 모듈 하위에 나타난다.

3.2.3. Boot-time Deploy

WebAdmin을 이용하여 애플리케이션을 Boot-time Deploy할 수 있다.

Boot-time Deploy는 Runtime할 때 바로 서버에 디플로이하는 것이 아니라, 해당 애플리케이션의 설정을 JEUSMain.xml의 <application>에 등록해 놓았다가 이후 서버(정확하게는 엔진 컨테이너)가 기동될 때 등 록된 애플리케이션이 디플로이되는 것이다. 따라서 WebAdmin에서의 Boot-time Deploy는 WebAdmin에 서 JEUSMain.xml에 애플리케이션을 등록하는 것이고, WebAdmin을 이용할 경우에는 직접 xml을 다루는 것보다 쉽게 애플리케이션을 등록 및 편집할 수 있다.

Boot-time Deploy 과정은 Runtime Deploy 과정과 거의 유사하다. 차이점은 디플로이를 실행할 경우 해당 애플리케이션 설정을 서버가 아닌 JEUSMain.xml에 보내어 바로 디플로이하는 것이 아니라 파일로 저장 한다는 것이다. 따라서 애플리케이션에 대한 설정을 하는 과정(모듈 선택 ~ 선택 사항)까지는 동일하다.

본 절에서는 차이점인 마지막 두 단계에 대해서만 설명하고, 등록된 애플리케이션 설정을 수정하는 방법 에 대해서 추가로 설명한다.

(42)

디플로이

설정한 내용을 바탕으로 애플리케이션 설정을 JEUSMain.xml에 등록한다. 서버의 상태에 따라 2가지의 경우가 발생한다.

● 서버가 기동된 경우

이 경우에는 Runtime Deploy를 하는 경우와 동일한 화면이 나타난다. Boot-time Deploy를 할 경우에는

"영구적인 디플로이" 옵션을 선택하고 [다음] 버튼을 클릭하여 디플로이를 진행한다.

● 서버가 종료된 경우

서버가 다운되었기 때문에 Boot-time Deploy만 진행이 가능하다. 따라서 이 경우에는 선택할 수 있는 옵션이 없다.

[그림 3.14] WebAdmin을 이용한 Boot-time Deploy - 4. 디플로이 : 서버가 종료된 경우

디플로이할 때 문제가 발생했을 경우에 에러 상황에 대한 stack trace 등이 출력되어, 문제점을 파악할 수 있다. 디플로이가 성공적으로 완료되었다면, 디플로이 성공 메시지와 함께 해당 애플리케이션이 JEUS 노 드 트리의 영구 모듈 하위에 나타난다. 이렇게 영구 모듈에 등록된 애플리케이션의 설정은 변경할 수가 있 다. 그 내용은 다음과 같다.

● 영구 모듈

Boot-time Deploy가 성공적으로 완료된 애플리케이션은 영구 모듈 하위에 나타난다. 이것을 클릭하면 영구 모듈 화면으로 이동하여 설정을 변경하거나 삭제할 수 있다. 영구 모듈 화면은 [개요]와 [설정]의 2개의 탭으로 구성된다.

– 개요

JEUSMain.xml에 등록된 이 애플리케이션의 설정을 xml 형식의 텍스트로 보여준다.

(43)

[그림 3.15] 영구 모듈 - 개요

– 설정

이 애플리케이션의 설정을 변경한다. 하나의 테이블은 JEUSMain.xml에서 하나의 <application> 태 그에 속한 애플리케이션을 나타낸다. 마지막 컬럼의 아이콘을 클릭하면 해당 애플리케이션 설정 을 JEUSMain.xml에서 삭제한다.

[그림 3.16] 영구 모듈 - 설정

첫 번째 컬럼의 아이콘에 마우스 포인터를 위치하면 해당 애플리케이션의 <application> 태그 설정 을 보여준다.

[그림 3.17] 영구 모듈 - 설정 : <application> 설정 보기

(44)

세 번째 컬럼의 아이콘을 클릭하면 애플리케이션을 설정할 수 있다.

[그림 3.18] 영구 모듈 - 설정 : 애플리케이션 대상 설정하기

[그림 3.19] 영구 모듈 - 설정 : 애플리케이션 공통 속성 설정하기

아이콘을 클릭하면 컴포넌트별 속성을 설정할 수 있다.

[그림 3.20] 영구 모듈 - 설정 : 각 컴포넌트별 선택 사항 설정하기

(45)

3.3. jeusadmin 을 이용한 Deploy

jeusadmin은 JEUS를직접관리할수있는콘솔툴이다. jeusadmin을통해 JEUS, 엔진컨테이너그리고

엔진의제어및모니터링을할수있으며, 애플리케이션을디플로이할수도있다.

본 절에서는 jeusadmin 명령어 중 애플리케이션 디플로이에 관련된 명령어와 이를 통해 애플리케이션을 디플로이하는 방법에 대해서 설명한다.

3.3.1. 애플리케이션 관련 명령어

jeusadmin에는 애플리케이션과 관련된 7개의 명령어가 있다.

본 절에서는 jeusadmin에서 애플리케이션과 관련된 7개의 명령어 중에서 applist명령어에 대해 설명한 다.

[표 3.1] 애플리케이션 관련 명령어 설명

명령어

애플리케이션을 디플로이할 수 있도록 배치 대상에 애플리케이션을 복사한다.

distribute

애플리케이션을 Deploy한다. Deploy란 디플로이 대상에 애플리케이션을 복사하 고(distribute), 애플리케이션의 서비스를 시작(start)하는 것이다.

deploy

디플로이가 성공적으로 완료되면 'running' 상태가 되며, distribute 완료 후 서비스 단계에서 장애가 발생하면 'failed' 상태가 된다.

'stopped' 또는 'failed' 상태에 있는 애플리케이션을 실행한다. 작업이 수행되는 동 안에는 'starting' 상태로, 성공적으로 완료되면 'running' 상태가 된다.

start

'running' 또는 'failed' 상태에 있는 애플리케이션을 정지한다. 작업이 수행되는 동 안에는 'stopping' 상태로, 성공적으로 완료되면 'stopped' 상태가 된다.

stop

디플로이가 완료된 애플리케이션에 변경된 내용이 있는 경우, 변경 내용을 반영하 여 다시 디플로이한다. 디플로이와 같은 단계로 이루어지며, 각 단계에서의 상태 또한 같다.

redeploy

배치 대상에서 애플리케이션을 제거한다.

undeploy

디플로이된 모든 애플리케이션 또는 모듈의 정보를 출력한다.

applist

참고

jeusadmin에 대한 설명 및 각 명령어에 대한 자세한 내용은 “JEUS Reference Book”의 “4.2. jeusadmin”

을 참고한다.

(46)

applist

applist 명령어는 디플로이된 모든 애플리케이션 또는 모듈의 정보를 출력한다.

다음은 applist 실행 예로 calc.jar EJB 모듈을 johan_container1에 성공적으로 디플로이한 경우이다.

[예 3.1] applist 실행 예

johan> applist name : calc

type : EJBModule EngineContainer : johan_container1 node : johan state : running

applist 명령어를 사용하여 출력되는 정보는 다음과 같다.

설명 항목

애플리케이션의 이름이다.

name

애플리케이션의 종류로 5가지 중 하나가 될 수 있다.

type

- J2EEApplication : 애플리케이션 - EJBModule : EJB 모듈

- WebModule : 웹 애플리케이션 모듈 - ResourceAdapter : 리소스 어댑터 모듈

- AppClientModule : 애플리케이션 클라이언트 모듈 애플리케이션이 배치되어 있는 대상 엔진 컨테이너이다.

EngineContainer

애플리케이션이배치되어있는대상노드이다. node

애플리케이션의 상태로 5가지(starting, running, stopping, stopped, failed) 중 하나가 될 수 있다. [그림 3.21]을 참고한다.

state

[그림 3.21] 애플리케이션 상태

(47)

3.3.2. Runtime Deploy

jeusadmin을 통한 Runtime Deploy 방법은 다음의 사항을 가정하여 설명한다.

● 애플리케이션은 “3.1. 애플리케이션 작성”에서 작성한 MyApp.ear을 사용한다.

● JEUS의 노드 이름은 'johan'이고, 이미 부팅된 'johan_container1'이라는 엔진 컨테이너 1개를 가지고

있다.

● -absolute-path를 제외한 deploy 명령어의 다른 옵션은 사용하지 않는다.

참고

옵션에 대한 자세한 내용은 “JEUS Reference Book”의 “4.2.3.19. deploy”를 참고한다.

JEUS에서는 jeusadmin에서 애플리케이션을 Runtime 디플로이할 경우, 애플리케이션의 위치에 따라 다 음의 2가지 방법을 제공한다.

● 디플로이할 애플리케이션을 APP_HOME에 복사한다. 시스템 프로퍼티 jeus.apphome을 설정하여 변 경할 수 있다. 이 경우에는 deploy 명령어를 사용할 때, 파라미터로 애플리케이션의 이름만 설정하면 된 다. 기본적으로 APP_HOME의 위치는 다음과 같다.

JEUS_HOME/webhome/app_home

● 디플로이할 애플리케이션을 APP_HOME에 복사하지 않고, 디플로이할 애플리케이션의 경로를 설정한 다. 이때는 deploy 명령어 다음 -absolute-path 옵션을 사용하여, 현재 디플로이할 애플리케이션의 절대 경로를 설정한다.

다음은 jeusadmin에서의 Runtime Deploy 예제이다.

[예 3.2] jeusadmin - Runtime Deploy

--- 1. using deploy command for application in APP_HOME

--- johan>deploy MyApp

using the following application info :

<deploy-when-booting>true</deploy-when-booting>

<path>MyApp.ear</path>

<ejb-component>

</ejb-component>

<web-component>

<uri>cookie.war</uri>

</web-component>

<deployment-target>

(48)

<all-targets>

</all-targets>

</deployment-target>

<class-ftp-unit>JAR</class-ftp-unit>

</applicationType>

The J2EEApplication, MyApp, is deployed on johan_container1 johan>applist

name : MyApp

type : J2EEApplication EngineContainer : johan_container1 node : johan state : running

johan>stop MyApp

The J2EEApplication [MyApp] is stopped on the johan_container1

johan>applist name : MyApp

type : J2EEApplication EngineContainer : johan_container1 node : johan state : stopped

johan>start MyApp

The J2EEApplication [MyApp] is started on the johan_container1

johan>applist name : MyApp

type : J2EEApplication EngineContainer : johan_container1 node : johan state : running

johan>redeploy MyApp

Undeploying J2EEApplication [MyApp] from johan_container1 (This may take time due to graceful undeployment)

J2EEApplication [MyApp] is undeployed from johan_container1 (elapsed = 59ms) using the following application info :

<deploy-when-booting>true</deploy-when-booting>

<path>MyApp.ear</path>

<ejb-component>

</ejb-component>

<web-component>

<uri>cookie.war</uri>

</web-component>

<deployment-target>

<all-targets>

</all-targets>

</deployment-target>

JEUS Applications & Deployment 안내서