내용 목차
본 장에서는 JEUS에서의 EJB 공통 특성에 대해 설명한다.
EJB 표준에 언급된 내용은 설명하지 않고, JEUS에서 EJB를 사용하기 위해 필요한 추가적인 정보들만 제공한다. 또한 EJB deploy에 대해 언급하지 않으므로 “제3장 EJB 모듈”의 내용을 먼저 참조한다.
본 절에서는 EJB의 종류와 각 종류별 DD 설정에 대해서 설명한다.
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의 사용을 권장하지 않지만 하위 호환성을 위해 계속 지원하고 있다.
JEUS EJB DD(Deployment Descriptors)는 jeus-ejb-dd.xml로 명명된 XML 파일이며, EJB JAR 파일의 META-INF 하위에 존재한다. JEUS EJB DD에 대한 간단한 내용은 “제3장 EJB 모듈”을 참고한다.
다음은 JEUS EJB DD로 설정 가능한 기능들과 컴포넌트들의 간략한 정보를 나타낸다("@" 표시는 Annotation으로도 설정 가능한 개체이다). 표의 왼쪽에 나열된 항목들은 실제 설정 가능한 JEUS EJB DD의 XML 태그들이다. 표의 나머지 6개 열은 EJB 종류에 따른 설정 사항들을 나타낸다.
[표 4.1] JEUS EJB의 설정 가능한 특징들과 컴포넌트들
위의 표는 다음과 같이 나누어 진다.
항목 1부터 16까지는 6개의 EJB 종류 모두에 공통으로 적용되는 사항이다(MDB의 2~5과 14~16은 제외). 이 모든 항목들에 대해서 본 장에서 설명한다.
항목 7(Run-as Identify)과 8(security interoperability), 14(clustering)은 모든 EJB 종류에 공통이지만, 각각 “4.2.6. EJB 보안 설정”, “제5장 EJB 상호 운용성 및 RMI/IIOP”, “제6장 EJB 클러스터링”에서 별도로 설명한다.
항목 17은 Stateful Session Bean에 대해서만 적용되며, “제7장 Session Bean”에서 자세히 설명한다.
항목 18(object management)은 6개의 EJB 종류 모두에 공통으로 적용되는 사항이나 Bean의 종류에 따라 조금씩 다르므로 기본적인 것은 “제7장 Session Bean”에서 설명하고 각 장에서 차이점을 설명한다.
항목 19부터 22까지는 Entity Bean에만 적용된다. 이들은 “제8장 Entity Bean”에서 설명한다.
항목 23부터 28까지는 MDB에만 적용된다. 이들은 “제9장 Message Driven Bean(MDB)”에서 설명한다.
항목 29는 EJB 스펙에서 제공하는 타이머 서비스를 사용할 수 있는 Bean(Stateful Session Bean을 제외한 모든 Bean)에 사용할 수 있다. 이는 “제10장 EJB Timer Service”에서 설명한다.
모든 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에서 <ejb-name> 또는 구현 클래스의 @Stateless, @Stateful, @MessageDriven의 "name" 값과 동일한 이름이다.
<export-name>
글로벌 JNDI에 등록될 시스템 내부에서 유일한 이름을 가져야 한다.
DD 파일에 이 element가 없는 경우 Annotation @Stateless나 @Stateful의 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가 실패한다.
순위는 다음과 같다.
jeus-ejb-dd.xml의 <export-name>
ejb-jar의 <mapped-name>
@EJB의 mappedName
기본값인 Remote Business Interface의 클래스 이름(패키지명 포함)
<local-export-name>
JNDI에 등록될 시스템 내부의 유일한 이름을 가져야 한다.
DD 파일에 이 element가 없는 경우 Annotation @EJB 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이 발생한다.
순위는 다음과 같다.
jeus-ejb-dd.xml의 <local-export-name>
Remote Business Interface가 존재하면 ejb-jar.xml의 <mapped-name>+ _Local
Remote Business Interface가 존재하지 않으면 ejb-jar.xml의 <mapped-name>
Remote Business Interface가 존재하면 @EJB의 mappedName + _Local
Remote Business Interface가 존재하지 않으면 @EJB의 mappedName
기본값인 Local Business Interface의 클래스 이름(패키지명 포함)
<export-port>
RMI 서비스 포트를 명시적으로 설정할 필요가 있을 때에 이 설정을 사용한다.
방화벽을 사용하고 있어서 특정 포트로만 시스템 접근을 허용할 경우에 유용하다. 이 태그의 설정은 방화벽 설정의 “allowed”로 설정된 포트와 동일한 것이어야 한다. 값을 지정하지 않는 경우는 시스템 프로퍼티에 따라 일괄적으로 포트가 적용되는데 정리하면 다음과 같다.
항목 | 설명 |
---|---|
jeus.ejb.exportPort | jeus-ejb-dd에 특정 EJB에 대한 <export-port>가 지정되어 있지 않는 나머지 EJB의 export port를 결정한다. |
jeus.rmi.usebaseport | 값이 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 ejb.basic.statefulSession;
@Stateful(name="counter", 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>
<export-iiop/>
. . .
</jeus-bean>
. . .
</beanlist>
. . .
</jeus-ejb-dd>
다음은 EJB Thread Ticket Pool(이하 TTP)의 개념을 나타낸 그림이다.
기본적인 동작은 클라이언트로부터 요청을 받으면 새로운 RMI 스레드를 클라이언트 요청에 부여하는 것이다. 이때 부여된 RMI 스레드의 수가 설정된 최댓값보다 많은 경우에는 해당 요청에 스레드를 부여하지 않고 대기한다.
위 그림에서 볼 수 있듯이 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분이 초과할 경우 시간 초과로 RemoteException을 던진다.
EJB 처리가 끝나거나(Stateless Session Bean) Connection 타임아웃이 발생하여 클라이언트가 연결을 잃을 경우에 TTP로 TT가 반환된다. 그리고 TTP는 원격 호출이 가능한 EJB 컴포넌트마다 하나씩 가지고 있다. 이 외에도 Connection Pool과 Bean Pool이 있다. MDB에서는 TTP가 아닌 Bean Pool을 설정한다.
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>
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> 태그는 다음의 하위 태그를 설정해야 한다.
태그 | 설명 |
---|---|
<name> | env의 이름으로 ejb-jar.xml에 정의된 <env-entry-name> 태그의 값과 같은 값을 사용한다. |
<type> | 값의 자료형에 해당하는 완전한 Java 클래스 이름으로 기본 자료형은 wrapper 클래스를 사용한다. |
<value> | env의 실제 값을 선언한다. |
다른 태그들(<ejb-ref>, <res-ref>, <res-env-ref>)은 여러 개의 <jndi-info> 태그를 가진다. 이 태그들은 또 JNDI export name에 reference를 매핑하기 위해서 다음과 같은 하위 태그를 설정해야 한다.
<ref-name>과 <export-name> 태그는 반드시 ejb-jar.xml에 설정된 이름과 같은 값이어야 한다.
다음은 External Reference를 JNDI로 매핑하는 방법으로, Annotation과 XML의 예이다.
[예 4.4] External Reference를 JNDI로 매핑 : <<CounterEJB.java>>
@Stateful @EJB(name="AccountEJB", beanInterface=ejb.Account.class, mapppedName="ACCEJB") @Resource(name="jdbc/DBDS", type=javax.sql.DataSource.class, mappedName="ACCOUNTDB") public class CounterEJB implements Counter{ @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> </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>
EJB 모듈 중 특정 EJB에 HTTP invocation을 설정하고 사용하기 위해서는 jeus-ejb-dd.xml의 <jeus-bean> 하위에 <invoke-http>를 설정해야 한다. EJB 엔진에서 HTTP invocation이 필요하면 domain.xml의 ejb-engine에 <invoke-http>를 추가한다(“제2장 EJB 엔진”에서 언급). 이 설정은 모든 모듈에 적용되는데, 각 모듈의 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>
<invoke-http> 설정에는 2개의 하위 태그가 존재한다.
HTTP invoke가 정상적으로 작동하기 위해선 RMI 핸들러 서블릿이 deploy되어 있어야 한다. RMI 핸들러 서블릿을 구현한 클래스는 jeus.rmi.http.ServletHandler이다. jeus.rmi.http.ServletHandler는 context 내에 <invoke-http>에 설정된 URL과 동일하게 deploy되어야 한다. deploy에 대한 자세한 내용은 "JEUS Web Engine 안내서"를 참조한다.
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"을 참고한다.
본 절에서는 JEUS에서 EJB를 위한 보안 설정 방법에 대해 설명한다. 여기에서 사용된 보안은 인증과 권한 부여를 의미한다.
JEUS EJB의 보안 설정과 관련된 항목은 다음과 같다.
EJB 모듈의 역할 할당(Role Assignment)
EJB Run-as Identify 설정
EJB 설정에서 사용하는 실제 JEUS 사용자 목록은 accounts.xml에 정의되어 있다. 이에 대한 설정은 "JEUS Security 안내서"를 참고한다.
다음은 상황별 보안 설정하는 방법에 대한 설명이다.
EJB 모듈의 역할 할당 설정은 표준 ejb-jar.xml 파일에 개발자가 정의한 역할과 실제 JEUS 보안 도메인의 principal와 group name을 매핑하는 것이다. 이는 jeus-ejb-dd.xml 파일의 <module-info>의 <role-permission> 태그에서 설정한다.
다음은 역할 할당을 설정한 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>
다음은 설정 하위 필수 태그에 대한 설명이다.
Run-as Identify 설정은 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] 보안 설정 : <<CustomerBean.java>>
@Stateless(name="CustomerEJB")
@RolesAllowed("CUSTOMER")
public class CustomerBean implementes Customer {
...
}
[예 4.11] 보안 설정 : <<EmployeeServiceBean.java>>
@Stateful(name="EmployeeService")
@RunAs("ADMIN")
public class EmployeeServiceBean implements EmployService{
...
}
[예 4.12] 보안 설정 : <<ejb-jar.xml>>
<?xml version="1.0"?> <ejb-jar version="3.1" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"> <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> </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="http://www.tmaxsoft.com/xml/ns/jeus"> <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="http://www.tmaxsoft.com/xml/ns/jeus"> <users> <user> <name>customer</ name> <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" 역할과 연관되어
있다.
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 about the EJB module [countermod].
==============================================================
+-------------+----------------------------------------------+
| Module Name | Unique Module Name |
+-------------+----------------------------------------------+
| countermod | countermod |
+-------------+----------------------------------------------+
==============================================================
Beans
================================================================================
+-----------+-------------------------+-------------------+--------------------+
| Bean Name | Type | Local Export Name | Remote Export Name |
+-----------+-------------------------+-------------------+--------------------+
| Count | StatelessSessionBean | | Count |
+-----------+-------------------------+-------------------+--------------------+
================================================================================
다음과 같이 명령을 실행하면 지정한 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) | | | |
+---------------+-----------+-------------------+--------------+---------------+
| comitted | transactio| | | |
| |n(0) | | | |
+---------------+-----------+-------------------+--------------+---------------+
| total-remote-t| |thread(100:100:100)| | |
|hread | | | | |
+---------------+-----------+-------------------+--------------+---------------+
| timed-rb | transactio| | | |
| |n(0) | | | |
+---------------+-----------+-------------------+--------------+---------------+
| remove | times(0) | | | |
+---------------+-----------+-------------------+--------------+---------------+
| active-bean | | bean(0:0:0) | | |
+---------------+-----------+-------------------+--------------+---------------+
| request | request(0)| | | |
+---------------+-----------+-------------------+--------------+---------------+
| total-bean | | bean(0:0:0) | | |
+---------------+-----------+-------------------+--------------+---------------+
| rolledback | transactio| | | |
| |n(0) | | | |
+---------------+-----------+-------------------+--------------+---------------+
| active-thread | | thread(0:0:0) | | |
+---------------+-----------+-------------------+--------------+---------------+
| MethodReadyCou| | bean(0:0:0) | | |
|nt | | | | |
+---------------+-----------+-------------------+--------------+---------------+
================================================================================
application-info 명령에 대한 자세한 내용은 “JEUS Reference Book”의 “4.2.6.3. application-info”를 참고한다.
모든 EJB 종류에 공통으로 EJB 운영 성능을 향상(또는 시스템 리소스의 낭비를 방지하기 위해)하기 위해 적용할 수 있는 몇 가지 설정은 다음과 같다.
TTP의 최댓값을 적절히 수정한다.
여러 개의 EJB 엔진에 Bean들을 클러스터링해서 설정한다. “제6장 EJB 클러스터링”을 참고한다.
적절한 JDBC Connection Pool을 설정한다. 설정에 대한 자세한 내용은 "JEUS Server 안내서"를 참고한다.
EJB 2.x인 경우 EJB 모듈 Deploy 시간을 절약하기 위해 deploy 명령에 -fast 옵션과 appcompiler를 사용한다. 자세한 내용은 “제3장 EJB 모듈”을 참고한다.
위의 기본적인 최적화 옵션뿐만 아니라 Bean의 종류에 따라 수십 개의 튜닝 팁이 존재한다. 그러므로, 각 EJB 종류에 따른 튜닝과 최적화하는 방법은 해당하는 각 장을 참고한다.
EJB가 최상의 성능을 내기 위해서는 다음의 원칙을 적용해서 TTP가 올바르게 설정되어야 한다.
max pool 크기를 크게 설정할수록 더 많은 TT들이 생성될 수 있고, 따라서 더 많은 클라이언트 요청을 수행할 수 있다. 그러나 크게 설정한 max pool 크기는 많은 클라이언트들이 EJB 엔진에 접속한 경우에 많은 메모리 자원을 소모하게 된다.
특정한 시간대에 Bean의 서비스 사용을 요청하는 클라이언트가 급격히 증가할 경우에는 max pool 크기에서 min pool 크기를 뺀 값을 증가시켜 새로운 TT들이 "batch"로 생성될 수 있도록 설정한다.
TTP의 설정은 특정한 EJB에 대하여 접근 가능한 양을 조절할 수 있는 밸브의 역할을 한다.
max pool 크기는 TTP에서 가장 중요한 파라미터이다. 그러므로 성능 개선을 위해서는 이 값을 가장 먼저 조절하고 튜닝해야 한다. 이 값은 <thread-max>에 설정한다.