JEUS

Transcription

1 JEUS EJB 안내서 JEUS v7.0 Fix#1 Copyright 2013 TmaxSoft Co., Ltd. All Rights Reserved.

2 Copyright Notice Copyright 2013 TmaxSoft Co., Ltd. All Rights Reserved. 대한민국경기도성남시분당구서현동 우 ) Restricted Rights Legend All TmaxSoft Software (JEUS ) and documents are protected by copyright laws 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 Some modules or files of this product are subject to the terms of the following licenses. : APACHE2.0, CDDL1.0, EDL1.0, OPEN SYMPHONY SOFTWARE1.1, TRILEAD-SSH2, Bouncy Castle, BSD, MIT, SIL OPEN FONT1.1 Detailed Information related to the license can be found in the following directory : ${INSTALL_PATH}/lib/licenses 본제품의일부파일또는모듈은다음의라이선스를준수합니다. : APACHE2.0, CDDL1.0, EDL1.0, OPEN SYM PHONY SOFTWARE1.1, TRILEAD-SSH2, Bouncy Castle, BSD, MIT, SIL OPEN FONT1.1 관련상세한정보는제품의다음의디렉터리에기재된사항을참고해주십시오. : ${INSTALL_PATH}/lib/licenses 안내서정보안내서제목 : JEUS EJB 안내서발행일 : 소프트웨어버전 : JEUS v7.0 Fix#1 안내서버전 : v2.1.2

3 내용목차 안내서에대하여... xiii 제1장 EJB 소개 개요 구성요소 EJB 환경및설정 디렉터리구조 XML 설정파일 관련툴 EJB 기본설정... 6 제2장 EJB 엔진 개요 주요기능 EJB 엔진디렉터리구조 EJB 엔진설정 Basic 설정 Active Management 설정 Timer Service 설정 시스템로그설정 EJB 엔진제어및모니터링 EJB 엔진튜닝 Resolution 설정튜닝 Fast Deploy 최대성능을위한시스템로그설정 Active Management 사용하지않기 HTTP Invoke 모드사용 제3장 EJB 모듈 개요 EJB 모듈관리 EJB 모듈조립 (Assembling) EJB 클래스컴파일 Deployment Descriptors(DD) 작성 EJB JAR 파일패키징 EJB 모듈 Deploy Deploy Deploy된 EJB 모듈의디렉터리구조 EJB 모듈제어및모니터링 EJB 모듈제어 EJB 모듈의모니터링 제4장 EJB의공통특성 JEUS iii

4 4.1. 개요 EJB 설정 기본환경설정 Thread Ticket 설정 External Reference 설정과매핑 HTTP Invoke 환경설정 JEUS RMI 설정 EJB 보안설정 EJB 모니터링 EJB 튜닝 Thread Ticket Pool 설정튜닝 제5장 EJB 상호운용성및 RMI/IIOP 개요 트랜잭션상호운용 (OTS) 보안상호운용 (CSIv2) 상호운용설정 COS Naming Service 설정 상호운용성활성화설정 CSIv2 보안상호운용설정 EJB RMI/IIOP 설정 RMI/IIOP 클라이언트 JEUS Managed Server 다른벤더 WAS standalone 클라이언트 알려진문제점 (Known Issues) 제6장 EJB 클러스터링 개요 주요기능 Load Balancing Failover(EJB 복구 ) Idempotent 메소드를통한 EJB 복구 Session Replication EJB 클러스터링설정 Annotation을통한클러스터링설정 xml을통한클러스터링설정 Stateful Session Bean의클러스터링설정 EJB Failover의제한 제7장 Session Bean Stateless Session Bean Thread Ticket Pool(TTP) 과 Object Management Web Service Endpoint Stateful Session Bean iv JEUS EJB 안내서

5 Thread Ticket Pool(TTP) 과 Object Management Pooling Session Bean Bean Pool 설정 세션데이터유지메커니즘설정 공통설정 Object Management 관련설정 제8장 Entity Bean 개요 주요기능 공통기능 BMP & CMP CMP 1.1/ CMP Entity EJB 설정 공통설정 CMP 1.1/ CMP DB Insert Delay 설정 (CMP Only) Entity EJB 튜닝 공통 BMP & CMP CMP 1.1/ CMP 완전한 CMP 2.0 Entity Bean 예제 제9장 Message Driven Bean(MDB) 개요 MDB 설정 기본환경설정 JMS 설정 JNDI SPI 환경설정 제10장 EJB Timer Service Timer Service의설정 Persistent Timer Service 설정 (EJB 엔진 ) Persistent Timer 처리 (jeus-ejb-dd.xml) Cluster-Wide Timer Service 설정 타이머모니터링 Timer Service 사용주의사항 Persistent Timer와 JDBC Connection 제11장 EJB 클라이언트 개요 EJB 접근을위한클라이언트프로그래밍 JEUS v

6 11.3. InitialContext 설정 JVM 속성을이용한 Naming 속성값설정 Hashtable을이용한 Naming 속성설정 제12장 부가기능 WorkArea 서비스 UserWorkArea 인터페이스 PropertyMode 타입 예외 Nested UserWorkArea UserWorkArea를사용하는응용프로그램개발 Appendix A. 기본 Java 타입과 DB 필드매핑 A.1. 개요 A.2. Tibero 필드 - 컬럼타입매핑 A.3. Oracle 필드 - 컬럼타입매핑 A.4. Sybase 필드 - 컬럼타입매핑 A.5. MSSQL 필드 - 컬럼타입매핑 A.6. DB2 필드 - 컬럼타입매핑 A.7. Cloudscape 필드 - 컬럼타입매핑 A.8. Informix 필드 - 컬럼타입매핑 Appendix B. Instant EJB QL API Reference B.1. 개요 B.2. The EJBInstanceFinder Interface B.3. The EJBInstanceFinder Method 용어해설 색인 vi JEUS EJB 안내서

7 그림목차 [ 그림 1.1] EJB 구현체의주요구성요소... 2 [ 그림 1.2] EJB 엔진설정... 7 [ 그림 2.1] EJB 엔진디렉터리구조 [ 그림 2.2] EJB 엔진설정 - Basic 설정 [ 그림 2.3] EJB 엔진설정 - Active Management 설정 [ 그림 3.1] EJB 모듈관리순서도 [ 그림 3.2] Java EE EJB 모듈 JAR 파일의구조 [ 그림 3.3] 애플리케이션 deploy - 애플리케이션목록조회 [ 그림 3.4] 애플리케이션 deploy - 속성설정 [ 그림 3.5] 애플리케이션 deploy - 결과 [ 그림 3.6] deploy된 EJB 모듈의디렉터리구조 [ 그림 3.7] deploy된애플리케이션목록 [ 그림 3.8] 애플리케이션 undeploy - 속성설정 [ 그림 3.9] undeploy 애플리케이션 - 결과 [ 그림 4.1] TTP 상태전이도 [ 그림 5.1] 상호운용성활성화설정 [ 그림 5.2] CSIv2 보안상호운용설정 - Interop Ssl Config [ 그림 6.1] EJB 클러스터링아키텍처 [ 그림 6.2] Session Router Config 설정 - 속성설정 [ 그림 7.1] Stateless Session Bean의 TTP과 Bean Pool [ 그림 7.2] Stateful Session Bean의 Connection Pool과 TTP, Bean Pool [ 그림 8.1] JEUS EJB 엔진에서 Entity Bean의 object와 Instance 관리 [ 그림 8.2] ejbload() 주기적호출시나리오 [ 그림 8.3] EXCLUSIVE_ACCESS 모드의시나리오 [ 그림 8.4] SINGLE_OBJECT 엔진모드 [ 그림 8.5] MULTIPLE_OBJECT 엔진모드 [ 그림 10.1] Persistent Timer Service 설정 - 기본설정 [ 그림 10.2] Persistent Timer Service - 고급선택사항 [ 그림 10.3] Cluster-Wide Timer Service 설정 [ 그림 10.4] Timer 모니터링 [ 그림 10.5] 타이머동작취소 [ 그림 12.1] 중첩된 UserWorkArea에서의등록정보 JEUS vii

8

9 표목차 [ 표 4.1] JEUS EJB의설정가능한특징들과컴포넌트들 [ 표 4.2] ejb-jar.xml과 JEUS EJB DD 파일의참조태그와관계 [ 표 5.1] keystore와 truestore 파일에관련된 JVM D 파라미터 [ 표 8.1] Entity Bean 종류의설정 [ 표 8.2] 3가지엔진모드의단점과장점 [ 표 8.3] EmployeeBean Instance을위한 EJB 필드들 [ 표 8.4] 결과 ResultSet [ 표 8.5] Entity Bean 엔진타입선택과클러스터링사용여부 [ 표 A.1] Tibero를위한 EJB CMP 필드-DB 컬럼타입매핑 [ 표 A.2] Oracle을위한 EJB CMP 필드-DB 컬럼타입매핑 [ 표 A.3] Sybase를위한 EJB CMP 필드-DB 컬럼타입매핑 [ 표 A.4] MSSQL을위한 EJB CMP 필드-DB 컬럼타입매핑 [ 표 A.5] DB2를위한 EJB CMP 필드-DB 컬럼타입매핑 [ 표 A.6] Cloudscape를위한 EJB CMP 필드-DB 컬럼타입매핑 [ 표 A.7] Informix를위한 EJB CMP 필드-DB 컬럼타입매핑 JEUS ix

10

11 예목차 [ 예 1.1] XML 헤더 : <<domain.xml>>... 5 [ 예 1.2] XML 헤더 : <<ejb-jar.xml >>... 5 [ 예 1.3] XML 헤더 : <<jeus-ejb-dd.xml>>... 6 [ 예 3.1] EJB 표준 DD : <<ejb-jar.xml>> [ 예 3.2] JEUS EJB DD : <<jeus-ejb-dd.xml>> [ 예 4.1] Stateful Session Bean class와 DD : <<CounterEJB.java>> [ 예 4.2] Stateful Session Bean class와 DD : <<jeus-ejb-dd.xml>> [ 예 4.3] BMP Bean 설정 : <<jeus-ejb-dd.xml>> [ 예 4.4] External Reference를 JNDI로매핑 : <<CounterEJB.java>> [ 예 4.5] External Reference를 JNDI로매핑 : <<ejb-jar.xml>> [ 예 4.6] External Reference를 JNDI로매핑 : <<jeus-ejb-dd.xml>> [ 예 4.7] HTTP Invoke 환경설정 : <<jeus-ejb-dd.xml>> [ 예 4.8] 역할할당 (Role Assignment) 설정 : <<jeus-ejb-dd.xml>> [ 예 4.9] Run-as Identify 설정 : <<jeus-ejb-dd.xml>> [ 예 4.10] 보안설정 : <<CustomerBean.java>> [ 예 4.11] 보안설정 : <<EmployeeServiceBean.java>> [ 예 4.12] 보안설정 : <<ejb-jar.xml>> [ 예 4.13] 보안설정 : <<jeus-ejb-dd.xml>> [ 예 4.14] 보안설정 : <<accounts.xml>> [ 예 5.1] EJB RMI/IIOP 설정 : <<jeus-ejb-dd.xml>> [ 예 5.2] corbaname lookup 사용 [ 예 5.3] PROVIDER URL 사용 [ 예 5.4] Servelet EJB Injection [ 예 5.5] RMI/IIOP EJB 매핑 : <<jeus-web-dd.xml>> [ 예 5.6] standalone 클라이언트사용 [ 예 5.7] NullPointerException이발생하는경우 [ 예 6.1] Annotation을통한클러스터링설정 : <<CounterEJB.java>> [ 예 6.2] xml을통한클러스터링설정 : <<jeus-ejb-dd.xml>> [ 예 7.1] Bean Pool 설정 : <<jeus-ejb-dd.xml>> [ 예 7.2] Object Management 설정 : <<jeus-ejb-dd.xml>> [ 예 8.1] Oracle DB에서 Primary Key 생성설정 : <<jeus-ejb-dd.xml>> [ 예 8.2] MS SQL 서버에서자동 Primary Key 생성설정 : <<jeus-ejb-dd.xml>> [ 예 8.3] Other DB의자동 Primary Key 생성설정 : <<jeus-ejb-dd.xml>> [ 예 8.4] Entity EJB의기본공통항목설정 : <<jeus-ejb-dd.xml>> [ 예 8.5] Object Management 관련설정 : <<jeus-ejb-dd.xml>> [ 예 8.6] ejbload() 와 ejbstore() Persistence 최적화설정 : <<jeus-ejb-dd.xml>> [ 예 8.7] ejbload() 와 ejbfind() CM Persistence 최적화설정 : <<jeus-ejb-dd.xml>> [ 예 8.8] DB 스키마정보설정 : <<jeus-ejb-dd.xml>> [ 예 8.9] One-to-one/One-to-many Relationship 설정 : <<jeus-ejb-dd.xml>> [ 예 8.10] Many-to-many Relationship Mapping 설정 : <<jeus-ejb-dd.xml>> JEUS xi

12 [ 예 8.11] Instant EJB QL 설정 : <<jeus-ejb-dd.xml>> [ 예 8.12] XML DD 파일에 ">" 와 "<" 문자삽입 : <<ejb-jar.xml>> [ 예 8.13] DB Insert Delay 설정 : <<jeus-ejb-dd.xml>> [ 예 8.14] Remote Interface : <<Book.java>> [ 예 8.15] Home Interface : <<BookHome.java>> [ 예 8.16] Bean Implementation : <<BookEJB.java>> [ 예 8.17] Java EE EJB DD : <<ejb-jar.xml>> [ 예 8.18] JEUS EJB DD : <<jeus-ejb-dd.xml>> [ 예 9.1] 기본환경설정 : <<jeus-ejb-dd.xml>> [ 예 9.2] JMS 설정 : <<MyMDB.class>> [ 예 9.3] JMS 설정 : <<jeus-ejb-dd.xml>> [ 예 9.4] JNDI SPI 환경설정 : <<jeus-ejb-dd.xml>> [ 예 10.1] Persistent Timer의처리 : <<jeus-ejb-dd.xml>> [ 예 11.1] <<HelloClient.java>> [ 예 12.1] <<UserWorkArea 인터페이스 >> [ 예 12.2] UserWorkArea 액세스 : <<UserWorkAreaSampleSenderBean.java>> [ 예 12.3] 새 UserWorkArea 시작 : <<UserWorkAreaSampleSenderBean.java>> [ 예 12.4] WorkArea에등록정보설정 : <<UserWorkAreaSampleSenderBean.java>> [ 예 12.5] WorkArea에설정된등록정보가져오기 : <<UserWorkAreaSampleReceiverBean.java>>. 155 [ 예 12.6] UserWorkArea 완료하기 : <<UserWorkAreaSampleSenderBean.java>> xii JEUS EJB 안내서

13 안내서에대하여 안내서의대상 본안내서는 JEUS 시스템관리자와 JEUS 에서 Java EE Enterprise JavaBeans(EJB) 을 deploy 하려는개 발자를대상으로한다. 안내서의전제조건 본안내서는 EJB 개념을시작으로 JEUS에서 EJB 엔진, EJB 모듈그리고 EJB 클라이언트까지다루고있다. 본안내서를이해하기위해서는다음의지식을필요로한다. JEUS에대한전반적인이해 "JEUS Server 안내서 " 참조 Java EE 스펙에대한이해 EJB의기본개념 안내서의제한조건 본안내서에서는 EJB 에대한기본적인설명은제공하지않으므로별도의자료를참고한다. 참고 Entity Bean 은 EJB 3.0 부터 JPA 로대체되었으므로 "JEUS JPA 안내서 " 를참조한다. 안내서에대하여 xiii

14 안내서구성 본안내서는총 12개의장과 2개의 Appendix로구성되어있다. 제1장 EJB 소개 EJB의구성요소와특성그리고간단한설치및환경설정방법에대해서설명한다. 제2장 EJB 엔진 EJB 엔진개념과 JEUS EJB의최상위레벨의개념인구조, 설정, 모니터링과튜닝에대해서설명한다. 제3장 EJB 모듈 EJB 모듈의구조와관리방법에대해서설명한다. 제4장 EJB의공통특성 EJB 공통특성에대해서소개한다. 제5장 EJB 상호운용성및 RMI/IIOP EJB의상호운용성및 RMI/IIOP에대해서설명한다. 제6장 EJB 클러스터링 EJB 클러스터링개념과주요기능설정방법에대해서설명한다. 제7장 Session Bean Stateless Session Bean과 Stateful Session Bean에대해서설명한다. 제8장 Entity Bean EJB들을설정하고튜닝할때필요한모든정보를설명한다. 제9장 Message Driven Bean(MDB) MDB를 EJB 엔진에서사용할때유의해야할사항들을설명한다. 제10장 EJB Timer Service JEUS EJB에서제공하는타이머서비스와이를사용하기위한설정에대해서설명한다. 제11장 EJB 클라이언트 EJB 클라이언트프로그램밍예제와 Initial Context 설정방법에대해서설명한다. 제12장부가기능 JEUS에서 EJB를개발할때사용할수있는부가기능들에대해서설명한다. Appendix A. 기본 Java 타입과 DB 필드매핑 Java 필드종류와 JEUS에서지원하는주요 DB 벤더의데이터베이스컬럼종류와의기본매핑을설명한다. Appendix B. Instant EJB QL API Reference Instant EJB QL API Reference로메소드와인터페이스의사용법에대해서설명한다. xiv JEUS EJB 안내서

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

16 시스템사용환경 본안내서의모든예제와환경구성은 UNIX의스타일에준하여작성되어 Microsoft Windows ( 이하 Windows) 와같이다른환경에서작업하는경우몇가지사항을고려해야한다. 예를들어경로구분자의경우 UNIX 스타일인 / 를 Windows 스타일인 \ 로바꿔서사용한다. 또한환경변수도 Windows 스타일로변경해서사용하면된다. 문서의내용은 Java 표준을고려해서작성했기때문에대부분의내용은동일하게적용된다. 관련안내서 안내서 JEUS Server 안내서 JEUS JPA 안내서 JEUS Applications & Deployment 안내서 JEUS Application Client 안내서 JEUS Reference Book 설명 JEUS 서버에대한설명과시스템관리를위한방법을기술한안내서이다. JEUS에통합된 TopLink Essential의사용방법에대해기술한안내서이다. Java EE 애플리케이션을 JEUS에 Deploy하기위한여러가지방법과툴에대해기술한안내서이다. Java EE 클라이언트와 JEUS 사이의상호운용에대해기술한안내서이다. JEUS를사용할때도움이되는 Reference를기술한안내서이다. 참고자료 EJB 3.1 Specification XML Reference - domain.xml 설정 JEUS_HOME/docs/reference/schema/index.html XML Reference - jeus-ejb-dd.xml 설정 JEUS_HOME/docs/reference/schema/index.html xvi JEUS EJB 안내서

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

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

19 제 1 장 EJB 소개 본장에서는 EJB 의구성요소와특성, 그리고간단한설치와환경설정방법에대해서설명한다 개요 JEUS는 JSR 318 Enterprise JavaBeansTM 3.1( 이하 EJB 3.1) 을지원하고있다. EJB 3.1 표준 ( 이하 EJB 표준 ) 은복잡하고중요한고성능의비즈니스로직을개발할때개발자의노력을최소화하면서도이식성이뛰어난비즈니스컴포넌트를작성할수있는구조를기술하고있다. EJB 3.1에따르면 EJB의정의는다음과같다. "EJB 아키텍처는객체지향분산엔터프라이즈애플리케이션의개발및분산배치를위한컴포넌트이다. EJB로작성된애플리케이션은확장성, 트랜잭션처리그리고동시사용자처리에안전하다. EJB 스펙을준수한애플리케이션은한번작성되면어떠한서버플랫폼에도배치된다." JEUS 는위에서언급한 " 서버플랫폼 " 의역할을담당한다. 본안내서에서는 JEUS 에서구현한 EJB 구현체와엔터프라이즈환경에필수적인부가기능에대해서설 명한다. 참고 더자세한스펙구현정보들은 "JEUS 소개 " 를참조한다. JEUS EJB는클러스터링을통한성능과안정성을더하기위해 JEUS는표준외에 2가지추가기능을제공한다. 성능개선을위한 Load Balancing 기능 안정성확장을위한 Failover 기능이기능들을사용하려면 2개이상의 Managed Server( 이하 MS) 가클러스터로구성되어있어야한다. 참고 EJB 클러스터링에대한자세한내용은 제 6 장 EJB 클러스터링 을참고하고, MS 클러스터링에대한 자세한내용은 JEUS Domain 안내서 의 제 5 장 JEUS 클러스터링 을참고한다. 제 1 장 EJB 소개 1

20 1.2. 구성요소 다음은 EJB 구현체의주요구성요소에대한그림이다. [ 그림 1.1] EJB 구현체의주요구성요소 EJB Engine Main Settings Active Mngmnt. Startup/Sh utdown classes Logging HTTP Invoke EJB Module* ( " * " = zero or more) Module info EJB Relation Map Stateless Session Bean* Stateful Session Bean* BMP Entity Bean* CMP Entity Bean* Messagedriven Bean* EJB 엔진 EJB 3.1에서설명하는 EJB 컨테이너에해당하는것으로 deploy된 EJB 모듈의실행환경을제공한다. EJB 엔진은 제2장 EJB 엔진 에서자세히설명한다. EJB 모듈각각의 EJB 컴포넌트를그룹화하고관리할수있는단위이다. JEUS에서는 EJB 컴포넌트를 deploy하고제어할때 EJB 모듈을기본단위로하므로, EJB 모듈은반드시하나이상의 EJB 컴포넌트를포함하고있다. EJB 모듈에대해자세한내용은 제3장 EJB 모듈 에서설명한다. EJB 컴포넌트 EJB 모듈내에속해있으며실제비즈니스컴포넌트를일컫는다. 각 EJB 컴포넌트의공통특성은 제4 장 EJB의공통특성 을참고한다. EJB 컴포넌트는다음과같이 5가지종류로구분된다. 각컴포넌트에대한자세한내용은각장을참고한다. Stateless Session Bean : 제7장 Session Bean Stateful Session Bean : 제7장 Session Bean BMP Entity Bean : 제8장 Entity Bean CMP 1.1 & CMP 2.x Entity Bean : 제8장 Entity Bean MDB : 제9장 Message Driven Bean(MDB) 참고 Entity Bean 은 EJB 3.0 부터 JPA 로대체되었으므로이에대해서는 "JEUS JPA 안내서 " 를참고한다. 2 JEUS EJB 안내서

21 1.3. EJB 환경및설정 JEUS EJB 에관련된환경설정요소들은 EJB 에관련된디렉터리구조와 EJB 설정파일들, 각종툴등으로 구성된다. 또한 EJB 와관련된시스템프로퍼티들과그특성들도설명한다 디렉터리구조 다음은 JEUS EJB 에관련된디렉터리들과파일에대한설명이다. 제 1 장 EJB 소개 3

22 bin 관리자가 EJB를관리할때사용할수있는실행스크립트들이저장된다. 여기에는 jeusadmin, appcom piler 등이있다. domains\<domain name>\config 현재의 JEUS 시스템의주요설정디렉터리이다. 이디렉터리에는 domain.xml 파일이위치한다. domains\<domain name>\servers\<server name>\logs EJB 엔진의로그파일이위치한다. EJB 로그의파일핸들러를별도로지정한경우별도의파일로생성된다. 핸들러가없는경우에는서버의로그설정을따른다. domains\<domain name>\.application\ 도메인에서사용하는애플리케이션들의 Archive 파일이복사되고이 Archive 파일을풀어놓은디렉터리가위치한다. 애플리케이션의 Archive 파일과풀린디렉터리에는 EJB 구현클래스들과 helper 클래스들이포함되어있다. 파일 <EAR archive file> <EJB archive file> 설명 EAR application-id 이름의디렉터리밑에 EAR 애플리케이션의구성파일이그대로복사된다. EJB module-id 이름의디렉터리밑에 EJB 모듈을구성하는파일이그대로복사된다. lib\schemas EJB 와관련된스키마파일이다음과같이디렉터리별로위치한다. 하위디렉터리 javaee jeus 설명 EJB 와관련된모든 Java EE XML 스키마파일들이위치한다. EJB 와관련된모든 JEUS XML 스키마파일들이위치한다. samples\ejb 여러종류의 EJB 들을구현해놓은예제코드들과하위디렉터리들이포함되어있다. 참고디렉터리목록에서사용된 "<", ">" 표현 ( 예 "<server name>/ ) 은그사이에사용된문자들은실제시스템설정값으로대체되어야한다. 예를들어, 실제시스템이 "server1" 이라면 JEUS MS는 "server1" 이라고값이설정되어야한다. 그러므로 "<server name>/" 표현은실제시스템에서 "server1/" 이라는이름의디렉터리로대체되어야한다. 4 JEUS EJB 안내서

23 XML 설정파일 다음은 JEUS EJB의관리와설정에관련된 XML 설정파일이다. XML 설정파일들의내용은반드시표준, 즉 JEUS에서정의된 XML 헤더로시작되어야한다. 각설정파일의 XML 스키마파일은 JEUS_HOME/lib/schemas/jeus/ 디렉터리에위치한다. 또한 Root Element는 JEUS XML 스키마의 namespace를기존 name-space로지정해야한다. domain.xml (jeus-domain.xsd) EJB 엔진에대한설정을한다. 자세한설명은 "JEUS Server 안내서 " 와 제2장 EJB 엔진 을참고한다. 위치 JEUS_HOME/domains/<domain name>/config domain.xml의 XML 헤더 [ 예 1.1] XML 헤더 : <<domain.xml>> <?xml version="1.0"?> <jeus-system xmlns=" version="7.0"> ejb-jar.xml (ejb-jar_3_1.xsd) 주 EJB 엔진설정파일이다. 자세한설명은 EJB 3.1 스펙을참고한다. 위치 META-INF\ 표준 JAR 파일내의구조 ejb-jar.xml의 XML 헤더 ejb-jar.xml의 XML 헤더는 EJB 표준에포함되어있다. [ 예 1.2] XML 헤더 : <<ejb-jar.xml >> <?xml version="1.0"?> <ejb-jar version="3.1" xmlns=" xmlns:xsi=" xsi:schemalocation=" jeus-ejb-dd.xml (jeus-ejb-dd.xsd) JEUS EJB 모듈을위한 JEUS Deployment Descriptors( 이하 DD) 정보를설정한다. 자세한설명은 제3 장 EJB 모듈 을참고한다. 위치 META-INF\ 표준 JAR 파일내의구조 jeus-ejb-dd.xml 의 XML 헤더 제 1 장 EJB 소개 5

24 [ 예 1.3] XML 헤더 : <<jeus-ejb-dd.xml>> <?xml version="1.0"?> <jeus-ejb-dd xmlns=" version="7.0"> 참고본안내서에서사용되는모든태그순서는 XML 스키마의설정순서대로작성되어있다. 태그순서는 "JEUS XML Reference" 를참고한다. 그러나실제사용할때는순서를제대로지키기가쉽지않으므로 JEUS에서는태그순서를자동으로정렬해주는기능을제공한다. 그러므로 XML 설정파일을작성할때순서를정확하게지키지않아도무방하다. 위파일들의예제가본안내서에서사용될때에는표준헤더가편의상생략되어사용되고있다. 실제 XML 설정파일에는이헤더들이포함되어있다는것에주의한다 관련툴 다음은 EJB 엔진, EJB 모듈그리고 EJB 컴포넌트를관리하기위해사용되는툴이다. 콘솔툴 (jeusadmin) JEUS 콘솔툴은 EJB 엔진을제어하고모니터링하기위해사용된다. 자세한내용은 JEUS Reference Book 의 EJB 엔진관련명령어 를참고한다. WebAdmin WebAdmin은 JEUS의 GUI 기반의관리툴로콘솔툴에서가능한모든작업을지원한다. WebAdmin에대한자세한내용은 "JEUS WebAdmin 안내서 " 를참고한다. 참고 EJB 2.x 를위한 appcompiler 에대한설명은 JEUS Reference Book 의 4.3. appcompiler 를참고한 다 EJB 기본설정 본절에서는 JEUS에서 EJB를사용하기위한설치단계를설명한다. 다음은 'server1' 이라는이름의서버에 EJB 엔진을설정하는과정에대한설명이다. 1. JEUS가제대로설치되었는지확인하고, 환경변수를확인한다. 2. COMMAND 화면을실행하고 $JEUS_HOME/bin에서다음과같이입력하면 DAS가기동된다. $ startdomainadminserver -domain domain1 -u administrator -p passsword1 -verbose [ :33:15][2] [adminserver-1] [SERVER-0248] JeusServer is STARTING 6 JEUS EJB 안내서

25 [ :33:16][3] [adminserver-1] [Security-0082] JEUS security manager started [ :33:16][3] [adminserver-1] [SERVER-0173] JNDI Naming Server started [ :33:18][3] [adminserver-1] [GMS-1904] [check components (domain1_ )] DomainAdminServer = ready [ :33:28][2] [launcher-10] [Launcher-0034] The server[adminserver] initialization successfully done [pid : 2380] [ :33:28][0] [launcher-1] [Launcher-0040] Successfully started server. The server is RUNNING now. 참고위에보이는 [3] 은로그레벨중 CONFIG를의미한다. 따라서 CONFIG 이상의로그레벨이설정되어있을경우에만확인가능하다. 3. WebAdmin에서 [Servers] 메뉴를선택하면서버목록조회화면으로이동한다. 서버목록에서서버 (MS) 를선택하면서버설정화면으로이동하고, [Engine] > [Ejb Engine] > [Basic] 메뉴에서 EJB 엔진에대해설정할수있다. 설정이없어도기본값으로동작된다. [ 그림 1.2] EJB 엔진설정 제 1 장 EJB 소개 7

26 참고 JEUS에서제공되는툴을통한 MS 의설정변경은 DAS가기동되어있는상태에서가능하다. 4. 다른 COMMAND 화면에서다음과같이명령을실행한다 ( 호스트정보는 DAS의정보이다 ). $ jeusadmin -host localhost:9736 User name: 5. 설치할때설정한관리자의사용자이름과패스워드를입력한다. User name: administrator Password: 6. COMMAND 화면에서다음과같이입력하고실행하면서버가기동 (Booting) 된다. $ startmanagedserver -domain domain1 -server server1 -u administrator -p passsword1 -verbose... [ :10:10][2] [server1-1] [SERVER-0248] JEUS Server is STARTING... [ :10:17][2] [server1-1] [SERVER-0248] JEUS Server is RUNNING 7. help 명령을입력하면 EJB 엔진에대한모니터링과관리에대한명령어들을조회할수있다. [DAS]domain1.adminServer>help -g EJB [ EJB] cancel-ejb-timer Cancel active EJB timers. ejb-timer-info List active EJB timers; If no option is specified, a list of EJB modules containing timers will be displayed. modify-active-management Modify active management configuration. modify-check-resolution Set the check resolution of EJB engine in the server. show-active-management Show the active management of EJB engine in the server. show-check-resolution Show the check resolution of EJB engine in the server. For the detailed information of a specified command, use 'help [COMMAND_NAME]'. ex) help connect 8. 종료하려면 COMMAND 화면에 stop-server( 서버종료 ) local-shutdown(das 종료 ) exit( 툴종료 ) 를순서대로입력한다. [DAS]domain1.adminServer>stop-server server1 Server [server1] is stopped successfully. [DAS]domain1.adminServer>local-shutdown 8 JEUS EJB 안내서

