EJB 3.x 모듈 패키지 개요
이 주제에서는 EJB(Enterprise JavaBeans) 3.x Bean을 사용하는 경우 애플리케이션 패키징에 대해 설명합니다.
EJB 3.x Bean을 사용하는 패키징 애플리케이션은 Java™ Platform, Enterprise Edition(Java EE) 1.4 애플리케이션의 어셈블리 요구사항과 유사합니다. 컴포넌트는 모듈로 패키지되고 모듈은 애플리케이션 엔터프라이즈 아카이브(EAR) 파일로 패키지됩니다. 컴포넌트와 모듈 모두 XML(Extensible Markup Language) 배치 디스크립터에서 제공되는 설명 메타데이터를 포함합니다. EJB 3.x 스펙은 설명 메타데이터 및 지속성 단위 패키징을 위한 추가 메소드를 제공합니다.
- EJB 모듈용 JAR(Java application archive). Java EE 애플리케이션 클라이언트 모듈 및 유틸리티 클래스 모듈.
- 모듈 또는 EJB 컨텐츠용 웹 애플리케이션 아카이브(WAR) 파일. EJB 컨텐츠를 포함하려면 WAR 파일은 버전 2.5 이상이어야 합니다.
- 자원 애플리케이션 아카이브(RAR) 파일과 같은 기타 기술 특정 모듈과 기타 모듈 유형.
배치 디스크립터가 없는 EJB 모듈
EJB 3.x Bean을 사용하는 경우 배치 디스크립터가 없는 EJB 모듈을 패키지할 수 있습니다. 그러려면 EJB 컴포넌트에 있는 어노테이션에 메타데이터가 포함된 JAR 파일 또는 WAR 파일을 작성해야 합니다. EJB 3.x Bean은 어노테이션을 통해 정의한 메타데이터에 대해 ejb-jar.xml 파일에 항목이 필요하지 않습니다.
EJB 3.0에서는 기본적으로 EJB 3.0 모듈 설치 중에 어노테이션 스캔이 수행되었습니다.WebSphere® Application Server, 버전 9.0에 대해 애플리케이션 설치 또는 서버 시작 중에 기본적으로 Java EE 5 이전 모듈을 스캔하지 않습니다.
Feature Pack for EJB 3.0 및 Feature Pack for Web Services 둘 다에서 이전 버전과의 호환성을 유지하기 위해 추가 메타데이터에 대해 레거시 웹 모듈을 스캔할지 여부를 선택합니다. 각 기능팩 스캔 동작에 대해 서버 레벨 스위치가 정의됩니다. 기본값이 적절하지 않은 경우 기본값 변경에 필요한 스위치를 각 서버 및 관리 서버에 설정해야 합니다. 스위치는 서버 사용자 정의 특성인 com.ibm.websphere.webservices.UseWSFEP61ScanPolicy={true|false} 및 com.ibm.websphere.ejb.UseEJB61FEPScanPolicy={true|false}입니다. 관리 콘솔에서 이 특성을 정의하려면
을 클릭하십시오.배치 디스크립터가 포함된 EJB 모듈
배치 디스크립터가 포함된 EJB 모듈은 계속 사용할 수 있습니다. 배치 디스크립터가 포함된 모듈은 EJB 3.x를 포함하여 모든 EJB 스펙 버전 레벨을 지원하지만 일반적으로 이 디스크립터는 모듈에서 컴포넌트의 구현 요구사항을 반영해야 합니다.
EJB 모듈은 EJB 3.x, 2.x 또는 1.x 배치 디스크립터를 포함할 수 있습니다.
EJB 2.x 또는 1.x 배치 디스크립터의 경우, 배치 디스크립터에 모듈에 대한 전체 메타데이터가 포함되고 어노테이션 메타데이터에 대한 추가 스캔이 없는 것으로 간주합니다.
EJB 컨테이너 어노테이션 스캔은 배치 디스크립터가 없거나 metadata-complete XML 속성이 false로 설정 또는 생략되는 EJB 3.0 스키마 레벨에서의 ejb-jar.xml 배치 디스크립터를 포함하는 EJB 모듈에서 수행됩니다. 서버에서 어노테이션 스캔 수행 여부를 판별하기 위해 서버가 사용하는 규칙의 전체 세트에 대해서는 어노테이션 스캔 동작 절을 참조하십시오.
어노테이션 스캔 동작
서버는 모듈의 클래스 파일에서 어노테이션 컨텐츠를 검사할 수 있습니다. 서버는 컴포넌트, 자원에 대한 참조 또는 특정 동작을 정의할 수 있는 어노테이션 컨텐츠를 검색합니다. 예를 들어, 어노테이션을 사용하여 EJB 컴포넌트를 정의 또는 EJB 컴포넌트에서 사용되어야 하는 데이터 소스에 대한 참조 선언 또는 EJB 메소드와 연관되는 트랜잭션 또는 보안 속성을 선언할 수 있습니다. 이 검사 프로세스를 어노테이션 스캔이라고 합니다. 모듈의 클래스 파일이 서버에서 고려해야 하는 어노테이션을 포함하는 경우 서버는 어노테이션 스캔이 수행되도록 구성되어야 합니다. 모듈의 클래스 파일이 어노테이션을 포함하고 성능상의 이유로 어노테이션 스캔이 수행되지 않도록 서버를 구성할 수 있습니다.
- ejb-jar.xml 배치 디스크립터 파일 존재 여부
- ejb-jar.xml 배치 디스크립터가 있는 경우 해당 버전
- ejb-jar.xml 배치 디스크립터가 있는 경우 metadata-complete 설정 값
- EJB 컨텐츠가 WAR 모듈로 패키지되고 ejb-jar.xml 배치 디스크립터가 없는 경우 web.xml 배치 디스크립터의 버전
- EJB 컨텐츠가 WAR 모듈로 패키지되고 ejb-jar.xml 배치 디스크립터가 없는 경우 web.xml 배치 디스크립터의 metadata-complete 설정 값
다음 테이블은 스캔 여부 의사결정 및 어노테이션이 EJB JAR 모듈 또는 WAR 모듈로 패키지되는 방법을 표시합니다.
ejb-jar.xml | ejb-jar.xml의 metadata-complete 값 | 어노테이션 스캔 여부 |
---|---|---|
존재하며 버전 2.x 이하 | NA | 아니오 |
존재하며 버전 3.x 이상 | true | 아니오 |
존재하며 버전 3.x 이상 | false(또는 생략) | 예 |
존재하지 않음 | NA | 예 |
ejb-jar.xml 파일 | ejb-jar.xml의 metadata-complete 값 | web.xml 파일 | web.xml의 metadata-complete 값 | 어노테이션 스캔 여부 |
---|---|---|---|---|
존재하며 버전 3.x 이상 | true | NA | NA | 아니오 |
존재하며 버전 3.x 이상 | false(또는 생략) | NA | NA | 예 |
존재하며 버전 2.x 이하 | NA | NA | NA | 아니오 |
존재하지 않음 | NA | 존재하며 버전 2.5 이상 | true | 아니오 |
존재하지 않음 | NA | 존재하며 버전 2.5 이상 | false(또는 생략) | 예 |
존재하지 않음 | NA | 존재하며 버전 2.4 이하 | NA | 아니오 |
존재하지 않음 | NA | 존재하지 않음 | NA | 예 |
ejb-jar.xml 배치 디스크립터의 ejb-jar 요소의 metadata-complete 속성과 애플리케이션이나 모듈 설치 프로세스 중에 지정될 수 있는 metadata-complete 설치 설정 사이의 차이를 이해하는 것이 중요합니다.
ejb-jar.xml 파일의 ejb-jar 요소에 대한 metadata-complete 속성은 XML 속성입니다. 이는 EJB 컨텐츠에 대해 어노테이션 스캔 테이블에서 설명하는 것처럼 어노테이션 데이터를 클래스에서 스캔하는지 여부를 판별하기 위해 사용됩니다.
이와 반대로 설치 시에 지정될 수 있는 metadata-complete 설정은 서버가 ejb-jar.xml 파일 생성을 돕기 위해 사용합니다. ejb-jar.xml 파일이 모듈에 없고 metadata-complete 설치 설정이 true 값으로 지정되면 서버는 어노테이션 컨텐츠를 스캔하고 이를 사용하여 ejb-jar.xml 파일을 생성한 후 metadata-complete XML 속성을 해당 파일에 true 값으로 설정합니다.
지속성 단위
persistence.xml 파일 및 이에 연관된 클래스를 포함하는 지속성 단위는 필요한 모듈에 패키지 가능합니다. 이는 해당 종속 모듈과 같이 EAR 파일로 패키지되는 별도의 유틸리티 JAR 파일로도 패키지할 수 있습니다.
애플리케이션 패키지
EJB 2.x 및 이전 Bean을 EJB 3.x Bean과 동일한 애플리케이션에서 혼합할 수 있습니다. 그렇지만 EJB 3.x Bean은 EJB 2.x 또는 EJB 1.x 모듈에서는 인식되지 않습니다.
- 애플리케이션 이름은 EAR 파일 이름으로 간주되지만 EAR 파일 확장자는 제거되었습니다.
- .war로 끝나는 파일은 웹 모듈로 간주됩니다. 웹 모듈의 컨텍스트 루트는 애플리케이션 패키지의 루트의 상대로 간주되고 WAR 파일 확장자는 제거되었습니다.
- /lib 디렉토리에 없는 .jar로 끝나고 ejb-jar.xml 파일이나 @Stateful, @Stateless, @Singleton 또는 @MessageDriven 어노테이션을 정의하는 하나 이상의 클래스를 포함하는 파일은 EJB 모듈로 간주됩니다.
- /lib 디렉토리에 없는 기타 JAR 파일은 EJB 모듈로 간주되지 않습니다.
JPA 패키징
더 쉽게 액세스하고 재사용할 수 있도록 지속성 단위는 별도의 JAR 파일로 패키지되도록 권장됩니다. 이는 실제 발생하는 데이터베이스 지속성을 사용하거나 사용하지 않고 컨테이너 밖에서 테스트할 수 있습니다. 지속성 단위는 독립형 애플리케이션 또는 EAR 파일에 유틸리티 JAR 파일로 포함될 수 있습니다. 많은 수량의 클래스를 스캔하는 경우 다양한 유스 케이스 및 잠재적 성능 문제로 인해 지속성 단위는 지속성 단위의 클래스를 정의하도록 권장됩니다.
지속성 시나리오에 사용되는 세션 Facade
공통 패턴은 세션 Facade를 지속성에 사용하는 것입니다. 세션 Bean Facade를 사용하여 JPA를 구동하는 것은 지원됩니다. EntityManager 인터페이스는 스레드에서 안전하지 않기 때문에 서블릿은 @PersistenceContext를 주입하면 안됩니다. 서블릿은 Facade 패턴을 사용하거나 EntityManagerFactory 인스턴스를 사용하여 각 요청에서 EntityManager를 작성해야 합니다.
세션 Bean Facade와 별도로 JPA 지속성 단위는 별도의 JAR 파일에 정의되도록 권장됩니다. 이를 통해 공유에서 더 나은 유연성이 제공될 뿐만 아니라 JPA가 JPA 이외의 어노테이션이 있는 클래스와 혼합되는 것을 방지할 수 있습니다.
일반적으로 작성은 엔티티 클래스 및 JPA persistence.xml 정의를 보유하도록 작성되고 EAR 파일에 유틸리티 JAR 파일로 추가됩니다. EJB 3.x 모듈은 종속성을 EJB 3.x 모듈 MANIFEST.MF에 선언하여 JAR 파일에 추가합니다. 예를 들어, EAR이 TradeApp.ear, TradeWeb.war, EJB3Trade.jar, TradeInfo.jar 파일을 포함하는 경우 EJB3Trade.jar 파일은 다음과 유사한 MANIFEST.MF를 갖게 됩니다.
Manifest-Version: 1.0
Class-Path: TradeInfo.jar
EJB3Trade.jar 파일의 세션 Facade는 JPA 엔티티 클래스 및 TradeInfo.jar 파일의 지속성 단위를 나타냅니다. TradeWeb.war 파일에 정의된 웹 애플리케이션은 웹 및 EJB 컨테이너 티어 뒤에 오는 데이터 전송 오브젝트와 동일하게 JPA 엔티티 오브젝트에 대해 작동할 수 있습니다.
상호 티어 및 상호 버전 세션 Bean 참조 시나리오
몇 가지 방법으로 EJB 3.x 세션 Bean에 대한 참조를 정의하고 사용할 수 있습니다. EJB 3.x 세션 대 세션인 경우, @EJB 인젝션 대상을 사용할 수 있습니다. 상호 티어의 경우, 예를 들어, EJB 3.x 세션의 웹 애플리케이션 또는 상호 버전의 경우, 예를 들어 EJB 2.1 세션에서 EJB 3.x 세션으로, XML 배치 디스크립터 참조가 ejb-refs 및 ejb-local-refs를 정의할 수 있습니다. 여기에는 EJB 3.x 비즈니스 인터페이스가 참조되는지 또는 EJBLocalHome도 정의하는 EJB 3.x 이전의 component-style 인터페이스도 참조되는지에 따라 두 개의 변형이 있습니다. 웹 애플리케이션 및 클라이언트 애플리케이션은 참조 중인 컴포넌트가 AutoLink를 사용하여 해결되는 경우에도 @EJB 어노테이션을 사용할 수 있습니다.
이전 시나리오는 EJB 3.x 스타일 세션 Bean 구현이 포함된 EJB 2.1 스타일의 클라이언트 패턴을 사용합니다. 더 최근의 클라이언트 스타일의 경우 클라이언트 측은 홈 인터페이스를 통해 이동하지 않고 세션 Bean 비즈니스 인터페이스를 직접 검색하도록 정리됩니다. 이 경우, @LocalHome(<localhome>.class) 어노테이션을 정의할 필요가 없습니다. Yejb-ref 및 ejb-local-ref의 다양한 정의를 사용하여 이를 수행할 수 있습니다. null 값을 local-home 요소 값으로 사용하고 ejb-local-ref를 홈 바인딩 대신 세션 Bean의 ejblocal에 바인드하십시오. 예를 들어, 다음과 같습니다.
<ejb-local-ref id="EJBLocalRef_1154112538064">
<description>com.ibm.persistence.ejb3.order.facadecom.ibm.persistence.ejb3.order.facade</description>
<ejb-ref-name>ejb/OrderEJB</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local-home></local-home>
<local>com.ibm.persistence.ejb3.order.facade.OrderProcessor</local>
</ejb-local-ref>
클라이언트 코드도 검색 중인 오브젝트에 대해 적절한 캐스트를 수행하도록 조정되어야 합니다. 이 경우, 홈 인터페이스 대신 비즈니스 인터페이스 사용:
try {
InitialContext ctx = new InitialContext();
orderProcessor = (OrderProcessor)ctx.lookup("java:comp/env/ejb/OrderEJB");
}
catch(Exception e){
e.printStackTrace(System.out);
throw new ServletException(e);
}