27 The server [adminserver] has downed successfully. offline>exit 9. 전체 JEUS 시스템이종료된다. 참고 설치와설정에대한자세한내용은 "JEUS 설치및시작하기 " 와 "JEUS Server 안내서 " 를참고한다. 제 1 장 EJB 소개 9

28

29 제 2 장 EJB 엔진 본장에서는 EJB 엔진에대한기초적인사항과 JEUS EJB 의최상위레벨의개념인구조, 설정, 운영, 모니 터링과튜닝에대해설명한다 개요 EJB 엔진은 EJB의운영환경을제공한다. EJB 표준에서는 EJB 컨테이너라는용어가사용되고있으며, 본안내서에서사용한 EJB 엔진과동일한개념이다. EJB 모듈, EJB deploy에대한상세한정보는각각 제3장 EJB 모듈 과 제4장 EJB의공통특성 을참고한다 주요기능 다음은 EJB 엔진의주요기능에대한설명이다. EJB 엔진과 Managed Server(MS) 하나의 MS에는하나의 EJB 엔진이존재한다. 그러나하나의도메인에는여러개의 MS가존재할수있기때문에하나의도메인에여러개의 EJB 엔진이존재할수있다. 일반적으로여러개의머신이나 CPU 위에여러개의 MS에 EJB 엔진이설정되고, DAS에의해 MS는클러스터로묶이는데이러한설정을 EJB 클러스터링이라고한다. 이구조는시스템의성능향상과높은안정성및보안성을유지해주는효율적인시스템구조이다. EJB 클러스터링에대한자세한내용은 제6장 EJB 클러스터링 을참고한다. EJB 엔진기본설정 EJB 엔진은 domain.xml의 <ejb-engine> 에서설정한다. 자세한내용은 2.4. EJB 엔진설정 을참고한다. EJB 엔진 Logging domain.xml의설정에따라 MS에로그를남길수있지만특별히 EJB 엔진의로그 (jeus.ejb) 만별도로남길수있다. 이때 EJB 엔진로그를별도로남기더라도 MS 로그에는 EJB 엔진로그가남는다. Logger의핸들러에파일핸들러가지정되면지정한파일명으로로그파일이생성된다. 또한, 콘솔핸들러를사용하면모든로그메시지를화면에남길수도있다. 일반적으로이런상황에서는로그메시지가파이프를통하여 MS가시작된 COMMAND 화면에출력된다. 참고 그외에사용자가생성한사용자핸들러를등록할수있다. 자세한설명은 JEUS Server 안내서 의 제 8 장 Logging 을참고한다. 제 2 장 EJB 엔진 11

30 Active Management Active management는 EJB 모듈에문제가발생한경우에 EJB 엔진이자체적으로이메일 ( ) 로통지를보내주는기능이다. 예를들어 Bean 클래스의잘못된구현으로인해서무한루프에빠지거나 Deadlock과같은심각한오류가발생했을때 EJB 엔진이이를감지하여통지를보내주도록되어있다. 부가적으로오류처리정책을설정할수있어서비정상적인현상이발생한경우에이메일통지뿐만아니라해당 EJB 엔진이동작하는 MS를자동으로재시작시킬수도있다. Active Management에대한자세한설정은 2.4. EJB 엔진설정 을참고한다. HTTP Invoke 원격클라이언트가 JNDI 서비스를통해서 EJB 인스턴스를찾을때클라이언트는 EJB 메소드를호출할수있는 RMI Stub을받는다. 기본적으로 Stub은 RMI 런타임을통해서 EJB와원격통신이이루어지며, RMI 통신은 TCP 소켓을기반으로하고있다. 이방식은 RMI 통신포트를별도로필요로하기때문에방화벽이있는환경에서는문제가될수있다. 이경우특별한통신모드가필요한데이것이 HTTP Invoke 모드이다. 이모드를사용할경우원격클라이언트의 RMI 요청을 HTTP로감싸서웹엔진으로보내고웹엔진은 RMI 요청을다루는서블릿 (jeus.rmi.http.servlethandler) 으로요청을전달한다. 이서블릿은 RMI 런타임으로요청을전달해서실제 EJB 메소드를호출한뒤그결과를 HTTP 응답으로감싸서원격클라이언트로전달한다. HTTP Invoke 모드는 EJB 엔진또는 EJB 컴포넌트별로설정할수있다. domain.xml의 <invoke-http> 에 HTTP Invoke 모드가설정되면 EJB 엔진내의모든모듈에적용된다. EJB 모듈의 jeus-ejb-dd.xml에서는특정 EJB 컴포넌트에만적용할수있다. 이때 jeus-ejb-dd.xml의설정이 EJBMain.xml의설정보다우선한다. EJBMain.xml과 jeus-ejb-dd.xml의설정에대한자세한내용은 Timer Service 설정 을참고한다. 12 JEUS EJB 안내서

31 2.3. EJB 엔진디렉터리구조 다음은 EJB 엔진을관리할때사용하게되는디렉터리와파일의목록이다. [ 그림 2.1] EJB 엔진디렉터리구조 JEUS_HOME\ bin\ 0I 0I appcompiler jeusadmin domains\ Legend: 0I: binary or executable file X: XML document J: JAR file T: Text file C: Class file V: Java source file <domain name>\ config\ X domain.xml servers\ <server name>\ logs\ T error.log lib\ schemas\ javaee\ jeus\ 기본디렉터리에대한내용은 디렉터리구조 와동일하고, 다음은 EJB 엔진에서주로사용하는디렉터리에대한설명이다. bin EJB 엔진을관리하는툴이위치한디렉터리이다. EJB 엔진관리툴 appcompiler jeusadmin 설명 EJB를 deploy하기위해필요한클래스를생성하고컴파일해서 Fast Deploy를수행한다. EJB 엔진을제어하고모니터링하기위해사용된다. EJB 를 deploy 하기위해필요한클래스를생성하고컴파일해서 Fast Deploy 를하게한다. 제 2 장 EJB 엔진 13

32 domains/<doamin name>/servers/<server name>/logs EJB 엔진의로그파일이위치한디렉터리이다. EJB 로그의파일핸들러를별도로지정한경우별도 의파일로생성된다. 핸들러가없는경우에는서버의로그설정을따르게된다 EJB 엔진설정 본절에서는 WebAdmin을사용하여 EJB 엔진을설정하는방법을설명한다. WebAdmin을통한 EJB 엔진설정은크게다음의 3가지설정으로나눌수있다. WebAdmin을사용하여설정된내용은 JEUS_HOME/domains/<domain name>/config에위치한 domain.xml 파일에저장된다. Basic Active Management Timer Service 참고 하나의 MS 에는하나의 EJB 엔진이존재한다. MS 를추가하는방법에대한자세한내용은 JEUS Server 안내서 의 제 2 장 JEUS 설정 을참고한다 Basic 설정 WebAdmin을사용한 EJB 엔진의 Basic 설정과정은다음과같다. 1. WebAdmin의 [Servers] 메뉴를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택하여서버설정화면으로이동한후 [Engine] > [Ejb Engine] > [Basic] 메뉴를선택한다. 2. [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 14 JEUS EJB 안내서

33 3. EJB Engine 화면에서 EJB 엔진에대한기본적인항목을설정하고 [ 확인 ] 버튼을클릭한다. [ 그림 2.2] EJB 엔진설정 - Basic 설정 다음은기본정보및고급선택사항의영역별설정항목에대한설명이다. 기본정보 제 2 장 EJB 엔진 15

34 항목 Resolution Use Dynamic Proxy For Ejb2 설명 Active Management의체크주기와 Passivation 체크주기를설정한다. 즉, Block 된스레드를감지하는주기와 Passivation 타임아웃동안클라이언트로부터요청을받지않은 Bean을감지하는주기이다. 기존 RMI Stub 방식대신 Dynamic Proxy 방식을사용한다. Ejb Engine 항목 Enable User Notify 설명 옵션을설정하면 EJB Exception 이서버에설정한 user log 에남게된다. user log 에대한설명은 JEUS Server 안내서 의 제 8 장 Logging 을참고한다. Async Service Asynchronous invocation service 를위한설정이다. 항목 Thread Min Thread Max Access Timeout 설명유지할스레드개수의최솟값을설정한다. 유지할스레드개수최댓값을설정한다. Async 메소드가수행이완료된후일정시간이지나도클라이언트에서 get을하지않으면 Future 객체를없애버리는시간이다. 이는클라이언트의실수로 get 을하지않는경우 Memory Leak 의발생을방지하 기위한설정이다. Invoke Http EJB RMI Stub 이 RMI 런타임포트를접근할수없는상황일경우에설정한다. 항목 Url 설명 RMI Stub 으로부터호출되는 RMI 핸들러서블릿의 URI 를입력한다. URI에는프로토콜, IP 주소, 포트를제외한서블릿요청경로만을넣는다. 즉, rmihandlerservlet.war의 jeus-web-dd.xml에설정한 <contex-path> 와 web.xml 에설정한 <url-pattern> 을이어서입력한다. jeus-web-dd.xml을별도로생성하지않으면 <contex-path> 의기본값인 war 이름으로예에서는 rmihan dlerservlet이된다. 프로토콜은 "HTTP" 로 IP는 RMI 런타임과동일한주소로간주된다. HTTP-RMI 요청을받은웹서버와웹엔진이 RMI 런타임과같은머신에있어야한다. 그러면 RMI 런타임의주소는 RMI Stub에게알려지게된다. 웹서버의포트는반드시다음 <http-port> 에설정해야한다. 16 JEUS EJB 안내서

35 항목 설명 JEUS에서제공하는 rmihandlerservlet.war에는 jeus-web-dd.xml이포함되어있지않다. 따라서기본적으로컨텍스트는모듈이름과같은 rmihadlerservlet 을사용하게된다. 또한 web.xml에는 <url-pattern> 이서블릿핸들러가설정되어있다. 기본값외의설정을사용하고싶은경우에는 jeus-web-dd.xml을생성하고 web.xml를수정한후 rmihandlerservlet.war를 deploy한다. Http Port HTTP-RMI 요청을받고처리할웹서버또는웹엔진을설정한다. 웹서버및웹 엔진에는반드시 RMI 핸들러서블릿이 deploy 되어실행되고있어야한다. 4. 설정내용의동적반영을위해 [Activate Changes] 버튼을클릭한다 Active Management 설정 Active Management 설정은엔진재시작조건들과이메일통보기능으로나누어진다. 엔진재시작조건은 EJB 엔진이재시작하기전까지의허용가능한최대 Block된 EJB 스레드수로결정된다. WebAdmin을사용한 EJB 엔진의 Active Management 설정과정은다음과같다. 1. WebAdmin의 [Servers] 메뉴를선택하면서버목록조회화면으로이동한다. 서버목록에서실행할서버를선택해서서버설정화면으로이동한후 [Engine] > [Ejb Engine] > [Active Management] 메뉴를선택한다. 2. [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. Active Management 화면에서항목을설정하고 [ 확인 ] 버튼을클릭한다. [ 그림 2.3] EJB 엔진설정 - Active Management 설정 제 2 장 EJB 엔진 17

36 다음은기본정보및고급선택사항의영역별설정항목에대한설명이다 기본정보 항목 Max Blocked Thread 설명 EJB 엔진이재시작하기전까지허용할수있는 Block된 EJB 스레드의최대개수이다. 이값이작게설정되어있다면 EJB 엔진이너무자주재시작될수도있기때문에주의해야한다. 기본값으로설정하면 Block 된스레드개수에대한제한이없음을의미한다. 즉, 기본적으로 EJB 엔진은 Block 된스레드때문에재시작되지않는다. Max Idle Time 지정된시간동안스레드가 Block 된상태로요청을받지않고 idle 상태에있 으면 "Block 된스레드리스트 " 로추가된다. 이설정은엔진에서 Block 된스레드로판단하는기준이된다. Notify 재시작조건에따라 EJB 엔진이시작될경우에이메일통보를보내기위한정보를설정한다. 다음은하위설정항목에대한설명이다. 항목 Smtp Host Address From Address Sender Id 설명메시지를전송할때사용할 SMTP 의주소로이주소는호스트이름이나 IP 주소로설정해야한다. 메일송신자의주소를설정한다. SMTP 주소를통해인증받을 ID를설정한다. 18 JEUS EJB 안내서

37 항목 Sender Password To Address Property Cc Address Bcc Address 설명 SMTP 주소를통해인증받을 ID의암호를설정한다. 메일수신자의주소를설정한다. 기본적인 SMTP property 외에추가로필요한 property 가있다면 key, value의형태로설정한다. 메일을참조로받을수신자의주소를설정한다. 메일을숨은참조로받을수신자의주소를설정한다. 4. 설정내용의동적반영을위해 [Activate Changes] 버튼을클릭한다 Timer Service 설정 EJB Timer Service는 EJB가특정한시간또는주기적으로 callback을받을수있도록하는서비스이다. 기본적인사용방법은 EJB 스펙에설명되어있으므로 JEUS EJB에서제공하는 Timer Service와이를사용하기위한설정에대해서만설명한다. 자세한내용은 제10장 EJB Timer Service 를참고한다 시스템로그설정 EJB 엔진의 System Logging과 User Logging은 WebAdmin의다음메뉴에서설정할수있다. System Logging 설정 WebAdmin의 [Servers] > 서버선택 > [Basic] > [System Logging] 메뉴에서설정한다. User Logging 설정 WebAdmin의 [Servers] > 서버선택 > [Basic] > [User Logging] 메뉴에서설정한다. System Logging 설정은 EJB 엔진뿐만아니라다른모든엔진에도적용되는공통적인설정이므로자세한내용은 JEUS Server 안내서 의 제8장 Logging 을참고한다 EJB 엔진제어및모니터링 EJB 엔진을제어하는것은다른 JEUS 엔진 ( 서블릿또는 JMS) 을제어하는것과많은유사점을가진다. WebAdmin 및콘솔툴을사용하여 EJB 엔진의실행환경정보와상태정보를모니터링할수있다. WebAd min을사용한 EJB 엔진의제어및모니터링방법은다음과같다. EJB 엔진제어 WebAdmin의 [Servers] 메뉴를선택하여나타나는서버목록에서원하는서버명을선택한후, [Engine] > [Ejb Engine] 을선택하면된다. EJB 엔진모니터링 제 2 장 EJB 엔진 19

38 WebAdmin 의 [RUNTIME INFO] 버튼을클릭한뒤 EJB 엔진제어를위한메뉴선택과같은방법으로모 니터링하려는 EJB 엔진을선택하면된다. 참고 1. EJB 엔진에대한모니터링은 WebAdmin을사용할것을권장한다. WebAdmin이콘솔툴에비해자세하고완벽한엔진상태정보를제공한다. WebAdmin에대한자세한내용은 "JEUS WebAdmin 안내서 " 를참고한다. 2. 콘솔툴을통해기본적인실행환경정보를얻을수있다. 더자세한내용은 JEUS Reference Book 의 EJB 엔진관련명령어 를참고한다 EJB 엔진튜닝 EJB 엔진의전체적인성능향상을위해설정을변경할수있다. 본절에서는 EJB 엔진의성능관련설정을간략하게설명한다. 튜닝을위해필요한사항은다음과같다. Resolution 설정튜닝 Fast Deploy 기능사용 최대성능을위한시스템로그설정 Active Management 사용하지않기 HTTP Invoke 모드사용 참고 EJB 엔진의정보나팁에대해서는 "JEUS XML Reference" 의 "11. domain.xml EJB 엔진설정 " 을참 고한다. XML/Schema 중 "P" 라고표시된것은성능과관련된것이다 Resolution 설정튜닝 Resolution은 EJB 엔진의상태를체크하는주기로 2가지주기로사용된다. Block된스레드개수가몇개인지검사한후, EJB 엔진을재시작하는 Active management의체크주기를나타낸다. 모든하위컴포넌트들 ( 예, Bean pool) 을점검하고, 각 Bean이비활성화대상인지검사하는 passivation 의체크주기를나타낸다. Resolution 값이클수록시스템메모리나기타리소스의회수주기가길어져자원활용률은떨어지지만이에대한작업수행이덜발생하므로엔진의성능은향상된다. 이값을작게하면엔진은최신상태를유지하겠지만전체적인성능은저하된다. 따라서메모리크기나용도에따라서 Resolution 값을적절하게설정하는것이매우중요하다. 20 JEUS EJB 안내서

39 참고 Resolution 값의설정에따라 <passivation-timeout> 이나 <disconnect-timeout> 이원하는때에발생 하지않을수있으므로주의해야한다 Fast Deploy Fast deploy 옵션은 EJB에설정하지않고애플리케이션별로설정하는것이지만성능에큰영향을미친다. 엔진이기동될때 deploy되어야할 EJB 모듈들이이미컴파일되어 RMI Stub과 Skeleton이있다면 deploy 명령을사용할때 fast 옵션을추가한다. 이는엔진이 EJB 모듈을 deploy할때 RMI 클래스를생성하지않도록하는것이다. EJB 모듈과 deploy에대한자세한내용은 제3장 EJB 모듈 을참고한다 최대성능을위한시스템로그설정 시스템로그는성능개선을위해 3가지방법으로조정가능하다. 가능하면파일핸들러를사용해서 Logging이빠르게이루어지도록하는게좋다. 파일핸들러의버퍼크기를크게설정한다. 로그레벨을 'SEVERE' 로설정한다. 주의위의제안은안정적인운영환경에서만적용되어야한다. 개발환경에서는 " 반대 " 의값들이설정되어야한다. 즉, 콘솔핸들러를사용하고, 작은버퍼크기를사용하고, 'FINE' 로그레벨을사용하는것이개발을용이하게한다 Active Management 사용하지않기 EJB 엔진레벨에 Active Management의사용이반드시필요한것은아니다. 설정에따라성능저하를가져올수있기때문에기본적으로는사용하지않는다. 대신서블릿엔진에정의된 Active Management를사용하는것이편리하다. 그러므로일반적으로 Active Management 설정은생략하는경우가많다 HTTP Invoke 모드사용 클라이언트가많은경우 HTTP Invoke 모드를사용하면성능향상효과가나타난다. 웹서버가 JEUS로의요청을일정하게조절해주기때문에클라이언트의요청대로스레드를생성시키는 RMI에비해 connection 의개수가적게생성된다. 그러나보통의경우에 HTTP 프로토콜로변화하는것은오히려성능저하를가져올수있다는것을고려해야한다. 제 2 장 EJB 엔진 21

40

41 제 3 장 EJB 모듈 본장에서는 EJB 모듈의구조와관리방법에대해서설명한다 개요 EJB 모듈은 EJB 엔진에 deploy할수있는기본단위이다. 또한 EJB 컴포넌트들을그룹화하고이들의설정정보를 Deployment Descriptors( 이하 DD) 로표현할수있도록한것이다. EJB를 deploy할경우에는단하나의 EJB 컴포넌트를 deploy하더라도반드시 EJB 모듈로패키징해야한다. 참고 EJB 2.1 이하의컴포넌트인경우에는 EJB 모듈에반드시 DD(ejb-jar.xml) 가있어야하지만 3.0 이상 의컴포넌트부터는 Annotation 을지원하게되면서 DD 는선택사항으로변경되었다 EJB 모듈관리 다음은 JEUS 내부적으로 EJB 모듈을관리하기위한 4가지주요작업으로각작업에대한상세한설명은세부절을참고한다. assembly : 3.3. EJB 모듈조립 (Assembling) deployment : 3.4. EJB 모듈 Deploy control (undeploy, redeploy, stop-application, start-application) : EJB 모듈제어 monitoring : EJB 모듈의모니터링 제 3 장 EJB 모듈 23

42 EJB 모듈의관리순서는다음과같다. [ 그림 3.1] EJB 모듈관리순서도 EJB Module Assembly Compiling EJB classes?? JARpackaging the EJB Module Creating the Java EE EJB module DD Creating JEUS EJB module DD EJB Module Deployment Pre-compile EJBs through appcompiler tool?? EJB Module Boot-time deployment EJB Module Runtime deployment Execution, control, monitoring EJB Client Component Service request JEUS EJB Engine EJB Module in service Admin Tool (jeusadmin, webmanager) Reload, suspend, resume, undeploy, monitor 24 JEUS EJB 안내서

43 EJB 모듈 JAR 파일구조 다음은표준 EJB 모듈 JAR 파일의구조에대한설명이다. [ 그림 3.2] Java EE EJB 모듈 JAR 파일의구조 EJB Module JAR X META-INF\ Java EE EJB DD Legend: 0I: binary or executable file X: XML document J: JAR file T: Text file C: Class file V: Java source file DD: deployment descriptor X JEUS EJB DD <package name>\ C C C Business Interface EJB Implementation Helper class J Helper library META-INF 구분 ejb-jar.xml jeus-ejb-dd.xml 설명실제적인표준 EJB DD(Deployment Descriptors) 파일이다. Annotation으로설정정보를표현한경우에는존재하지않을수있다. 단, EJB 2.x 스타일의경우에는반드시필요하다. JEUS에서 EJB를 deploy할때필요한 DD 파일이다 ( 선택사항 ). <package name>\ EJB 클래스들을포함하고있다. EJB 소스코드에정의되어있는것과같이 Java 패키지구조를반영하는구조로되어있어야한다. 예를들어하나의 EJB가 "mypackage" 라는패키지에속해있다고선언되어있으면 EJB의클래스는반드시 EJB JAR의 "mypackage" 라는디렉터리아래에위치해야한다. 다음과같은 EJB 컴포넌트를포함한다. 구분 인터페이스 엔터프라이즈 Bean 클래스 설명클라이언트가접근하기위한 EJB 2.x 스타일의인터페이스, 3.0 이상의인터페이스들이다. 인터페이스에맞춰서실제업무로직을구현한 Bean 클래스들을의미한다. 제 3 장 EJB 모듈 25

44 Helper library MANIFEST.MF Class-Path Entry 에명시한라이브러리에해당한다 EJB 모듈조립 (Assembling) [ 그림 3.1] 과같이 EJB 모듈을조립할때는다음의과정을수행한다. 1. EJB 클래스컴파일개발자가구현한 EJB 소스파일들을컴파일한다. 2. 경우에따른 DD 작성 ejb-jar.xml DD 작성 jeus-ejb-dd.xml DD 작성 3. EJB JAR 파일패키징 JAR 파일로 EJB 클래스와 DD를패키징한다. 다음절부터는 "counter" 예제를통해 EJB 모듈조립과정을설명한다. "counter" 는 JEUS_HOME/sam ples/ejb/basic/statefulsession/ 디렉터리에위치한 Stateful Session Bean으로, 다음과같은 2개의 Java 소스파일이갖는다. Counter.java(business interface) CounterEJB.java(bean implementation) 참고 Stateful Session Bean 이나다른종류의 Bean 에대한자세한정보는 제 7 장 Session Bean, 제 9 장 Message Driven Bean(MDB) 을참고한다 EJB 클래스컴파일 개발자가구현한 EJB 소스파일들을컴파일한다. EJB 소스파일들로부터 EJB 모듈을조립하는첫번째과정은소스파일들을컴파일하는것이다. 이는 JDK의 javac 컴파일러를이용한다. 클래스패스는기본적으로 JEUS_HOME/lib/system/javaee.jar를사용하며, jeus-ejb-dd.xml에대응되는 Annotation을사용했다면 JEUS_HOME/lib/system/jeusapi.jar를추가하고, 또다른 helper 클래스가있다면모두추가한다. 다음은 "counter" Bean에서사용될 EJB Java 파일들을 UNIX 환경에서컴파일하는명령실행에대한예이다. $ javac classpath JEUS_HOME/lib/system/javaee.jar *.java 위명령을실행하면클래스파일들이생성된다. 26 JEUS EJB 안내서

45 Deployment Descriptors(DD) 작성 EJB 모듈을 deploy할때사용되는 DD는다음과같이 2가지로나누어진다. 표준 EJB DD "ejb-jar.xml" 로명명되고, EJB 모듈의 "META-INF/" 디렉터리에위치한다. 개발자가 EJB 컴포넌트를작성할때는설정정보의일부또는전부를 Annotation으로작성할수도있다. 만약 Annotation 정보를무시하고 DD의설정만을적용하고싶은경우에는 ejb-jar.xml에 <metadata-complete> 를 true로설정한다. Annotation과 DD를혼용해서사용한경우는 DD가 Annotation에우선한다. JEUS EJB DD "jeus-ejb-dd.xml" 로명명되고, EJB 모듈의 "META-INF/" 디렉터리에위치한다. 이파일의내용에대한정보는아래의 "jeus-ejb-dd.xml DD 작성 " 을참고한다. ejb-jar.xml DD 작성 DD의포맷은 EJB 표준에따른다. 대부분 Annotation으로가능하지만필요한경우 DD를사용한다. package public interface Counter { public void increase();... } @TransactionManagement( TransactionManagementType.BEAN) public class CounterEJB implements Counter { private int count = 0; public void increase() { count++; }... } 위의 Annotation을표준 DD인 ejb-jar.xml로나타내면다음과같다. 다음예제는 "counter" Bean의간단한 EJB 표준 DD를나타낸것이다. [ 예 3.1] EJB 표준 DD : <<ejb-jar.xml>> <?xml version="1.0"?> <ejb-jar version="3.1" xmlns=" 제 3 장 EJB 모듈 27

46 xmlns:xsi=" xsi:schemalocation=" <enterprise-beans> <session> <ejb-name>counter</ejb-name> <business-remote>ejb.basic.statefulsession.counter</business-remote> <ejb-class>ejb.basic.statefulsession.counterejb</ejb-class> <session-type>stateful</session-type> <transaction-type>bean</transaction-type> </session> </enterprise-beans> <assembly-descriptor/> </ejb-jar> 참고 EJB 3.0 이상부터는 ejb-jar.xml 의모든내용은 Annotation 으로표현가능하므로 ejb-jar.xml 은선택 적으로사용한다. jeus-ejb-dd.xml DD 작성 JEUS EJB DD가필요한이유는 EJB 엔진에 deploy하기위한기본설정및 External Reference들을 JEUS 서비스에매핑시키기위함이다. 그외에도인스턴스 Pooling과 Entity Bean, DB 테이블과의매핑설정도 jeus-ejb-dd.xml에서한다. 참고이러한설정들은 EJB 모듈을 JEUS에맞추어 deploy하기위해서필요한작업들이지만일부는 Anno tation으로설정가능하고 jeus-ejb-dd.xml이존재하지않아도기본값으로설정되기때문에별도로환경설정을해야하는경우에만이작업을수행한다. JEUS EJB DD는표준 EJB DD에부가적인설정으로볼수있다. 표준 EJB DD와마찬가지로 JEUS EJB DD도 EJB 모듈에적용된다. 다음은 JEUS EJB DD의전반적인구성이다. [ 예 3.2] JEUS EJB DD : <<jeus-ejb-dd.xml>> <?xml version="1.0"?> <jeus-ejb-dd xmlns=" <module-info> <role-permission> <!-- See chapter EJB 보안설정 --> </role-permission> </module-info> <beanlist> 28 JEUS EJB 안내서

47 <jeusbean> <!-- See chapters 제4장 EJB의공통특성 and 제7장 Session Bean --> </jeusbean> <jeusbean> <!-- See chapters 제4장 EJB의공통특성 and 제7장 Session Bean --> </jeusbean> </beanlist> <ejb-relation-map> <!-- See chapter 제8장 Entity Bean --> </ejb-relation-map> <message-destination> <jndi-info> <ref-name>ejb/accountejb</ref-name> <export-name>accejb</export-name> </jndi-info> </message-destination> <library-ref> <library-name>jsf</library-name> <specification-version>1.2</specification-version> <implementation-version>1.2</implementation-version> </library-ref> </jeus-ejb-dd> JEUS EJB DD 의주요요소들은다음과같다. 항목 <module-info> <beanlist> <ejb-relation-map> <message-destination> 설명 EJB 모듈전체에적용되는포괄적인정보를설정한다. Role assignment에관련된정보는 EJB 보안설정 을참고한다. 모듈에포함되는 EJB들을선언한다. 이하위태그의이름과내용은 Bean의종류 (Session Bean. Entity Bean, MDB) 에따라세부설정이달라진다. beanlist와그것의하위태그는 제4장 EJB의공통특성, 제7장 Session Bean 부터 제9장 Message Driven Bean(MDB) 을통해자세히설명한다. CMP 2.0 Bean들을위한 CMR 매핑을정의한 EJB Relation Mapping 설정이다. CMP는더이상사용을권장하지않으므로 JPA를사용한다. ejb-jar.xml의 <message-destination> 에선언된 message destination과 JNDI 에등록된실제 Destination 객체를매핑한다. 제 3 장 EJB 모듈 29

48 항목 <library-ref> 설명 애플리케이션에서사용할공유라이브러리 (shared library) 의정보를명기한 다 EJB JAR 파일패키징 EJB JAR 파일을패키징할때에는 jar 유틸리티를사용하고, 다음의사항을가정한다. ejb/basic/statefulsession 디렉터리에 counter EJB 클래스파일들이존재한다. 클래스에 Annotation으로설정하여 ejb-jar.xml과 jeus-ejb-dd.xml은존재하지않는다. EJB JAR 파일의패키징과정은다음과같다. 1. 다음과같이 EJB 클래스들을하나의 JAR 파일로묶는다. $ jar cf countermod.jar ejb/basic/statefulsession counterbeanclient.jar 이것으로 countermod.jar라는 Java EE EJB 모듈을완성한다. 2. 클라이언트에서이 EJB를사용하기위해서는인터페이스파일이필요하다. 클라이언트에서사용하기위해배포할 counterbeanclient.jar는다음과같이생성한다. $ jar cf counterbeanclient.jar ejb/basic/statefulsession/counter.class 참고 counterbeanclient.jar 는원격클라이언트에서사용하기위한배포용라이브러리이다 EJB 모듈 Deploy 본절에서는 EJB 모듈의 deploy 에대한내용을설명한다 Deploy 일반적으로는 deploy할때 EJB 클래스를컴파일하지만 appcompiler를사용해서 EJB 클래스를미리컴파일하면 deploy할때의속도를향상시킬수있다. 또한 Auto Deploy 기능을사용해서손쉽게 EJB 모듈을 deploy할수도있다. Deploy에대한자세한내용은 "JEUS Applications & Deployment 안내서 " 를참고한다. [ 그림 3.1] 에서 JEUS는다음과같은방법으로 EJB 모듈을 deploy한다. appcompiler 툴이용 appcompiler 툴을사용하면 Stub과 Skeleton 파일들을미리생성하여 Deploy 속도를빠르게할수있다. EJB 모듈의 Boot-time Deploy 30 JEUS EJB 안내서

49 EJB 엔진이시작할때마다 EJB 모듈이자동으로 deploy되도록한다. EJB 모듈의 Runtime Deploy EJB 엔진이시작되고난후에즉, EJB 엔진이운영되고있을때 EJB 모듈을 deploy한다. 콘솔툴과 WebAdmin을사용해서 EJB 모듈을 EJB 엔진에 deploy한다. appcompiler 툴이용 EJB 2.x 모듈의경우 appcompiler 툴을사용함으로써 Stub과 Skeleton 파일들을미리생성하여 Deploy 속도를빠르게할수있다. appcompiler를사용할경우에는콘솔툴의 deploy 명령을할때 fast 옵션을사용한다. 이옵션이사용되지않을경우에는 appcompiler는효과가없다. appcompiler 툴에대한자세한정보는 JEUS Reference Book 의 4.3. appcompiler 를참조한다. EJB 모듈의 Boot-time Deploy MS가기동 (Booting) 될때 deploy되는것을 Boot-time deploy라고하는데, DAS를통해한번 deploy된애플리케이션은 MS를기동할때마다 Boot-time deploy된다. 애플리케이션의 deploy 설정에대한자세한내용은 "JEUS Applications & Deployment 안내서 " 의 deploy 항목을참고한다. 하나의도메인에여러개의애플리케이션을등록할수있다. EJB 모듈의 Runtime Deploy Runtime deploy는실행되고있는 EJB 엔진에 EJB 모듈을 deploy하는것을의미한다. 콘솔툴의 deploy 명령어를이용하여실행되고있는 EJB 엔진에모듈을설치할수있다. "countermod" EJB 모듈의 deploy 과정을설명한다. 모듈을 deploy하기위해다음의사항을가정한다. JEUS의 domain1이라는 DAS와 server1이라는 MS가이미기동 (Booting) 되어있다. countermod 모듈이 JEUS_HOME/apphome 하위의 countermod.jar나 countermod 디렉터리형태로존재한다. EJB 모듈의 Runtime Deploy는콘솔툴을사용하거나 WebAdmin을사용할수있다. 콘솔툴사용 deploy 과정은다음과같다. 1. 콘솔툴을실행한다. 콘솔툴에대한자세한설명은 JEUS Reference Book 의 Local 명령어 를참고한다. $ jeusadmin -host localhost: 사용자이름과패스워드를입력한다. 제 3 장 EJB 모듈 31

50 User name: administrator Password: Try to connect to localhost:9736. Connection has been established to domain administration server: adminserver in domain: domain1. JEUS7 Administration Tool To print help, use the 'help' command. [DAS]domain1.adminServer> 3. deploy 명령을실행해서 "countermod" EJB 모듈을 deploy 한다. [DAS]domain1.adminServer> deploy countermod -servers server1 4. deploy 를확인하기위해다음과같이 application-info 명령을실행하면 "countermod" 모듈이포함 된모든 deploy 된애플리케이션들이출력된다. [DAS]domain1.adminServer> application-info WebAdmin 사용 WebAdmin을사용하여 deploy하는과정은다음과같다. 1. WebAdmin의 [Applications] 메뉴를선택하면애플리케이션목록조회화면으로이동한다. 애플리케이션목록조회화면에서 deploy하려는애플리케이션의 [deploy] 버튼을클릭한다. [ 그림 3.3] 애플리케이션 deploy - 애플리케이션목록조회 2. [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. Deploy 화면에서애플리케이션의 deploy 속성을설정하고 [ 확인 ] 버튼을클릭한다. WebAdmin에서의애플리케이션 deploy 설정에대한자세한내용은 "JEUS Applications & Deployment 안내서 " 의 deploy 항목을참고한다. 32 JEUS EJB 안내서

51 [ 그림 3.4] 애플리케이션 deploy - 속성설정 4. deploy 된애플리케이션은 'Command' 컬럼에다음과같이 [stop], [undeploy], [redeploy], [addtarget], [remove-target] 의버튼이생기면서제어가가능해진다. 각버튼의기능과제어에대한자세 한내용은 EJB 모듈제어 를참고한다. 제 3 장 EJB 모듈 33

52 [ 그림 3.5] 애플리케이션 deploy - 결과 Deploy 된 EJB 모듈의디렉터리구조 EJB 모듈이 deploy된후에클래스파일들과설정파일들은다음과같은구조로 JEUS 설치디렉터리에배포된다. [ 그림 3.6] deploy된 EJB 모듈의디렉터리구조 34 JEUS EJB 안내서

53 JEUS_HOME/domains/<domain name>/servers/<server name>/.workspace/deployed/ 디렉터리는 <server name> 에해당하는 MS에 deploy된애플리케이션들이존재하는디렉터리이다. 여기에는 deploy 된 EJB 모듈의 EJB 구현클래스들뿐만아니라 helper 클래스들이위치한다. Deploy 방식은다음과같이나누어지며, 방식에따라 deploy되는파일이위치하는디렉터리가달라진다. Deploy 방식 EAR Deploy 방식 Standalone Deploy 방식 Exploded EAR Deploy 방식 Exploded Standalone Deploy 방식 설명 EAR 파일이 deploy되는경우에는해당 EAR 파일이름으로생성된디렉터리아래에 EAR에포함된모듈이각각놓인다. JAR 파일이 deploy된경우에는해당 JAR 파일이름으로생성된디렉터리에 "<jar 파일이름 >_jar " 디렉터리아래에놓인다. EAR 파일을 archive 형태가아닌풀어놓은상태에서 deploy하는방식이다. JAR 파일을 archive 형태가아닌풀어놓은상태에서 deploy하는방식이다. Exploded EAR Deploy 방식과 Exploded Standalone Deploy 방식은 webhome 디렉터리로복사되지않고 원래의위치를참조한다. JEUS 에서는 Archive 파일이존재하는 standalone Deployment 를 COMPONENT Type, 풀어놓은것을 EXPLODED COMPONENT Type 이라고부른다. 참고 이후의설명에서는 Standalone 모듈에대해서만설명한다. EAR Deploy 방식이나 deploy 전반에대 한상세한설명은 "JEUS Applications & Deployment 안내서 " 의 Deploy 관련부분을참고한다 EJB 모듈제어및모니터링 deploy 된 EJB 모듈에대해실행상태를제어하거나모니터링할수있다. ([ 그림 3.1] 참고 ) EJB 모듈제어 deploy된 EJB 모듈을 stop-application, start-application, redeploy-application, undeploy 명령을통해 EJB 모듈내의실행상태를제어할수있다. EJB 모듈의제어는다음과같이 2가지방법을사용할수있다. WebAdmin을사용한 EJB 모듈제어 콘솔툴을사용한 EJB 모듈제어본절에서는 undeploy 명령의사용예제를통해 EJB 모듈을제어하는방법에대해설명한다. 제 3 장 EJB 모듈 35

54 WebAdmin 사용 WebAdmin을사용하여 EJB 모듈을제어할수있다. WebAdmin의 [Applications] 메뉴를클릭하면다음과같이 Deployed Applications 화면에애플리케이션목록이조회된다. 목록에서 deploy된애플리케이션의 'Command' 컬럼에는다음과같은컨트롤버튼이존재한다. 각버튼은콘솔툴의옵션과각각대응된다. [ 그림 3.7] deploy된애플리케이션목록 WebAdmin을사용하여 undeploy하는과정은다음과같다. 1. 애플리케이션을 undeploy하려면 [Applications] 메뉴를선택한다. 조회된애플리케이션목록에서원하는애플리케이션의 'Command' 컬럼에위치한 [undeploy] 버튼을클릭한다. ([ 그림 3.7] 참고 ) 2. 다음과같이 Undeploy 화면이나타나고, 요청중인서비스가완료될때까지기다리는시간인 'Timeout' 항목을설정하고 [ 확인 ] 버튼을클릭하면 undeploy가수행된다. [ 그림 3.8] 애플리케이션 undeploy - 속성설정 36 JEUS EJB 안내서

55 참고 'Graceful' 항목은 Graceful Redeploy가진행된경우 old 애플리케이션과 new 애플리케이션중어느것을 undeploy할지결정하는설정이다. 3. 정상적으로 undeploy가되면다음과같이결과메시지가나타나고해당애플리케이션의 'State' 와 'Command' 컬럼이변경된것을확인할수있다. [ 그림 3.9] undeploy 애플리케이션 - 결과 콘솔툴사용 콘솔툴에는다음과같은제어명령을사용해서 EJB 모듈을제어한다. 모든명령어는 EJB 모듈이름을파라미터로받는다. redeploy-application redeploy-application은지정한 EJB 모듈을다시로딩하는명령어로현재활성화되어있는 EJB 모듈을 EJB 실행환경에서 undeploy했다가다시디스크로부터읽어 deploy하는것을의미한다. undeploy가실행되고다시로딩이수행될때 undeploy된 EJB 모듈의모든트랜잭션상태는잃어버린다. 이는 undeploy되거나 redeploy되는모듈과연관있는모든 EJB 트랜잭션이 rollback된다는것을의미한다. redeploy-application <module name> stop-application stop-application 명령은선택된 EJB 모듈을일시적으로중지시켜클라이언트의요청으로부터한시적으로 EJB 모듈이접근이불가능한상태가된다. start-application 명령으로다시 EJB 모듈을접근가능한상태로되돌린다. stop-application <module name> start-application 제 3 장 EJB 모듈 37

56 stop-application 명령으로중지되었던 EJB 모듈을다시활성화한다. start-application <module name> undeploy undeploy 명령은선택된모듈을 EJB 엔진의실행메모리에서제거해서 EJB 엔진의운영메모리에서 EJB 모듈을내려 EJB 클라이언트가 EJB에접근불가능한상태가된다. 그러나파일을물리적으로삭제하지는않는다. undeploy <module name> 다음은콘솔툴을사용하여 EJB 모듈을 undeploy 하는방법을설명하는예이다. 1. 콘솔툴을실행한다. $ jeusadmin -host localhost: 사용자이름과패스워드를입력한다. User name: administrator Password: Try to connect to localhost:9736. Connection has been established to domain administration server: adminserver in domain: domain1. JEUS7 Administration Tool To print help, use the 'help' command. [DAS]domain1.adminServer> 3. 다음과같이 undeploy 명령을실행하고성공하면 "countermod" EJB 모듈이 undeploy 된다. [DAS]domain1.adminServer> undeploy countermod 4. undeploy 된것을확인하기위해다음과같이 application-info 명령을실행한다. "countermod" 모듈을 제외한 deploy 된모든모듈들이조회된다. [DAS]domain1.adminServer> application-info 참고 콘솔툴에대한상세한정보는 JEUS Reference Book 의 4.2. jeusadmin 을참조한다 EJB 모듈의모니터링 콘솔툴을사용하여 EJB 모듈을모니터링할수있다. 콘솔툴에서 application-info 명령을실행하면다음과같이 deploy되고활성화된 EJB모듈로부터상태와운영정보를조회할수있다. application-info 명령에대한자세한내용은 JEUS Reference Book 의 EJB 엔진관련명령어 를참고한다. 38 JEUS EJB 안내서

57 모듈정보조회해당모듈에대한정보를조회한다. [DAS]domain1.adminServer>application-info -server server1 -id countermod -detail General information of EJB module [countermod] ============================================================== Module Name Unique Module Name countermod countermod ============================================================== Beans ================================================================================ Bean Name Type Local Export Name Remote Export Name Count StatelessSessionBean Count ================================================================================ Bean 조회해당모듈 ("module name") 에포함된 EJB의목록을조회한다. [DAS]domain1.adminServer>application-info -server server1 -id countermod -bean Count Module name : countermod Bean name : Count ================================================================================ Name (Count) WaterMark(High:Low Bound(Upper:L Time(Max:Min:T :Cur) ower) otal) create times(0) 제 3 장 EJB 모듈 39

58 remove times(0) timed-rb transactio n(0) request request(0) active-bean bean(0:0:0) rolledback transactio n(0) total-bean bean(0:0:0) comitted transactio n(0) MethodReadyCou bean(0:0:0) nt active-thread thread(0:0:0) total-remote-t thread(100:100:100) 40 JEUS EJB 안내서

59 hread ================================================================================ 참고 EJB 모듈의모니터링은 WebAdmin을사용할수도있지만콘솔툴을사용할경우에더자세한정보를조회할수있다. WebAdmin을사용할경우 [Monitoring] 메뉴의 [JNDI] 메뉴또는 [EJBTimer] 메뉴를통해 EJB 모듈의일부정보를모니터링할수있다. 모니터링하는자세한방법은각각 JEUS Server 안내서 의 바인딩된객체확인 과 타이머모니터링 을참고한다. 제 3 장 EJB 모듈 41

60

61 제 4 장 EJB 의공통특성 본장에서는 JEUS 에서의 EJB 공통특성에대해설명한다. EJB 표준에언급된내용은설명하지않고, JEUS 에서 EJB 를사용하기위해필요한추가적인정보들만제 공한다. 또한 EJB deploy 에대해언급하지않으므로 제 3 장 EJB 모듈 의내용을먼저참조한다 개요 본절에서는 EJB 의종류와각종류별 DD 설정에대해서설명한다. EJB 종류 JEUS는 EJB 스펙에따라다음의 EJB들을지원한다. Stateless Session Bean : 제7장 Session Bean Stateful Session Bean : 제7장 Session Bean BMP Entity Bean : 제8장 Entity Bean CMP 1.1 & CMP 2.x Entity Bean : 제8장 Entity Bean Message-Driven Bean : 제9장 Message Driven Bean(MDB) 본장에서는모든 Bean들에적용되는공통적인특징과설정에대해서설명한다. 각 EJB에대한추가적인상세정보는위에나열된해당장을참고한다. 참고 Entity Bean 은 EJB 3.0 부터는 JPA 로대체되었으므로이에대해서는 "JEUS JPA 안내서 " 를참조한 다. 따라서 Entity Bean 의사용을권장하지않지만하위호환성을위해계속지원하고있다. EJB 종류별 Deployment Descriptors 설정 JEUS EJB DD는 "jeus-ejb-dd.xml" 로명명된 XML 파일이며, EJB JAR 파일의 META-INF 하위에존재한다. JEUS EJB DD에대한간단한내용은 제3장 EJB 모듈 을참고한다. 다음은 JEUS EJB DD로설정가능한기능들과컴포넌트들의간략한정보를나타낸다 ("@" 표시는 Anno tation으로도설정가능한개체이다 ). 표의왼쪽에나열된항목들은실제설정가능한 JEUS EJB DD의 XML 태그들이다. 표의나머지 6개의열은 EJB 종류에따른설정사항들을나타낸다. 제 4 장 EJB 의공통특성 43

62 [ 표 4.1] JEUS EJB 의설정가능한특징들과컴포넌트들 설정가능한개체 Stateless Stateful BMP CMP1.1 CMP2.0 MDB 1. EJB 2. Export 3. Local export 4. Export port 5. Export IIOP switch 6. Single VM switch 7. Local invocation optimization 8. Fast deploy 9. use-access-control 10. Run-as identity 11. Security CSI Interop. 12. Env. 13. EJB 14. Resource 15. Resource env. 16. Thread ticket pool settings ` 17. Clustering 18. HTTP Invoke 19. JEUS RMI 20. Pooling Bean Switch 21. Object management 22. Persistence Optimize 23. CM persistence opt. 24. Schema info 25. Relationship map 26. Connect. fact. name 27. MDB resource adaptor JNDI SPI settings 30. Max messages 31. Activation 44 JEUS EJB 안내서

63 설정가능한개체 Stateless Stateful BMP CMP1.1 CMP2.0 MDB 32. Durable Timer Service 위의표는다음과같이나누어진다. 항목 1부터 19까지는 6개의 EJB 종류모두에공통으로적용되는사항이다 (MDB의 2~8과 17~19은제외 ). 이모든항목들에대해서본장에서설명한다. 항목 10(run-as identity) 과 11(security interoperability), 17(clustering) 은모든 EJB 종류에공통이지만, 각각 EJB 보안설정, 제5장 EJB 상호운용성및 RMI/IIOP, 제6장 EJB 클러스터링 에서별도로설명한다. 항목 20은 Stateful Session Bean에대해서만적용되며, 제7장 Session Bean 에서자세히설명한다. 항목 21(object management) 은 6개의 EJB 종류모두에공통으로적용되는사항이나 Bean의종류에따라조금씩다르므로기본적인것은 제7장 Session Bean 에서설명하고각장에서차이점을설명한다. 항목 22부터 25까지는 Entity Bean에만적용된다. 이들은 제8장 Entity Bean 에서설명한다. 항목 26부터 31까지는 MDB에만적용된다. 이들은 제9장 Message Driven Bean(MDB) 에서설명한다. 항목 32는 EJB 스펙에서제공하는타이머서비스를사용할수있는 Bean(Stateful Session Bean을제외한모든 Bean) 에사용할수있다. 이는 제10장 EJB Timer Service 에서설명한다 EJB 설정 모든 EJB 설정들은 JEUS EJB DD 파일인 jeus-ejb-dd.xml 파일내에설정된다. 상위 XML 태그는 Bean의종류에관계없이 <jeus-bean> 을사용한다. 다음절에서는위의 5종류의 EJB XML 부모태그들에적용될수있는설정들을설명한다. <beanlist> 밖에있는다른태그들은 제3장 EJB 모듈 에서이미설명하였다. 특정 XML 부모태그 (Bean 종류 ) 에대한설명은이문서의후반부에나오는해당장들을참고한다. 참고 클러스터링환경설정은 제 6 장 EJB 클러스터링 을참고한다 기본환경설정 다음은주로사용되는 JEUS 전용설정들이며 jeus-ejb-dd.xml에선언되어있다. 이파일에대해서는 제3 장 EJB 모듈 을참고한다. <ejb-name> 표준 ejb-jar.xml에서 @MessageDriven의 "name" 값과동일한이름이다. 제 4 장 EJB 의공통특성 45

64 <export-name> 글로벌 JNDI에등록될시스템내부에서유일한이름을가져야한다. DD 파일에이 mappedname attribute 값이적용되거나, ejb-jar.xml의 <mapped-name> 값이적용된다. 이모든설정이없는경우는기본값으로 Remote Business Interface name이사용된다. 단, Remote Business Interface가하나만존재하고 Remote Home Interface가존재하지하는경우나, Remote Business Interface가존재하지않고 Remote Home Interface가존재하는경우에만기본값이적용되고아닌경우에는 JNDI name을결정할수없어 deploy가실패한다. 순위는다음과같다. 1. jeus-ejb-dd.xml의 <export-name> 2. ejb-jar의 <mapped-name> mappedname 4. 기본값인 Remote Business Interface의클래스이름 ( 패키지명포함 ) <local-export-name> JNDI에등록될시스템내부의유일한이름을가져야한다. DD 파일에이 element가없는경우 mappedname attribute 값에적용된다. 만약 Remote Business Interface가존재하는경우에는이값에 '_Local' 이붙는다. 둘다없는경우는기본값으로 Local Business Interface name이사용된다. 단, Local Business Interface 가하나만존재하고 Local Home Interface가존재하지않는경우나 Local Business Interface가존재하지않고 Local Home Interface가존재하는경우에만기본값이적용되고아닌경우에는 JNDI name 을찾을수없어 Exception이발생한다. 순위는다음과같다. 1. jeus-ejb-dd.xml의 <local-export-name> 2. Remote Business Interface가존재하면 ejb-jar.xml의 <mapped-name>+ _Local Remote Business Interface가존재하지않으면 ejb-jar.xml의 <mapped-name> 3. Remote Business mappedname + _Local Remote Business mappedname 4. 기본값인 Local Business Interface의클래스이름 ( 패키지명포함 ) <export-port> RMI 서비스포트를명시적으로설정할필요가있을때에이설정을사용한다. 방화벽을사용하고있어서특정포트로만시스템접근을허용할경우에유용하다. 이태그의설정은방화벽설정의 allowed 로설정된포트와동일한것이어야한다. 값을지정하지않는경우는시스템프로퍼티에따라일괄적으로포트가적용되는데정리하면다음과같다. 46 JEUS EJB 안내서

65 항목 jeus.ejb.exportport jeus.rmi.usebaseport 설명 jeus-ejb-dd에특정 EJB에대한 <export-port> 가지정되어있지않는나머지 EJB의 export port를결정한다. 값이 true이면 Managed Server base port를사용하고 false이면 Managed Server base port + 7을사용한다. <export-iiop> 활성화되어있을경우에 Bean의인터페이스가 IIOP Stub과 Skeleton으로서 COS Naming Server에 export될수있도록한다. 이는 IIOP로접근가능한모든클라이언트가 Bean에접근가능하도록한다. <use-access-control> Boolean 설정은 Bean 메소드들을수행할때 Java EE의 principal에따라메소드의수행이 Java SE Security Manager의감시를받도록할것인지를결정한다. 자세한내용은 "JEUS Security 안내서 " 와 JACC specification을참고한다. ( 기본값 : false) 다음은위의설정들이 Stateful Session Bean class와 DD에적용된예로, 대응되는 Annotation과 DD의 element는굵게표시했다. [ 예 4.1] Stateful Session Bean class와 DD : <<CounterEJB.java>> package mappedname="counterejb") public class CounterEJB implements Counter, CounterLocal { private int count = 0; public void increase() { count++; }... } [ 예 4.2] Stateful Session Bean class와 DD : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <ejb-name>counter</ejb-name> <export-name>counterejb</export-name> <local-export-name>counterejb_local</local-export-name> <export-port>7654</export-port> 제 4 장 EJB 의공통특성 47

66 <export-iiop/> </jeus-bean> </beanlist> </jeus-ejb-dd> Thread Ticket 설정 다음은 EJB Thread Ticket Pool( 이하 TTP) 의개념을나타낸그림이다. 기본적인동작은클라이언트로부터요청을받으면새로운 RMI 스레드를클라이언트요청에부여하는것이다. 이때부여된 RMI 스레드의수가설정된최댓값보다많은경우에는해당요청에스레드를부여하지않고대기한다. [ 그림 4.1] TTP 상태전이도 Transition format: <transition name> [ <guard cond. (boolean cond.)> ] / <Actions performed> EJB Client Thread Association Client -Thread ticket EJB Engine Thread Ticket Pool (TTP) Pooled Thread Ticket create [new client request] / Use/draw thread ticket from TTP Active Thread Ticket disconnect [business method returns] / Return thread ticket to TTP Association TT - EJB Object EJB Object 위그림에서볼수있듯이 TTP는 Thread Ticket( 이하 TT) 을가지고있다. 한개의 TT는하나의클라이언트스레드가 EJB 엔진에접근할수있도록허가한다. 클라이언트의요청이도착하면, 하나의 TT가 TTP에서얻어지고클라이언트에게부여된다. 이는각클라이언트스레드는실제 EJB Instance에게요청을전달할한개의 EJB Object에게할당된다는것을의미한다. 그러므로 EJB Object는 EJB 엔진내에존재하는하나의 Object라고볼수있고 EJB 클라이언트와실제 EJB Instance와의연결을관리한다. TTP에있는 TT의숫자보다많은클라이언트의요청이오는경우새로운요청은 TT가 Free되어 Pool로반환될때까지기다려야한다. 클라이언트의요청이 TT를기다린지 10분이초과할경우시간초과로 Re moteexception을던진다. EJB 처리가끝나거나 (Stateless Session Bean) connection 타임아웃이발생하여클라이언트가연결을잃을경우에 TTP로 TT가반환된다. 그리고 TTP는원격호출이가능한 EJB 컴포넌트마다하나씩가지고있다. 이외에도 Connection Pool과 Bean Pool이있다. MDB에서는 TTP가아닌 Bean Pool을설정해야한다. 48 JEUS EJB 안내서

67 참고 Connection Pool과 Bean Pool에대한자세한내용은 제7장 Session Bean 과 제8장 Entity Bean 을참고한다. MDB에서 Bean Pool 사용에대한자세한내용은 제9장 Message Driven Bean(MDB) 을참고한다. EJB의 TT은 Bean의최상위 XML 태그의 <thread-max> 에서설정한다. 이값은각 EJB를수행하는스레드의최대허용개수, 즉최대 TT의수를의미한다. 기본은 100이다. 대기하고있는클라이언트의요청수가이값보다클경우에는새로운요청들은먼저진행중인작업이끝나고, Pool로 TT가반환될때까지대기한다. 대기한지 10분이지날경우시간초과로 RemoteException을던진다. 다음은 BMP Bean에위의설정을적용한예이다. [ 예 4.3] BMP Bean 설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <thread-max>200</thread-max> </jeus-bean> </beanlist> </jeus-ejb-dd> External Reference 설정과매핑 Bean이사용하는 External Reference는 Annotation을통해설정하거나또는 ejb-jar.xml에서사용한 reference 이름과매핑된 jeus-ejb-dd.xml의 JNDI export name을사용하여설정할수있다. 선언된모든 External Reference들은 JNDI export name과매핑되어야한다. Annotation이나 ejb-jar.xml에선언된 External Reference는각 Reference에해당하는 jeus-ejb-dd.xml의태그에실제시스템 JNDI export name으로매핑되어야한다. 다음은 ejb-jar.xml 과 JEUS EJB DD 파일의참조태그에대한설명이다. [ 표 4.2] ejb-jar.xml 과 JEUS EJB DD 파일의참조태그와관계 태그 <env-entry> <ejb-ref> EJB DD XML 태그 <env> <ejb-ref> 설명 EJB 환경설정을정의하거나무시한다. EJB reference를실제 export name으로 binding한다. 제 4 장 EJB 의공통특성 49

68 태그 <resource-ref> <resource-env-ref> <message-destination-ref> <service-ref> EJB DD XML 태그 <res-ref> <res-env-ref> <message-destination-ref> <service-ref> 설명 external resource manage reference를실제 export name에 binding한다. 관리되고있는 object reference를실제 ex port name에 binding한다. message destination의 reference를실제 export name에 binding한다. webservice endpoint의 reference를실제 export name에 binding한다. 모든 <env> 태그는다음의하위태그를설정해야한다. 태그 <name> <type> <value> 설명 env의이름으로 ejb-jar.xml에정의된 <env-entry-name> 태그의값과같은값을사용한다. 값의자료형에해당하는완전한 Java 클래스이름으로기본자료형은 wrapper 클래스를사용한다. env의실제값을선언한다. 다른태그들 (<ejb-ref>, <res-ref>, <res-env-ref>) 은여러개의 <jndi-info> 태그를가진다. 이태그들은또 JNDI export name 에 Reference 를매핑하기위해서다음과같은하위태그를설정해야한다. 태그 <ref-name> <export-name> 설명 EJB 소스코드와 ejb-jar.xml에서정의된참조이름으로 ejb-jar.xml에서 <ejb-ref> 와동격의태그는 <ejb-ref> 이다. <resource-ref> 와동격은 <res-ref> 이고, <resource-envref> 와동격은 <res-env-ref> 이다. JNDI에 export될때사용되는이름이다. 참고 <ref-name> 과 <export-name> 태그는반드시 ejb-jar.xml 에설정된이름과같은값이어야한다. 다음은 External Reference 를 JNDI 로매핑하는방법으로, Annotation 과 XML 의예이다. [ 예 4.4] External Reference 를 JNDI 로매핑 beaninterface=ejb.account.class, type=javax.sql.datasource.class, mappedname="accountdb") public class CounterEJB implements Counter{ 50 JEUS EJB 안내서

69 @Resource(name="minAmount") private int minaccount = 100; } [ 예 4.5] External Reference를 JNDI로매핑 : <<ejb-jar.xml>> <ejb-jar.xml> <enterprise-beans> <session> <env-entry> <env-entry-name>minamount</env-entry-name> <env-entry-type>java.lang.integer</env-entry-type> </env-entry> <ejb-ref> <ejb-ref-name>accountejb</ejb-ref-name> <ejb-ref-type>session<ejb-ref-type> <remote>ejb.account</remote> </ejb-ref> <resource-ref> <res-ref-name>jdbc/dbds</res-ref-name> <res-ref-type>javax.sql.datasource</res-ref-type> </resource-ref> </session> </enterprise-beans> </ejb-jar.xml> [ 예 4.6] External Reference를 JNDI로매핑 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <env> <name>minamount</name> <type>java.lang.integer</type> <value>100</value> </env> <ejb-ref> <jndi-info> <ref-name>accountejb</ref-name> <export-name>accejb</export-name> 제 4 장 EJB 의공통특성 51

70 </jndi-info> </ejb-ref> <res-ref> <jndi-info> <ref-name>jdbc/dbds</ref-name> <export-name>accountdb</export-name> </jndi-info> </res-ref> </jeus-bean> </beanlist> </jeus-ejb-dd> HTTP Invoke 환경설정 EJB 모듈중특정 EJB에 HTTP invocation을설정하고사용하기위해서는 jeus-ejb-dd.xml의 <jeus-bean> 하위에 <invoke-http> 를설정해야한다. EJB 엔진에서 HTTP invocation이필요하면 EJBMain.xml에서 <invoke-http> 를추가한다 ( 제2장 EJB 엔진 에서언급 ). EJBMain.xml의설정은모든모듈에적용되는데, 각모듈의 DD 파일에 <invoke-http> 가있다면파일의설정을사용한다. 다음은 jeus-ejb-dd.xml의 HTTP invoke 환경설정예제이다. [ 예 4.7] HTTP Invoke 환경설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <invoke-http> <url> /mycontext/rmiservlethandler </url> <http-port> 80 </http-port> </invoke-http> </jeus-bean> </beanlist> </jeus-ejb-dd> 52 JEUS EJB 안내서

71 <invoke-http> 설정에는 2 개의하위태그가존재한다. 태그 <url> 설명 반드시 HTTP-RMI Stub으로부터 호출되는 RMI 핸들러 서블릿 (jeus.rmi.http.servlethandler) 의 URI를입력한다. 이 URI에서는프로토콜, IP, 포 트를제외한서블릿요청경로만을입력한다. 프로토콜은 "HTTP" 로 IP는 RMI 런타임과동일한주소로간주된다. 즉, HTTP-RMI 요청을받은웹서버와웹엔진이 RMI 런타임과같은머신에있어야된다. 그러면 RMI 런타임의주소는 RMI Stub에게알려지게된다. 웹서버의포트는반드시다음 <http-port> 에설정해야한다. <http-port> HTTP-RMI 요청을받고처리할웹서버또는웹엔진을설정해야한다. 이웹서버 또는웹엔진은반드시 RMI 핸들러서블릿이 deploy 되어실행되고있어야한다. 참고 HTTP invoke가정상적으로작동하기위해선 RMI 핸들러서블릿이 deploy되어있어야한다. RMI 핸들러서블릿을구현한클래스는 jeus.rmi.http.servlethandler이다. jeus.rmi.http.servlethandler는 context 내에 <invoke-http> 에설정된 URL과동일하게 deploy되어야한다. deploy에대한자세한내용은 "JEUS Web Engine 안내서 " 를참조한다 JEUS RMI 설정 JEUS에서는성능을향상시킨 JEUS RMI 통신을제공한다. 이 RMI는 Non-blocking IO로도 RMI 통신을할수있기때문에클라이언트수가많은경우에유용하다. JEUS RMI를사용하기위해서는클라이언트용라이브러리인 JEUS_HOME\lib\client\jclient.jar를클래스패스에설정하는것외에특별히다른작업은필요하지않다. JEUS RMI의사용여부는 jeus-ejb-dd.xml에 Bean별로설정할수있으며, JEUS 전체에시스템프로퍼티 (-Djeus.ejb.rmi.jeus=true) 로적용할수도있다. 이때 DD의설정이우선한다. JEUS RMI를 Blocking IO와 Non-blocking IO로사용할지여부와채널과소켓의사용여부등통신레이어의상세한것은시스템프로퍼티로모두설정가능하다. 이에대한설명은 "JEUS Reference Book" 을참고한다 EJB 보안설정 본절에서는 JEUS에서 EJB를위한보안설정방법에대해설명한다. 여기에서사용된보안은인증과권한부여를의미한다. JEUS EJB의보안설정과관련된항목은다음과같다. EJB 모듈의역할할당 (Role Assignment) 제 4 장 EJB 의공통특성 53

72 EJB run-as identity 설정 참고 EJB 설정에서사용하는실제 JEUS 사용자목록은 accounts.xml 에정의되어있다. 이에대한설정은 "JEUS Security 안내서 " 를참고한다 보안설정 다음은상황별보안설정하는방법에대한설명이다. 역할할당 (Role Assignment) 설정 EJB 모듈의역할할당설정은표준 ejb-jar.xml 파일에개발자가정의한역할과실제 JEUS 보안도메인의 principal와 group name을매핑하는것이다. 이는 jeus-ejb-dd.xml 파일의 <module-info> 의 <role-permis sion> 태그에서설정한다. 다음은역할할당을설정한 XML의예이다. [ 예 4.8] 역할할당 (Role Assignment) 설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <module-info> <role-permission> <role>manager</role> <principal>peter</principal> </role-permission> </module-info> <beanlist> </beanlist> </jeus-ejb-dd> 다음은설정하위필수태그에대한설명이다. 태그 <role> <principal> 설명 EJB에설정된 (Annotation이나 ejb-jar.xml을통해 ) 논리적인 role name을지정한다. accounts.xml에서정의된실제 user name을지정한다. role name-user name 쌍이개발자가정의한 role과 JEUS principal 간의매핑을정의한다. 하나의역할이름에복수개의사용자이름을설정할수있다. 54 JEUS EJB 안내서

73 Run-as Identify 설정 Run-as identity 설정은 ejb-jar.xml의 <run-as> 에서개발자가정의한역할이름과 JEUS 보안도메인설정에서지정한실제 principal의매핑을제공한다 ( 예 : accounts.xml 파일에서 ). 이 principal은일반적으로간단한사용자이름을사용한다. 이는 jeus-ejb-dd.xml에서 Bean 설정수준과같은 <run-as-identity> 태그에서설정한다. 다음은 Run-as Identify를설정한 XML 예이다. [ 예 4.9] Run-as Identify 설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <run-as-identity> <principal-name>peter</principal-name> </run-as-identity> </jeus-bean> </beanlist> </jeus-ejb-dd> 태그 <principal-name> 설명 ejb-jar.xml 파일의 <run-as> 태그에서주어진 role 에매핑할 user name 으로 accounts.xml 에설정되어있어야한다 보안설정의예 다음은 role-permisstion의 role과 run-as의 role이실제 JEUS 사용자에서매핑되는예이다. Java 클래스와 XML 내용의일부분들은 3개의설정파일들 (ejb-jar.xml, jeus-ejb-dd.xml, accounts.xml) 에서가져온것이다. 이파일들에서서로동일해야하는부분들은굵은글자로강조하였다. [ 예 4.10] 보안설정 public class CustomerBean implementes Customer {... } 제 4 장 EJB 의공통특성 55

74 [ 예 4.11] 보안설정 public class EmployeeServiceBean implements EmployService{... } [ 예 4.12] 보안설정 : <<ejb-jar.xml>> <?xml version="1.0"?> <ejb-jar version="3.1" xmlns=" xmlns:xsi=" xsi:schemalocation=" <enterprise-beans> <session> <ejb-name>customerejb</ejb-name> <security-role-ref> <role-name>customer</role-name> </security-role-ref> <security-identity> <use-caller-identity /> </security-identity> </session> <session> <ejb-name>employeeservice</ejb-name> <security-identity> <run-as> <role-name>admin</role-name> </run-as> </security-identity> </session> </enterprise-beans> <assembly-descriptor> <security-role> <role-name>customer</role-name> </security-role> <method-permission> <role-name>customer</role-name> <method> <ejb-name>customerejb</ejb-name> <method-name>*</method-name> <method-params /> </method> 56 JEUS EJB 안내서

75 </method-permission> </assembly-descriptor> </ejb-jar> 위의예에서는 2개의 Session Bean을선언하였다. 첫번째 Session Bean("CustomerEJB") 은 "CUSTOMER" 역할에연결되는보안역할을가지고있다. 두번째 Session Bean("EmployeeService") 은 "ADMIN" 이라는 <run-as> 역할을선언하고있다. "CUSTOMER" 와 "ADMIN" 역할은 EJB deploy할때실제시스템 principal들과매핑되어야한다. 다음의 XML DD 파일은 "CUSTOMER" 와 "ADMIN" 역할이실제시스템 principal 이름들 ( 각각 "customer" 와 "peter") 에어떻게매핑되는지보여주는예이다. [ 예 4.13] 보안설정 : <<jeus-ejb-dd.xml>> <?xml version="1.0" encoding="utf-8"?> <jeus-ejb-dd xmlns=" <module-info> <role-permission> <principal>customer</principal> <role>customer</role> </role-permission> </module-info> <beanlist> <jeus-bean> <ejb-name>employeeservice</ejb-name> <run-as-identity> <principal-name>peter</principal-name> </run-as-identity> </jeus-bean> </beanlist> </jeus-ejb-dd> 다음은이사용자들이 accounts.xml에어떻게설정되는지를확인할수있는예이다. [ 예 4.14] 보안설정 : <<accounts.xml>> <?xml version="1.0" encoding="utf-8" standalone="yes"?> <accounts xmlns=" <users> <user> <name>customer</ name> 제 4 장 EJB 의공통특성 57

76 <password>{sha}blsupypdjb8qdcq+ozfbiezx5oy=</name> <group>test</group> </user> <user> <name>peter</ name> <password>{sha}mcbqlyhi3yiog1hgtg8dqvwkyhg=</name> <group>test</group> </user> </users> </accounts> 위의예에서 "customer" 와 "peter" 라는사용자들의정의를확인할수있다. 이사용자들은 jeus-ejb-dd.xml 파일을통하여 ejb-jar.xml 파일의 "CUSTOMER" 와 "ADMIN" 역할과연관되어있다 EJB 모니터링 JEUS 에서는 EJB 모듈에포함된개별 EJB 를제어하는방법은제공하지않는다. 그러나콘솔툴을사용한 Bean 별모니터링은가능하다. 콘솔툴에서는 application-info 명령을사용하여 Bean의이름, Export Name 및상태등개별 EJB의정보를조회할수있다. 다음의예제에서는 countermod라는 EJB가 deploy되어있다고가정한다. 다음과같이명령을실행하면 EJB 모듈내의각 Bean들의이름과 Export Name을확인할수있다. [DAS]domain1.adminServer>application-info -server server1 -id countermod -detail General information of EJB module [countermod] ============================================================== Module Name Unique Module Name countermod countermod ============================================================== Beans ================================================================================ Bean Name Type Local Export Name Remote Export Name Count StatelessSessionBean Count JEUS EJB 안내서

77 ================================================================================ 다음과같이명령을실행하면지정한 EJB 모듈에등록되어있는개별 Bean의상태를확인할수있다. [DAS]domain1.adminServer>application-info -server server1 -id countermod -bean Count Module name : countermod Bean name : Count ================================================================================ Name (Count) WaterMark(High:Low Bound(Upper:L Time(Max:Min:T :Cur) ower) otal) create times(0) remove times(0) timed-rb transactio n(0) request request(0) active-bean bean(0:0:0) rolledback transactio n(0) total-bean bean(0:0:0) 제 4 장 EJB 의공통특성 59

78 comitted transactio n(0) MethodReadyCou bean(0:0:0) nt active-thread thread(0:0:0) total-remote-t thread(100:100:100) hread ================================================================================ 참고 application-info 명령에대한자세한내용은 JEUS Reference Book 의 application-info 를 참고한다 EJB 튜닝 모든 EJB 종류에공통으로 EJB 운영성능을향상 ( 또는시스템리소스의낭비를방지하기위해 ) 하기위해적용할수있는몇가지설정은다음과같다. TTP의최댓값을적절히수정한다. 여러개의 EJB 엔진에 Bean들을클러스터링해서설정한다. 제6장 EJB 클러스터링 을참고한다. 적절한 JDBC Connection Pool을설정한다. 설정에대한자세한내용은 "JEUS Server 안내서 " 를참고한다. EJB 2.x인경우 EJB 모듈 deploy 시간을절약하기위해 deploy 명령에 -fast 옵션과 appcompiler를사용한다. 자세한내용은 제3장 EJB 모듈 을참고한다. 60 JEUS EJB 안내서

79 위의기본적인최적화옵션뿐만아니라 Bean 의종류에따라수십개의튜닝팁이존재한다. 그러므로, 각 EJB 종류에따른튜닝과최적화하는방법은해당하는각장을참고한다 Thread Ticket Pool 설정튜닝 EJB가최상의성능을내기위해서는 TTP이올바르게설정되어야한다. 다음과같은원칙이적용될수있다. max pool 크기를크게설정할수록더많은 TT들이생성될수있고, 따라서더많은클라이언트요청을수행할수있다. 그러나크게설정한 max pool 크기는많은클라이언트들이 EJB 엔진에접속한경우에많은메모리자원을소모하게된다. 특정한시간대에 Bean의서비스사용을요청하는클라이언트가급격히증가할경우에는 max pool 크기에서 min pool 크기를뺀값을증가시켜새로운 TT들이 "batch" 로생성될수있도록설정한다. TTP의설정은특정한 EJB에대하여접근가능한양을조절할수있는밸브의역할을한다. 참고 max pool 크기는 TTP 에서가장중요한파라미터이다. 그러므로성능개선을위해서는이값을가장 먼저조절하고튜닝해야한다. 이값은 <thread-max> 에설정한다. 제 4 장 EJB 의공통특성 61

80

81 제 5 장 EJB 상호운용성및 RMI/IIOP 본장에서는 EJB 의상호운용성및 RMI/IIOP 에대해서설명한다 개요 JEUS는다른 WAS나이기종시스템간에원격 EJB 호출을지원하기위해 RMI/IIOP 프로토콜을지원한다. RMI/IIOP는 OMG( 에서정한 CORBA(Common Object Request Broker Architecture) 에기반한것이며 EJB 상호운용성 (Interoperability) 을위해서 EJB 스펙에서정한표준방식이다. JEUS 간에또는다른 WAS로부터원격호출을지원해야한다면 RMI/IIOP 상호운용기능을사용할것을고려할수있다. RMI/IIOP 원격호출방식은다른 WAS나이기종시스템을지원하는방식중의하나이다. 다른 WAS 로부터 JEUS의 EJB를호출하고트랜잭션을연동하는 ( 또는반대로 ) 다른방법도존재하지만본장에서는 RMI/IIOP 방식에대해서만설명한다. 상호운용은 JEUS의 EJB를다른시스템에서호출하는것과다른 WAS의 EJB를 JEUS에서호출하는것의 2가지로나눌수있다. 즉, JEUS가 RMI/IIOP 서버, 클라이언트혹은둘다될수있다. 모든경우에마찬가지로이를지원할수있는 ORB(Object Request Broker) 런타임이필요하며트랜잭션과보안의상호운용또한지원해야한다. JEUS에는 CORBA Naming Service를지원하기위한 COS Naming Server 및 Stub 클래스없이도 Dynamic Stub을메모리에서자동으로생성해주는 ORB 런타임을내장하고있으며, 트랜잭션의상호운용을위해 OTS(Object Transaction Service) 스펙과보안상호운용을위해 CSIv2(Common Secure Interoper ability version 2) 스펙을구현하고있다. CORBA 및 RMI/IIOP에대해이해하려면다음의관련링크를참조한다. CORBA Specification Glossary of Java IDL Terms Java RMI over IIOP OTS Specification CSIv2 Specification 트랜잭션상호운용 (OTS) 트랜잭션의상호운용은 OTS(Object Transaction Service) 스펙을기반으로이루어진다. Object는트랜잭션에영향을받는 CORBA Object를의미한다. OTS를사용하게될경우 ORB에트랜잭션을처리할수있는 Interceptor( 일종의 Listener) 를추가하게된다. 특별히추가된 Interceptor가 IIOP 프로토콜헤더의트랜잭션관련부분을처리한다. 이를통해서클라 제 5 장 EJB 상호운용성및 RMI/IIOP 63

82 이언트또는서버역할을하는 JEUS 는다른원격시스템 ( 다른 WAS 또는 JEUS) 간의트랜잭션전파 (Transaction propagation) 를지원한다. 참고 현재지원하는 OTS 의스펙버전은 1.2 이다 보안상호운용 (CSIv2) CSIv2는상호운용에있어보안을보장해주기위한스펙이다. CSI를사용하면앞서의 OTS와마찬가지로보안처리가가능한 Interceptor가 ORB에추가되며, Interceptor가보안에관한헤더및그밖의처리를수행한다. 보안상호운용은 EJB Reference의 IOR(Interoperable Object Reference) 에 CSI를위한보안정보가첨부됨으로써시작된다. Naming Service에 IOR이등록되면이를사용하려는클라이언트의 ORB와 JEUS MS가 IIOP 프로토콜의보안레벨에서협상 (negotiation) 을처리한다. 또한 JEUS MS는다른 EJB Bean을호출할경우 CSI 서비스가필요하다면클라이언트로동작한다. 참고 보안상호운용에대한자세한내용은 CORBA 의 CSIv2 스펙을참고한다 상호운용설정 기본적으로상호운용은설정되지않았기때문에이를사용하려면반드시관련된서버설정을해야한다. JEUS의 EJB를 RMI/IIOP로노출시키기위해서는 MS의 Enable Interop 설정을활성화해야하고, deploy 되는 EJB에 IIOP export 관련설정이있어야한다. 반대로 JEUS를 RMI/IIOP 클라이언트로만사용하는경우에는해당 MS의 Enable Interop 설정만활성화하면된다. 상호운용과관련된사항은 WebAdmin을사용하여설정할수있다 COS Naming Service 설정 MS에서제공하는기본적인 JNDI Naming Service 외에 CORBA 객체를위한 COS Naming Service를추가할수있다. COS Naming Service에는 RMI/IIOP로노출되는 EJB의 Reference(Stub) 가저장되고이를 EJB 클라이언트에서찾아서 (lookup) 사용하게된다. COS Naming Service는필요한시점에자동으로시작되며, MS JVM에구동되어 'BASEPORT + 4( 예 : 9740)' 을서비스포트로사용한다. 참고 'BASEPORT' 는 WebAdmin 에서 [Servers] 메뉴의서버목록에서서버를선택한후 [Resource] > [Listener] 메뉴의 'base' 항목에설정된 Listener 의 'Listen Port' 이다. 64 JEUS EJB 안내서

83 상호운용성활성화설정 RMI/IIOP 클라이언트및서버에필요한상호운용기능을사용하려면상호운용성속성이활성화되어야한다. 이속성이활성화되어야 ORB가초기화된다. 상호운용성속성을활성화하려면 WebAdmin의 [Servers] 메뉴를선택한후조회된서버목록에서원하는서버를클릭한다. Server 화면의고급선택사항에서 'Enable Interop' 을설정한다. [ 그림 5.1] 상호운용성활성화설정 CSIv2 기능을사용하려면좀더자세한설정이필요한데이는 CSIv2 보안상호운용설정 을참고 한다 CSIv2 보안상호운용설정 CSIv2 기능을수행하기위해서 2 가지추가적인보안환경파일과 JEUS Security Manager 의정보를이용 한다. 설정할추가적인보안환경파일은 Keystore 파일과 Truststore 파일이다. 보안환경파일 keystore 파일 truststore 파일 설명 X.509를위한 key를저장하고 Oracle 사에의해서공급된 X.509 keystore를구현한파일이다. Secure Socket Layer(SSL) 가호출됐을때이파일이클라이언트에게보내진다. X.509 클라이언트측증명설정파일이며, 형식은 keystore와같다. 이파일들의경로와필요한정보는 WebAmdin 이나시스템프로퍼티를사용해서설정할수있다. CSIv2 관련사항은 Enable Interop 의 Interop Ssl Config 에설정한다. [ 그림 5.2] CSIv2 보안상호운용설정 - Interop Ssl Config CSIv2 관련설정은실행스크립트의시스템프로퍼티를통해서도가능하다. 그러나시스템프로퍼티보다 WebAdmin 설정이우선된다는것을유념한다. 제 5 장 EJB 상호운용성및 RMI/IIOP 65

84 다음은이를위한실행스크립트옵션이다. 다음에설정한값은 " D" 를이용해서설정된다. [ 표 5.1] keystore 와 truestore 파일에관련된 JVM D 파라미터 파라미터 jeus.ssl.keystore 설명 Keystore 파일까지절대경로이다. ( 기본값 : DOMAIN_HOME/config/keystore) jeus.ssl.keypass jeus.ssl.truststore Keystore 파일에주어진패스워드값이다. ( 기본값 : jeuskeypass) Truststore 파일까지절대경로이다. ( 기본값 : DOMAIN_HOME/config/truststore) jeus.ssl.trustpass Truststore 파일에주어진패스워드값이다. ( 기본값 : jeustrustpass) 신뢰하는노드사이에서는호출자의 authentication과 authorization이불필요할때도있다. jeus.ejb.csi.trusthosts 시스템프로퍼티에 IP 주소를설정하면신뢰하는노드의불필요한보안점검을피할수있다. JEUS Security Manager는불특정접근자에게 anonymous principal을나타내는 'guest' 를사용한다 EJB RMI/IIOP 설정 EJB를 RMI/IIOP로노출시키려면 jeus-ejb-dd.xml에 EJB별로 <export-iiop> 를설정해야한다. <exportiiop> 가설정되면 EJB Home Reference가 COS Naming Service에주어진 <export-name> 으로등록된다. 이렇게등록이되어야만외부에서 COS Naming Service를통해 EJB Reference를가져와서사용할수있다. 다음은 EJB RMI/IIOP을설정한 jeus-ejb-dd.xml의예이다. [ 예 5.1] EJB RMI/IIOP 설정 : <<jeus-ejb-dd.xml>>... <jeus-bean> <ejb-name>calcejb</ejb-bean> <export-name>ejb/calc</export-name> <export-iiop> <only-iiop>true</only-iiop> </export-iiop> </jeus-bean>... 다음은설정태그에대한설명이다. 태그 <only-iiop> 설명 EJB를 RMI와 RMI/IIOP로각각노출할지아니면 RMI/IIOP만노출할지를설정한다. 각각노출한다면 COS Naming Server에는 RMI/IIOP Stub이등록되고, JEUS Naming Server에는일반 RMI Stub이등록된다. 66 JEUS EJB 안내서

85 참고 현재는 EJB Home 과 EJB Object Reference 만 RMI/IIOP 로노출할수있다. EJB 3.0 비즈니스뷰는 RMI/IIOP 로노출할수없다 RMI/IIOP 클라이언트 RMI/IIOP 클라이언트는다른 JEUS 나다른벤더의 WAS 또는 Standalone 클라이언트가될수있다. 본절 에서는각각어떤방식으로 EJB 를사용할수있는지설명한다 JEUS Managed Server JEUS MS에서운용되는애플리케이션에서 JEUS나다른벤더의 WAS 위에있는 RMI/IIOP EJB를호출하기위한방법은다음과같다. 먼저, COS Naming Server에서 EJB Home Reference(Stub) 를찾아와야한다. 직접찾아오는경우에는 JNDI API의 corbaname URL을사용해서얻어올수있다. [ 예 5.2] corbaname lookup 사용 InitialContext ctx = new InitialContext(); Object obj = ctx.lookup("corbaname:iiop:1.2@ :9740#ejb/calc"); CalcHome home = (CalcHome)PortableRemoteObject.narrow(obj, CalcHome.class); Calc calcref = home.create(); URL은 "corbaname:iiop:1.2@<host>:<port>#<name>" 형식으로 <host> 와 <port> 는 COS Naming Server 의주소이다. 또는직접 COS Naming Server를 PROVIDER URL로지정하여 InitialContext를얻어서사용할수도있다. 다음의예와같이 PROVIDER URL을지정하는방식은여러가지가있기때문에이중에서한가지방식으로지정한다. [ 예 5.3] PROVIDER URL 사용 Hashtable env = new Hashtable(); env.put(context.provider_url, "iiop:// :9740"); // env.put(context.provider_url, "iiopname:// :9740"); // env.put(context.provider_url, "corbaname:iiop:1.2@ :9740"); // env.put(context.provider_url, "corbaloc:iiop:1.2@ :9740"); InitialContext ctx = new InitialContext(env); Object obj = ctx.lookup("ejb/calc"); CalcHome home = (CalcHome)PortableRemoteObject.narrow(obj, CalcHome.class); Calc calcref = home.create(); 제 5 장 EJB 상호운용성및 RMI/IIOP 67

86 Dependency Injection을사용하거나 "java:comp/env/" 형식의논리적인 JNDI 이름을사용하는클라이언트의경우에는 jeus-web-dd.xml과같은애플리케이션 JEUS DD 파일에서 <export-name> 을위의 corbaname URL로매핑한다. [ 예 5.4] Servelet EJB private CalcHome calchome; [ 예 5.5] RMI/IIOP EJB 매핑 : <<jeus-web-dd.xml>> <ejb-ref> <jndi-info> <ref-name>ejb/calc</ref-name> <export-name>corbaname:iiop:1.2@ :9740#ejb/calc</export-name> </jndi-info> </ejb-ref> 다른벤더 WAS 다른벤더의 WAS에서운용되는애플리케이션에서 JEUS의 RMI/IIOP EJB를호출하기위한방법은 JEUS Managed Server 의방식과거의동일하다. 이경우 JEUS처럼별도의 ORB 설정이필요한지확인하고, 필요하다면설정을해야한다. 자세한내용은해당제품의관련문서를참고한다 standalone 클라이언트 standalone 클라이언트는별도의 ORB 런타임및관련된설정이되어있지않기때문에, 먼저기본적으로필요한 jclient.jar 클라이언트라이브러리외에도 JEUS 시스템라이브러리에위치한 corba-omgapi.jar와 corba-orb.jar를클래스패스에추가하고 jeus.client.interop=true 시스템프로퍼티를추가해야한다. EJB Home Reference(Stub) 를얻어오는방식은 JEUS Managed Server 와비슷하다. 단지, JEUS 에서제공하는 JNDI 프로바이더를추가적으로지정한다. [ 예 5.6] standalone 클라이언트사용 Hashtable env = new Hashtable(); env.put(context.initial_context_factory, "jeus.jndi.jeuscontextfactory"); env.put(context.provider_url, "iiop:// :9740"); InitialContext ctx = new InitialContext(env); Object obj = ctx.lookup("ejb/calc"); CalcHome home = (CalcHome)PortableRemoteObject.narrow(obj, CalcHome.class); Calc calcref = home.create(); 68 JEUS EJB 안내서

87 5.4. 알려진문제점 (Known Issues) 알려진문제점들은다음과같다. 서버로접속할수없을때재접속을 1분동안무한시도하는현상 JEUS에내장된 ORB에서기본적으로서버로연결할수없을때재접속을 60초동안재시도하는데, 이때별도의 sleep time 없이진행된다. 따라서수많은로그메시지가찍히거나 CPU가과점되는문제가있다. 이를방지하기위해서는다음과같은옵션을클라이언트에서시스템프로퍼티로설정해야한다. ( 기본값 : 60000, 단위 : ms) com.sun.corba.ee.transport.orbcommunicationsretrytimeout=1 PortableRemoteObject.narrow() 호출후에 NullPointerException이발생하는현상클라이언트에서다음과같이호출을하는경우 home 객체가 null이리턴되면서 NullPointerException이발생하는경우가있다. [ 예 5.7] NullPointerException이발생하는경우 CalcHome home = (CalcHome)PortableRemoteObject.narrow(obj, CalcHome.class); // null is returned Calc calcref = home.create(); // NullPointerException 이문제는 CORBA Stub 클래스를찾지못한경우발생한다. JEUS MS에서 Enable Interop 설정이제대로되어있지않은경우이다. 해당설정이있으면올바른 ORB가초기화되어 Stub을동적으로메모리에자동생성한다. 외부클라이언트의경우에는동적 Stub를생성하는기능이없는경우에이런에러가발생할수있다. standalone 클라이언트의경우에는시스템프로퍼티에다음과같이설정되어있는지를확인한다. jeus.client.interop=true WebLogic에서 JEUS에 dot(.) 이포함된이름의 EJB를찾지못하는현상 "com.acme.calchome" 과같이 dot(.) 이포함된형식으로 <export-name> 을지정한경우 WebLogic에서는 lookup이실패한다. 이는 WebLogic에서 dot(.) 을 slash(/) 와동일하게취급하여내부적으로 "com/acme/calchome" 과같이요청을보내기때문이다. 이런경우에는 dot(.) 이포함된이름을사용하지않도록한다. 제 5 장 EJB 상호운용성및 RMI/IIOP 69

88

89 제 6 장 EJB 클러스터링 본장에서는 EJB 클러스터링개념과주요기능설정방법에대해설명한다 개요 EJB의 Failover와 Load Balancing 기능을사용하기위해서각 Bean들은여러 EJB 엔진에 deploy되어클러스터링을형성해야한다. 클러스터링은컴포넌트레벨 ( 개별 Bean) 에서수행되고 Stateless/Stateful Session Bean과 Entity Bean에서이용할수있다. Message Driven Bean(MDB) 은클러스터링대상에해당되지않는다. JEUS EJB 클러스터링은크게다음과같은 2가지기능을갖는다. Failover Bean의메소드실행전과실행중에하나의 EJB 인스턴스나 EJB 엔진이멈추면다른 EJB 엔진의 EJB 인스턴스에서요청이처리된다. Load Balancing EJB에대한요청을분산시켜 Bean의전체적인응답속도를향상시킨다. 다음그림은 2 가지 EJB 클러스터링의주요기능인 Failover 와 Load Balancing 을설명한다. [ 그림 6.1] EJB 클러스터링아키텍처 5. In case engine 3 fails, the active stub will attempt to look up the same bean in a different engine. 1. Client looks up EJB cluster named "A" EJB Client Busines s code Naming Server "Active Stub" Wrapper Failover logic Loadbalance logic 2. One of the EJB engines is selected (in this case engine 3) and a wrapper stub is returned. Business Interface EJB Engine 1 EJB A EJB Engine 2 EJB A EJB Engine 3 EJB A The three beans are clustered and, from the client's point of view, is known under a single JNDI export name: "A" 3. Client interacts with the standard EJB interfaces of EJB engine The wrapped EJB interfaces is communicating with bean in engine 3 (as usual). 제 6 장 EJB 클러스터링 71

90 클러스터링을원하는모듈을 deploy하면 Naming Server에모두같은이름으로바인드된다. 클라이언트는그하나의이름으로수행해도 Load Balancing과 Failover가가능하다. 따라서같은모듈이더라도 Naming Server에바인딩할이름을다르게하여 deploy하면해당모듈은클러스터링되지않음에주의한다. 참고 Stateful Session Bean의경우 Failover를위해 JEUS 분산 Session Manager를사용한다. Session Manager는 EJB 엔진당하나만존재하기때문에클러스터링할 Bean의클러스터링범위가각 Bean 별로달라서는안된다. 예를들어 Bean A는 EJB einge1과 EJB engine2로묶고 Bean B는 EJB engine1 과 engine3으로묶었다면 Session Manager는 Bean A와 Bean B가 EJB engine1, EJB engine2, EJB engine3에클러스터링되어있다고잘못확인하게된다 주요기능 다음은 EJB 클러스트링의주요기능에대한설명이다 Load Balancing 클라이언트가 lookup이나 injection에의해 Bean A를요청하면 Naming Server는 3개의 EJB 엔진에존재하는 3개의 Bean 중하나를임의로선택하여반환한다. 클라이언트는그후부터는선택된 EJB 엔진에서비즈니스인터페이스를통하여 Bean과일반적인방법으로연동한다. 이는 3개의 Bean들은동일하게같은메소드호출요청을받게되고잠재적으로한개의엔진이모든요청에대해서비스하는것보다무려 3배의시스템성능향상을기대할수있다는것을의미한다 (Load Balancing 의경우에발생하는작은자원소모를계산하지않을때 ) Failover(EJB 복구 ) Failover는하나의 EJB 서비스에장애가발생해도서비스를정상적으로제공하는것을의미한다 ( 예 : OS 장애, 네트워크중단또는 EJB 엔진장애 ). JEUS 시스템이처리할수있는장애복구에는다음의 2가지가있다. 클라이언트의요청이도착했을때접근불가한 Bean에게요청을보내지않고, 처리되지않은요청을다른 Bean에게다시보내는방법단순히문제가발생한 EJB 엔진을제외하고 Load Balancing 알고리즘을실행한다. 새로운클라이언트의요청을처리하기위해서는사용가능한엔진의 Bean을선택한다. JEUS에서는 Failover의 Rerouting이클라이언트측의 EJB Stub에서처리된다. 이 Stub을 Active Stub 이라부르고또는표준 EJB 인터페이스를둘러싼 wrapper라고도부른다. 이러한 wrapper를사용할때의다른점은현재연결되어있는 Bean 또는 EJB 엔진이문제가있는지판단할수있는로직을가지고있는지여부이다. 이러한문제점이발견되면, 기동중인 Stub이자동으로 JNDI 서버에접속해서작동하고있는 EJB 엔진을대신하여새로운 Stub을요청한다 ([ 그림 6.1] 의 5번 ). 72 JEUS EJB 안내서

91 실행중인 Bean이어떤이유로런타임오류를가지고있다면진행중인요청을다른 Bean에게다시보내는방법이러한상황에서의복구방법은한계가있다. Bean이요청을처리하고있을때문제가발견되면얼만큼요청을처리하고있었는지도모르고문제가발생했을때어떤런타임에러를발생시켰는지도모른다. 단순하게클러스터에존재하는다른 Bean의같은메소드를호출하는것은또다른부작용을조장할수있기때문에자칫하면위험한결과를가져올수도있다. 이문제를명백히하기위해 DB 필드를 1씩증가시키는메소드를가지는 Bean Instance A를고려해보자. 1이증가된후에바로문제가발생하는경우단순하게다른 Bean "B" 에있는같은 Business 메소드를다시호출하면 1이다시한번증가한다. 결과적으로 DB에일괄적이지못하고잘못된값을전송하게된다. 이런경우 Idempotent 메소드를이용하면안전하게복구될수있다. Idempotent 메소드를통한 EJB 복구방법에대한자세한내용은 Idempotent 메소드를통한 EJB 복구 를참고한다. 위의두시나리오의차이는오류상황이발견되는시점이다. 즉, Remote Business 메소드를호출하기전 인지또는 Bean 이요청을처리하고있는중인지의예가있을수있다 Idempotent 메소드를통한 EJB 복구 Idempotent 메소드는부작용이없는 "getter" 메소드이다. 이는메소드의수행중에어떠한상태 ( 예 : instance 변수, DB 필드등 ) 도변경되지않는것을보장한다. 따라서 Failover(EJB 복구 ) 에서의두번째복구방법이지닌한계는 Idempotent 메소드로극복할수있다. 그러나 Idempotent 메소드가아니라면역시대책이없다. 런타임에러가발생한메소드를다시실행시키는것보다는 Exception을던지는것이차라리낫다. 그러므로 Idempotent 메소드를많이사용할수록 EJB Failover는더잘작동된다. 메소드가 Idempotent 메소드인지아닌지판단하는공식은없다. 그러므로 Business 메소드의상태를정확히식별하고설정해야한다 Session Replication Stateful Session Bean의경우세션의백업을위해서 JEUS Session Manager를사용한다. 일반적으로 Business 메소드호출단위로세션의상태가변화하기때문에 JEUS에서는메소드호출이발생하고결과가리턴되는시점마다 JEUS Session Manager에세션백업을요청한다. 이러한백업작업을다른용어로세션복제 (Session Replication) 라고한다. JEUS Session Manager는세션을동기적 (Sync) 또는비동기적 (Async) 으로복제할수있다. JEUS에서는이를복제모드 (Replication Mode) 라고한다. 동기적 (Sync) 복제모드세션백업이완료될때까지 Bean이기다려야한다. 따라서 Failover를해야할때항상최신의세션이복제되어있다는장점이있다. 하지만 Session Manager에서네트워크장애등의원인으로타임아웃이발생해서진행이안될경우 Bean도그만큼기다려야하는문제가있다. 제 6 장 EJB 클러스터링 73

92 비동기적 (Async) 복제모드퍼포먼스문제는없어지지만세션복제가바로발생하지않고나중에이루어지기때문에그사이에 Failover를한다면최신의세션을얻을수없게된다. 2가지방법은서로장단점이있으므로 JEUS에서는 Bean과각 Business 메소드특성에따라사용자가설정할수있다. 또한세션복제를하지않아도되는메소드가있을수있으므로이역시설정할수있다. 자세한설정방법은 6.3. EJB 클러스터링설정 을참고한다. 참고 JEUS 에서는클러스터링에참여한 Stateful Session Bean 이라면기본적으로동기적 (Sync) 복제모 드로세션복제가이루어진다. 사용자는설정에의해이를조정할수있다 EJB 클러스터링설정 EJB 클러스터링은 Bean 클래스에 Annotation으로설정하거나 jeus-ejb-dd.xml에설정할수있다. 설정할사항은클러스터링으로구성될 Bean, 그 Bean의 idempotent 메소드그리고 Bean 또는각메소드의세션복제모드이다. 본절에서는예를통해 Annotation과 DD(xml) 파일에클러스터링을설정하는방법에대해설명한다 Annotation 을통한클러스터링설정 클러스터링에참여하는 Bean 클래스또는메소드에다음과같은 Annotation을이용하여설정한다. [ 예 6.1] Annotation을통한클러스터링설정 : <<CounterEJB.java>> package ejb.basic.statelesssession; import javax.ejb.stateful; import jeus.ejb.clustered; import jeus.ejb.replication; import public class CounterEJB implements Counter, CounterLocal { private int count = 0; public int increaseandget() { } return ++count; 74 JEUS EJB 안내서

93 @Replication(ReplicationMode.NONE) public void donothing(int a, String b) { public int getresult() { return public int getresultanother() { return count; }... } 다음은각클래스별설정에대한설명이다. 설명 Bean Bean 또는 Business 메소드가 idempotent인지선언한다. value를 false로하면 idempotent하지않은경우이다. 원격 Bean 객체를생성하는중예외상황이발생할경우 Stateless Session Bean에대해서는 idempotent로항상다시시도하고 stateful Session Bean 의경우에는 non-idempotent tent Session Bean을생성할때 Idempotent하게할지선언한다. value를 false로하면 idempotent하지않은경우이다. 만약이 Annotation 을기술하지않는다면 Stateless Session Bean에대해서는항상 idempotent Bean별또는각 Business 메소드별로세션복제모드를설정할수있다. 여기에는 jeus.ejb.replicationmode라는 enum 타입의클래스를사용해야한다. 이클래스에대한것은 JEUS API 문서 (javadoc) 를참고한다. 이 와같은식으로사용이가능하다. 사용자는 Bean별로설정할수있으며아무런설정을하지않을경우디폴트는 ReplicationMode.SYNC이다. 메소드는아무런설정을하지않았을경우기본적으로 Bean에설정된값을따른다. 인경우는기본적으로 ReplicationMode.NONE이다. 그리고비즈니스홈에정의되는 create() 는 Bean의설정을따른다. 제 6 장 EJB 클러스터링 75

94 xml 을통한클러스터링설정 JEUS EJB 모듈 DD 파일 (jeus-ejb-dd.xml) 에는클러스터링에참여하는각각의 Bean들을위해서 <cluster ing> 태그아래에다음과같은설정을적용할수있다. [ 예 6.2] xml을통한클러스터링설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <ejb-name>counter</ejb-name> <export-name>counter</export-name> <clustering> <enable-clustering>true</enable-clustering> <ejb-remote-idempotent-method> <method-name>getresult</method-name> </ejb-remote-idempotent-method> <ejb-remote-idempotent-method> <method-name>getresultanother</method-name> </ejb-remote-idempotent-method> <create-idempotent>true</create-idempotent> <replication> <bean-mode>sync</bean-mode> <methods> <method> <method-name>donothing</method-name> <method-params> <method-param>int</method-param> <method-param>java.lang.string</method-param> </method-params> <mode>none</mode> </method> <method> <method-name>getresultanother</method-name> <method-params> <method-param>void</method-param> </method-params> <mode>async</mode> </method> </methods> </replication> </clustering> </jeus-bean> 76 JEUS EJB 안내서

95 </beanlist> </jeus-ejb-dd> 다음은 <clustering> 의하위설정태그에대한설명이다. 태그 <enable-clustering> <ejb-remote-idempotent-method> <ejb-remote-idempotent-excludemethod> <ejb-home-idempotent-method> <ejb-home-idempotent-excludemethod> <create-idempotent> <replication> 설명 Bean의클러스터링을전체적으로활성화또는비활성화시킨다. Bean 메소드중에 idempotent 메소드들을선언한다 ( Annota tion을통한클러스터링설정 설명참조 ). Bean 메소드중에 idempotent 메소드들로선언한것중제외하고싶은메소드를선언한다. <ejb-remote-idempotent-method> 보다우선순위는높고, 사용법은동일하다. 2.x 스타일의홈인터페이스에정의된메소드중에 idempotent 메소드들을선언한다 ( Annotation을통한클러스터링설정 설명참조 ). 사용법은 <ejb-remoteidempotent-method> 와동일하다. 2.x 스타일의홈인터페이스에정의된메소드중에 idempotent 메소드들로선언한것중제외하고싶은메소드를선언한다. <ejb-homeidempotent-method> 보다우선된다. 사용법은 <ejb-remote-idempo tent-method> 와동일하다. Session Bean을생성할때 idempotent하게할지선언한다. Bean 레벨의세션복제모드또는메소드별복제모드를설정한다. 자세한내용은 Session Replication 과 [ 예 6.2] 를참고한다. 위에서지정한 Bean 클러스터링이작동하기위해서는다음의내용을주의해야한다. 클러스터링에참여하는모든 Bean 들은 <clustering> 하위의모든정보가동일해야한다. 클러스터링으로구성하기위해서는원하는 Bean 의 <export-name> 을모두동일하게설정한다 Stateful Session Bean 의클러스터링설정 클러스터링환경에서 Stateful Session Bean을실행하려면 Session Manager 설정을추가로해야한다. 다음은 WebAamin을사용해서 Session Manager를설정하는방법이다. 1. WebAdmin의 [Clusters] 메뉴를선택한후 [Session Router Config] 탭으로이동한다. 2. 동적설정변경을위해화면왼쪽의 [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. 다음과같이 Session Router Config 화면에서설정항목을설정한후 [ 확인 ] 버튼을클릭한다. 제 6 장 EJB 클러스터링 77

96 [ 그림 6.2] Session Router Config 설정 - 속성설정 항목 Passivation Timeout 설명 Bean 의정보를 passivate 하는것과관계된설정이다. EJB 엔진의 Resolution 에설정된 MS 마다 passivate 되거나 disconnect 할 Bean 이있는지를체크한다. 이때마지막으로 Bean 에접근한시간이설정한 MS 을초 과한 Bean 들은 passivation 대상이된다. 78 JEUS EJB 안내서

97 4. 서버에설정내용을반영하기위해화면왼쪽의 [Activate Changes] 버튼을클릭한다. 참고 Session Manager 설정에대한자세한내용은 JEUS 세션관리안내서 의 2.6. 세션서버설정 을 참고한다 EJB Failover 의제한 매번클라이언트에서 EJB Reference(Stub) 를 lookup하지않고, lookup한 EJB Reference를 Cache하여계속사용하는경우 (Injection을사용하는경우도포함 ), 살아있는다른 EJB End-point가있음에도불구하고 Failover가되지않는경우가있을수있다. 이는 lookup하는시점에존재했던 EJB End-point 리스트에해당하는 MS들이모두살아있지않고그이후에구동된새로운 MS만존재하는경우에발생할수있다. Failover를해야하는시점에서내부적으로 lookup하여새로운 EJB Reference를클라이언트에게전달한다. 그러나이때사용중이던 EJB Reference가 lookup될때 deploy되어있던 MS들이모두다운되면현재사용중이던 EJB Reference가 lookup될당시 deploy되지는않았지만그후에 deploy되어 Failover하는시점에서서비스가능한새로운 EJB End-point가존재해도 Failover가되지않는다. 여기서기존 MS들이모두다운되었다는것은비정상종료되거나, 다운되거나, EJB End-point가 undeploy 되어서기존의모든 EJB End-point의서비스가불가능한것을의미한다. 또한새로운 EJB End-point가 deploy되는경우는뒤늦게 (EJB Reference를 lookup하여이미사용중일때 ) 새로운 MS가클러스터에포함되거나, 뒤늦게다운했던 MS를재시작했거나 undeploy했던 EJB End-point를뒤늦게 redeploy를하는경우가포함된다. 2개의 MS로 Active/Backup 클러스터링을구성하는경우에이런현상이발생할수있다. 또는다음과같은시나리오에서이런경우가발생할수있다. 예를들어 A, B, C라는 MS가있는데클라이언트가처음 lookup을하여계속 Cache를하는경우이다. 1. A, B, C에모두 deploy되어있고처음 lookup한결과, A의 EJB를받는다. 2. A의 EJB를사용하다 A가비정상종료되어내부적으로 B의 EJB를 lookup하여계속서비스받는다. 3. B의 EJB가 undeploy되어서 C의 EJB를 lookup해서사용한다. 4. 이때다시 B의 EJB가 deploy되고, 곧이어 C가비정상종료되었다. 이경우 C의 EJB Reference가 lookup될때 B의 EJB End-point는 undeploy되어있었고 C의 EJB Reference 를 lookup한다음에 deploy되었으므로 C가다운되었을때 B는운용중이었지만 Failover는되지않는다. 그러나이때 B가 deploy나 undeploy된것이아니라비정상기동나비정상종료가되었다면정상적으로 Failover된다. 비정상종료의경우에는 Failover 시점에서재기동여부를검사하기때문에가능하다. 이렇게 Failover가제대로수행되지않는상황에는다시 lookup해서새로운 EJB Reference를가져온다. 그러면새로운 End-point 목록을가져오기때문에이런문제를피할수있다. 제 6 장 EJB 클러스터링 79

98

99 제 7 장 Session Bean 본장에서는 Stateless Session Bean 과 Stateful Session Bean 에대해서자세히설명한다. Stateless Session Bean 은사실상 제 4 장 EJB 의공통특성 에서설명한내용외에는특별한것이없다. 따 라서본장에서는주로 Stateful Session Bean 들에대해설명한다 Stateless Session Bean 본절에서는 Session Bean 의 TTP(Thread Ticket Pool) 에대해설명한다 Thread Ticket Pool(TTP) 과 Object Management Stateless Session Bean은클라이언트의요청에관련된상태정보를가지고있지않기때문에모든클라이언트가 connection을공유해서 Connection Pool은설정할필요가없다. 그러나상태정보를가지고있지않은이유로 Bean Instance를재활용할수있기때문에 Bean Pool을설정할수있다. 다음은 Stateless Session Bean 의 TTP 과 Bean Pool 의관계를나타낸그림이다. [ 그림 7.1] Stateless Session Bean 의 TTP 과 Bean Pool Transition format: <transition name> [ <guard cond. (boolean cond.)> ] / <Actions performed> EJB Client Thread instance from Association TP Client thread - SL instance Thread Ticket Pool (TTP) Pooled SL instance creation [create() called] / Draw Active SL instance disconnect [business method returns] / Return instance to TP 1. create 시점에클라이언트와연결을맺은 connection으로요청을하면 TTP에서 TT(Thread Ticket) 를발급받는다. TT를발급받지못하면 TT를발급받을때까지기다린다. 기다리는시간이 10분을초과하면 RemoteException이발생하여요청을수행하지못한다. ( 제4장 EJB의공통특성 참고 ) 2. TT를발급받은클라이언트의요청을수행하기위해실제 Bean instance를 Bean Pool로부터할당받아 connection과연결을맺는다. 3. Stateless Session Bean Instance가처리를끝냈을때 TT는 TTP로반환되고 Bean Instance는 Bean Pool로반환되어다음클라이언트요청을기다린다. 즉, 매요청마다 TT와 Bean Instance를새로할당받고요청이끝나면반환된다. 제 7 장 Session Bean 81

100 Bean Pool 개수의의미가 TTP 개수의의미와다른점은동시수행될수있는로컬클라이언트와리모트클라인언트의요청의개수와관련된다는점이다. 즉, Remote call은 TTP에서 TT를할당받은후 Bean Pool 에서 Instance를할당받을수있고, Local call은클라이언트스레드에서바로수행되므로 TT를발급받을필요가없고 Bean Pool로부터 Instance만할당받는다. 따라서 jeus-ejb-dd.xml의 <thread-max> 의값을적게설정하면설정값이상의 Remote call은받을수없고 Bean Pool의최댓값은무한대이기때문에 Locall call은처리할수있다 Web Service Endpoint EJB 2.1 이후부터 Stateless Session Bean 은웹서비스형태로 Export 될수있다. 참고 이에대한자세한정보는 "JEUS Web Service 안내서 " 를참고한다 Stateful Session Bean 본절에서는다음의 Stateful Session Bean의추가적인설정들의개념에대해설명한다. Object Management 설정 : Bean Instance Pool과 Connection Pool Bean Instance Pooling 옵션 Session Manager를통한상태유지메커니즘 Thread Ticket Pool(TTP) 과 Object Management Stateful Session Bean은클라이언트의요청에관련된상태정보를지속적으로유지하고있어야하기때문에 Stateless Session Bean과는달리 Connection Pool을설정하고활용해야한다. 이는 Entity Bean에도동일하게적용된다. 자세한내용은 제8장 Entity Bean 을참고한다. 82 JEUS EJB 안내서

101 다음은 Stateful Session Bean 의 Connection Pool 과 TTP, Bean Pool 의관계를나타낸그림이다. [ 그림 7.2] Stateful Session Bean 의 Connection Pool 과 TTP, Bean Pool Transition format: <transition name> [ <guard cond. (boolean cond.)> ] / <Actions performed> Thread Ticket Pool (TTP) Pooled Thread Ticket creation [create() called] / Draw ticket from TTP disconnect [disconnect TO tiggered] / Return ticket to TTP EJB Client Thread Association Client thread - thread ticket Active Thread Ticket Connection Pool (CP) Pooled Connection Instance creation [create() called] / draw con. from CP, create SF association. Active Connection Instance Association Thread ticket - Connection Instance (EJB Object) disconnect 1 [disconnect TO triggered, CP not full] / Return instance to CP creation [create() called] / Draw instance from BP activation [passivated SF requested] / Draw instance from BP and read state from sec. storage Association EJB Object - SF instance Bean Pool (BP) Pooled SF instance Active SF instance removal 1 [remove() called, SF is pooling, BP not full] / Return SF to BP passivation 1 [passivation TO tiggered, SF is pooling and bean pool not full] / Write SF state to sec. storage, return instance to BP Garbage Collected Connection disconnect 2 [disconnect TO triggered, CP full] / GC con. instance removal 2 [remove() called, SF is not pooling or BP full] / GC the instance Garbage Collected SF passivation 2 [passivation TO triggered, SF is not pooling or bean pool full] / Write SF state to sec. storage, GC instance 제 7 장 Session Bean 83

102 클라이언트가 Stateful Session Bean을생성하면새로운 Bean Instance(SF Instance) 가만들어지고 Con nection Pool에서 connection을꺼내 2개가연결된다. Bean Instance와연결된 connection을클라이언트에게넘겨주면이 connection은현클라이언트에게할당되고다른클라이언트와공유하지않는다. 따라서클라이언트가제거하지않는한다시 Connection Pool로반환되지않는다. Connection Pool로반환될때에는연결되었던 Bean Instance와의연결을끊는다. 해당 connection으로요청을하면 TTP에서 TT를받는다. TT를받은요청만처리한다. Stateless Session Bean과달리매요청마다새로운 Bean Instance가 Bean Pool로부터할당되는것이아니라해당클라이언트를위한 Bean Instance가고정되어있다. 앞에서설명했듯이이 Bean Instance는클라이언트가 Bean을제거했을때 connection이 Connection Pool 로반환되면서 connection과의연결을잃으면서삭제된다. 기본적으로 Stateful Session Bean은상태가있기때문에 Bean Instance를재활용하는 Bean Pool을사용하지않는다 Pooling Session Bean EJB 표준에따르면, 실제 Stateful Session Bean의 Instance는다른클라이언트 Session에서재사용할수없다. 그러나 Bean이제거될때초기화가제대로이루어진다면 Bean Instance를재사용할수도있다. JEUS는 Bean Instance를매번생성하지않는점에서성능개선과자원낭비를줄이기위해이를재사용하는방법을제공한다. Bean Pool을사용하면 Bean이제거될때해당 Bean Instance가 Bean Pool로반환된다. Bean의제거는클라이언트가명시적으로 remove를부르거나오랫동안요청이없어타임아웃이된경우에발생한다. 이때 PRE DESTROY callback이불리게되는데여기서 Bean의초기화를잘구현한경우에만사용하도록권장한다 Bean Pool 설정 Stateful Session Bean을 Pooling Bean으로전환하려면간단히 jeus-ejb-dd.xml의 <pooling-bean> 값을 true로설정한다. [ 예 7.1] Bean Pool 설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <ejb-name>teller</ejb-name> <export-name>tellerejb</export-name> <local-export-name>localtellerejb</local-export-name> <export-port>7654</export-port> <export-iiop>true</export-iiop> <object-management> <pooling-bean>true</pooling-bean> <bean-pool> 84 JEUS EJB 안내서

103 <pool-min>10</pool-min> <pool-max>200</pool-max> <resizing-period> </resizing-period> </bean-pool> </object-management> </jeus-bean> </beanlist> </jeus-ejb-dd> 세션데이터유지메커니즘설정 이름에서암시하듯이 Stateful Session Bean은상태를지니고다닌다. 이상태는클라이언트세션동안반드시유지되어야한다. 즉, 같은클라이언트로부터오는모든다른요청에도상태는지속되어야한다. 이것이 Stateful Session Bean의기본특성이다. 일반적으로런타임할때의상태는 Instance 변수로저장된다. 그러나위에서설명한것과마찬가지로 Stateful Session Bean이 passivate 상태로진입하면시스템자원을보존하기위해운영환경에서이 Instance 변수들을제거해야한다. 그러나 Bean이다시재활성화되면상태를복구하기위해서어딘가에서데이터를가져와야한다. 즉, 2차저장소가필요하다. JEUS에포함된분산식 Session Manager를 2차저장소로사용한다. 기본적으로는 passivate될때클러스터링으로구성된 Stateful Session Bean의경우는 Failover를위해트랜잭션의 commit이성공적으로수행될때로 Bean의정보가 Session Manager로전달된다. Session Manager는 DAS에서설정된다. 설정에대한자세한내용은 Stateful Session Bean의클러스터링설정 을참고한다 공통설정 본절에서는 Stateless Session Bean 과 Stateful Session Bean 의공통설정항목에대해서설명한다. 이 모든항목들은 JEUS EJB 모듈 DD 의 <jeus-bean> 태그아래에설정된다 Object Management 관련설정 Stateless Session Bean은상태가없어서하나의 connection만사용해도무방하기때문에 Bean Pool만사용할수있고, Stateful Session Bean은상태가있기때문에 Connection Pool과 Bean Pool을모두사용할수있다. 따라서다음과같이제공되는설정을통해 Pool을이용하면매번 Instance를생성하는부하를줄일수있다. 제 7 장 Session Bean 85

104 다음은 Object Management 관련설정한 XML 예제이다. [ 예 7.2] Object Management 설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <object-management> <bean-pool> <pool-min>10</pool-min> <pool-max>200</pool-max> </bean-pool> <connect-pool> <pool-min>10</pool-min> <pool-max>200</pool-max> </connect-pool> <passivation-timeout>10000</passivation-timeout> <disconnect-timeout> </disconnect-timeout> </object-management> <jeus-bean> <beanlist> <jeus-ejb-dd> 다음은 <object-management> 의하위설정태그에대한설명이다. <bean-pool> EJB Bean Instance Pool의작동방식을결정한다. 하위태그들은다음과같다. 태그 <pool-min> <pool-max> 설명 Pool 을초기화할때생성해두는초기 Bean Instance 개수이다. ( 기본값 : 0) Instance 의사용이완료된후 Pool 에저장가능한최대 Bean Instance 개수이다. ( 기본값 : 100) <connect-pool> 클라이언트와 Bean Instance를연결하는 connection을몇개까지유지할지를설정한다 ( 해당옵션은 JEUS v6.0 Fix#8부터 Session Bean에서는사용하지않는다 ). 하위태그들은다음과같다. 86 JEUS EJB 안내서

105 태그 <pool-min> <pool-max> 설명 Pool 을초기화할때생성해두는초기 connection 개수이다. ( 기본값 : 0) connection 사용이완료된후 Pool 에저장가능한최대 connection 개수이다. ( 기본값 : 100) <passivation-timeout> 지정된시간동안클라이언트의요청을받지않은 Stateful Session Bean을 passivate할때사용된다. 그러므로여기에설정된시간을초과하는동안클라이언트의요청이없으면그 Bean은 passivation 의대상이된다. 어떤 Bean이 passivation 대상이되는지를검사하는주기는 EJB 엔진에설정한 resolution을따른다. Passivation이실행되면메모리에서해당하는 Bean Instance가제거되고 Instance의상태는파일에저장된다. 내부적으로분산세션서버를사용한다. 이설정은여러곳에서설정이가능하고우선순위는다음과같다. 1. 특정 Session Bean에만적용 : jeus-ejb-dd.xml의 <passivation-timeout> 2. 모든 Stateful Session Bean에적용 : 시스템프로퍼티 jeus.ejb.stateful.passivate 3. 모든 EJB Bean에 (Entity Bean과 Session Bean 모두 ) 적용 : 시스템프로퍼티 jeus.ejb.all.passivate 4. 모든 EJB Bean에 (Entity Bean과 Session Bean 모두 ) 적용 : DAS의 <node>/<session-router-con fig>/<session-router>/<file-db>/<passivation-to> 위의모든설정이없으면기본값으로설정된다. ( 기본값 : (5분 ), 단위 : ms) <disconnect-timeout> 지정된시간동안클라이언트의요청을받지못하면클라이언트와 Stateful Session Bean Instance 사이를연결하던 connection을끊을때사용된다. 그렇게되면 connection은각각의클라이언트및 Instance와맺고있던연결을끊고 Connection Pool로반환된다. 따라서클라이언트는이 connection으로더이상요청을할수없고, 사용중이던 Bean Instance는삭제되거나 Bean Pool을사용중이면 Bean Pool로반환된다. 이설정은여러곳에서설정가능하고우선순위는다음과같다. 1. 특정 Session Bean에만적용 : jeus-ejb-dd.xml의 <disconnect-timeout> 2. 모든 Stateful Session Bean에적용 : 시스템프로퍼티 jeus.ejb.stateful.disconnect 3. 모든 EJB Bean에 (Entity Bean과 Session Bean 모두 ) 적용 : 시스템프로퍼티 jeus.ejb.all.disconnect 위의모든설정이없으면시스템프로퍼티 jeus.ejb.all.disconnect의기본값으로설정된다. ( 기본값 : (1시간 ), 단위 : ms) 제 7 장 Session Bean 87

106 참고 <passivation-timeout> 과 <disconnect-timeout> 에사용되는시간은 Bean Instance에액세스했던마지막시점부터측정된다. 그러므로 <disconnect-timeout> 을 <passivation-timeout> 보다길게설정해야한다. 또한 <passivation-timeout> 은 EJB 엔진에설정되는 resolution보다는커야한다. 타임아웃값을길게설정하면오랜시간 ( 대략십여분이상또는타임아웃이중지된경우 ) 동안메모리내의많은 Instance가활성화된상태로머물러있다. 그러므로시스템자원낭비를초래한다. 너무짧은타임아웃값은 ( 수초 ) passivation, activation등의작업이너무자주발생하므로성능을저하시킬수있고 disconnect 작업으로인해세션유실가능성이있다. 88 JEUS EJB 안내서

107 제 8 장 Entity Bean Entity Bean 은 EJB 3.0 부터는 JPA 로대체되었다. 따라서 Bean 을새롭게개발하는경우는 JPA 사용을권 장한다. 그러나기존사용자를위해 JEUS EJB 엔진은 Entity Bean 를지원한다. 본장에서는 JEUS EJB 엔진에서 Entity Bean 을설정하고튜닝하는데필요한모든정보에대해설명한다 개요 EJB 스펙에따라 JEUS EJB 엔진은다음과같은 3가지 Entity Bean을지원한다. Bean Managed Persistence Entity Bean (BMP) EJB 1.1 스펙에따른 Container Managed Persistence Entity Bean (CMP 1.1) EJB 2.0 스펙에따른 Container Managed Persistence Entity Bean (CMP 2.0) 종류에상관없이 JEUS의 Entity Bean들은모두 제4장 EJB의공통특성 에서설명한기능과설정컴포넌트들을공유하므로 JEUS EJB 엔진에서 Entity Bean을설정하고사용하기전에관련장의내용에대한이해를필요로한다. 3개의 Bean 종류에따라 3개의설정이존재한다. 3가지종류에모두적용되는공통된설정 CMP 1.1과 CMP 2.0에만적용되고 BMP에는적용되지않는설정 CMP 2.0에만적용되는설정 다음은각 Entity Bean 종류별설정특성을나타낸표이다. [ 표 8.1] Entity Bean 종류의설정 설정가능한 Entity 옵션 BMP CMP 1.1 CMP EJB name 2. Export name 3. Local export name 4. Export port 5. Export IIOP switch 6. Single VM switch 7. Local invocation opt. 제 8 장 Entity Bean 89

108 설정가능한 Entity 옵션 BMP CMP 1.1 CMP Fast deploy 9. use-access-control 10. Run-as identity 11. Security CSI Interop. 12. Env. refs 13. EJB refs 14. Resource Refs 15. Resource env. Refs 16. Thread ticket pool settings 17. Clustering settings 18. HTTP invoke 19. JEUS RMI 20. Object management 21. Persistence Optimize 22. CM persistence opt. 23. Schema info 24. Relationship map 위의표에서와같이항목 1부터 19까지는모든 EJB에공통으로적용된다. 이항목들은 제4장 EJB의공통특성 에서모두설명하였다. 20번항목은 Session Bean과 Entity Bean에모두해당되지만사용법은차이가있어서그차이점을중점적으로설명한다. 항목 21부터 24까지는 Entity Bean에만해당하는항목들로본장에서자세히설명한다. 이외에도다음과같은 JEUS Entity EJB에연관된주제에대해서도설명한다. Default Primary Key 클래스 EJB QL 언어에추가된 JEUS 특정항목 JEUS Instant EJB QL API 참고 JEUS에서는성능튜닝이 EJB Entity Bean 설정의가장중요한부분이다. 그러므로본장에서는엔진모드와서브모드와같이성능관련부분에대해서자세히설명한다. 본장후반부의 8.4. Entity EJB 튜닝 은본절에서설명한내용을좀더간략하게다시정리한것이다. 90 JEUS EJB 안내서

109 8.2. 주요기능 Entity Bean 의공통기능과각 Bean 의주요기능에대해서설명한다 공통기능 3 가지 Entity Bean 들은종류에상관없이 JEUS 의 Entity Bean 의공통기능을갖는다 Entity Bean Object 관리및 Entity Cache 다음은 EJB 엔진에서 Entity Bean 객체가어떻게관리되는지보여준다. [ 그림 8.1] JEUS EJB 엔진에서 Entity Bean의 object와 Instance 관리 "object management" 는 EJB 엔진의내부적인 Bean Instance Pool과 Connection Pool을의미한다. 이 Pool들은각 Bean마다설정되고성능향상과시스템자원의효율적인관리를위해사용된다. 기본적으로 Stateful Session Bean과비슷하게동작하므로본절에서는차이점만언급하고자세한내용은 제7 장 Session Bean 을참고한다. Entity Bean은 Connection Pool외에 Entity-Cache를사용한다. Entity EJB가 passivate되려할때 (passivation timeout이지났을때 ) 그 Bean Instance는실제로는바로 passivate되지않는다 (Stateful Session Bean의경우에는 passivate된다 ). 대신에이는 Entity Cache로전달된다. 이 Cache에서는모든 passivate된 Entity Bean들이활성화상태로저장되어있다 ( 즉, 식별이가능하고, 유효한상태를유지한다 ). 다른 Pool들과마 제 8 장 Entity Bean 91

110 찬가지로이 Entity Cache 도런타임메모리에유지되고, 따라서활성화상태와 passivate 사이의존재하지 않는상태에서 Runtime Cache 로작동된다. Entity Bean이실제적으로 passivate되는때는다음과같다. Entity Cache가사이즈를줄여야할때 passivate가된다. 새로운 Entity Bean이 Cache로들어오려할때그 Cache에이미 passivate된 Bean들이많이있을경우 Cache 내의 Bean들이강제로밀려나간다. 이렇게강제로밀려나간 Entity Bean은 passivate되고그상태는 DB에쓰여지며그 Instance는 Bean Pool로반환되거나 Bean Pool이가득차있는상태라면버려진다. Cache에막들어오려는 Entity Bean은 Cache 에진입하여결과적으로강제로밀려난 Bean Instance의자리를차지하게된다. Cache 크기는 <persistence-optimize>/<entity-cache-size> 로조절가능하다. 반드시설정한크기만큼찼을때 Cache 크기를줄이는것은아나라힌트로사용된다. 또한강제로밀려나가는 Bean Instance를선택하는방법또한 Cache에오래머문순이아니다. 이러한 Cache를사용하면시간이많이소모되는 passivation을효과적으로관리할수있다는장점이있다. Cache를사용함으로써 passivate된 Entity Bean을다시활성화시킬때 DB에접근할필요가없어지고 Cache에있는 Instance( 만약에존재하면 ) 를사용함으로써해결할수있다. Object Pool의표준 passivation timeout 값이시간적인제약을관장하는 passivation 값이라면 Entity Cache 는메모리의제약을관장하는 passivation 설정값이라고할수있다. 이것이 Entity Cache를사용하는주요동기이다. 주의 Entity Cache 설정은실제로 "object management" 의설정이아니라일반적인 Entity Bean persistence 최적화설정이다. 이에대한자세한내용은 8.3. Entity EJB 설정 에서설명한다 엔진모드 Selection 을통한 ejbload() Persistence 최적화 Entity Bean에대해어느시기에 ejbload() 메소드를호출할것인지결정하는것은 EJB 엔진 ( 컨테이너 ) 이다. 이메소드는 DB의상태정보와 Bean Instance의런타임상태정보를동기화하기위해 BMP와 CMP에서사용한다. 본질적으로 ejbload() 메소드는 DB에서하나의레코드를읽고그결과를 Bean의내부특성값들에설정하기위해사용된다. ejbload() 메소드는 Entity Bean의생명주기동안적어도한번은호출된다. 어떤경우에는 Bean Instance 의호출할때마다바로전에 ejbload() 메소드를호출할필요가생기기도한다. DB에서 Bean의상태정보를읽어야하는시나리오는기본적으로크게 2가지가있다. Entity Bean이여러개의 EJB 엔진에걸쳐클러스터되어있을때그중하나의 Bean이 DB의한레코드를변경시킬수있다. 즉, 클러스터링된 Entity Bean들이서로통신할수없기때문에특정 Entity Bean Instance의상태정보가가장최신의것이라는것을보장할수없다. 어떤외부요소 ( 작업자또는시스템 ) 가 EJB와연동되어있는 DB를변경할경우가있다. 이시나리오에서 EJB 엔진의특정 EJB Instance는 DB의내용을제대로반영하지못한상태가된다. 92 JEUS EJB 안내서

111 다음그림은 Entity Bean 이클러스터링되어있을때나외부에서 Bean 의 DB 행을수정했을때 ejbload() 가주기적으로호출되는 2 개의시나리오이다. [ 그림 8.2] ejbload() 주기적호출시나리오 Bean Cluster EJB Engine 1 Clustered Bean A User 2. User modifes row A. EJB Engine 2 Clustered Bean A EJB Engine 3 Clustered Bean A 1. Bean modifes row A. 3. ejbload() MUST be called before each usage. 4. ejbload() MUST be called before each usage. EJB Database EJB row A 위의두시나리오의상황을피할수만있다면 ( 클러스터링을사용하지않고, 어떤외부요소도 EJB의 DB 데이터를변경하지않는다고보장한다면 ) Entity Bean의 ejbload() 동작을최적화할수있다. "EXCLUSIVE_ACCESS" 엔진모드를 Bean에적용하면최적화가가능하다. 이모드를사용하면, ejbload() 는 Bean이 Instance화될때단한번만호출된다. 이렇게함으로써 DB의접근량을약 50% 정도줄일수있다. 다음그림은 EXCLUSIVE_ACCESS 모드가사용될때의시나리오를보여주고있다. EXCLUSIVE_ACCESS 는단지하나의 Bean 이 DB 행을사용하고대부분의 ejbload() 는최적화된다. [ 그림 8.3] EXCLUSIVE_ACCESS 모드의시나리오 EJB Engine 1 Nonclustered bean A 1. ejbload() called only ONCE 2. ejbstore() called as required EJB Database EJB row A No other components accesses the database row. 제 8 장 Entity Bean 93

112 Bean을클러스터링해야하거나외부요소가 EJB 데이터를변경시켜야한다면 "SINGLE_OBJECT" 또는 "MULTIPLE_OBJECT" 엔진모드를사용해야한다. 두모드중하나가사용되면, EJB 엔진은 EJB 클라이언트의요청이도착할때마다 ejbload() 메소드를호출한다. 이렇게하면각 Entity Bean의성능이저하되지만모든상태정보가 DB에의해관리되기때문에다른엔진과 Bean들에게부하를분산시킬수있다. 다음은 SINGLE_OBJECT와 MULTIPLE_OBJECT 모드의차이점에대한설명이다. SINGLE_OBJECT 엔진모드 SINGLE_OBJECT 에서는각 EJB 엔진의단한개의 Bean Instance만이모든클라이언트의요청을처리한다. 즉, 첫요청이처리되고있는동안도착한요청들은대기하고있어야한다. [ 그림 8.4] SINGLE_OBJECT 엔진모드 Client request 1 Client request 2 Client request 3 EJB Engine 1 EJB A instance 1 EJB Database EJB row A EJB Engine 2 EJB A instance 1 Client request 4 Client request 5 Client request 6 Requests waiting until req 1 done. Requests waiting until req 4 done. MULTIPLE_OBJECT 엔진모드 MULTIPLE_OBJECT 모드에서는이러한제약이적용되지않고 EJB 엔진이새로운 Entity Bean Instance 를생성하여새로운 EJB 클라이언트요청을처리한다. 즉, MULTIPLE_OBJECT 엔진모드에서는새로운 EJB Instance가할당된다. [ 그림 8.5] MULTIPLE_OBJECT 엔진모드 Client request Client request EJB Engine 1 EJB A instance 1 EJB A instance 2 EJB Database EJB row A EJB Engine 2 EJB A instance 1 EJB A instance 2 Client request Client request Client request EJB A instance 3 Each new request spawns a new EJB instance EJB A instance 3 Client request 94 JEUS EJB 안내서

113 다음은각엔진모드를선택할때의장점과단점을비교한표이다. [ 표 8.2] 3 가지엔진모드의단점과장점 구분 EXCLUSIVE SINGLE MULITPLE 클러스터링을허용하는가? No Yes Yes 외부 Entity 가 DB 에접근가능한가? No Yes Yes DB connection 이효율적으로사용되는가?(ejbLoad() 호출 Yes 빈도 ) No No 장시간의트랜잭션의경우적당한옵션을지원하는가? No No Yes 하나의엔진에적합한단일처리의효과적인모드는? Not applicable Yes No 하나의엔진에서 EJB 를동시에처리하기위해요구되는 Not applicable 효과적인다중처리모드는? No Yes 3 가지엔진모드중적합한모드를선택하기위한기준은다음과같다. 많은양의요청이 Entity Bean에요청되고, 많은수의 EJB 엔진들이설정되어있다면 SINGLE_OBJECT 모드를선택하고엔진들에 Bean을클러스터링으로구성한다. 많은양의요청이 Entity Bean에요청되지만, 한정된 EJB 엔진이설정되어있으면 MULTIPLE_OBJECT 모드를선택하고엔진들에 Bean을클러스터링으로구성한다. MULTIPLE_OBJECT와 SINGLE_OBJECT를선택할때고려해야할중요한사항중의하나는한트랜잭션을수행하기위해필요한총시간이다. 수행시간이많이소요되는트랜잭션이라면당연히 MULTI PLE_OBJECT를선택할것을권장한다. 많지않은동시요청이 Entity Bean에들어온다면 EXCLUSIVE_ACCESS 모드를선택하고하나의 EJB 엔진에 Bean을 deploy한다. EJB 클러스터링에대한자세한정보는 제6장 EJB 클러스터링 의설명을참고한다 BMP & CMP 1.1 본절에서는 ejbstore() 호출을최적화하는방법에대해설명한다. 참고 본절에서설명하는 ejbstore() 호출의최적화방법은 BMP 와 CMP 1.1 Bean 들에만적용되고, CMP 2.0 은다른방법으로접근해야한다. 제 8 장 Entity Bean 95

114 Non-modifying 메소드에의한 ejbstore() Persistence 최적화 ejbstore() 는 EJB 엔진에의해 DB의 Bean 상태정보가유지되어야한다고판단될때마다호출된다. 일반적으로해당 DB로의접근은각트랜잭션의 commit 또는 Bean Instance가 passivate되기전에시도된다. 그러나만약에트랜잭션의중간에 Bean의상태가바뀌지않으면 ejbstore() 가호출될이유가없다. JEUS EJB 엔진은 Bean의상태변경을자동적으로예측할수없다. 그러므로개발자나 deployer는 ejbstore() 를호출하는시점을 EJB 엔진이판단할수있도록힌트를제공해야한다. 이힌트는 Non-modifying 메소드들의목록으로제공된다. Non-modifying 메소드는근본적으로읽기만허용하는메소드 ( getter ) 로서 Entity Bean의 DB 내부상태를변경하지않는다. Non-modifying 메소드의목록을보고 EJB 엔진은 ejbstore() 메소드를호출할지여부를결정한다. 트랜잭션중또는 Bean이활성화된상태일때 Non-modifying 메소드만실행되면 EJB 엔진은 ejbstore() 호출이불필요하다고판단하고그과정을생략한다. 이는전체적인성능이향상됨을의미한다 CMP 1.1/2.0 본절에서는 CMP 1.1/2.0 의주요기능에대해서설명한다 ejbload(), ejbfind(), CM Persistence 최적화 엔진모드 Selection을통한 ejbload() Persistence 최적화 와 Non-modifying 메소드에의한 ejbstore() Persistence 최적화 에서 ejbload() 와 ejbstore() 메소드의호출시점에대해서설명하였다. BMP와 CMP는 ejbload() 와 ejbstore() 메소드를사용하기때문에 BMP와 CMP Entity Bean에만적용되었다. 본절에서는성능향상을위해 ejbload() 와 ejbfind() 메소드를최적화하는방법에대해서설명한다. ejbload(), ejbfind() 의구현방법은 EJB 엔진에영향을받기때문에 CMP Bean(1.1과 2.0 버전 ) 에국한해서설명한다. BMP에서해당메소드의구현과작동방식은개발자에의해결정된다. EJB 엔진이 CMP ejbload(), ejbfind() 를호출하면다음과같은엔진의하위모드를선택하여작동방식을 최적화할수있다. 3 가지모드에대한자세한기술적설명은하지않는다. 모드 ReadLocking WriteLocking WriteLockingFind 설명 ejbload() 를호출할때 EJB 엔진이 DB의 Shared Lock을가질수있게한다. 이종류의 Lock은다른 Bean들이같은레코드를읽을수있지만쓰는것은금지한다. ejbload() 를호출할때 EJB 엔진이 DB의 Exclusive Lock을가질수있게한다. 다른 Bean들이 DB에읽고쓰는것을모두금지한다. ejbload() 와 ejbfind() 를호출할때 EJB 엔진이 DB의 Exclusive Lock을가질수있게한다. 다른 Bean들이 DB에읽고쓰는것을모두금지한다. 96 JEUS EJB 안내서

115 위의 3가지모드가사용되어야하는상황은다음과같다. CMP Bean이쓰기작업보다는읽기작업을더빈번히수행하면항상 ReadLocking 모드를선택한다. CMP Bean이읽기보다는쓰기작업을더많이수행하면 WriteLocking 모드나 WriteLockingFind 모드를선택한다. CMP에서는엔진모드와앞절에서설명한 Non-modifying 메소드, 그리고본절에서설명한엔진내하위모드가규칙에맞게조합되어설정되어야한다. 이모든파라미터들의설정요약은 8.4. Entity EJB 튜닝 의설명을참고한다. 또한 CMP Bean에서는 java.sql.resultset의 Fetch Size, EJB 엔진이기동 (Booting) 할때 Caching되어야하는지의여부와 EJB Bean Instance가미리 Instance되어야할지등을결정하는 <init caching> 설정을할수있다 Entity Bean 스키마정보 EJB 엔진이 Bean의 persistence를관리하는책임을가지고있다면 (CMP), Entity Bean Instance 필드와실제 DB의테이블과컬럼들과의매핑을선언적으로정의해주는방법이있어야한다. 또한 DB 소스도지정해주어야한다. 이정보는 EJB XML 환경에 <schema info> 로기술한다. CMP 1.1의이태그에는 EJB 엔진이 CMP 1.1 finder 메소드를생성할때기본적으로사용될 SQL 문도포함된다 자동 Primary Key 생성 경우에따라개발자들은 Primary Key 생성없이 EJB Instance를생성해야할때가있다. 이경우 JEUS EJB 엔진이새로운 EJB Instance에게할당할고유의 Primary Key를생성하도록설정할수있다. JEUS EJB 엔진은이기능을 DB와연동하여제공한다. 이러한자동 Primary Key 생성기능에대해 JEUS EJB 엔진은 DB와연동하여제공하고, CMP 1.1과 CMP 2.0에적용된다. 이기능을사용하면 Primary Key 에신경쓰지않고손쉽게 EJB를개발할수있다. 다음은자동 Primary Key 생성기능의사용방법과적용과정에대한설명이다. 1. 개발자들은습관적으로 CMP1.1/CMP2.0을파라미터없이 create() 를호출한다. 이것은 create() 메소드가 EJB의 Primary Key가되는파라미터를갖지않는다는의미이다. InitialContext ctx = new InitialContext(); BookHome bhome = (BJookHome) ctx.lookup("bookapp"); Book b = bhome.create( JEUS EJB Guide, Park Sungho ); // Start using b. 위의예제에서 EJB Home인 BookHome을찾고 EJB Home에서파라미터가 2개인 create() 를호출한다 ("JEUS EJB Guide" 와 "Park Sungho"). 이파라미터는새로운책의제목과저자이름을뜻한다. 저자는다르나동일한제목의책이있을수있기때문에이파라미터들을 Primary Key로이용하는것은적합하지않다. 제 8 장 Entity Bean 97

116 이기능을지원하기위해 EJB 엔진은 ("A") 반드시고유의 Primary Key를생성해서새책에할당해야한다. 그리고여러엔진들 ("B", "C") 이클러스터링된상태에서도같은일이동시에발생할수있다는것을고려해야한다. 광범위한클러스터링중에도각엔진들은고유한 Primary Key를얻을수있어야하기때문에하나의중앙저장장치를필요로한다. 이저장장치는하나의컬럼과하나의데이터로이루어진 DB로구현된다. 이하나의값은 EJB 엔진과연동하면서계속증가하는 Primary Key Counter( 또는 Primary Key Gener ator) 이다. 이방법으로 DB는항상클러스터링된 EJB 엔진이읽을수있는새롭고고유한 Primary Key 를유지할수있다. 2. Primary Key가없는 create() 가호출되면, EJB 엔진 "A" 는중앙저장장치 (Primary Key DB) 로접근한다. 이저장장치로부터정수로된 Primary Key를받아오고 Book Instance에할당한다. 3. EJB 엔진 "A" 는저장장치에있는미리결정된값으로 Primary Key를증가시킨다. 미리결정된값 (Key Cache Size) 은기본적으로 "1" 이다. 그러나 1 이상을사용할것을권장한다 ("20"). 만약 Key Cache Size가 "20" 이라면, EJB 엔진 "A" 는 "19" (20-1) 를할당한다. 다음에 Primary Key를읽는다른 EJB 엔진 ("B" 와 "C") 은가장최근에 Primary Key를읽어간것보다 20이큰값을읽게된다. 이것은 EJB 엔진 "A" 는 19개까지는외부의 Primary Key 저장장치에접근없이 EJB Instance를생성할수있다는것을의미한다. 따라서성능향상에큰기여를한다. 엔진 "A" 는할당받은 Primary Key의 Counter를유지함으로써이값을모두소비했을때에만외부에서새로운 Primary Key를읽어온다. 내부적인 Counter는물론 Primary Key를생성하는데사용된다. 다음은자동 Primary Key 생성의특징에대한설명이다. Oracle과 MS SQL 서버는자동으로 Primary Key Sequence를제공한다. 자동 Primary Key 생성설정에대한자세한내용은 "Oracle DB에서 Primary Key 생성설정 " 과 "MS SQL Server에서자동 Primary Key 생성설정 " 을참고한다. Non-Oracle과 Non-MS SQL 서버는직접 Primary Key 테이블을작성해야한다. 자세한내용은 "Other DB의자동 Primary Key 생성 " 을참고한다. 자동 Primary Key 생성기능을사용하기위해서는 DB가반드시 Transaction Isolation Level - TRANS ACTION_SERIALIZABLE을지원해야한다. 본안내서에서는지원한다고가정한다. Primary Key는 EJB에서반드시정의되어야한다. Primary Key는반드시 java.lang.integer 타입이고, 단일 key여야하며, EJB DD에선언되어야한다. 참고 자동 Primary Key 생성기능은반드시 TRANSACTION_SERIALIZABLE(Isolation Level) 을지원해야 만한다. 즉, Oracle, MS SQL 서버외에는모두이 Isolation Level 이지원되는지확인해야한다. 다음은각 DB 에설정하는방법에대해설명한다. 98 JEUS EJB 안내서

117 Oracle DB에서 Primary Key 생성설정 Oracle DB에서자동 Primary Key 생성은 Oracle에서사용하는 "Sequence 객체 " 를이용한다. 자동 Primary Key 생성기능을설정하기전에 Sequence 객체가생성되어있어야한다. Sequence 설정에관련한내용은 Oracle 문서를참고한다. 다음은 Oracle DB에서 Primary Key를생성하는 jeus-ejb-dd.xml의예이다. [ 예 8.1] Oracle DB에서 Primary Key 생성설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <schema-info> <data-source-name>myoracledb</data-source-name> <auto-key-generator> <generator-type> Oracle </generator-type> <generator-name> my_generator </generator-name> <key-cache-size> 20 </key-cache-size> </auto-key-generator> </schema-info> </jeus-bean> </beanlist> </jeus-ejb-dd> 위예제에서 Primary Key 생성타입을 "Oracle" 로설정했으며, <generator-name> 을 my_generator 로하 고 <key-cache-size> 를 "20" 으로설정했다. 참고 <key-cache-size> 는 Oracle의 Sequence 객체의 SEQUENCE INCREMENT 값과일치해야한다. Oracle DB는 <data-source-name> 에서선택된다 ( 여기서는 "MYORACLEDB" 가사용되었는데, JEUSMain.xml의 DB Connection Pool JNDI 이름이다 ). 설정에대한자세한내용은 "JEUS Server 안내서 " 를참고한다. 제 8 장 Entity Bean 99

118 MS SQL 서버에서자동 Primary Key 생성설정 MS SQL 서버에서자동 Primary Key 생성은간단하다. MS SQL 서버는자동으로고유의 IDENTITY 컬럼에 Primary Key를유지한다. 다음은 MS SQL 서버에서자동 Primary Key 생성을설정한 jeus-ejb-dd.xml의예이다. [ 예 8.2] MS SQL 서버에서자동 Primary Key 생성설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <schema-info> <data-source-name>mssqldb</data-source-name> <auto-key-generator> <generator-type> MSSQL </generator-type> </auto-key-generator> </schema-inboldfo> </jeus-bean> </beanlist> </jeus-ejb-dd> <generator-type> 에 "MSSQL" 을입력한다. MS SQL 서버는 <data-source-name> 에서선택된다. Other DB의자동 Primary Key 생성설정만약 Oracle과 MS SQL 서버외에다른 DB를이용해서자동 Primary Key를생성한다면, 다음의절차를반드시지켜야한다. 1. 다음과같이 DB에테이블을하나생성한다. 테이블은하나의컬럼과하나의열을갖고있어야하고, 값은 '0' 으로설정되어야한다. 다음은 Primary Key 값을관리할테이블이다. Primary Key generator table PrimKeyTable PrimKeyGeneratorColumn (Primary Key 값이저장되는컬럼 ) Row 1 0 (Primary Key 값의초기값 ) 위의테이블은다음의 SQL 로생성된다. CREATE table PrimKeyTable (PrimKeyGeneratorColumn int); INSERT into PrimKeyTable VALUES (0); 100 JEUS EJB 안내서

119 2. 테이블을생성하고 jeus-ejb-dd.xml을다음과같이수정한다. [ 예 8.3] Other DB의자동 Primary Key 생성설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <schema-info> <data-source-name>mydb</data-source-name> <auto-key-generator> <generator-type> USER_KEY_table </generator-type> <generator-name> PrimKeyTable </generator-name> <sequence-column> PrimKeyGeneratorColumn </sequence-column> <key-cache-size> 20 </key-cache-size> </auto-key-generator> </schema-info> </jeus-bean> </beanlist> </jeus-ejb-dd> 위예제에서타입은 'USER_KEY_table' 이고, 테이블이름이 'PrimKeyTable' 이다. 컬럼이름은 'PrimKeyGeneratorColumn' 이고 Key Cache 크기는 '20' 으로설정했다. DB를사용하기위해서설정하는 <data-source-name> 태그의값은 JEUSMain.xml의 DB Connection Pool의 <export-name> 과일치해야한다. 참고 설정에대한자세한내용은 "JEUS Server 안내서 " 를참고한다. 제 8 장 Entity Bean 101

120 CMP 2.0 본절에서는 CMP 2.0 의주요기능에대해서설명한다 Entity Bean Relationship Mapping EJB 2.0 스펙에는 DB에있는관계 (Relationship) 를지원하기위해 CMP Relationship의개념이소개되어있다. CMP 2.0 Bean들과이 Relationship들을사용할때에는 deployer가 JEUS EJB DD에추가정보를제공해야한다 JEUS EJB QL Extension CMP 2.0 Bean은 ejb-jar.xml의 EJB QL 문장과연계되어있는 home interface의 findbyxxxx() 메소드를가지고있어야한다. JEUS는표준 EJB QL 언어에몇가지추가사항을더지원한다. 이추가지원사항은 ejb-jar.xml에사용되거나 Instant EJB QL 요청에사용될수있다 JEUS EJB QL Extension 에는위의예가포함된완전한 ejb-jar.xml의예가포함되어있다 Instant EJB QL 클라이언트코드내에서 CMP Bean의집합을찾으려면 Bean의 home interface에선언되어있는 find ByXXXX() 메소드들에의존할수밖에없다. 이찾기방법이복잡한경우에는 findbyxxxx() 만으로는부족할수가있다. 이러한경우를대비하여 JEUS에서는클라이언트코드에서 EJB QL select 질의문들을정의할수있는비표준인터페이스를제공한다. 이인터페이스는 jeus.ejb.bean.objectbase.ejbinstancefinder라고불리며, JEUS EJB DD에 Bean의 Instant QL을활성화시킨경우 Entity Bean의 home interface에서구현한다. 이인터페이스는사용자의 EJB QL을 home interface로넘겨주는메소드인 findwithinstantql(string ejbql String) 을가지고있다. 이메소드는질의에해당하는 EJB 인터페이스의 java.util.collection 객체를반환한다. 이메소드의예제는 자동 Primary Key 생성 을참고하고, 해당 API에대한설명은 Appendix B. In stant EJB QL API Reference 를참고한다 Entity EJB 설정 다음과같은 JEUS Entity EJB의설정방법을설명한다. 모든 Entity Bean에적용가능한설정 기본적이고공통적인설정들 Object Pool Entity Cache 설정을포함한 Persistence 최적화 CMP에만적용가능한설정 CM persistence optimization 최적화 스키마정보설정 102 JEUS EJB 안내서

121 CMP 2.0 에만적용가능한설정 Relationships 매핑설정 Instant EJB QL 설정 모든이특성들은 JEUS EJB 모듈 DD(jeus-ejb-dd.xml) 의 <beanlist> 태그아래의 <jeus-bean> 에설정된 다 공통설정 다음은모든 Entity Bean 에적용가능한기본설정에대한설명이다 기본공통항목설정 제4장 EJB의공통특성 에서설명한 JEUS에서지원하는모든 Bean 종류에적용가능한설정은모든종류의 Entity Bean들에게도적용할수있다. 다음은 BMP Entity Bean의기본 XML 태그의예이다. [ 예 8.4] Entity EJB의기본공통항목설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <ejb-name>account</ejb-name> <export-name>accountejb</export-name> <local-export-name> LOCALACCOUNTEJB </local-export-name> <export-port>7654</export-port> <export-iiop>true</export-iiop> </jeus-bean> </beanlist> </jeus-ejb-dd> Object Management 관련설정 다음은 Object Management 관련설정이된 XML 예제로 <jeus-bean> 의 <object-management> 태그 내에서구성된다. 제 8 장 Entity Bean 103

122 [ 예 8.5] Object Management 관련설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <object-management> <bean-pool> <pool-min>10</pool-min> <pool-max>200</pool-max> </bean-pool> <connect-pool> <pool-min>10</pool-min> <pool-max>200</pool-max> </connect-pool> <passivation-timeout>10000</passivation-timeout> <disconnect-timeout> </disconnect-timeout> </object-management> </jeus-bean> </beanlist> </jeus-ejb-dd> 다음은설정태그에대한설명이다. <bean-pool> EJB Bean Instance Pool의작동방식을결정한다. 하위태그들은다음과같다. 태그 <pool-min> <pool-max> 설명 Pool을초기화할때생성해두는초기 Bean Instance 개수와 Pool에유지하려는최소 Bean Instance의개수 (resizing 작업할때 Pool에남기는 Instance의개수 ) 이다. ( 기본값 : 0) Instance의사용이끝난후 Pool에저장여부를결정하는 Pool이가질수있는최대 Bean Instance 개수이다. Session Bean은 <pool-max> 설정값까지만생성할수있으므로그이상의요청이한번에오면 EJB Exception이발생한다. 반면, Entity Bean 은 Bean Instance 생성에는제한이없고사용후에 Pool 에보관 할개수를제한한다. ( 기본값 : 100) <resizing-period> Pool 의크기를재조정하는시간으로 "resizing" 은사용되지않는 Bean Instance 들 이 Pool 의최솟값까지제거됨을의미한다. ( 기본값 : 1 분 ) 104 JEUS EJB 안내서

123 <connect-pool> 클라이언트와 Bean Instance를연결하는 connection을몇개까지유지할것인지를설정한다. 해당옵션은 Session Bean에서는사용하지않는다. 하위태그들은다음과같다. 태그 <pool-min> <pool-max> <resizing-period> 설명 Pool에유지하려는최소 connection의개수로 resizing 작업할때 Pool에남기는 Instance의개수이다. ( 기본값 : 0) connection 사용이끝난후 Pool에저장여부를결정하는 Pool이가질수있는최대 connection 개수이다. ( 기본값 : 100) Pool의크기를재조정하는시간으로 "resizing" 은사용되지않는 connection들이 Pool의최솟값까지제거됨을의미한다. ( 기본값 : 1, 단위 : 분 ) <passivation-timeout> 지정된시간동안클라이언트의요청을받지않은 Bean을 passivate할때사용된다. 여기에설정된시간을초과하는동안클라이언트의요청이없는 Bean Instance가 passivate 대상이된다. passivate 대상인 Bean Instance가메모리에남아있는개수를 <persistence-optimize>/<entitycache-size> 로조절할수있다. Stateful Session Bean의경우는 Entity Cache라는것이없어설정한시간동안요청이없으면 passivate 되지만 Entity Bean의경우는 Entity Cache에머물러있다가 passivate된다. 어떤 Bean이 passivate 되는지검사하는주기는 EJB 엔진에설정한 resolution을따른다. ( 기본값 : 5분 ) passivate가실행되면메모리에서해당하는 Bean Instance가제거된다. 이설정은다음과같이여러곳에서설정가능하고우선순위는다음과같다. 1. 특정 Session Bean에만적용 : jeus-ejb-dd.xml의 <passivation-timeout> 2. 모든 Entity Bean에적용 : 시스템프로퍼티 jeus.ejb.entity.passivate 3. 모든 EJB Bean에 (Entity Bean과 Session Bean 모두 ) 적용 : 시스템프로퍼티 jeus.ejb.all.passivate 위의모든설정이없으면기본값으로설정된다. ( 기본값 : (5분 ), 단위 : ms) <disconnect-timeout> 지정된시간동안클라이언트의요청을받지못하면클라이언트와 Bean Instance 사이를연결하던 connection을끊을때사용된다. 그렇게되면 connection은각각의클라이언트와 Instance가맺고있던연결을끊고 Connection Pool로반환된다. 따라서클라이언트는이 connection으로더이상요청을할수없고, 사용중이던 Bean Instance는삭제되거나 Bean Pool을사용중이면 Bean Pool로반환된다. 이설정은다음과같이여러곳에서설정가능하고우선순위는다음과같다. 1. 특정 Session Bean에만적용 : jeus-ejb-dd.xml의 <disconnect-timeout> 제 8 장 Entity Bean 105

124 2. 모든 Entity Bean에적용 : 시스템프로퍼티 jeus.ejb.stateful.disconnect 3. 모든 EJB Bean에 (Entity Bean과 Session Bean 모두 ) 적용 : 시스템프로퍼티 jeus.ejb.all.disconnect 위의모든설정이없으면시스템프로퍼티 jeus.ejb.all.disconnect의기본값인 (1시간 ) 으로설정된다. ( 단위 : ms) 참고 <passivation-timeout> 과 <disconnect-timeout> 에사용되는시간은 Bean Instance에액세스했던마지막시점부터측정된다. 그러므로 <disconnect-timeout> 을 <passivation- timeout> 보다길게설정해야한다. 또한 <passivation-timeout> 은 EJB 엔진에설정되는 resolution보다는커야한다. 타임아웃값을길게설정하면오랜시간 ( 대략십여분이상또는타임아웃이중지된경우 ) 동안메모리안에많은 Instance가활성화된상태로머물러있다. 그러므로시스템자원이낭비된다. 타임아웃값이수초정도로너무짧으면 passivation, activation 등의작업이자주발생되므로성능을저하시킬수있고 disconnect 작업으로인해세션의유실가능성이있다 ejbload() 와 ejbstore() Persistence 최적화설정 Persistence 메소드호출의최적화는 jeus-ejb-dd.xml의각 Bean DD에설정되어있다. 다음은 ejbload(), ejbstore() 메소드의 Persistence 최적화설정된 XML 예제로 <jeus-bean> 의 <persis tence-optimize> 태그내에서구성된다. [ 예 8.6] ejbload() 와 ejbstore() Persistence 최적화설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <persistence-optimize> <engine-type>single_object</engine-type> <non-modifying-method> <method-name>mybusinessmethod</method-name> <method-params> <method-param> java.lang.string </method-param> <method-param>int</method-param> <method-param>double</method-param> </method-params> </non-modifying-method> <non-modifying-method> <method-name>mybusinessmethod2</method-name> <method-params> 106 JEUS EJB 안내서

125 <method-param> java.lang.string </method-param> <method-param>int</method-param> </method-params> </non-modifying-method> <entity-cache-size>500</entity-cache-size> <update-delay-till-tx> false </update-delay-till-tx> <include-update> true <include-update> </persistence-optimize> </jeus-bean> </beanlist> </jeus-ejb-dd> 다음은설정태그에대한설명이다. 태그 <engine-type> <non-modifying-method> <entity-cache-size> <update-delay-till-tx> 설명 EXCLUSIVE_ACCESS, SINGLE_OBJECT, MULTIPLE _OBJECT 중의하나로설정되어야한다. 각설정에대한차이는 8.2. 주요기능 의설명을참고한다. ( 기본값 : EXCLUSIVE_ACCESS) ejbstore() 가호출되어야하는지에대한힌트를 EJB 엔진에제공한다. 이태그는 CMP 2.0 Bean에서는적용되지않는다. Passivate되어야할 Entity Bean Instance들을위한내부 Cache의크기를결정한다. Cache에담을수있는 Entity Bean Instance의최대크기만큼이주어진다. 크기가클수록좋은성능을가질수있지만시스템리소스 ( 주메모리 ) 는그만큼더많이사용된다. ( 기본값 : 2000) Boolean 값을가지며 EJB 데이터의 update, insert가트랜잭션이 commit될때까지지연될지를나타낸다. 이값이 false 이면모든 update, insert 작업은즉각실행되므로, 동일한트랜 잭션내에서는 commit() 이호출되기전에도변경사항을확인할수가있지만 성능에악영향을미친다. ( 기본값 : true) <include-update> <schema-info><jeus-query><include-updates> 의기본값을지정한다. 이값이 true 일경우 finder 메소드가호출되는동안에생성된 update 가 commit 되므로, finder 메소드가실행될동안업데이트된정보를조회할수있다. ( 기본값 : false) 제 8 장 Entity Bean 107

126 CMP 1.1/2.0 다음은 CMP 1.1/2.0 의설정에대한설명이다 ejbload() 와 ejbfind() CM Persistence 최적화설정 CMP 1.1과 2.0 Bean에는 ejbload() persistence 최적화를설정할수있다. 자세한내용은 ejbload() 와 ejbstore() Persistence 최적화설정 을참고한다. 다음은 ejbload, ejbfind CM Persistence 최적화설정한 XML의예로 <jeus-bean> 의 <cm-persistenceoptimize> 태그내에설정된다. [ 예 8.7] ejbload() 와 ejbfind() CM Persistence 최적화설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <cm-persistence-optimize> <subengine-type>writelocking</subengine-type> <fetch-size>80</fetch-size> <init-caching>true</init-caching> </cm-persistence-optimize> </jeus-bean> </beanlist> </jeus-ejb-dd> 다음은설정태그에대한설명이다. 태그 <subengine-type> 설명 ReadLocking, WriteLocking 또는 WriteLockingFind 로설정해야한다. ( 기본값 : ReadLocking) <fetch-size> <init-caching> ResultSet으로한번에가져올수있는레코드의수를결정한다. ( 기본값 : 10) Boolean 스위치값이활성화되면 DB 테이블의각레코드에대하여 EJB 엔진이미리 Instance화된 EJB Entity Instance를생성한다. 이작업은엔진이시작될때수행된다. 비활성화되어있으면 EJB Instance들은 home interface의 create(), find-byxxxx() 또는비슷한메소드호출에의해서만생성된다. ( 기본값 : false) 108 JEUS EJB 안내서

127 DB 스키마정보설정 CMP 1.1/2.0에서는 DB 테이블과컬럼에대응하는 EJB Instance 필드와의매핑을포함하고있는 DB 스키마정보를설정해야한다. 다음은 DB 스키마정보를설정한 XML 예제로 <jeus-bean> 의 <schema-info> 태그내에구성된다. [ 예 8.8] DB 스키마정보설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <schema-info> <table-name>account</table-name> <cm-field> <field>id</field> <column-name>id</column-name> <type>numeric</type> <exclude-field>false</exclude-field> </cm-field> <cm-field> <field>customer_addr</field> <column-name>customer_address</column-name> <type>varchar(30)</type> <exclude-field>false</exclude-field> </cm-field> <creating-table> <use-existing-table/> </creating-table> <deleting-table>true</deleting-table> <prim-key-field> <field>id</field> </prim-key-field> <jeus-query> <method> <method-name>findbyaddress</method-name> <method-params> <method-param>java.lang.string</method-param> </method-params> </method> <sql>customer_address=?</sql> </jeus-query> <jeus-query> <query-method> <method-name>findbytitle</method-name> 제 8 장 Entity Bean 109

128 <method-params> <method-param>java.lang.string</method-param> </method-params> </query-method> <jeus-ql> SELECT OBJECT(b) FROM Book b WHERE b.title =?1 ORDERBY b.price </jeus-ql> </jeus-query> <db-vendor>oracle</db-vendor> <data-source-name>mydb</data-source-name> </schema-info> </jeus-bean> </beanlist> </jeus-ejb-dd> 다음은설정태그에대한설명이다. <table-name> 현재 EJB에매핑되어야할관계형 DB 테이블의이름이다. 만약에설정되어있지않으면 <EJB module name>, <EJB name> 을이용해테이블이름이임의로설정된다. 일부 DBMS들이가지는테이블이름의길이제한때문에 15자이내의테이블이름만허용된다. <cm-field> Container Managed Field 매핑은각각의컬럼과필드의관계를위해존재한다. 하위에다음의태그를설정한다. 태그 <field> <column-name> <type> 설명 DB 컬럼에매핑되어야하는 EJB 필드의이름을지정한다. 주어진 DB 테이블에존재하는것과같은것이다. 지정되어있지않으면 EJB 필드의이름을사용한다. DB 컬럼에정의된데이터타입을기준으로한다. ( 예 : VARCHAR(25), NUMERIC 등 ) 태그가지정되어있지않으면, 디폴트타입이사용된다 ( 사용될타입은 DB에따라다를수있다 ). 이매핑은 Appendix A. 기본 Java 타입과 DB 필드매핑 에서설명한다. Oracle DBMS의경우 "BLOB"(Binary Large Object) 과 "CLOB"(Character Large Object) 를다룰수있다. 이타입들은이미지같이큰자료타입에적합하다. 110 JEUS EJB 안내서

129 태그 설명 CLOB : java.lang.string 에적합하다. BLOB : serializable 된필드에적합하다. <exclude-field> true 로설정하면 <field> 태그로지정된필드에대해 accessor 메소드가생성되 지않아클라이언트에서해당필드를접근할수없다. 이옵션은 CMP 2.0 Bean 에서만작동한다. 이옵션은이전 (migration) 을위한목적으로사용된다. <creating-table> Bean이 start되는시점에이 Bean이사용하고자하는테이블이 DB에존재하는지를검사하여하위태그에따라기존의테이블을사용하거나새로생성하거나에러를발생한다. 검사하는방법은 <schema-info>/<table-name> 과같은이름을가지고, <schema-info>/<cm-field> 에명시한필드들이존재하며, relation을관리하는 Bean이라면 <ejb-relation-map>/<jeus-relationshiprole>/<column-map> 에명시한 Foreign Key들도존재하는지검사한다. 다음의하위태그를설정한다. 태그 <use-existing-table> <force-creating-table> 설명 DB 에이미테이블이있으면그대로사용하고없는경우에만테이블을생성한다. DB 에테이블이존재해도그테이블을삭제하고새로운테이블을생성한다. 하위태그를지정하지않을경우테이블이이미존재하면에러를발생하고발생하고없는경우는테이블을생성한다. 태그가없는경우는 MS JVM 파라미터에 "-Djeus.ejb.checktable" 설정에따라테이블의검사여부를결정한다. 설정값 true 설명 테이블검사를하는데해당테이블이존재하지않으면에러가발생한다. ( 기본값 ) false Bean 이 start 하는시점에테이블검사를하지않기때문에실제테이블을사용할 때에러가발생한다. <deleting-table> 스위치가활성화되면 EJB 모듈이 undeploy될때지정된테이블이 DB에서제거된다. 이옵션은실제상황에서아주조심스럽게사용되어야하므로실수를방지하기위해 JEUS의시스템프로퍼티로별도의설정을해야동작한다. 즉, JEUSMain.xml의 Command 옵션에 "-Djeus.ejb.en able.configdeleteoption=true" 로설정할때만동작한다. 또한 <creating-table> 의설정이없는데 <deleting-table> 설정을사용하는경우는거의없으므로 <creating-table> 의설정이없을때에는 <deleting-table> 설정이실행되지않는다. 제 8 장 Entity Bean 111

130 <prim-key-field> 복합 key를 Primary Key로사용하는경우에선택적으로사용된다. 즉, ejb-jar.xml의 <prim-key-class> 에복합 key를위해사용자가구현한 Primary Key 클래스를지정한경우에선택적으로사용할수있다. 기본적으로는 <prim-key-class> 에선언된모든 public 필드가 Primary Key를구성하지만, 사용자가필드를선택하여 Primary Key를구성하고싶은경우에이목록을설정한다. 다음의 element를혼동하지않도록한다. 복합 Key Element ejb-jar.xml/<prim-key-class> ejb-jar.xml/<primkey-field> 설명사용자가구현한 Primary Key 클래스이다. ( 필수항목 ) 선언할수없다. <prim-key-class> 에선언한타입은여러필드를포함하는타입이므로하나의필드이름과매핑시킬수가없다. ( 선택항목 ) jeus-ejb-dd.xml/<prim-key-field> Primary Key 클래스의 public 필드모두를 Primary Key 로구성하지 않고필드를선택하고싶은경우그목록을선언한다. ( 선택항목 ) 단일 Key Element ejb-jar.xml/<prim-key-class> ejb-jar.xml/<primkey-field> 설명 java.lang.string, java.lang.integer 등 ejb-jar.xml/<primkey-field> 의타입이다. ( 필수항목 ) Primary Key에해당하는 Entity Bean의필드이름이다. <primkey-field> 에선언한필드이름과 <prim-key-class> 에선언한 타입이 Entity Bean 클래스에선언된필드이름, 타입과매핑되어야 한다. ( 선택항목 ) jeus-ejb-dd.xml/<prim-key-field> 여러필드가있을경우선택할때필요한것이기때문선언할필요가 없다. ( 선택항목 ) <jeus-query> CMP 1.1 Entity Bean의경우 finder 메소드에대해서필요한 SQL 문장을반드시명시해야한다. CMP 2.0의경우에는 ejb-jar.xml에지정된 EJB QL을 overriding할수있다. <jeus-query> 를설정하면 Query 메소드 (findxxx) 에서 EJB QL과 JEUS EJB QL 확장을사용할수있다. 이것은 ejb-jar.xml의 <query> 태그와비슷하다 JEUS EJB QL Extension 에서자세하게설명한다. 이태그는 BEA WebLogic 애플리케이션서버를 JEUS v4.2로마이그레이션할때용이하게하는것이주요목적이다. SQL들을정의하기위해 SQL 문장이사용될 finder 메소드의이름과파라미터그리고 SQL 문장이설정되어야한다. 이문장은 finder 메소드를생성할때사용된다. 112 JEUS EJB 안내서

131 지정된문장에는 WHERE 절다음에나오는부분만을포함하고있어야한다. 다른요소는자동으로주어진다. 여기에는 "?" 문자를지정할수있고이는 finder 메소드의파라미터값들을대신하게된다. ANSI SQL의 WHERE 절문법을사용할수있다 ( 이 SQL은 WHERE에포함된다 ). <include-updates> 가 true로설정되면 finder 메소드호출동안변경된사항이 DB에 Commit되므로 finder 메소드에서변경된사항을확인할수있다. <db-vendor> Bean을위해사용되는 DB의벤더를지정한다. 벤더이름은벤더특정최적화를위해 EJB 엔진이사용하게된다. 여기서지정된값이실제로성능에얼마나많은영향을미칠수있는지는확인된바없다. 사용가능한벤더의종류는 Appendix A. 기본 Java 타입과 DB 필드매핑 을참고한다. 일반적인예는 "oracle" 을들수있다. 이값은또한 Java 객체와벤더가정한 DB 필드타입과의정확한매핑을가려내기위하여사용된다. <data-source-name> DB와연결할때사용하는 DB Connection Pool의 JNDI 이름을지정한다. Connection Pool은일반적으로도메인에설정되고, MS JVM에의해실행된다. <auto-key-generator> CMP 2.0에서자동으로 Primary Key를생성하기위해사용하며하위태그들이있다. 하위태그에대한자세한설명은 자동 Primary Key 생성 을참고한다 CMP 2.0 다음은 CMP 2.0 설정에대해서설명한다 Relationship Mapping 설정 2개의 Bean 사이에 Relationship Mapping을설정하는방법은다음과같이경우에따라달라진다. One-to-one/One-to-many Relationship Mapping Many-to-many Relationship Mapping One-to-one/One-to-many Relationship Mapping 2개의 Bean 간에 One-to-one/One-to-many Relationship을설정할때 <ejb-relation-map> 태그내에설정해야한다. 다음은 'employee-manager' 라는관계를가지는 2개의 Bean 간에 Many-to-one(= One-to-many) 관계를설정한예로 <ejb-relation-map> 태그에설정한다. 제 8 장 Entity Bean 113

132 [ 예 8.9] One-to-one/One-to-many Relationship 설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <ejb-relation-map> <relation-name>employee-manager</relation-name> <jeus-relationship-role> <relationship-role-name>employee-to-manager</relationship-role-name> <column-map> <foreign-key-column>manager-id</foreign-key-column> <target-primary-key-column>man-id</target-primary-key-column> </column-map> </jeus-relationship-role> </ejb-relation-map> </jeus-ejb-dd> 다음은설정태그에대한설명이다. <relation-name> ejb-jar.xml 파일에정의되어있다. <jeus-relationship-role> 2개의 JEUS Relationship의열할을 Relationship의각방향별로설정한다. 각 Relationship의역할에필요한정보는다음과같다. <relationship-role-name> ejb-jar.xml의 <ejb-relationship-role-name> 태그에정의되어있다. <column-map> 2개의하위태그인 <foreign-key-column> 과 <target-primary-key-column> 을가진다. 태그 <foreign-key-column> <target-primary-key-column> 설명 Relationship에서 Foreign Key의역할을하는컬럼의이름이다. Foreign Key 컬럼이매핑되어야할테이블의 Primary Key 필드이다. key 가여러개의컬럼으로구성되어있으면여러개의컬럼대컬럼매핑을지정할수있다. 위의 XML예에서는 employee 테이블의 manager-id라는 Foreign key 컬럼이 employee-to-manager의 Many-to-one 관계를맺기위해 manager 테이블의 Primary Key 필드와매핑되어있다. One-to-one Mapping도이와비슷한방법으로설정된다. 단, One-to-one 관계에서는 Primary Key 컬럼과 Foreign Key 컬럼이테이블어디에존재해도상관없으며, One-to-many에서는반드시 many 측의테이블이 Foreign Key 컬럼을가지고있다는것을유념한다. 114 JEUS EJB 안내서

133 Many-to-many Relationship Mapping 2 개의 Bean 간에 Many-to-many 관계를맺기위해서는 One-to-one 의관계에서설정된정보외에추가로 <table-name> 과 <jeus-relationship-role> 의정보가반드시설정되어야한다. 다음은 Many-to-many 관계설정을나타내는 'student-course' 의예이다. [ 예 8.10] Many-to-many Relationship Mapping 설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <ejb-relation-map> <relation-name>student-course</relation-name> <table-name>studentcoursejoin</table-name> <jeus-relationship-role> <relationship-role-name>student</relationship-role-name> <column-map> <foreign-key-column> student-id <!--This column in join table--> </foreign-key-column> <target-primary-key-column> stu-id <!--This column in student table--> </target-primary-key-column> </column-map> </jeus-relationship-role> <jeus-relationship-role> <relationship-role-name>course</relationship-role-name> <column-map> <foreign-key-column> course-id <!--This column in join table--> </foreign-key-column> <target-primary-key-column> cou-id <!--This column in course table--> </target-primary-key-column> </column-map> </jeus-relationship-role> </ejb-relation-map> </jeus-ejb-dd> 다음은설정태그에대한설명이다. <table-name> Many-to-many 관계의 Join 테이블이름을지정한다. <jeus-relationship-role> 두 JEUS relationship role에서 Join 테이블의두 Foreign Key 컬럼을두 Bean이사용하는두테이블의 Primary Key 컬럼에매핑한다. 제 8 장 Entity Bean 115

134 위의예에서두 JEUS Relationship role이어떻게사용되고있는지확인할수있다. 각 role은 Join 테이블의두컬럼중한개와실제 Bean이사용하는테이블의 Primary Key 컬럼이매핑하도록선언하고있다 Instant EJB QL 의설정 클라이언트에 Instant EJB QL 질의를가능하게하려면, JEUS EJB DD의 <enable-instant-ql> 태그를 true 로설정한다. 자세한내용은 Appendix B. Instant EJB QL API Reference 를참고한다. [ 예 8.11] Instant EJB QL 설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <enable-instant-ql>true</enable-instant-ql> </jeus-bean> </beanlist> </jeus-ejb-dd JEUS EJB QL Extension JEUS CMP에관련된 EJB QL Extension에대해설명한다. 이확장자들은새로운키워드들과 subquery들, ejbselect() 메소드에의해리턴되는 ResultSet, 집합함수, 다양한 EJB QL 질의그리고 GROUP BY 키워드이다. CMP 2.0 Bean의 findbyxxx() 메소드와 ejbselectxxx() 메소드에서는그 home interface와 ejb-jar.xml의 EJB QL 문장이연계되어있어야한다. JEUS는표준 EJB QL 언어에몇가지사항들을추가한다. 이추가사항들은 ejb-jar.xml 파일이나 EJB QL에서사용된다. 이기능이사용된 ejb-jar.xml의예는 8.5. 완전한 CMP 2.0 Entity Bean 예제 를참고한다. 주의본안내서에서제공된 EJB QL Extension들은표준 EJB 2.1 QL에서지원하지않는항목들로서이것을이용하여작성된 EJB 애플리케이션은 Java EE 표준에준하지않으므로이식성이떨어진다. 이의미는여기서제공된확장기능을사용하여생성한 EJB 컴포넌트는다른 Java EE 서버에 deploy될수없다는것이다. JEUS의 EJB QL Extension은대부분표준 SQL처럼작동한다. 그러므로더상세한정보는 SQL을참고한다. 116 JEUS EJB 안내서

135 JEUS EJB QL Extension 키워드추가사항 JEUS에서는다음과같은비표준키워드들이 EJB QL 문장에사용될수있다. ORACLEHINT 키워드 "oraclehint< 표준 Oracle hint string>" 의문법을가진다. SELECT OBJECT(b) ORACLEHINT '/*+ALL_ROWS*/' FROM Book b 이키워드에대한상세한정보는 Oracle의문서를참고한다. JEUS EJB QL Extension Subquery JEUS의 EJB QL Subquery는 EJB QL 질의의하나로 WHERE 절에포함된또다른질의절을의미한다. 이것은 SQL 질의와 Subquery의관계와비슷하다. 다음의예에서는중첩된 EJB QL 질의의한예로서평균이상의월급을받는고용인들을질의한다. SELECT OBJECT(e) FROM EmployeeBean AS e WHERE e.salary > (SELECT AVG(e2.salary) FROM EmployeeBean AS e2) 리턴타입 JEUS EJB QL 질의에대해다음과같은리턴타입들이올수있다. Single value 또는 <cmp-field> 에대응하는 Collection( 위의예에서 e.salary와같은값들 ) 집합함수를통해서생성된한개의리턴값 ( 예 : MAX(e.salary)) 간단한 Primary Key(compound Primary Key가아닌 ) 를포함한 cmp-bean( 예 : SELECT OBJECT(emp)) 비교연산자 JEUS EJB QL은 Subquery를비교연산자의피연산자로사용할수있다. JEUS EJB QL은비교연산자는다음과같다. [NOT] IN, [NOT] EXISTS, [NOT] UNIQUE ) <, >, <=, >=, =, <> 위연산자와 ANY, ALL, SOME의조합 다음은매니저가아닌직원을추출하는예이다. SELECT OBJECT(employee) FROM EmployeeBean AS employee WHERE employee.id NOT IN (SELECT employee2.id FROM ManagerBean AS employee2) 제 8 장 Entity Bean 117

136 다음은 Subquery 결과값이없는지테스트하는 NOT EXISTS 연산자의예이다 ("NOT" 은값이있는지를테스트하기위해제거될수있다 ). SELECT OBJECT(cust) FROM CustomerBean AS cust WHERE NOT EXISTS (SELECT order.cust_num FROM OrderBean AS order WHERE cust.num = order.cust_num) 위질의의결과는주문을하지않은모든고객의명단이된다. 마지막예는상호연관된 (correlated) 질의라고할수있는데, 그이유는 Subquery의결과가상위질의의파라미터로반영되어야하기때문이다. 의존관계가없는질의를비상호연관 (uncorrelated) 질의라고한다. 다음의예는 UNIQUE 연산자의사용을보여주고있다. 이연산자는 result set의 row 중중복된것이있는지를확인한다. 0개또는 1개의 row이거나, Subquery의결과내에있는모든레코드가유일하다면 TRUE 를리턴한다. 이연산자에 NOT을붙이면반대의결과를얻게된다. SELECT OBJECT(cust) FROM CustomerBean AS cust WHERE UNIQUE (SELECT cust2.id FROM CustomerBean AS cust2) 다음은 ">" 연산자의예로서, 다른연산자와마찬가지로 Subquery의결과값과사용될수있다. SELECT OBJECT(employee) FROM EmployeeBean AS employee WHERE employee.salary > (SELECT AVG(employee2.salary) FROM EmployeeBean AS employee2) 위의 JEUS EJB QL 질의는평균월급보다많이받는모든고용인의결과를리턴한다. 참고로 ANY, ALL, SOME이사용되지않는경우에는반드시한개의값만이 subquery의결과로리턴되어야한다 ( 이경우에서는평균월급 ). ANY, ALL, SOME 연산자는하나의값보다더많은값을리턴하는 Subquery에사용한다. 이연산작업은다음과같이해석할수있다. <Operand> <arithmetic operator> ANY <subquery> subquery의결과중적어도한개의값이 true를리턴하면 true를리턴한다. <Operand> <arithmetic operator> SOME <subquery> "ANY" 와같은의미를가진다. <Operand> <arithmetic operator> ALL <subquery> Subquery의결과모두가 true를리턴해야 true를리턴한다. 118 JEUS EJB 안내서

137 참고 XML DD 파일에 ">" 와 "<" 문자를넣으려할때는 CDATA 부분에포함시켜야한다. 그렇지않으면 XML Parser 가혼동을일으키고 XML 태그지정문자로인식한다. [ 예 8.12] XML DD 파일에 ">" 와 "<" 문자삽입 : <<ejb-jar.xml>> <query> <description>method finds large orders</description> <query-method> <method-name>findlargeorders</method-name> <method-params></method-params> </query-method> <ejb-ql> <![CDATA[SELECT OBJECT(o) FROM Order o WHERE o.amount > 1000]]> </ejb-ql> </query> JEUS EJB QL Extension ResultSet JEUS EJB 엔진은복수컬럼인 java.sql.resultset 객체를반환하는 ejbselect() 질의를지원한다. 그러므로 ejbselect 메소드의 SELECT 문안에콤마 (,) 로구분된 Target 필드의목록을지정할수있다. SELECT employee.name, employee.id, employee.salary FROM EmployeeBean AS employee 위의질의는모든 EmployeeBean Instance의 name, id, salary로구성된 java.sql.resultset을생성한다. 이 ResultSet은 "name", "id", "salary" 의컬럼으로구성된레코드를포함하게된다. 이 ResultSet의각레코드는해당하는 Entity Bean Instance를표현한다. ResultSet들은 <cmp-field> 값 (Bean이나 relationship filed가아닌 ) 만을반환한다. 참고 ejbselect() 메소드를사용해서 java.sql.resultset 종류의객체를얻어와모든작업을마쳤을때에는 ResultSet.close() 를호출해야한다. 이 close() 메소드는 EJB 엔진에의해자동적으로호출되지않는다. JEUS EJB QL Extension Dynamic Query JEUS EJB QL은 EJB QL 질의를프로그램적으로구현할수있도록지원한다. 이것은 Instant EJB QL 기능으로가능한것이다. 본절에서는 JEUS CMP 2.0에서 Instant EJB QL을프로그래밍할때필요한기본적인사항들을설명한다. 제 8 장 Entity Bean 119

138 다음코드에서는 CMP 2.0 Home Interface의 Instant EJB QL 사용법을보여주고있다. 이코드는순수하게클라이언트측의것이다. 이코드가작동되도록하려면 Instant EJB QL을사용하도록 CMP Bean에설정되어있어야한다. 이부분에대해서는 8.3. Entity EJB 설정 을참고한다. import jeus.ejb.bean.objectbase.ejbinstancefinder; import java.util.collection; Context initial = new InitialContext(); Object objref = initial.lookup("emp"); EmpHome home = (EmpHome) PortableRemoteObject.narrow(objref, EmpHome.class); EJBInstanceFinder finder = (EJBInstanceFinder) home; java.util.collection foundbeans = finder.findwithinstantql ( <EJB QL query sentence> ); // Use foundbeans collection 위예에서의 "<EJB QL query sentence>" 는파라미터없는완전한 EJB QL 문장으로대체되어야한다 ("?" 가허용되지않는다 ). 이 API에대해서는 Appendix B. Instant EJB QL API Reference 를참고한다. JEUS EJB QL Extension GROUP BY 키워드 JEUS EJB QL은 GROUP BY와 GROUP BY HAVING 절을지원한다. 이들은다음과같이작동한다. <SELECT statement> GROUP BY <grouping column(s)> SELECT 문장이실행되면레코드들이생성되고, GROUP BY 문장은 <grouping column(s)> 에지정된컬럼 ( 들 ) 의셋을검색한다. 같은값을갖는이컬럼 ( 들 ) 내의모든레코드들은하나의레코드로합쳐지고중복되는것들은버려진다. SELECT employee.departmentname FROM EmployeeBean AS employee GROUP BY employee.departmentname 위질의는 employee Bean의유일한모든 departmentname의목록을결과값으로가진다. <SELECT statement> GROUP BY <grouping column(s)> HAVING <condition> 이런형식의문장은이전에설명한예제와같은방식으로동작하지만, <condition> 에설정된것을만족시키는컬럼그룹만이포함된다. SELECT employee.departmentname FROM EmployeeBean AS employee GROUP BY employee.departmentname HAVING COUNT(employee.departmentName) >= 3 위의질의는 2개이상의 EmployeeBean Instance가발견된모든유일한 departmentname들의목록을반환한다 ( 즉, 3 이상의 employee들을가진 department의목록 ). 예를들어 [ 표 8.3] 의데이터에 EJB QL 질의를실행시키면 [ 표 8.4] 와같은결과가출력된다. 120 JEUS EJB 안내서

139 [ 표 8.3] EmployeeBean Instance 을위한 EJB 필드들 id johnsmith peterwright lydiajobs catherinepeters departmentname R&D R&D R&D Marketing [ 표 8.4] 결과 ResultSet departmentname R&D 이결과는 HAVING 조건이적어도 3 개의레코드를가진컬럼그룹을포함시켜야한다고명시되었기때문 이다. 더자세한 GROUP BY, GROUP BY HAVING 절에대한정보는 SQL 문서들을참고한다. 참고 JEUS EJB QL에서는 GROUP BY와 GROUP BY HAVING 문장을 Subquery 또는최상위의질의에서사용할수있다. 후자의경우에는 java.lang.string 객체의집합이리턴된다. 최상위의 GROUP BY 와 GROUP BY HAVING 문장은 Bean 객체를리턴할수없다 DB Insert Delay 설정 (CMP Only) CMP 에서 EJB 가생성될때 EJB 데이터가 backend DB 에기록되는시점을설정할수있다. 메소드 ejbcreate ejbpostcreate 설명 ejbcreate() 를실행후 ejbpostcreate() 를실행하기전에새로운 EJB 데이터를삽입한다. ejbcreate() 와 ejbpostcreate() 를완성한후에새로운 EJB 데이터를삽입한다. DB Insert Delay 설정은 jeus-ejb-dd.xml에서 <jeus-bean> 의 <database-insert-delay> 태그내에서구성된다. [ 예 8.13] DB Insert Delay 설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <database-insert-delay>ejbcreate</database-insert-delay> 제 8 장 Entity Bean 121

140 </jeus-bean> </beanlist> </jeus-ejb-dd> 8.4. Entity EJB 튜닝 본절에서는 JEUS의 Entity EJB 성능튜닝방법에대해서자세히설명한다. 본절에서제공하는튜닝방법들은 제4장 EJB의공통특성 과 제7장 Session Bean 의 "object manage ment" 에서제공한방법들과함께 Entity Bean에적용할수있다 공통 모든 Entity Bean의성능튜닝에공통적으로필요한설정은다음과같다. 엔진메인모드선택과클러스터링적용여부 Entity Cache 크기설정 -DB 벤더설정다음은모든 Entity Bean의성능튜닝을위한설명이다. 엔진메인모드선택과클러스터링적용여부 다음은 <engine-type> 을선택할때와몇개의 EJB 엔진에 EJB를클러스터링할지를선택할때주요판단기준이될수있는규칙을정리한표이다. [ 표 8.5] Entity Bean 엔진타입선택과클러스터링사용여부 Bean 당요청수많은 EJB 엔진다수의 CPU 적은 EJB 엔진 1 개이상의 CPU EJB 엔진 1 개 CPU 1 개 더많은 EJB 엔진을사용하도 자주사용 EJB를클러스터링하고, SIN GLE_OBJECT를사용한다. EJB 를클러스터링하고, MULTI PLE_OBJECT 를사용한다. 록한다. 그렇지않으면, 클러스터링하지말고, MULIT PLE_OBJECT 를사용한다. 보통으로사용 EJB를클러스터링하고, SIN GLE_OBJECT를사용한다. EJB 를클러스터링하고, MULTI PLE_OBJECT 를사용한다. EJB를클러스터링하지말고, EXCLUSIVE_ACCESS를사용한다. EJB 를클러스터링하지말고, EJB 를클러스터링하지말고, EJB 를클러스터링하지말고, 조금사용 EXCLUSIVE_ACCESS 를사용 EXCLUSIVE_ACCESS 를사용 EXCLUSIVE_ACCESS 를사 한다. 한다. 용한다. 122 JEUS EJB 안내서

141 물론 Entity Bean의 DB 데이터가외부의 WAS가아닌컴포넌트에의해변경되는환경에서는 SINGLE_OB JECT나 MULTIPLE_OBJECT를사용해야한다. 그리고 Failover를위해서는 Bean을클러스터링해야한다. SINGLE_OBJECT와 MULTIPLE_OBJECT 모드중하나를선택할때마지막으로고려해야할사항은대상 Bean의트랜잭션처리시간이다 ( 즉, Bean 내부에서트랜잭션이시작하고 commit되어끝날때까지의평균시간 ). 그시간이아주길면 MULTIPLE_OBJECT 모드를선택하기를권장하고, 이모드에서사용가능한동시성을사용해야한다. 그시간이반대로짧으면 SINGLE_OBJECT 모드사용을권장한다. 만약에위의 " 규칙 " 이준수되면 EJB 엔진은최적의성능으로 ejbload() 를호출할수있다. 참고 위의테이블에서사용된 " 자주사용되는 ", " 보통으로사용되는 ", " 조금사용되는 " 의의미를명확하게 정의할수없다. 약간의직관력과많은테스트가주어진환경에최적의설정을찾는방법일것이다. Entity Cache 크기설정 Entity Cache는 passivate된 Entity Bean Instance들의저장소역할을한다. Instance들은 Entity Bean이다시 Activate가되면 Cache에서나오게된다. <entity-cache-size> 크기를크게 ( 수백개의 Instance가수용되도록 ) 설정하면 passivate된 Bean들이다시 Activate될때새로운 Entity Bean Instance들이생성되지않아도되므로성능이좋아질것이다. 그러나메모리관리가가장중요한사항이라면이값을적게주거나아예사용하지않도록한다 ( 값이 '0' 이면 Entity Cache를사용하지않는다 ). DB 벤더설정 <db-vendor> 태그를올바르게설정한다. 모든경우는아니지만어떤상황에서는 Oracle과같은벤더의제품을위해서 EJB 엔진이 DB와의연결을최적화시킨다. 이태그에사용할수있는 DBMS 벤더의이름값들은 "JEUS XML Reference" 의 " 제11장.domain.xml EJB 엔진설정 " 을참고한다 BMP & CMP 1.1 다음은 BMP 와 CMP 1.1 튜닝에대한설명이다. Non-modifying 메소드등록 DB에표현된상태정보를변경하지않는 Entity Bean의모든업무메소드들은 JEUS EJB 모듈 DD의 <nonmodifying-method> 태그에등록되어야한다. 이렇게하면 EJB 엔진이 ejbstore() 를호출하지않아효율적으로운영될수있다. 이튜닝은 BMP와 CMP 1.1 Bean에게만적용할수있다. 제 8 장 Entity Bean 123

142 CMP 1.1/2.0 다음은 CMP 1.1/2.0 튜닝에대한설명이다. 엔진 Sub-mode 선택 CMP Bean을사용할때 <subengine-type> 을선택하면 EJB 엔진이 ejbload(), ejbfind() 메소드를최적화해서사용할수있다. <subengine-type> 을선택하는주요기준은다음과같다. CMP Bean이읽기작업을쓰기작업보다더많이할것이라예상되면 ReadLocking 모드를사용한다. CMP Bean이쓰기작업을읽기작업보다더많이할것이라예상되면 WriteLocking 또는 WriteLockingFind 모드를사용한다. Fetch Size 설정 시스템메모리의과용을감수하더라도높은성능을원한다면 CMP Bean의 <fetch-size> 태그를시스템메모리의과용을감수하더라도높은성능을원한다면높게설정해야한다. 큰값을설정하면매호출마다많은양의데이터를읽어오기때문에네트워크를효과적으로사용할수있다. 그러나 EJB 엔진은많은양의데이터를 Caching해야하기때문에시스템자원을많이소모하게되어각호출에대한대기시간이증가한다. 반대의경우만약시스템메모리의절약이높은우선순위를가지고느린네트워크속도를감수할수있다면이값을상대적으로낮게설정한다. 기본값은 "10" 이다. 대부분의경우 "100" 은높은값이고 "10" 보다낮은값은낮은값으로생각할수있다. Initial Caching 설정 높은운영성능을위해많은시스템메모리사용을감수할수있다면, CMP Bean의 <init-caching> 값을 true로설정한다. 이렇게설정하면 EJB 엔진이기동 (Booting) 할때모든 DB의레코드들이읽혀져 Entity Bean Instance로전달된다. 결과적으로엔진기동 (Booting) 시간이오래걸리겠지만, 처음의접근시간을훨씬줄일수있다. 반대의경우만약시스템메모리의절약또는빠른엔진기동 (Booting) 시간이우선이라면이값은 false로설정해야한다. 만약 DB 테이블이 EJB에아주많이매핑되어있는경우 ( 수백, 수천레코드 ) 에는 <initcaching> 가 false로설정되어야할것이다. 그러나 EJB가 read-only(ejbload() 가한번만호출되는것을암시 ) 라면이옵션을강력히추천한다 CMP 2.0 CMP 2.0 튜닝을위해서 EJB QL 사용하는데 EJB QL 은효율적이지않으므로간단한경우에만사용하도 록한다. 124 JEUS EJB 안내서

143 8.5. 완전한 CMP 2.0 Entity Bean 예제 EJB 코드, 표준 EJB DD, JEUS DD가함께설정되고작동될수있는지보여주기위해본절에서는완전한 CMP 2.0 Bean의예를제시한다. 이예제는책을개념으로모델화한 Book EJB이다. 기본적으로모든예에주석을달지않았고 CMP 2.0 Bean이 jeus-ejb-dd.xml에설정하는방법만보여준다. 예제를 deploy하려면패키징후에 EJB로 deploy한다. 자세한내용은 제3장 EJB 모듈 을참고한다. JEUS의 ejb-jar.xml에서 EJB QL 사용예는본절의절 8.5. Java EE EJB DD 를참고한다. Remote Interface [ 예 8.14] Remote Interface : <<Book.java>> package test.book; import java.rmi.remoteexception; import javax.ejb.ejbobject; public interface Book extends EJBObject { } public String gettitle() throws RemoteException; public void settitle(string title) throws RemoteException; public String getauthor() throws RemoteException; public void setauthor(string author) throws RemoteException; public double getprice() throws RemoteException; public void setprice(double price) throws RemoteException; public String getpublisher() throws RemoteException; public void setpublisher(string publisher) throws RemoteException; public String tobookstring() throws RemoteException; Home Interface [ 예 8.15] Home Interface : <<BookHome.java>> package test.book; import java.rmi.remoteexception; import javax.ejb.createexception; import javax.ejb.finderexception; import javax.ejb.ejbhome; import java.util.*; 제 8 장 Entity Bean 125

144 public interface BookHome extends EJBHome { } public Book create(string code, String title, String double price, String publisher) throws CreateException, RemoteException; public Book findbyprimarykey(string code) throws FinderException, RemoteException; public Collection findbytitle(string title) throws FinderException, RemoteException; public Collection findinrange(string from, String to) throws FinderException, RemoteException; public Collection findall() throws FinderException, RemoteException; author, Bean Implementation [ 예 8.16] Bean Implementation : <<BookEJB.java>> package test.book; import javax.ejb.entitybean; import javax.ejb.entitycontext; public abstract class BookEJB implements EntityBean { public String ejbcreate(string code, String title, String author, double price, String publisher) { setcode(code); settitle(title); setauthor(author); setprice(price); setpublisher(publisher); return null; } public void ejbpostcreate(string code, String title, String author, double price, String publisher) {} public abstract String getcode(); public abstract void setcode(string code); public abstract String gettitle(); public abstract void settitle(string title); public abstract String getauthor(); 126 JEUS EJB 안내서

145 public abstract void setauthor(string author); public abstract double getprice(); public abstract void setprice(double price); public abstract String getpublisher(); public abstract void setpublisher(string publisher); public String tobookstring() { return getcode() + "- [" + gettitle() + "] by " + getauthor() + " " + getprice() + " " + getpublisher(); } } public BookEJB() {} public void setentitycontext(entitycontext ctx) {} public void unsetentitycontext() {} public void ejbload() {} public void ejbstore() {} public void ejbactivate() {} public void ejbpassivate() {} public void ejbremove() {} Java EE EJB DD [ 예 8.17] Java EE EJB DD : <<ejb-jar.xml>> <?xml version="1.0"?> <ejb-jar version="3.1" xmlns=" xmlns:xsi=" xsi:schemalocation=" <enterprise-beans> <entity> <ejb-name>bookbean</ejb-name> <home>test.book.bookhome</home> <remote>test.book.book</remote> <ejb-class>test.book.bookejb</ejb-class> <persistence-type>container</persistence-type> <prim-key-class>java.lang.string</prim-key-class> <reentrant>false</reentrant> <cmp-version>2.x</cmp-version> <abstract-schema-name>book</abstract-schema-name> <cmp-field><field-name>code</field-name></cmp-field> <cmp-field><field-name>title</field-name></cmp-field> <cmp-field><field-name>author</field-name></cmp-field> 제 8 장 Entity Bean 127

146 <cmp-field><field-name>price</field-name></cmp-field> <cmp-field><field-name>publisher</field-name></cmp-field> <primkey-field>code</primkey-field> <query> <query-method> <method-name>findbytitle</method-name> <method-params> <method-param> java.lang.string </method-param> </method-params> </query-method> <ejb-ql> SELECT OBJECT(b) FROM Book b WHERE b.title =?1 ORDERBY b.price </ejb-ql> </query> <query> <query-method> <method-name>findinrange</method-name> <method-params> <method-param> java.lang.string </method-param> <method-param> java.lang.string </method-param> </method-params> </query-method> <ejb-ql> SELECT OBJECT(b) FROM Book b WHERE b.title BETWEEN?1 AND?2 </ejb-ql> </query> <query> <query-method> <method-name>findall</method-name> <method-params/> </query-method> <ejb-ql> SELECT OBJECT(b) ORACLEHINT '/*+ALL_ROWS*/' FROM Book b </ejb-ql> </query> </entity> </enterprise-beans> <assembly-descriptor> 128 JEUS EJB 안내서

147 <container-transaction> <method> <ejb-name>bookbean</ejb-name> <method-name>*</method-name> <method-params/> </method> <trans-attribute>required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar> 참고 굵은글자의 3 줄이비표준의 JEUS 전용 EJB QL 이다 ("ORDERBY", "BETWEEN", "ORACLEHINT"). JEUS EJB DD [ 예 8.18] JEUS EJB DD : <<jeus-ejb-dd.xml>> <?xml version="1.0"?> <jeus-ejb-dd xmlns=" <module-info/> <beanlist> <jeus-bean> <ejb-name>bookbean</ejb-name> <export-name>book</export-name> <export-port>0</export-port> <export-iiop><only-iiop>false</only-iiop></export-iiop> <persistence-optimize> <engine-type>exclusive_access</engine-type> <non-modifying-method> <method-name>gettitle</method-name> </non-modifying-method> <non-modifying-method> <method-name>getauthor</method-name> </non-modifying-method> <non-modifying-method> <method-name>getprice</method-name> </non-modifying-method> <non-modifying-method> <method-name>getpublisher</method-name> </non-modifying-method> <non-modifying-method> <method-name>tobookstring</method-name> </non-modifying-method> 제 8 장 Entity Bean 129

148 </persistence-optimize> <schema-info> <table-name>booktable</table-name> <cm-field><field>code</field></cm-field> <cm-field><field>title</field></cm-field> <cm-field><field>author</field></cm-field> <cm-field><field>price</field></cm-field> <cm-field><field>publisher</field></cm-field> <creating-table> <use-existing-table/> </creating-table> <deleting-table>true</deleting-table> <db-vendor>oracle</db-vendor> <data-source-name>datasource1</data-source-name> </schema-info> <enable-instant-ql>true</enable-instant-ql> </jeus-bean> </beanlist> </jeus-ejb-dd> 130 JEUS EJB 안내서

149 제 9 장 Message Driven Bean(MDB) 본장에서는 EJB 엔진에서 MDB(Message Driven Bean) 를사용할때유의해야할사항들을설명한다 개요 EJB 엔진은 MDB Instance들을동시에여러개실행시킬수있으며, 또한 message stream을처리할수도있다. EJB 엔진은 MDB 클래스에도착하는메시지들의순서를보장하지않으므로받은순서대로메시지를전달하지못하고임의로메시지를전달한다. MDB도처리순서를보장하지않는다. 예를들어예약을하는메시지가도착하기전에예약을취소하는메시지가먼저올수있기때문에설계할때처리순서에대해고려해야한다. 이런동시처리는 Bean Pool이 MDB에서 Instance를가져와서 Request에할당함으로써처리된다. 이는 Stateless Session Bean의 TTP(Thread Ticket Pool) 의동작법과거의동일하다. 따라서 MDB에서는 <thread-max> 값이아닌 <pool-max> 값을사용해야한다. 이에대해서는 제7장 Session Bean 을참조한다 MDB 설정 EJB 엔진이 MDB를실행하기위해서는약간의설정이필요하다. MDB는고유의설정외에 JEUS의다른 EJB와공통되는설정도가지고있다. 본절에서는다음항목을간략하게설명한다. JEUS EJB DD의기본 MDB 설정 ( 제4장 EJB의공통특성 에서설명한설정들의하위항목 ) JEUS EJB DD 파일에설정되어있는 JEUS MDB의 JMS 전용설정 참고 MDB 설정은 MDB 를잘알고있는이들에게는별도로설명할필요가없다 기본환경설정 MDB는다른 EJB 종류와유사한기본설정을사용한다. 각 MDB에설정할수있는것들은 <ejb-name>, <run-as identity>, <security-interop> 등이있다. 다음은 MDB의기본설정예제이다. 제 9 장 Message Driven Bean(MDB) 131

150 [ 예 9.1] 기본환경설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <ejb-name>order</ejb-name> <!--JMS settings goes here (see JMS 설정 )--> <run-as-identity> </run-as-identity> <security-interop> </security-interop> <env> </env> <ejb-ref> </ejb-ref> <res-ref> </res-ref> <res-env-ref> </res-env-ref> <!-- No clustering of MDB --> </jeus-bean> </beanlist> </jeus-ejb-dd> JMS 설정 MDB가처리하는메시지에따라성격이달라진다. JMS 메시지를처리하는경우에는 JMS Connection Factory의 export name이필요하고 Connector 메시지를처리하는경우에는리소스어댑터가필요하다. 다음은 MDB 클래스의 Annotation으로설정한것과그에대응되는 XML 문서의일부이다. [ 예 9.2] JMS 설정 : activationconfig = 132 JEUS EJB 안내서

151 propertyvalue="auto-acknowledge") }, mappedname = "jms/queue1" ) public class MyMDB implements MessageListener {... } [ 예 9.3] JMS 설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <ejb-name>mymdb</ejb-name> <connection-factory-name> QueueConnectionFactory </connection-factory-name> <destination>jms/queue1</destination> <max-message>15</max-message> <activation-config> <activation-config-property> <activation-config-property-name> destinationtype </activation-config-property-name> <activation-config-property-value> javax.jms.queue </activation-config-property-value> </activation-config-property> <activation-config-property> <activation-config-property-name> acknowlegemode </activation-config-property-name> <activation-config-property-value> Auto-acknowledge </activation-config-property-value> </activation-config-property> </activation-config> </jeus-bean> 제 9 장 Message Driven Bean(MDB) 133

152 </beanlist> </jeus-ejb-dd> 다음은설정태그에대한설명이다. <connection-factory-name> JMS Connection Factory가사용할 JNDI export name을설정한다. 이설정은여러곳에서설정가능하고우선순위는다음과같다. 1. jeus-ejb-dd.xml/<jeus-bean>/<connection-factory-name> 2. jeus-ejb-dd.xml/<jeus-bean>/<activation-config> property name : jeus.connectionfactoryname property name : jeus.connectionfactoryname <mdb-resource-adapter> JEUS Connector를통해메시징시스템과연결될경우사용하는리소스어댑터를설정한다. 해당리소스어댑터의 jeus-connector-dd.xml에지정되어있는모듈의 id를설정하여사용한다. <destination> JMS Destination의 JNDI 이름을설정한다. 이설정은여러곳에서설정가능하고우선순위는다음과같다. 1. jeus-ejb-dd.xml/<jeus-bean>/<destination> 2. ejb-jar.xml의 <message-driven>/<mapped-name> mappedname 4. ejb-jar.xml의 <message-driven>/<message-destination-link> <jndi-spi> MDB가기본값 (jeus.jndi.jnscontextfactory) 이아닌다른 JNDI 이름서비스에등록되어있는 JMS 서비스를사용할때즉, JEUS MDB를 IBM MQ나 SONIC MQ같은 JEUS JMS 서비스이외의것과연결할때사용한다. <max-messages> 여러개의 JMS 세션을등록해서처리할경우한세션에메시지를할당하는최대개수를지정할때사용한다. 큐에쌓인메시지수가설정된값보다적으면하나의세션이계속처리하며쌓인메시지가이값을넘어가면그때다른세션을사용한다. 즉, 이값이 10일경우메시지수가 10개를넘을때까지는하나의세션만이메시지를처리한다. 이는 load를줄이기위한것이며자세한것은 JMS 스펙을참고한다. <activation-config> 134 JEUS EJB 안내서

153 JMS나리소스어댑터를설정할 activation config로 ejb-jar.xml의 activation config를 override하는경우에사용한다. JMS MDB의경우에는 acknowledgemode, messageselector, destinationtype, subscriptiondurability 의기본적으로인식된다. 추가적으로위에서말한 jeus.connectionfactoryname와 jeus.clientid, jeus.subscriptionname을사용할수있다. jeus.clientid와 jeus.subscriptionname은 Topic의 Durable Subscription을위해제공되고만약이값들이설정되지않으면 " 모듈이름 "/"Bean 이름 " 으로설정된다. 이설정은여러곳에서설정가능하고우선순위는다음과같다. 1. jeus-ejb-dd.xml의 <activation-config> 2. ejb-jar.xml의 <activation-config> <ack-mode> JMS 세션의 Acknowlege 모드를설정한다. 이설정은여러곳에서설정가능하고우선순위는다음과같다. 1. jeus-ejb-dd.xml/<jeus-bean>/<ack-mode> 2. jeus-ejb-dd.xml/<jeus-bean>/<activation-config> property name : acknowlegemode 3. ejb-jar.xml/<message-driven-bean>/<activation-config> property name : acknowlegemode 4. ejb-jar.xml/<message-driven-bean>/<acknowledge-mode> property name : acknowledgemode <durable> JMS의 Durable Subscriber를설정한다. 이설정은여러곳에서설정가능하고우선순위는다음과같다. 1. jeus-ejb-dd.xml/<jeus-bean>/<durable> 2. jeus-ejb-dd.xml/<jeus-bean>/<activation-config> property name : subscriptiondurablity 3. ejb-jar.xml/<message-driven-bean>/<activation-config> property name : subscriptiondurablity 4. ejb-jar.xml/<message-driven-bean>/<subscription-durability> property name : subscriptiondurablity <msg-selector> JMS의 message selector를설정한다. 이설정은여러곳에서설정가능하고우선순위는다음과같다. 1. jeus-ejb-dd.xml/<jeus-bean>/<msg-seletor> 제 9 장 Message Driven Bean(MDB) 135

154 2. jeus-ejb-dd.xml/<jeus-bean>/<activation-config> property name : messageselector 3. ejb-jar.xml/<message-driven-bean>/<activation-config> property name : messageselector 4. ejb-jar.xml/<message-driven-bean>/<message-selector> property name : messageselector 참고 위의설정에대한자세한내용은 "JEUS MQ 안내서 ", "JEUS JCA 안내서 ", "JMS 표준 ", "EJB 표준 " 을 참고한다 JNDI SPI 환경설정 기본적으로 JEUS MDB는 JEUS Naming Service로 JMS의 connection을 lookup해서사용한다. 만약다른 JMS 서비스 (IBM MQ나 SONIC MQ) 를이용하는경우다른서비스에서 connection을얻어야한다. 이런경우는 JMS 서비스를포함한외부 Naming Service를사용하는 MDB를설정할수있다. MDB 가 JMS 서비스를찾기위해각각의 MDB에 <jndi-spi> 를설정한다. 다음은 JNDI SPI 환경설정에대한예제이다. [ 예 9.4] JNDI SPI 환경설정 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <jndi-spi> <mq-vendor>sonicmq</mq-vendor> <initial-context-factory> acme.jndi.acmecontextfactory </initial-context-factory> <provider-url> protocol://localhost:2345 </provider-url> </jndi-spi> </jeus-bean> </beanlist> </jeus-ejb-dd> 136 JEUS EJB 안내서

155 다음은 <jndi-spi> 하위의설정태그에대한설명이다. 태그 <mq-vendor> <initial-context-factory> <provider-url> 설명 MDB가 connection을맺을 MQ/JMS의벤더의이름이다 (JNDI naming 서비스를통해설정 ). 'IBMMQ' 와 'SONICMQ' 가공식적인지원벤더이다. Naming Server를위한 JNDI InitialContext Factory 클래스의이름을사용해서 JMS 서비스에연결된다. 요청에의해서 Naming Service에접속할때사용하는 URL이다. 제 9 장 Message Driven Bean(MDB) 137

156

157 제 10 장 EJB Timer Service EJB Timer Service 는 EJB 가특정한시간또는주기적으로 callback 을받을수있도록하는서비스이다. 기본적인사용방법은 EJB 스펙에설명되어있으므로본장에서는 JEUS EJB 에서제공하는 Timer Service 와이를사용하기위한설정에대해서설명한다 Timer Service 의설정 JEUS EJB Timer Service는기본적으로스펙을따르지만 persistence하게타이머를관리하는기능은성능과사용자의필요에따라선택적으로사용할수있다. Timer Service는다음의 2개의설정을한다. EJB 엔진의 Timer Service Timer Service를사용하는모든 Bean에적용되는공통적인설정과 persistence한 Timer Service를가능하게하는설정이다. jeus-ejb-dd.xml 각 Bean이 deploy 또는 undeploy될때 Persistent 타이머들을어떻게관리하는방법에대해설정한다 Persistent Timer Service 설정 (EJB 엔진 ) WebAdmin을사용하여 EJB 엔진의 Persistent Timer Service를설정할수있다. 1. WebAdmin의 [Servers] 메뉴를선택하면서버목록조회화면으로이동한다. 서버목록에서원하는서버를선택하면서버설정화면으로이동한다. 서버설정화면에서 [Engine] > [Ejb Engine] > [Timer Service] 를선택한다. 2. [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. Timer Service 설정화면에서기본정보와고급선택사항의항목을설정한후 [ 확인 ] 버튼을클릭한다. 제 10 장 EJB Timer Service 139

158 [ 그림 10.1] Persistent Timer Service 설정 - 기본설정 다음은고급선택사항에서 Persistent Timer Service 를설정한예이다. [ 그림 10.2] Persistent Timer Service - 고급선택사항 각설정항목대한설명은다음과같다. Thread Pool Timer Service 가 timeout() 메소드를실행할때사용하는 Thread Pool 에대한설정이다. 항목 Min Max Period 설명 Pooling되는스레드의최솟값이다. Pooling되는스레드의최댓값이다. Pooling되는스레드를정리하는시간이다. 140 JEUS EJB 안내서

159 Database Setting Persistent Timer Service를사용한다면반드시설정해야하는항목이다. Persistent Timer는 DB를사용하기위해내부적으로 CMP Bean을사용하므로이 CMP Bean이아래항목들을통해설정된다. 따라서각항목은 CMP Bean의스키마설정과같다. 항목 Db Vendor Data Source Id 설명 Timer CMP Bean 이사용하는 DB 의벤더를지정한다. Timer CMP Bean 이사용하는데이터소스리소스의이름을지정한다. 4. 설정내용의동적반영을위해 [Activate Changes] 버튼을클릭한다 Persistent Timer 처리 (jeus-ejb-dd.xml) Persistent Timer Service를사용하도록 EJB 엔진에설정되어있을때사용자는각 EJB Bean별로 Persistent Timer Service를사용할지, deploy하기전에 DB에남아있는 Persistent Timer를사용할지제거할지등의동작을설정할수있다. 이는 jeus-ejb-dd.xml을통해서설정한다. 참고 Persistent Timer Service 의설정은 WebAdmin 에서가능하다. WebAdmin 에서의설정방법에대한 자세한내용은 Persistent Timer Service 설정 (EJB 엔진 ) 을참고한다. 다음은 jeus-ejb-dd.xml에 Persistent Timer 처리를설정한예제로, <jeus-bean> 의 <timer-service> 태그내에설정한다. [ 예 10.1] Persistent Timer의처리 : <<jeus-ejb-dd.xml>> <jeus-ejb-dd> <beanlist> <jeus-bean> <timer-service> <support-persistence> true </support-persistence> </timer-service> </jeus-bean> </beanlist> 제 10 장 EJB Timer Service 141

160 </jeus-ejb-dd> 다음은설정태그에대한설명이다. 태그 <support-persistence> 설명 해당 Bean 의타이머를 persistent 하게관리할것인지를결정한다 Cluster-Wide Timer Service 설정 클러스터의경우에는모든 EJB 엔진이동일한 EJB Timer Service를사용해야하므로공통된설정을해야한다. 따라서각 MS에설정된값은무시된다. WebAdmin을사용하여 Cluster-Wide Timer Service를설정할수있다. 방법은다음과같다. 1. WebAdmin의 [Clusters] 메뉴를선택하면클러스터목록조회화면으로이동한다. 클러스터목록에서원하는클러스터를선택하면클러스터설정화면으로이동한다. 2. [LOCK & EDIT] 버튼을클릭해서설정변경모드로전환한다. 3. 클러스터설정화면에서 Cluster Wide Timer Service 영역의항목을설정하고 [ 확인 ] 버튼을클릭한다. [ 그림 10.3] Cluster-Wide Timer Service 설정 각설정항목에대한설명은 Persistent Timer Service 설정 (EJB 엔진 ) 의 'Database Setting' 항목과동일하다. 4. 설정내용의동적반영을위해 [Activate Changes] 버튼을클릭한다. 142 JEUS EJB 안내서

161 10.2. 타이머모니터링 WebAdmin 과콘솔툴을사용하여동작중인 EJB 타이머에대한모니터링및동작취소가가능하다. WebAdmin 사용 WebAdmin을사용한모니터링및동작취소방법은다음과같다. 모니터링 WebAdmin에서 [Monitoring] > [EJB Timer] 를선택하면 EJB Timer 화면으로이동한다. 동작중인 EJB 타이머의목록과정보가다음과같이조회된다. [ 그림 10.4] Timer 모니터링 제 10 장 EJB Timer Service 143

162 동작취소 EJB Timer 화면에서특정타이머또는 'command' 컬럼의 [cancel] 버튼을클릭하면동작중인타이머를취소할수있다. 다음은 [cancel] 버튼을클릭하여 EJB 타이머가동작취소된화면이다. [ 그림 10.5] 타이머동작취소 콘솔툴사용 타이머의모니터링및동작취소는콘솔툴을사용할수도있다 모니터링 ejb-timer-info 명령을사용해서특정서버의 EJB 타이머정보를확인할수있다. ejb-timer-info -server <server-name> 동작취소 cancel-ejb-timer 명령을사용해서특정서버의 EJB 타이머를취소할수있다. cancel-ejb-timer -server <server-name> 참고 위의 2 가지명령및 EJB 엔진관련명령어에대한자세한내용은 JEUS Reference Book 의 EJB 엔진관련명령어 를참고한다. 144 JEUS EJB 안내서