EJB 3.0 및 EJB 3.1 애플리케이션 바인딩 개요
애플리케이션 서버에 설치된 애플리케이션을 시작하기 전에 애플리케이션에 정의된 모든 EJB(Enterprise JavaBeans) 참조 및 자원 참조가 애플리케이션 서버에 정의된 실제 아티팩트(엔터프라이즈 Bean 또는 자원)에 바인드되도록 해야 합니다.
버전 8.0부터 EJB 컨테이너의 바인딩 지원이 확장됩니다. EJB 컨테이너는 애플리케이션 이름, 모듈 이름 및 컴포넌트 이름을 기반으로 EJB 3.x 비즈니스 인터페이스에 대해 기본 JNDI 바인딩을 지정합니다. EJB 3.x 모듈 내 각 인터페이스나 EJB 홈 또는 EJB 3.1 모듈 내 인터페이스 없는 보기에 대해 JNDI 바인딩 이름을 명시적으로 정의하지 않아도 됩니다.
바인딩을 정의할 때, 애플리케이션에서 참조 가능한 아티팩트 및 참조된 아티팩트에 대한 JNDI(Java™ Naming and Directory Interface) 이름을 지정합니다. 아티팩트에 지정된 jndiName 값은 규정된 찾아보기 이름이어야 합니다.
EJB 3.x 모듈에서 엔터프라이즈 Bean의 각 인터페이스, EJB 홈 또는 인터페이스 없는 보기에 대해 JNDI 바인딩 이름을 수동으로 지정하지 않아도 됩니다. 바인딩을 명시적으로 지정하지 않으면 EJB 컨테이너가 기본 바인딩을 지정합니다.
기본 EJB JNDI 바인딩에 대한 네임스페이스
애플리케이션 서버는 기본 EJB 바인딩을 클래식 및 java:[범위] 네임스페이스 세트 모두에 배치할 수 있습니다.
클래식 네임스페이스 세트는 ejblocal: 및 글로벌 JNDI 네임스페이스로 구성됩니다. 클래식 네임스페이스에는 WebSphere® 확장이 포함되고 이는 버전 8.0 이전의 애플리케이션 서버에 존재했습니다.
java:[범위] 네임스페이스 세트는 java:global, java:app 및 java:module 네임스페이스로 구성됩니다. java:[scope] 네임스페이스는 Java EE 6 스펙에 의해 정의되며 버전 8의 WebSphere Application Server에 도입되었습니다. 클래식 네임스페이스의 대체물이 아닙니다. 오히려 클래식 네임스페이스와 함께 추가됩니다.
클래식 네임스페이스 세부사항
- JVM(Java Virtual Machine) 범위, ejblocal: namespace
- 글로벌 JNDI 네임스페이스
로컬 EJB 인터페이스, 홈 및 인터페이스 없는 보기는 항상 JVM 범위 클래식 ejblocal: namespace에 바인드해야 합니다. 즉, 동일한 애플리케이션 서버 프로세스에서만 액세스할 수 있습니다.
반대로, 원격 EJB 인터페이스와 홈은 항상 클래식 글로벌 범위 WebSphere JNDI 네임스페이스에 바인드해야 합니다. 즉, 기타 서버 프로세스 및 기타 원격 클라이언트를 포함하여 어느 위치에서나 액세스할 수 있습니다. 로컬 인터페이스 및 인터페이스 없는 보기는 클래식 글로벌 범위 JNDI 네임스페이스에 바인드할 수 없으며, 원격 인터페이스도 JVM 범위 클래식 ejblocal: namespace에 바인드할 수 없습니다.
클래식 ejblocal: 및 클래식 글로벌 범위 JNDI 네임스페이스는 완전히 다른 별개의 것입니다. 예를 들어, "ejblocal:AccountHome"에 바인드된 EJB 로컬 인터페이스 또는 인터페이스 없는 보기는 클래식 글로벌 범위 네임스페이스의 "AccountHome"에 바인드된 원격 인터페이스와 다릅니다. 이러한 작동을 통해 로컬 및 원격 인터페이스 참조 간에 구별을 유지할 수 있습니다. JVM 범위 로컬 네임스페이스를 갖게 되면 또한 애플리케이션이 Java EE(Java Platform, Enterprise Edition) 애플리케이션 경계를 포함하여 JVM 서버 프로세스의 임의의 위치에서 로컬 EJB 인터페이스 및 인터페이스 없는 보기를 직접 검색하거나 참조할 수 있습니다.
애플리케이션, 모듈 및 컴포넌트 이름을 기반으로 EJB 3.x 컨테이너의 EJB 비즈니스 인터페이스에 대해 클래식 기본 JNDI 바인딩을 지정합니다.
EJB 컨테이너는 애플리케이션 이름, 모듈 이름 및 컴포넌트 이름을 기반으로 EJB 3.x 비즈니스 인터페이스에 대한 기본 클래식 JNDI 바인딩을 지정하므로 이러한 이름 정의 방법을 이해하는 것이 중요합니다. 이 이름은 각각 문자열입니다.
- EJB 모듈용 JAR(Java Application Archive) 파일, Java EE 애플리케이션 클라이언트 모듈 및 유틸리티 클래스 모듈
- 웹 모듈용 WAR(Web Application Archive) 파일
- 자원 애플리케이션 아카이브(RAR) 파일과 같은 기타 기술 특정 모듈과 기타 모듈 유형
Java EE 모듈은 Java EE 애플리케이션 아카이브에 패키지되고 Java EE 컴포넌트는 Java EE 모듈에 패키지되므로 각 컴포넌트의 "내포 경로"를 사용하여 해당 애플리케이션 이름, 모듈 이름 및 컴포넌트 이름에 따라 Java EE 애플리케이션 아카이브 내 모든 컴포넌트를 고유하게 식별할 수 있습니다.
클래식 바인딩에 사용되는 애플리케이션 이름
- 제품에 애플리케이션을 설치하는 동안 제품 관리 콘솔에 지정된 애플리케이션 이름 값이나 wsadmin 명령행 스크립트 도구에 제공된 appname 매개변수
- 애플리케이션의 META-INF/application.xml 배치 디스크립터 내의 <display-name> 매개변수 값
- EAR 파일 이름(.ear 파일 접미부 제외). 예를 들어, 이 경우 애플리케이션 EAR 파일 CustomerServiceApp.ear의 애플리케이션 이름은 "CustomerServiceApp"입니다.
- 애플리케이션의 application.xml 배치 디스크립터 내의 <application-name> 매개변수 값
- EAR 파일 이름(.ear 파일 접미부 제외). 예를 들어, 애플리케이션 EAR 파일 CustomerServiceApp.ear의 애플리케이션 이름은 "CustomerServiceApp"입니다. 애플리케이션이 독립형 모듈일 경우 java:global 검색 이름에 애플리케이션 컴포넌트가 포함되지 않습니다.
클래식 바인딩에 사용되는 모듈 이름
모듈 이름은 모듈 파일의 URI(Uniform Resource Identifier)로 정의되며 모듈이 상주하는 EAR 파일의 루트와 관련이 있습니다. 다른 방법으로 설명하면, 모듈 이름은 EAR 파일의 루트에 상대적인 모듈의 파일 이름입니다(모듈 파일이 내포된 서브디렉토리 포함). 이 네이밍 규칙은 module-name 요소를 사용하여 배치 디스크립터에 논리 모듈 이름이 명시적으로 지정된 경우에도 여전히 해당됩니다.
CustomerServiceApp.ear:AccountProcessing.jar
com/mycompany/AccountProcessingServiceBean.class AccountProcessingService.class
Utility/FinanceUtils.jar META-INF/ejb-jar.xml
com/mycompany/InterestCalculatorServiceBean.class InterestCalculatorService.class
AppPresentation.war META-INF/web.xml
- 모듈의 ejb-jar.xml 또는 web.xml 배치 디스크립터 내의 <module-name> 매개변수 값
- 모듈 URI(.jar 또는 .war 접미부 제외). 예를 들어, URI가 CustomerService.jar 또는 CustomerService.war인 모듈의 모듈 이름은 "CustomerService"입니다.
클래식 바인딩에 사용되는 EJB 컴포넌트 이름
- ejb-jar.xml 배치 디스크립터(존재하는 경우)의 Bean과 연관된 ejb-name 태그 값
- Bean과 연관된 @Stateless 또는 @Stateful 어노테이션에서 "name" 매개변수(있는 경우) 값
- 패키지 레벨 규정자가 없는 Bean 구현 클래스 이름
바인딩
EJB 3.x 모듈이 지원하는 다음 바인딩을 검토하십시오.
- 비즈니스 인터페이스, 홈 및 인터페이스 없는 보기에 대한 기본 클래식 바인딩
- 기본 클래식 바인딩 패턴
- java:[범위] 바인딩
- EJB 비즈니스 인터페이스, 홈 및 인터페이스 없는 보기에 대한 사용자 정의 바인딩
- 참조 및 인젝션 대상 해석을 위한 사용자 정의 바인딩
- EJB 참조 및 EJB 인젝션에 대한 기본 해석: 자동 링크 기능
- EJB 및 자원 참조 및 주입에 대한 해석: 검색 기능
- 애플리케이션에 정의된 환경 항목 대체
- 데이터 소스 정의 대체
- 클러스터 환경의 네이밍 고려사항
- 사용자 정의 EJB 확장 설정
- 레거시(XMI) 바인딩
- 사용자 지정 XML 바인딩
EJB 비즈니스 인터페이스, 홈 및 인터페이스 없는 보기에 대한 기본 클래식 바인딩
EJB 3.x 모듈 내 각 인터페이스나 EJB 홈 또는 EJB 3.1 모듈 내 인터페이스 없는 보기에 대해 JNDI 바인딩 이름을 명시적으로 정의하지 않아도 됩니다. 바인딩을 명시적으로 지정하지 않으면, 제품의 EJB 컨테이너가 여기 설명된 규칙을 사용하여 기본 클래식 바인딩을 지정합니다. 이는 지원 중인 EJB 3.0 스펙 이전의 제품의 EJB 지원과는 다릅니다.
EJB 컨테이너는 각 엔터프라이즈 Bean에서 각 인터페이스(비즈니스, 원격 홈 또는 로컬 홈) 또는 인터페이스 없는 보기에 대해 두 가지 기본 클래식 바인딩을 수행합니다. 이러한 두 가지 클래식 바인딩을 여기서는 인터페이스 또는 인터페이스 없는 축약형 바인딩 및 긴 바인딩 보기라고 합니다. 축약형 바인딩은 인터페이스 또는 인터페이스 없는 보기의 패키지 규정 Java 클래스 이름만 사용하는 반면에, 긴 바인딩은 엔터프라이즈 Bean의 컴포넌트 ID를 패키지 규정 인터페이스 또는 인터페이스 없는 보기 클래스 이름 앞에 추가 규정자로 사용합니다. 여기서, 컴포넌트 ID와 인터페이스 또는 인터페이스 없는 보기 클래스 이름 사이에 해시 또는 번호 부호(# 기호)를 사용합니다. 두 양식 간의 차이점은 축약형 TCP/IP 호스트 이름(시스템 이름만)과 긴 호스트 이름(도메인 이름이 앞에 추가된 시스템 이름) 간의 차이점과 유사하다고 할 수 있습니다.
예를 들어, 인터페이스 또는 인터페이스 없는 보기에 대한 축약형 및 긴 기본 클래식 바인딩은 각각 com.mycompany.AccountService 및 AccountApp/module1.jar/ServiceBean#com.mycompany.AccountService입니다.
기본적으로, EJB 기본 클래식 바인딩의 컴포넌트 ID는 엔터프라이즈 Bean의 애플리케이션 이름, 모듈 이름 및 컴포넌트 이름을 사용하여 구성되지만 원하는 문자열을 대신 지정할 수 있습니다. 원하는 문자열을 컴포넌트 ID로 정의하면, 엔터프라이즈 Bean의 긴 양식 바인딩이 공통 사용자 정의 부분을 공유하고 각 인터페이스 또는 인터페이스 없는 보기 클래스의 이름을 기반으로 하는 시스템 정의 부분도 있는 네이밍 규칙을 설정할 수 있습니다. 또한 애플리케이션 모듈 계층 구조에서 엔터프라이즈 Bean을 패키지한 방법과 관계없이 기본 EJB 바인딩 이름을 작성할 수 있습니다. 엔터프라이즈 Bean의 기본 컴포넌트 ID 대체는 이 주제의 "EJB 비즈니스 인터페이스, 홈 및 인터페이스 없는 보기에 대한 사용자 정의 바인딩" 절에 설명되어 있습니다.
클래식 JVM 범위 로컬 네임스페이스 및 클래식 글로벌 범위 JNDI 네임스페이스에 대한 절에서 앞서 언급한 대로, 모든 로컬 인터페이스, 홈 및 인터페이스 없는 보기는 동일한 서버 프로세스(JVM)에서만 액세스할 수 있는 클래식 ejblocal: namespace에 바인드해야 합니다. 반면에, 원격 인터페이스와 홈은 WebSphere 제품 셀의 임의의 위치에서 액세스할 수 있는 클래식 글로벌 범위 네임스페이스에 바인드해야 합니다. 예상한 대로, EJB 컨테이너는 기본 바인딩에 이 규칙을 따릅니다.
또한 원격 인터페이스에 대한 긴 기본 바인딩은 ejb 컨텍스트 이름으로 그룹화된다는 점에서 권장 Java EE 우수 사례를 따릅니다. EJB 원격 홈 및 비즈니스 인터페이스는 기본적으로 애플리케이션 서버 네이밍 컨텍스트의 루트에 바인드됩니다. 그러나 Application Server 루트 컨텍스트는 EJB 인터페이스 이외의 바인딩에도 사용되므로 이 컨텍스트가 너무 복잡해지지 않도록 하려면 EJB 관련 바인딩을 서버 루트 컨텍스트에 직접 배치하는 것보다 공통 "ejb" 서브컨텍스트에 그룹화하는 것이 좋습니다. 이는 모든 파일을 루트 디렉토리에 두지 않고 디스크 볼륨의 서브디렉토리를 사용하는 이유와 유사합니다.
- 축약형 기본 바인딩은 EJB 인터페이스에 액세스하기 위한 간단하고 직접적인 방법을 제공합니다. 이 바인딩을 서버 루트 컨텍스트에 직접 두고 ejblocal:이 앞에 추가된 인터페이스 이름 또는 단지 인터페이스 이름만으로 참조하므로 간단한 방법이라고 할 수 있습니다.
- 동시에, 긴 기본 바인딩을 ejb 컨텍스트 또는 로컬 인터페이스의 경우 ejblocal: context에 배치함으로써 해당 바인딩을 서버의 루트 컨텍스트 외부에 두고 복잡성을 줄여 루트 컨텍스트에 축약형 바인딩을 둘 수 있습니다.
- 유사한 네이밍 규칙을 사용하는 기타 Java EE 애플리케이션 서버와 일정 수준의 상호 호환성을 제공합니다.
요약하면, 모든 로컬 기본 바인딩(축약형 바인딩과 긴 바인딩 모두)은 클래식 ejblocal: server/JVM 범위 네임스페이스에 배치되는 반면에, 원격 기본 바인딩은 클래식 글로벌 범위 네임스페이스의 서버 루트 컨텍스트(축약형 바인딩의 경우) 또는 서버 루트 컨텍스트 다음의 <server_root>/ejb 컨텍스트(긴 바인딩의 경우)에 배치됩니다. 따라서 서버의 글로벌 범위 루트 컨텍스트에 있는 기본 바인딩만이 원격 인터페이스에 대한 축약형 바인딩입니다. 이는 간단하고 이식 가능한 모델을 제공함과 동시에 서버의 글로벌 범위 루트 컨텍스트가 너무 복잡해지지 않게 할 수 있게 적절히 밸런스를 맞춥니다.
기본 클래식 바인딩 패턴
각 클래식 바인딩 유형의 패턴은 표에 표시됩니다. 이 패턴에서 <대괄호 이탤릭체>로 작성된 문자열은 값을 나타냅니다. 예를 들어, <package.qualified.interface>는 com.mycompany.AccountService이고 <component-id>는 AccountApp/module1.jar/ServiceBean입니다.
바인딩 패턴 | 설명 |
---|---|
ejblocal:<package.qualified.interface> | 축약형 양식의 로컬 인터페이스, 홈 및 인터페이스 없는 보기 |
<package.qualified.interface> | 축양형 양식의 원격 인터페이스 및 홈 |
ejblocal:<component-id>#<package.qualified.interface> | 긴 양식의 로컬 인터페이스, 홈 및 인터페이스 없는 보기 |
ejb/<component-id>#<package.qualified.interface> | 긴 양식의 원격 인터페이스 및 홈 |
component-id 기본 패턴은 다음 절("다중 엔터프라이즈 Bean이 동일한 인터페이스를 구현하는 경우 축약형 기본 바인딩 이름 충돌")에 설명된 대로 component-id 속성을 사용하여 EJB 모듈 바인딩 파일에서 대체되지 않는 한 <application-name>/<module-jar-name>/<ejb-name>입니다. <module-jar-name> 변수는 EJB 모듈 바인딩 파일로 대체되지 않으면 배치 디스크립터에 논리 모듈 이름이 지정된 경우에도 이전 "모듈 이름" 절에 설명된 대로 확장자(예: .jar, .ear, .war)를 포함하여 EAR 내 실제 모듈 파일의 이름입니다.
여러 엔터프라이즈 Bean이 동일한 인터페이스를 구현하는 경우 축약형 기본 클래식 바인딩 이름 충돌
애플리케이션 서버에서 실행 중인 두 개 이상의 엔터프라이즈 Bean이 정해진 인터페이스 또는 인터페이스 없는 보기를 구현하는 경우, 축약형 기본 클래식 바인딩 이름이 모호해집니다. 이는 축약형 이름이 이 인터페이스 또는 인터페이스 없는 보기를 구현하는 임의의 Enterprise JavaBeans를 참조할 수 있기 때문입니다. 이러한 상황을 방지하려면 다음 절에 설명된 대로 제공된 인터페이스 또는 인터페이스 없는 보기를 구현하는 각 Enterprise JavaBeans에 대한 바인딩을 명시적으로 정의하거나, WebSphere 제품 JVM 사용자 정의 특성인 com.ibm.websphere.ejbcontainer.disableShortDefaultBindings를 정의하여 이러한 Enterprise JavaBeans가 포함된 애플리케이션의 축약형 기본 클래식 바인딩을 사용할 수 없게 해야 합니다. JVM 사용자 정의 특성 정의에 대한 자세한 정보는 JVM(Java Virtual Machine) 사용자 정의 특성을 참조하십시오.
이 JVM 사용자 정의 특성을 사용하려면 특성 이름을 com.ibm.websphere.ejbcontainer.disableShortFormBinding으로 설정하고 특성 값을 와일드카드 값인 *(별표)로 설정하여 서버의 모든 애플리케이션에 대한 축약형 양식 기본 클래식 바인딩을 사용 불가능하게 하거나, 축약형 기본 클래식 바인딩을 사용 불가능하게 할 Java EE 애플리케이션 이름의 콜론으로 구분된 순서로 설정하십시오(예: PayablesApp:InventoryApp:AccountServicesApp).
기본 클래식 바인딩에 대한 명시적 지정 효과

java:[범위] 네임스페이스
java:global, java:app 및 java:module 네임스페이스는 Java EE 6 스펙에 의해 도입되었습니다. 해당 네임스페이스는 여러 애플리케이션 서버 사이에서 이식 가능한 자원을 바인드하고 검색하는 메커니즘을 제공합니다.
서버는 항상 인터페이스 없는 보기를 포함하여 각 EJB 인터페이스에 대한 기본 긴 양식 바인딩을 작성하여 java:global, java:app 및 java:module 네임스페이스에 배치합니다. Bean이 인터페이스 없는 보기를 포함하여 하나의 인터페이스만 표시하는 경우, 축약형 양식 바인딩도 작성되어 java:global, java:app 및 java:module 네임스페이스에 배치됩니다. 기본 바인딩은 세션 Bean에 대해서만 작성됩니다. 엔티티 Bean 또는 메시지 구동 Bean에 대해서는 작성되지 않습니다.
긴 양식 바인딩 및 축약형 양식 바인딩은 모두 애플리케이션 이름, 모듈 이름 및 Bean 컴포넌트 이름을 포함합니다. 애플리케이션 이름의 기본값은 확장자 없이 .ear 파일의 기본 이름으로 설정됩니다. application.xml 파일의 application-name 요소를 사용하여 애플리케이션 이름을 대체할 수 있습니다. 모듈 이름의 기본값은 확장자는 제거되고 디렉토리 이름은 포함된 모듈의 경로 이름으로 설정됩니다. ejb-jar.xml 또는 web.xml 파일의 module-name 요소를 사용하여 모듈 이름을 대체할 수 있습니다. Bean 컴포넌트 이름의 기본값은 Bean 클래스의 규정되지 않은 이름으로 설정됩니다. 어노테이션을 정의하는 EJB 컴포넌트의 이름 속성 또는 ejb-jar.xml 파일의 ejb-name 요소를 사용하여 Bean 컴포넌트 이름을 대체할 수 있습니다.
긴 양식 바인딩 패턴은 java:global/<applicationName>/<moduleName>/<Bean 컴포넌트 이름>!<완전한 인터페이스 이름>입니다.
짧은 양식 바인딩 패턴은 java:global/<applicationName>/<moduleName>/<Bean 컴포넌트 이름>입니다.
- java:global/myApp/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
- java:global/myApp/myModule/MyBeanComponent
- java:app/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
- java:app/myModule/MyBeanComponent
- java:module/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
- java:module/MyBeanComponent
- @EJB 어노테이션에서 lookup 속성을 사용하십시오. 예를 들면, 다음과 같습니다.
@EJB(lookup="java:global/myApp/myModule/MyBeanComponent")
- ejb-jar.xml에서 lookup-name 요소를 사용하십시오. 예를 들면, 다음과 같습니다.
<lookup-name>java:global/myApp/myModule/MyBeanComponent!com.ibm.MyBeanComponentLocalInterfaces</lookup-name>
- InitialContext 오브젝트에서 검색을 완료하십시오. 예를 들면, 다음과 같습니다.
initialContext.lookup("java:global/myApp/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterfaces")
애플리케이션 서버에 의해 작성되는 기본 바인딩 외에 java:global, java:app 및 java:module 네임스페이스에 참조를 정의할 수 있습니다. java:global, java:app 및 java:module 네임스페이스에 정의된 참조는 컴포넌트 네임스페이스로 이동하지 않습니다. java:global, java:app 또는 java:module 네임스페이스에 정의된 참조는 해당 네임스페이스에서 검색되거나 삽입되어야 합니다. 컴포넌트 네임스페이스에서 검색하거나 삽입할 수 없습니다.
Bean 컴포넌트는 java:module 네임스페이스를 사용하여 동일한 모듈에 패키지된 컴포넌트가 사용할 수 있는 참조를 선언할 수 있습니다. 해당 컴포넌트는 java:app 네임스페이스를 사용하여 동일한 애플리케이션 내의 다른 모듈에 패키지된 컴포넌트가 사용할 수 있는 참조를 선언할 수 있습니다. 또한 java:global 네임스페이스를 사용하여 다른 애플리케이션에 패키지된 컴포넌트가 사용할 수 있는 참조를 선언할 수 있습니다.
컴포넌트 네임스페이스에서 이름이 동일한 참조가 충돌할 수 있는 것처럼 java:global, java:app 또는 java:module 네임스페이스에서 이름이 동일한 참조는 서로 충돌할 수 있습니다. 한 애플리케이션의 java:app 네임스페이스로 범위가 지정된 참조는 다른 애플리케이션의 java:app 네임스페이스로 범위가 지정된 동일한 이름의 참조와 충돌하지 않습니다. 마찬가지로 한 모듈의 java:module 네임스페이스로 범위가 지정된 참조는 다른 모듈의 java:module 네임스페이스로 범위가 지정된 동일한 이름의 참조와 충돌하지 않습니다.
@EJB(name="java:global/env/myBean")
<resource-ref>
<res-ref-name>java:global/env/myDataSource</res-ref-name>
....
</resource-ref>
java:[범위] 네임스페이스에 대한 추가 문서는 Java EE 6 스펙의 5.2.2 절 및 Enterprise JavaBeans 3.1 스펙의 4.4 절을 참조하십시오.
EJB 비즈니스 인터페이스, 홈 및 인터페이스 없는 보기에 대한 사용자 정의 바인딩
제품 기본 바인딩을 사용하지 않고 바인딩 위치를 수동으로 지정하려는 경우, EJB 모듈 바인딩 파일을 사용하여 특정 인터페이스, 홈 및 인터페이스 없는 보기에 바인딩 위치를 직접 지정할 수 있습니다. 이 파일을 사용하여 모듈의 하나 이상의 엔터프라이즈 Bean에서 기본 바인딩의 컴포넌트 ID 부분만 대체할 수도 있습니다. 컴포넌트 ID 대체는 모든 기본 바인딩을 사용하는 것과 각 인터페이스 또는 인터페이스 없는 보기에 대해 바인딩 이름을 완벽히 지정하는 것 간에 절충안을 제공합니다.
EJB 3.x 모듈에 대한 사용자 정의 바인딩 정보를 지정하려면 EJB JAR(Java Archive) 파일의 META-INF 디렉토리에 ibm-ejb-jar-bnd.xml 파일을 배치하십시오. 이 파일의 접미부는 XML입니다. 또한 로컬 인터페이스 또는 인터페이스 없는 보기에 대한 클래식 바인딩을 정의하는 경우, 이름 앞에 문자열 "ejblocal:"을 추가해야 하므로 클래식 JVM 범위 ejblocal: namespace에 바인드됩니다.
- XMI 파일 형식에 선언된 바인딩 및 확장자는 해당 파일의 요소에 첨부된 고유 ID 번호를 명시적으로 참조하는 해당 ejb-jar.xml 배치 디스크립터 파일의 존재 여부에 따라 다릅니다. 이 시스템은 더 이상 EJB 3.0 이상의 모듈에 실행할 수 없으므로 더 이상 모듈에 ejb-jar.xml 배치 디스크립터가 포함되지 않아도 됩니다.
- XMI 파일 형식은 제품 개발 도구와 시스템 관리 기능만으로 시스템을 편집할 수 있도록 디자인되었습니다. 이는 실질적으로 제품 내부 구현의 일부이며 파일 구조는 외부적으로 문서화되지 않았습니다. 이로 인해 개발자가 바인딩 파일을 수동으로 편집하거나, 지원되는 방법을 사용하여 WebSphere 독립 빌드 프로세스의 일부로 작성할 수 없습니다.
- XML 기반 바인딩 파일은 ejb-jar.xml 배치 디스크립터에 인코드된 ID 번호를 참조하지 않고 EJB 이름으로 EJB 컴포넌트를 참조합니다. 모듈의 각 EJB 컴포넌트에는 기본적으로 또는 개발자가 명시적으로 지정한 고유한 EJB 이름이 있습니다. 따라서 이 작동은 대상 바인딩 및 확장에 명확한 방법을 제공합니다.
- 새 바인딩 파일은 XML을 기반으로 하며, 구조를 외부적으로 문서화하는 XSD(XML Schema Definition) 파일이 제공됩니다. 많은 공통 XML 파일 편집기가 구문 확인 및 코드 완료 기능을 지원하기 위해 이러한 .xsd 파일을 사용할 수 있습니다. 따라서 이제 개발자는 애플리케이션 서버 인프라에 관계없이 바인딩 및 확장 파일을 생성하고 편집할 수 있습니다.
요소 또는 속성 | 사용 방법 | 예제 | 주석 |
---|---|---|---|
<session> | 세션 Bean의 바인딩 지정 그룹을 선언합니다. | <session name="AccountServiceBean"/> | name 속성과 하나 이상의 simple-binding-name 속성, local-home-binding-name 속성, remote-home-binding-name 속성 또는 <interface> 요소가 필요합니다. |
이름 | <session>, <message-driven>, <entity> 또는 기타 요소가 적용되는 엔터프라이즈 Bean의 ejb-name을 식별하는 속성입니다. | <session name="AccountServiceBean"/> | name 값은 ejb-jar.xml 배치 디스크립터 파일의 <ejb-name> 요소에 선언된 이름이거나 @Stateful, @Stateless, @Singleton 또는 @MessageDriven 어노테이션의 name 속성이며, 기본값은 @Session 또는 @MessageDriven 어노테이션이 있는 EJB 구현 클래스의 규정되지 않은 클래스 이름입니다(XML 배치 디스크립터에 <ejb-name> 값이 선언되지 않고 어노테이션에 name 매개변수가 선언되지 않는 경우). |
component-id | 엔터프라이즈 Bean의 기본 컴포넌트 ID 값을 대체하는 속성입니다. 이 엔터프라이즈 Bean의 기본 긴 양식 클래식 바인딩은 <app_name>/<module_jar_name>/<bean_name> 대신 지정된 컴포넌트 ID를 사용합니다. |
이전 예제를 실행하면 ejb-name이 AccountServiceBean인 Bean이 생성되며, 이 Bean의 긴 양식 기본 클래식 로컬 인터페이스는 ejblocal:Department549/AccountProcessor#<package.qualified.interface>에 바인드되고 긴 양식 기본 클래식 원격 인터페이스는 ejb/Department549/AccountProcessor#<package.qualified.interface>에 바인드됩니다. |
단독으로
사용하거나 <interface> 요소, local-home-binding-name 속성 또는 remote-home-binding-name
속성과 함께 사용할 수 있습니다. 명시적 바인딩이 지정되지 않은
인터페이스는 사용자 지정 컴포넌트 ID 값을 사용하여 수행된
기본 클래식 바인딩을 갖습니다. 명시적
바인딩이 지정된 인터페이스는 해당 값을 사용하여 바인드됩니다. simple-binding-name 속성은 제공된 엔터프라이즈 Bean에 정의된 모든 인터페이스에 적용되므로(기본 인터페이스가 없음) simple-binding-name과 함께 component-id를 적용하는 것은 일반적으로 유용하지 않습니다. |
simple-binding-name | Enterprise JavaBeans에 대한
인터페이스 바인딩을 지정하는 단순 메커니즘은 다음과 같습니다.
|
이 예제를 실행하면 ejb-name이 AccountServiceBean인
Bean이 생성되며, 해당 로컬 비즈니스 인터페이스 또는 홈(있는 경우)은 클래식 로컬
JVM 범위 EJB 네임스페이스의 ejblocal:ejb/AccountService에 바인드되고 해당 원격
비즈니스 인터페이스 또는 홈(있는 경우)은 클래식 글로벌 범위 JNDI 네임스페이스의
애플리케이션 서버 루트 컨텍스트의 ejb/AccountService에 바인드됩니다.
중요사항: 중요:
정확한 속성 값(이 특정 예제에서는 "ejb"
서브컨텍스트 이름 포함)은 인터페이스가 ejblocal: namespace에 바인드된
로컬 인터페이스인 경우에도 사용됩니다. 사용자 정의 바인딩이 지정되면
속성으로 지정된 정확한 이름이 사용됩니다. |
local-home-binding-name
또는 remote-home-binding-name 속성이나 <interface> 요소와 함께 사용되지
않습니다. 또한 두 개 이상의 비즈니스 인터페이스를 구현하는 Bean에서 사용해서는
안됩니다(이 경우에 <interface> 요소를 대신 사용). 이 속성이 두 개 이상의 비즈니스 인터페이스 또는 비즈니스 인터페이스 및 로컬/원격 컴포넌트 인터페이스와 홈의 조합을 구현하는 엔터프라이즈 Bean에서 사용되는 경우, 속성 값에 해시 또는 번호 부호(# 기호)를 추가하고 그 뒤에 엔터프라이즈 Bean의 각 인터페이스, 홈 또는 둘 다의 패키지 규정 클래스 이름이 오게 하면 결과 바인딩이 명확해집니다. 그러나 simple-binding-name을 사용하는 대신 <interface> 요소를 사용하여 각 비즈니스 인터페이스에 대한 바인딩을 정의하면 이러한 조건을 방지할 수 있습니다. 중요사항: 중요:
두 개
이상의 비즈니스 인터페이스를 구현하는 Bean에 simple-binding-name을 정의하는 것은
<component-id>를 사용하여 Bean의 기본 컴포넌트 ID를 대체하는 것과 다릅니다. component-id를 사용하여 정의된 원격 인터페이스 기본 바인딩은 모든
원격 인터페이스 기본 바인딩과 마찬가지로 여전히 EJB 컨텍스트에 그룹화되는 반면에,
인터페이스가 여러 개인 Bean에서 simple-binding-name을 잘못
사용하여 EJB 컨테이너가 명확성을 부여한 원격 인터페이스
바인딩은 ejb 컨텍스트에 그룹화되지 않습니다. |
local-home-binding-name | 엔터프라이즈 Bean 로컬 홈의 바인딩 위치를 지정하는 속성입니다. |
|
simple-binding-name 속성과 함께 사용되지 않습니다. 로컬 홈은 항상 클래식 JVM 범위 네임스페이스에 바인드되어야 하므로 해당 값은 ejblocal: 접두부로 시작해야 합니다. |
remote-home-binding-name | 엔터프라이즈 Bean 원격 홈의 바인딩 위치를 지정하는 속성입니다. |
|
simple-binding-name 속성과 함께 사용되지 않습니다. 원격 홈은 클래식 ejblocal: namespac에 바인드될 수 없으므로 해당 값은 클래식 ejblocal: 접두부로 시작할 수 없습니다. |
<interface> | 특정 EJB 비즈니스 인터페이스 또는 인터페이스 없는 보기에 바인딩을 지정하는 <session> 요소의 하위 요소. simple-binding-name, local-home-binding-name 및 remote-home-binding-name 속성과 달리 binding-name 매개변수와 클래스 매개변수가 모두 필요합니다. 실제로 이러한 차이로 인해 속성이 아닌 별도 XML 요소가 필요합니다. 클래스 매개변수는 바인드될 비즈니스 인터페이스 또는 인터페이스 없는 보기 클래스의 패키지 규정 이름을 지정합니다. |
(<session> 요소 내에 하위 요소로 선언됨)
|
simple-binding-name 속성과 함께 사용되지 않습니다. 로컬 인터페이스 및 인터페이스 없는 보기는 항상 클래식 JVM 범위 네임스페이스에 바인드되어야 하므로 이 요소가 로컬 인터페이스 또는 인터페이스 없는 보기에 적용되는 경우 binding-name 값은 ejblocal: 접두부로 시작해야 합니다. |
binding-name | <interface> 요소를 사용하여 바인드된 비즈니스 인터페이스의 바인딩 위치를 지정하는 속성입니다. |
(<session> 요소 내에 하위 요소로 선언됨)
|
<interface> 요소와 함께 필요하며 해당 요소에서만 사용됩니다. 로컬 인터페이스는 항상 클래식 JVM 범위 네임스페이스에 바인드되어야 하므로 로컬 인터페이스에 적용되는 경우 binding-name 값은 ejblocal: 접두부로 시작해야 합니다. |
바인딩 파일 예제 1
<?xml version="1.0" encoding="UTF-8?">
<ejb-jar-bnd xmlns=http://websphere.ibm.com/xml/ns/javaee xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance "xsi:schemaLocation"=
http://websphere.ibm.com/xml/ns/javaee
http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd "version 1.0">
<session name="S01" component-id="Department549/AccountProcessors"/>
<session name="S02" simple-binding-name="ejb/session/S02"/>
<session name="S03">
<interface class="com.ejbs.BankAccountService" binding-name="ejblocal:session/BAS"/>
</session>
</ejb-jar-bnd>
이 바인딩 파일의 결과는 다음과 같습니다.- ejb-name이 S01인 세션 Bean에는 사용자 정의 컴포넌트 ID가 지정되고 해당 Bean에 있는 모든 인터페이스 및 인터페이스 없는 보기의 기본 컴포넌트 ID(애플리케이션 이름/ejb-jar 모듈 이름/Bean 이름)를 대체합니다. 이 Bean의 로컬 인터페이스 및 인터페이스 없는 보기는 ejblocal:Department549/AccountProcessors#<package.qualified.interface.name>에 바인드되는 반면에, 원격 인터페이스는 ejb/Department549/AccountProcessors#<package.qualified.interface.name>에 바인드됩니다.
- ejb-name이 S02인 세션 Bean에는
단일 EJB 3.x 비즈니스 인터페이스 또는 EJB 3.1 인터페이스 없는 보기가
있는 것으로 가정합니다. 또는 로컬 홈, 원격 홈 또는 로컬 홈과 원격 홈이
모두 있는 EJB 3.0 이전 "컴포넌트" 인터페이스를 가질 수 있습니다. 비즈니스 인터페이스 또는 컴포넌트 인터페이스 홈은
ejblocal:ejb/session/S02(로컬인 경우) 또는 ejb/session/S02(원격인 경우)에 바인드됩니다.
S02 Bean에 두 개 이상의 비즈니스 인터페이스 또는 비즈니스 인터페이스와 홈이 있는 경우 simple-binding-name이 명확하지 않습니다. 이 경우, 컨테이너는 각 Bean 인터페이스의 단순 바인딩 이름 ejb/session/S02에 #<package.qualified.interface.name>을 추가하여 바인딩 지정의 명확성을 부여합니다.
- ejb-name이 S03인 세션 Bean에서 EJB 3.x 비즈니스 인터페이스 또는 EJB 3.1 인터페이스 없는 보기(com.ejbs.BankAccountService)는 ejblocal:session/BAS에 바인드됩니다.
다음 절은 이 예제의 확장으로서, XML 배치 디스크립터에서 또는 어노테이션을 통해 선언되는 다양한 유형의 참조 및 인젝션 항목의 대상을 해석하는 요소에 대해 설명합니다.
참조 및 인젝션 대상을 해석하는 사용자 정의 바인딩
이전 절에서는 비즈니스 인터페이스, 홈 및 인터페이스 없는 보기에 대해 사용자 정의 바인딩 이름을 지정하는 방법을 설명했습니다. 이 절에서는 참조, 인젝션 지시문 및 메시지 구동 Bean 대상의 연계 대상을 해석하는 방법을 설명합니다.
요소 또는 속성 | 사용 방법 | 예제 | 주석 |
---|---|---|---|
<jca-adapter> | 메시지 구동 Bean으로 메시지를 전달하기 위한 JCA 1.5 어댑터 활성화 스펙과 메시지 대상 JNDI 위치를 정의합니다. |
|
activation-spec-binding-name 속성이 필요합니다. 해당하는 메시지 구동 Bean이 <message-destination-link> 요소를 사용하여 메시지 대상을 식별하지 못하는 경우, destination-binding-name 속성도 필요합니다. 선택적으로 activation-spec-auth-alias 속성을 포함할 수 있습니다. |
<ejb-ref> | @EJB 어노테이션 또는 ejb-jar.xml 배치 디스크립터의 ejb-ref를 통해 선언되는 ejb-ref 선언의 대상을 해석하여 컴포넌트 범위 java:comp/env 네임스페이스에 선언된 이름과 클래식 JVM 범위 ejblocal: 또는 클래식 글로벌 범위 JNDI 네임스페이스의 대상 엔터프라이즈 Bean의 이름을 연결합니다. |
|
name 및 binding-name 속성이 필요합니다. |
<message-driven> | 메시지 구동 Bean의 바인딩 지정 그룹을 선언합니다. |
|
name 속성 및 <jca-adapter> 하위 요소가 필요합니다. |
<message-destination> | Java EE 모듈 배치 디스크립터에 정의된 논리 이름인 메시지 대상 이름과 JNDI 네임스페이스의 실제 이름인 특정 글로벌 JNDI 이름을 연관시킵니다. 그러면 Java EE 모듈 배치 디스크립터의 <message-destination-ref> 요소 또는 메시지 대상을 삽입하는 @Resource 인젝션 지시문이 <message-destination-line> 요소를 사용하여 대상 논리 이름으로 이 메시지 대상을 참조할 수 있습니다. 이 경우 정의된 각 message-destination-ref에 대한 개별 <message-destination-ref> 바인딩 항목이 바인딩 파일에서 필요하지 않습니다. |
|
name 및 binding-name 속성이 필요합니다. |
<message-destination-ref> | @Resource 어노테이션 또는 ejb-jar.xml의 message-destination-ref를 통해 선언된 message-destination-ref 선언의 대상을 해석하여 컴포넌트 범위 java:comp/env 네임스페이스에 선언된 이름과 글로벌 JNDI 네임스페이스의 대상 자원 환경의 이름을 연결합니다. |
|
name 및 binding-name 속성이 필요합니다. |
<resource-ref> | @Resource 어노테이션 또는 ejb-jar.xml의 resource-ref를 통해 선언된 resource-ref 선언의 대상을 해석하여 컴포넌트 범위 java:comp/env 네임스페이스에 선언된 이름과 글로벌 JNDI 네임스페이스의 대상 자원의 이름을 연결합니다. |
|
name 및 binding-name 속성이 필요합니다. authentication-alias 또는 custom-login-configuration 속성을 포함할 수 있습니다. |
<resource-env-ref> | @Resource 어노테이션 또는 ejb-jar.xml의 resource-env-ref를 통해 선언된 resource-env-ref 선언의 대상을 해석하여 컴포넌트 범위 java:comp/env 네임스페이스에 선언된 이름과 글로벌 JNDI 네임스페이스의 대상 자원 환경의 이름을 연결합니다. |
|
name 및 binding-name 속성이 필요합니다. |
<env-entry> | 문자열 형식으로 표시된 지정된 값 또는 기본 초기 컨텍스트에 적용된 지정된 검색 이름에서 JNDI 검색을 사용하여 액세스할 수 있는 오브젝트로 환경 항목을 대체합니다. |
|
이름 속성 및 값 또는 바인딩 이름 속성이 필요하지만 둘 다 필요하지는 않습니다. |
<data-source> | @DataSourceDefinition 어노테이션 또는 애플리케이션의 데이터 소스 요소를 통해 선언된 데이터 소스 정의 또는 모듈 배치 디스크립터를 관리 자원으로 대체합니다. |
|
name 및 binding-name 속성이 필요합니다. |
이름 | 참조/대상 연계의 "소스" 측을 정의하고 일반적으로 컴포넌트 특정 java:comp/env 네임스페이스에서 이름 지정 위치를 식별하는 속성입니다(예를 들어, ejb-ref, resource-ref, resource-env-ref, message-destination 또는 message-destination-ref에서). |
|
|
binding-name | ejb-ref, resource-ref, resource-env-ref, message-destination 또는 message-destination-ref에서와 같이 참조/대상 연계의 "대상" 측을 정의하는 클래식 ejblocal: 또는 클래식 글로벌 범위 JNDI 네임스페이스 또는 java:global 네임스페이스에서 네이밍 위치를 식별하는 속성입니다. |
|
|
value | env-entry 바인딩에 사용할 값을 지정하는 속성입니다. |
|
|
activation-spec-binding-name | 메시지 구동 Bean으로 메시지를 전달하는 데 사용할 JCA 1.5 어댑터와 연관된 활성화 스펙의 JNDI 위치를 식별하는 속성 |
|
이 이름은 WebSphere Application Server에 정의하는 JCA 1.5 활성화 스펙의 이름과 일치해야 합니다. |
activation-spec-auth-alias | JCA 자원 어댑터에 대한 연결 인증에 사용되는 J2C 인증 별명의 이름을 식별하는 선택적 속성. J2C 인증 별명은 JCA 자원 어댑터에 새 연결 작성을 인증하는 데 사용되는 사용자 ID 및 비밀번호를 지정합니다. |
|
이 이름은 WebSphere Application Server에 정의하는 J2C 권한 별명 이름과 일치해야 합니다. |
destination-binding-name | 메시지 구동 Bean이 JNDI 네임스페이스에서 해당 JMS 대상을 찾기 위해 사용하는 JNDI 이름을 식별하는 속성 |
|
이 이름은 WebSphere Application Server에 정의하는 JMS 큐 또는 토픽의 이름과 일치해야 합니다. |
authentication -alias | <resource-ref> 바인딩 요소의 선택적 하위 요소입니다. 자원 참조가 연결 팩토리용인 경우 선택적 JAAS 로그인 구성을 지정할 수 있습니다(이 경우 단순 인증 별명 이름). |
|
이 이름은 WebSphere Application Server에 정의하는 JAAS 인증 별명의 이름과 일치해야 합니다. |
custom-login-configuration | <resource-ref> 바인딩 요소의 선택적 하위 요소입니다. 자원 참조가 연결 팩토리용인 경우 선택적 JAAS 로그인 구성을 지정할 수 있습니다(이 경우 한 세트의 특성 - 이름/값 쌍). |
|
이 이름은 WebSphere Application Server에 정의하는 JAAS 로그인 구성의 이름과 일치해야 합니다. |
바인딩 파일 예제 2
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" "xmlns:xsi"=
"http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee"
"http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd version" "1.0">
<session name="S01" component-id="Department549/AccountProcessors"/>
<session name="S02" simple-binding-name="ejb/session/S02"/>
<session name="S03">
<interface class="com.ejbs.BankAccountService"
binding-name="ejblocal:session/BAS"/>
<ejb-ref name="com.ejbs.BankAccountServiceBean/goodBye"
binding-name="ejb/session/S02"/>
<resource-ref name="com.ejbs.BankAccountServiceBean/dataSource"
binding-name="jdbc/Default"/>
</session>
<message-driven name="MO1">
<jca-adapter activation-spec-binding-name="jms/InternalProviderSpec"
destination-binding-name=jms/"ServiceQueue"/>
</message-driven>
<session name="S04" simple-binding-name="ejb/session/S04">
<resource-ref name="ejbs.S04Bean/dataSource"
binding-name="jdbc/Default">
<authentication-alias name="defaultlogin"/>
</resource-ref>
</session>
<session name="S05">
<interface class="com.ejbs.InventoryService"
binding-name="ejb/session/S05Inventory"/>
<resource-ref name="ejbs.S05Bean/dataSource"
binding-name="jdbc/Default">
<custom-login-configuration name="customLogin">
<property name="loginParm1" value="ABC123"/>
<property name="loginParm2" value="DEF456"/>
</custom-login-configuration>
</resource-ref>
</session>
</ejb-jar-bnd>
이 바인딩 결과는 다음과 같습니다.- S01, S02 및 S03 세션 Bean에 대한 비즈니스 인터페이스, 홈 및 인터페이스 없는 보기 바인딩은 이전 예제와 같습니다.
- ejb-name이 S03인 세션 Bean에는 이제 다음과
같은 두 개의 참조 대상 해석 바인딩이 포함됩니다.
- ejb-ref 바인딩은 java:comp/env/com.ejbs.BankAccountServiceBean/goodBye에
정의된 EJB 참조를 애플리케이션 서버 루트 JNDI 컨텍스트 내 JNDI 위치 ejb/session/S02로
해석합니다. 또한 EJB 참조를 com.ejbs.BankAccountServiceBean 클래스에서 "goodBye"
인스턴스 변수로의 @EJB 인젝션으로도 정의할 수 있습니다. 참고: ejb/session/S02는 이와 동일한 바인딩 파일에도 정의된 세션 Bean S02의 JNDI 위치이며 이는 해당 참조가 이름이 S02인 세션 Bean을 가리킴을 의미합니다.
- resource-ref 바인딩은 java:comp/env/com.ejbs.BankAccountServiceBean/dataSource에 정의된 자원 참조를 JNDI 위치 jdbc/Default로 해석합니다. 자원 참조는 com.ejbs.BankAccountServiceBean 클래스에서 "dataSource" 인스턴스 변수로의 @Resource 인젝션으로도 정의될 수 있습니다.
- ejb-ref 바인딩은 java:comp/env/com.ejbs.BankAccountServiceBean/goodBye에
정의된 EJB 참조를 애플리케이션 서버 루트 JNDI 컨텍스트 내 JNDI 위치 ejb/session/S02로
해석합니다. 또한 EJB 참조를 com.ejbs.BankAccountServiceBean 클래스에서 "goodBye"
인스턴스 변수로의 @EJB 인젝션으로도 정의할 수 있습니다.
- ejb-name이 M01인 메시지 구동 Bean에 대한 바인딩이 정의됩니다. MDB는 JCA 1.5 활성화 스펙이 jms/InternalProviderSpec을 이름으로 하여 WebSphere Application Server에 정의된 JCA 1.5 어댑터를 사용하여 WebSphere Application Server에 정의된 JMS 대상(JNDI 이름이 jms/ServiceQueue임)에서 메시지를 수신합니다.
- ejb-name이 S04인 세션 Bean은 단일 비즈니스 인터페이스 또는 인터페이스 없는 보기(원격인 경우 ejb/session/S04에 바인드되고 로컬인 경우 ejblocal:ejb/session/S04에 바인드됨)를 갖는 것으로 가정합니다. 이름이 java:comp/env/ejbs/S04Bean/dataSource인 resource-ref를 갖습니다. 이는 또한 dataSource라는 변수에 @Resource가 삽입된 ejbs.S04Bean 클래스일 수 있습니다. 이 resource-ref는 JNDI 위치 jdbc/Default로 해석됩니다. resource-ref는 J2C 연결을 참조하며 WebSphere Application Server에 정의된 defaultlogin이라는 단순 인증 별명을 사용하여 이 자원에 연결됩니다.
- ejb-name이 S05인 세션 Bean이 구현한 클래스 이름이 com.ejbs.InventoryService인 인터페이스에 대해 비즈니스 인터페이스 바인딩이 정의됩니다. 이 인터페이스는 "ejblocal:" 접두부가 추가되지 않기 때문에 원격으로 가정되므로 클래식 글로벌 범위 네임스페이스에서 서버 루트 JNDI 컨텍스트의 ejb/session/S05Inventory에 바인드됩니다. 이 세션 Bean이 구현한 기타 모든 비즈니스 인터페이스에는 기본 클래식 바인딩이 지정됩니다. 이 Bean에는 JNDI 위치 jdbc/Default로 해석되는 이름 java:comp/env/ejbs.S05Bean/dataSource를 갖는 resource-ref(또는 ejbs.S05Bean 클래스에서 "dataSource" 변수로의 @Resource 인젝션)가 있습니다. resource-ref는 J2C 연결을 참조하며 두 개의 이름-값 쌍을 포함하는 사용자 정의 로그인 구성을 사용하여 이 자원에 연결됩니다.
바인딩 파일 예제 3
이 절의 뒤에서 설명하는 이 예제는 동일한 WebSphere Application Server 셀의 애플리케이션 서버 인스턴스에서 JNDI 검색을 수행하는 EJB 참조 바인딩을 정의하고 해석하는 방법을 보여줍니다. 이 예제는 두 개의 EJB Bean을 사용합니다. 즉, simple-binding-name 속성을 사용하여 명시적 바인딩을 정의하는 피호출 Bean과, EJB 인젝션을 수행하고 연관된 바인딩 파일에서 ejb-ref 요소를 사용하여 참조가 다른 애플리케이션 서버 프로세스에 상주하는 피호출 Bean을 가리키는 것으로 해석하는 호출 Bean을 사용합니다.
ibm-ejb-jar-bnd.xml(호출된 bean)
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee"
"http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd" version="1.0">
<session name="FacadeBean" simple-binding-name="ejb/session/FacadeBean"/>
</ejb-jar-bnd>
이 바인딩 파일 컨텐츠는 ejb-name이
"FacadeBean"인 세션 Bean이 단일 비즈니스 인터페이스를 구현하는 것으로
가정하므로, <interface> 하위 요소에 대한 대안으로 simple-binding-name
속성을 사용할 수 있습니다. 이 경우 FacadeBean은
FacadeBean이 상주하는 Application Serve의 서버 루트 JNDI 컨텍스트에서
ejb/session/FacadeBean에 바인드되는 단일 원격 비즈니스 인터페이스를 구현합니다.
코드 스니펫(호출 Bean)
@EJB(name="ejb/FacadeRemoteRef")
FacadeRemote remoteRef;
try {
output = remoteRef.orderStatus(input);
}
catch(Exception e){
// Handle exception, etc.
}
이 코드 스니펫은 FacadeRemote 유형의 "remoteRef" 인스턴스 변수로의
EJB 자원 인젝션을 수행합니다. 이 인젝션은 "name" 매개변수를 대체하고 결과
ejb-ref 참조 이름을 ejb/FacadeRemoteRef로 설정합니다. 이 코드는 주입된 참조에 비즈니스 메소드를
호출합니다. ibm-ejb-jar-bnd.xml(호출 Bean)
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee"
"xmlns:xsi="
"http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee"
"http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd" version="1.0">
<session name="CallingBean">
<ejb-ref name="ejb/FacadeRemoteRef"
binding-name="cell/nodes/S35NLA1/servers/S35serverA1/ejb/session/FacadeBean"/>
</session>
</ejb-bnd-jar>
마지막으로, 이 바인딩 파일은
ejb-ref 이름이 ejb/FacadeRemoteRef인 EJB 참조가 클래식 글로벌 범위 JNDI 이름
cell/nodes/S35NLA1/servers/S35serverA1/ejb/session/FacadeBean을 가리킨다고 해석합니다.
이 클래식 글로벌 범위 JNDI 이름은 호출 Bean의
WebSphere Application Server 셀에서 "S35NLA1" 노드에 있는 "S35serverA1" 서버의 서버 루트 컨텍스트
아래의 ejb/session/FacadeBean에 바인드된 인터페이스를 나타냅니다. 다른 WebSphere Application Server 셀 내부의
위치를 가리키려면 표준 JNDI 이름 대신 CORBAName 스타일 이름을 사용하면 됩니다. ibm-ejb-jar-bnd.xml 파일 수정 방법에 대한 지시사항은 애플리케이션 파일 업데이트 방법 주제를 참조하십시오.
주입과 참조의 관계
주입 지시문과 참조 선언은 일대일 관계입니다. 즉, 모든 주입은 특정 유형의 참조를 암묵적으로 정의하며 반대로 모든 참조는 선택적으로 주입을 정의할 수도 있습니다. 인젝션 어노테이션은 XML 배치 디스크립터에 참조를 정의하지 않고 어노테이션을 통해 참조를 정의하는 메커니즘으로 생각할 수 있습니다.
인젝션은 기본적으로 인젝션을 수행하는 컴포넌트의 패키지 규정 클래스 이름, 슬래시(/) 및 삽입되는 변수 또는 특성 이름의 순서로 이름이 구성되는 참조를 정의합니다. 예를 들어, com.ejbs.AccountService 클래스에서 "depositService" 변수 또는 특성에 수행되는 인젝션의 결과 참조 이름은 java:comp/env/com.ejbs.AccountService/depositService입니다. 그러나 인젝션 지시문에 선택적 "name" 매개변수를 지정하면 기본값을 대체하여 "name" 매개변수 값에 따라 참조 이름이 지정됩니다.
이 규칙을 알고 있으면 바인딩 파일을 사용하여 XML 배치 디스크립터에 선언된 참조의 대상을 해석하고 어노테이션 인젝션 지시문으로 암묵적으로 선언된 참조의 대상을 해석할 수 있는 방법을 쉽게 이해할 수 있습니다. 인젝션 어노테이션에 "name" 매개변수 값을 사용하거나, "name" 매개변수가 지정되지 않은 경우 XML 배치 디스크립터에 선언된 참조의 이름인 것처럼 클래스 이름과 변수/특성 이름의 기본 참조 이름을 사용하면 됩니다.
EJB 참조 및 EJB 인젝션에 대한 기본 해석: EJB 링크 및 자동 링크 기능
EJB 링크 및 자동 링크 기능은 참조 컴포넌트와 동일한 애플리케이션 및 애플리케이션 서버 프로세스에 패키지된 EJB 컴포넌트에 대한 참조를 해석하는 두 개의 서로 다른 메커니즘입니다. EJB 링크와 자동 링크 둘 다 바인딩 정보를 사용하여 EJB 참조를 명시적으로 해석하지 않아도 됩니다. EJB 링크 기능은 EJB 스펙으로 정의되는 반면에, 자동 링크 기능은 WebSphere Application Server 확장입니다.
EJB 링크 및 자동 링크 기능은 서로 다른 검색 기준을 사용하여 대상 지정된 Bean 컴포넌트를 찾습니다. EJB 링크는 명시적으로 지정된 Bean 이름을 사용하여 대상 지정된 Bean 컴포넌트를 검색합니다. 자동 링크는 Bean이 구현하는 인터페이스를 사용하여 대상 지정된 Bean 컴포넌트를 검색합니다. 명시적 바인딩은 제공되지 않지만 Bean 이름이 제공되는 경우, EJB 링크 기능이 사용됩니다. 명시적 바인딩이 제공되지 않고 Bean 이름이 제공되지 않은 경우, 자동 링크 기능이 사용됩니다. EJB 링크 및 자동 링크 기능은 동일 검색 프로세스의 일부로 함께 사용되지 않습니다.
검색 기준을 제외하고 EJB 링크 및 자동 링크 기능은 비슷합니다. 두 기능 모두 특정 모듈을 먼저 검색한 후, 필요하면 동일 애플리케이션 및 애플리케이션 서버 프로세스에서 기타 모듈을 검색합니다. 두 기능 모두 검색 기준은 정확히 하나의 Bean 컴포넌트로 해석되어야 하며, 검색 기준이 여러 개의 Bean 컴포넌트로 해석되면 오류 조건으로 간주합니다. 애플리케이션 서버가 여러 개의 Bean 컴포넌트 중 어느 것을 사용해야 하는지 모르기 때문에 오류 조건이 존재합니다. 이 경우, com.ibm.websphere.ejbcontainer.AmbiguousEJBReferenceException 예외가 발생합니다. 참조 컴포넌트가 대상 지정된 Bean 컴포넌트를 찾으려고 시도하면 런타임 시 이 예외가 발생합니다.
- Bean 컴포넌트 이름만 지정합니다(예: MyBean).
- 대상 지정된 Bean 컴포넌트 다음에 # 문자가 오고 그 뒤에 Bean 컴포넌트 이름이 오는 실제 모듈 파일의 이름(확장자 포함)을 지정합니다(예: myModule.jar#MyBean).
- 대상 지정된 Bean 컴포넌트, 슬래시 문자(/), 그 뒤에 Bean 컴포넌트 이름이 오는 모듈의 논리 이름을 지정합니다(예: MyModule/MyBean).
선택적으로 ejb-jar 모듈의 EJB 배치 디스크립터에 module-name 요소를 사용하여 모듈의 논리 이름을 지정하거나, EJB 컨텐츠가 들어 있는 WAR 모듈의 웹 배치 디스크립터 파일에 module-name 요소를 사용할 수 있습니다. EJB 컨텐츠가 들어 있는 WAR 모듈의 경우, EJB 배치 디스크립터에 지정된 module-name 요소는 무시되고 웹 배치 디스크립터에 지정된 module-name 요소가 처리됩니다. 배치 디스크립터에 module-name 값이 지정되지 않은 경우, 모듈에는 기본 논리 이름이 지정됩니다. 기본 논리 모듈 이름은 모듈 파일의 기본 이름에서 확장자를 뺀 이름입니다. 예를 들어, 모듈 파일 MyModule.jar의 기본 논리 모듈 이름은 MyModule입니다.
실제 모듈 파일 이름을 지정하는 것은 모듈이 논리 이름을 갖는 경우에도 여전히 지원됩니다. 모듈의 논리 이름을 지정하는 것은 배치 디스크립터에 논리 모듈 이름이 구성되지 않은 경우에도 여전히 지원됩니다. 이 경우, 모듈의 기본 이름이 모듈의 논리 이름으로 사용됩니다.
임베드 가능한 EJB 컨테이너는 모든 EJB 링크 형식을 지원합니다. 물리적 모듈 파일 형식을 지원하기 위해 임베드 가능한 EJB 컨테이너는 동일한 기본 이름으로 여러 모듈을 시작하는 것을 허용하지 않습니다.
자동 링크는 특정 사용법 시나리오에서 EJB 참조 대상을 명시적으로 해석하지 않아도 되는 WebSphere Application Server의 부가 기능입니다. WebSphere Application Server V8에서는 각 WebSphere Application Server 프로세스의 경계 내에서 자동 링크가 구현됩니다. 자동 링크 알고리즘은 다음과 같이 실행됩니다.
제품의 EJB 컨테이너는 정해진 EJB 모듈에서 EJB 참조를 발견하면 먼저 사용자가 모듈 바인딩 파일에 항목을 포함시켜 해당 참조의 대상을 명시적으로 해석했는지 여부를 확인합니다. 바인딩 파일에서 명시적인 대상 해석을 찾지 못하면 컨테이너는 참조 내에 사용자가 정의한 인터페이스 유형 또는 인터페이스 없는 보기를 구현하는 엔터프라이즈 Bean을 참조 모듈에서 검색합니다.
모듈에서 인터페이스 또는 인터페이스 없는 보기를 구현하는 엔터프라이즈 Bean을 하나만 찾으면, 해당 엔터프라이즈 Bean을 EJB 참조 대상으로 사용합니다. 컨테이너가 모듈에서 해당 유형의 엔터프라이즈 Bean을 찾을 수 없으면, 검색 범위를 모듈이 포함된 애플리케이션으로 확장하여 해당 애플리케이션에서 참조 모듈과 동일한 애플리케이션 서버에 지정된 기타 모듈을 검색합니다. 여기서도 컨테이너가 참조 모듈과 동일한 서버에 지정된 애플리케이션의 기타 모듈에서 대상 인터페이스 또는 인터페이스 없는 보기를 구현하는 엔터프라이즈 Bean을 하나만 찾으면 해당 엔터프라이즈 Bean을 참조 대상으로 사용합니다.
자동 링크 범위는 EJB 참조가 나타나는 애플리케이션과 참조 모듈이 지정되는 애플리케이션 서버로 제한됩니다. 다른 애플리케이션의 엔터프라이즈 Bean, 다른 애플리케이션 서버에 지정된 모듈의 엔터프라이즈 Bean 또는 WebSphere Application Server 클러스터에 지정된 모듈에 상주하는 엔터프라이즈 Bean에 대한 참조는 EJB 모듈의 ibm-ejb-jar-bnd.xml 파일 또는 웹 모듈의 ibm-web-bnd.xmi 파일에서 참조 대상 바인딩을 사용하여 명시적으로 해석해야 합니다.
자동 링크는 EJB 참조에만 지원되며 다른 참조 유형에는 지원되지 않습니다. 그러나 EJB 컨테이너, 웹 컨테이너 및 애플리케이션 클라이언트 컨테이너에서는 지원됩니다. 또한 자동 링크 기능의 범위가 참조 모듈이 지정된 서버 또는 Java EE 클라이언트 컨테이너의 경우에는 클라이언트 컨테이너가 해당 JNDI 부트스트랩 서버로 구성된 서버로 제한되므로 주로 개발 환경과 기타 단일 서버 사용법 시나리오에서 유용합니다. 이러한 현재 한계에도 불구하고 EJB 참조를 명시적으로 해석해야 하는 필요성을 없애므로 이는 개발 시 상당한 가치가 있습니다.
EJB 및 자원 참조 및 인젝션에 대한 해석: 검색 기능
검색 기능은 명시적 JNDI 이름을 기준으로 EJB 또는 자원에 대한 참조를 해석하는 메커니즘으로 EJB 3.1 스펙에 의해 정의됩니다. javax.ejb.EJB 어노테이션 또는 javax.annotation.Resource 어노테이션에서 lookup 속성을 지정할 수 있습니다. ejb-jar.xml 파일에서 해당 XML 속성은 <ejb-ref>, <ejb-local-ref>, <env-entry>, <resource-ref>, <resource-env-ref> 또는 <message-destination-ref> 요소 중 하나의 <lookup-name>입니다. lookup 또는 <lookup-name>은 java:comp/env 이름 지정 컨텍스트와 관련된 JNDI 이름입니다.
EJB 참조에서 lookup 또는 <lookup-name>은 beanName 또는 <ejb-link>와 함께 지정하면 안 됩니다. 관리 콘솔은 lookup-name 및 ejb-link를 읽기 전용으로 표시합니다. 그러나 JNDI 이름이 애플리케이션 설치 단계인 "Bean으로 EJB 참조 맵핑"에서 지정된 경우, 이 이름이 lookup-name 또는 ejb-link 값을 대체합니다.
애플리케이션에 정의된 환경 항목 대체
<env-entry name="name" value="value"/>
여기서 name은 애플리케이션에
정의된 env-entry 이름이고 value는 문자열 형식으로 표시된 env-entry에 지정된 값입니다. value의
문자열은 env-entry-value를 사용하여 배치 디스크립터에 값이 지정된 것처럼 환경 항목의 유형에 따라 구문 분석됩니다. 예를 들어, 다음과 같습니다. <env-entry name="java:module/env/taxYear" value="2010"/>
"java:module/env/taxYear" 이름의 env-entry를
"2010" 값과 연관시킵니다. <env-entry name="name" binding-name="lookupName"/>
여기서 name은
애플리케이션에 정의된 env-entry 이름이고 lookupName은 기본 초기 컨텍스트에서 검색에 적용되는
경우 해석되는 JNDI 이름입니다. 예를 들어, 다음과 같습니다. <env-entry name="java:module/env/taxYear" binding-name="cell/persistent/MyApp/MyModule/taxYear"/>
"java:module/env/taxYear" 이름의 env-entry를
"cell/persistent/MyApp/MyModule/taxYear"의 기본 초기 컨텍스트 검색 조작에서 리턴된
값과 연관시킵니다. 사용자가 JNDI 오브젝트 바인딩을 작성합니다. 바인드된 오브젝트의 클래스를 연관된 env-entry의 오브젝트 유형에 지정할 수 있어야 합니다. 환경 항목은 애플리케이션 레벨과 EJB, 웹 및 클라이언트 모듈에서 정의할 수 있습니다. 해당 레벨은 바인딩 파일 application-bnd.xml, ejb-jar-bnd.xml, web-app-bnd.xml, application-client-bnd.xml에 해당합니다.
데이터 소스 정의 대체
Java EE 6에서 @DataSourceDefinition 어노테이션 또는 <data-source> 배치 디스크립터 항목을 사용하여 데이터 소스를 정의하는 애플리케이션을 개발할 수 있습니다.
<data-source name="name" binding-name="lookupName"/>
여기서 name은
애플리케이션에 정의된 env-entry 이름이고 lookupName은 기본 초기 컨텍스트에서 검색에 적용되는
경우 해석되는 JNDI 이름입니다. 예를 들어, 다음과 같습니다. <data-source name="java:module/env/myDS" binding-name="jdbc/DB2DS"/>
"java:module/env/myDS"에서 검색을 실행하여 기본 초기 컨텍스트에 상대적인
"jdbc/DB2DS" 이름으로 바인드되는 데이터 소스로 해석됩니다. 예를 들어, 관리 콘솔을 통해 jdbc/DB2DS에 바인드된 데이터 소스를 작성할 수 있습니다. 데이터 소스는 애플리케이션 레벨과 EJB, 웹 및 클라이언트 모듈에서 정의할 수 있습니다. 해당 레벨은 바인딩 파일 application-bnd.xml, ejb-jar-bnd.xml, web-app-bnd.xml, application-client-bnd.xml에 해당합니다.
클러스터 및 서버 간 환경의 이름 지정 고려사항
cell/clusters/<cluster-name>/<name-binding-location>
예를 들어, Application Server 루트 컨텍스트 내부에 EJB 인터페이스 바인딩 위치를 지정하는
경우: ejb/Department549/AccountProcessors/CheckingAccountReconciler
cell/clusters/Cluster47/ejb/Department549/AccountProcessors/CheckingAccountReconciler
cell/nodes/<node-name>/servers/<server-name>/<name binding location>
또한 Application Server 루트 컨텍스트 내부에 EJB 인터페이스 바인딩 위치를 지정하는
경우: ejb/Department549/AccountProcessors/CheckingAccountReconciler
cell/nodes/S47NLA1/servers/Server47A1/ejb/Department549/AccountProcessors/CheckingAccountReconciler
사용자 정의 EJB 확장 설정
WebSphere Application Server EJB 확장 설정 값을 지정할 경우, EJB 모듈 확장 파일을 사용하여 해당 모듈에서 특정 EJB 유형에 이러한 설정을 지정할 수 있습니다. 정의되는 확장 유형에 따라 EJB JAR 파일의 META-INF 디렉토리에 두 파일 중 하나 또는 둘 다를 배치하여 EJB 3.x 모듈에 대한 확장 설정 정보를 지정하십시오. 두 파일의 이름은 ibm-ejb-jar-ext.xml 및 ibm-ejb-jar-ext-pme.xml입니다.
- xmi 파일 형식에 선언된 바인딩과 확장은 해당 파일의 요소에 첨부된 고유 ID 번호를 명시적으로 참조하는, 대응하는 ejb-jar.xml 배치 디스크립터 파일의 존재 여부에 따라 다릅니다. 이 시스템은 더 이상 EJB 3.0 이상 모듈에 실행할 수 없으므로 더 이상 모듈에 ejb-jar.xml 배치 디스크립터가 포함되지 않아도 됩니다.
- xmi 파일 형식은 WebSphere 개발 도구와 시스템 관리 기능만으로 시스템을 편집할 수 있도록 디자인되었습니다. 이는 실질적으로 WebSphere 내부 구현의 일부이며 파일 구조는 외부적으로 문서화되지 않았습니다. 이로 인해 개발자가 바인딩 또는 확장 파일을 수동으로 작성 또는 편집하거나, 지원되는 방법을 사용하여 WebSphere 독립 빌드 프로세스의 일부로 작성할 수 없었습니다.
- XML 기반 확장 파일 형식은 ejb-jar.xml에 인코드된 ID 번호를 참조하지 않고 해당 EJB 이름으로 EJB 컴포넌트를 참조합니다. 모듈의 각 EJB 컴포넌트는 기본적으로 또는 개발자가 명시적으로 지정하여 고유한 EJB 이름을 가지므로, 바인딩 및 확장자를 대상으로 지정하는 명확한 방법을 제공합니다.
- 새 바인딩 및 확장 파일 형식은 XML을 기반으로 하며, 구조를 외부적으로 문서화하는 XSD(XML Schema Definition) 파일이 제공됩니다. 일반적인 많은 XML 파일 편집기가 이러한 .xsd 파일을 이용하여 구문 확인 및 코드 완료 기능을 지원할 수 있습니다. 따라서 이제 개발자는 WebSphere Application Server 인프라에 관계없이 일반 XML 편집기 또는 자신이 선택한 스크립트 시스템을 사용하여 바인딩 및 확장 파일을 생성하고 편집할 수 있습니다.
META-INF/ibm-ejb-jar-ext.xml에 정의된 확장자
요소 또는 속성 | 설명 | 예제 | 사용법 참고 |
---|---|---|---|
<session> | 세션 Bean의 확장 설정 그룹을 선언합니다. |
|
name 속성이 필요합니다. 유효하려면 하나 이상의 확장 설정 정의 하위 요소도 포함시키십시오. |
<message-driven> | 메시지 구동 Bean의 확장 설정 그룹을 선언합니다. |
|
name 속성이 필요합니다. 유효하려면 하나 이상의 확장 설정 정의 하위 요소도 포함시키십시오. |
요소 또는 속성 | 설명 | 예제 | 사용법 참고 |
---|---|---|---|
<time-out> | <session> 요소의 하위 요소로, 이 시간이 지나면 Stateful 세션 Bean을 더 이상 사용할 수 없게 되는 메소드 호출 간격(초)을 선택적으로 선언합니다. |
|
value 속성(양의 정수)이 필요합니다.
참고: Stateful 세션 Bean에만 적용 가능하며, Stateless Bean에서
사용해서는 안됩니다.
속성 기본값: 300(5분) |
<bean-cache> | Stateful 세션 Bean의 Bean 활성화/비활성화 설정을 선언하는 데 사용되는 <session> 요소의 하위 요소입니다. |
|
적용하려면 activation-policy 속성도 포함시켜야 합니다. |
activation-policy | Bean 인스턴스를 활성화 및 비활성화할 수 있는
조건을 선언하는 <bean-cache> 요소의 속성입니다. Stateful 세션 Bean에만 적용 가능합니다. 허용 가능한 값과 의미는 다음과 같습니다.
|
|
속성 기본값: Stateful 세션 Bean의 경우 ONCE |
요소 또는 속성 | 설명 | 예제 | 사용법 참고 |
---|---|---|---|
<global-transaction> | (글로벌 트랜잭션 제한시간의 서버 설정을 대체하여) 이러한 특정 EJB 유형으로 시작된 트랜잭션에서 사용할 트랜잭션 제한시간(초)을 선언하는 데 사용할 수 있고 이 EJB 유형이 이기종 웹 서비스 환경에서 웹 서비스 원자적 트랜잭션을 통해 수신된 글로벌 트랜잭션 컨텍스트를 전파하는지 여부를 선언할 수도 있는 <session> 및 <message-driven> 요소의 하위 요소. |
|
transaction-time-out 또는
send-wsat-context 속성 중 최소한 하나가 필요합니다. 속성 기본값: transaction-time-out에 대한 서버 트랜잭션 제한시간 설정(send-wsat-context의 경우 FALSE) |
<local-transaction> | 로컬 트랜잭션과 관련된 설정을 선언하는 데 사용할 수 있는
<session> 및 <message-driven> 요소의 하위 요소입니다.
지원되는 속성은
boundary, resolver 및 unresolved-action입니다.
이러한 속성은 컴포넌트에 대해 글로벌 트랜잭션이 없을 때마다
컨테이너가 설정하는 컨테이너의 로컬 트랜잭션 포함(LTC) 환경 작동을
구성합니다. 각 속성의 의미는 다음과 같습니다. 경계 이 설정은 모든 포함된 자원 관리자 로컬 트랜잭션(RMLT)을 완료해야 하는
포함 경계를 지정합니다. 가능한 값은 다음과 같습니다.
분석기 이 설정은 RMLT 시작 및 종료의 책임을 지는 컴포넌트를 지정합니다.
가능한 값은 다음과 같습니다.
분석되지 않은 조치 이 설정은 해당 트랜잭션이 LTC 경계 범위 끝에
해결되지 않고 분석기가
애플리케이션으로 설정된 경우 컨테이너가 RMLT에 요청하는 지시를 지정합니다. 가능한 값은 다음과 같습니다.
|
|
boundary, resolver 또는
unresolved-action 속성 중 최소한 하나가 필요합니다.
속성 기본값:
|
요소 또는 속성 | 설명 | 예제 | 사용법 참고 |
---|---|---|---|
<method> | <method-session-attribute> 및 <run-as-mode>
요소의 하위 요소로, 정해진 설정이 적용되는 메소드 이름, 메소드 서명 또는
메소드 유형을 지정하는 데 사용됩니다.
지원되는 속성은
type, name 및 params입니다. 각 속성은 다음과 같이 설명됩니다. 유형
name 설정이 적용되는 메소드 이름, 또는 이름에 관계없이 설정이 모든 메소드에 적용될 경우에는 별표(*)입니다. params 설정이 적용되는 메소드의 매개변수 서명입니다. 이 서명을 사용하여 두 개 이상의 단일 메소드가 동일한 이름을 사용하는 경우 특정 메소드를 고유하게 규정할 수 있습니다. 매개변수 서명은 쉼표로 분리된 Java 유형 목록입니다. 기본 유형은 이름만 사용하여 지정됩니다. 기본이 아닌 유형은 Java 패키지를 포함하는 완전한 클래스 또는 인터페이스 이름을 사용하여 지정되며, Java 유형 배열은 배열 요소 유형 뒤에 하나 이상의 대괄호 쌍을 사용하여 지정됩니다(예: int[][]). |
|
|
<run-as-mode> | <session> 및 <message-driven> 요소의 하위 요소로, 메소드가 실행되는 동안 정해진 EJB 메소드가 다른 메소드 호출 시에 사용되도록 보안 ID를 선언하는 데 사용할 수 있습니다. 호출자 ID(mode = CALLER_IDENTITY), EJB 서버 ID(mode = SYSTEM_IDENTITY) 또는 특정 보안 역할의 ID(mode = SPECIFIED_IDENTITY)를 사용하도록 ID를 설정할 수 있습니다. |
|
mode 속성 및 <method> 하위 요소가 필요합니다. mode가 SPECIFIED_IDENTITY이면, <specified-identity 하위 요소도 필요합니다. |
<start-at-app-start> | 애플리케이션에서 EJB 유형이 처음 사용된 시점이 아니라 애플리케이션이 처음 시작된 시점에서 지정된 EJB 유형이 초기화된 EJB 컨테이너를 알려주는 데 사용할 수 있는 <session> 및 <message-driven> 요소의 하위 요소. |
|
value 속성이 필요합니다. 속성 기본값: 메시지 구동 Bean 이외의 Bean의 경우 FALSE(애플리케이션이 EJB를 처음으로 사용할 때 EJB 유형을 초기화함). 메시지 구동 Bean의 경우 항상 TRUE입니다. |
<resource-ref> | <session> 및 <message-driven> 요소의 하위 요소로, Java EE 자원 참조에 추가 설정(예: 참조별로
참조하는 연결을 통해 구동된 트랜잭션에서 사용될 분리 레벨)을 선언하는 데
사용할 수 있습니다. 허용 가능한 속성으로는 isolation-level이 있습니다.
속성은 다음과 같이 정의됩니다. isolation-level
|
|
name 속성이 필요합니다. 적용하려면 isolation-level 속성도 포함시켜야 합니다. |
META-INF/ibm-ejb-jar-ext-pme.xml 파일에 정의된 확장기능
요소 또는 속성 | 설명 | 예제 | 사용법 참고 |
---|---|---|---|
<internationalization> | EJB 유형이 사용할 수 있는 로케일(호출자 로케일 또는 서버 로케일)을 선언하는 데 사용할 수 있는 요소입니다. |
|
이 확장자에 대한 정보는
컨테이너 국제화 속성: WebSphere Application Server의 내용을 참조하십시오. 이 기능의 복잡도로 인해 Rational® Application Developer와 같이 WebSphere Application Server용으로 고안된 도구를 사용하여 원하는 확장 파일 스탠자를 생성한 후 원하는 대로 XML 파일을 수정할 수 있습니다. |
<activity-sessions> | 지정된 세션 Bean(BEAN 또는 CONTAINER)에서 사용될 활동 세션 관리 유형, 컨테이너 관리 활동 세션의 경우 컨테이너가 제공할 활동 세션 작동 유형을 선택적으로 선언하는 요소입니다. |
|
이 확장자에 대한 정보는 EJB 모듈
ActivitySession 배치 속성 설정을 참조하십시오. 이 기능의 복잡도로 인해 Rational Application Developer와 같이 WebSphere Application Server용으로 고안된 도구를 사용할 수 있습니다. |
<app-profiles> | 하나 이상의 EJB 파일에 대한 애플리케이션 프로파일 설정을 선택적으로 선언하는 요소입니다. |
|
이 기능의 복잡도로 인해 Rational Application Developer와 같이 WebSphere Application Server용으로 고안된 도구를 사용하여 원하는 확장 파일 스탠자를 생성한 후 원하는 대로 XML 파일을 수정할 수 있습니다. |
레거시(XMI) 바인딩
기존 모듈과 애플리케이션은 제품에 제공된 레거시 바인딩 지원을 계속 사용할 수 있으므로 기존 도구와 마법사를 사용하여 애플리케이션 및 모듈에 대한 바인딩 및 확장 정보를 지정할 수 있습니다. 레거시 지원 사용은 J2EE 1.4 스타일 XML 배치 디스크립터를 사용하는 EAR 파일 및 모듈로 제한됩니다.
버전 3.x XML 배치 디스크립터 스키마를 사용하거나 XML 배치 디스크립터 파일이 없는 EJB 모듈은, 기본 바인딩 및 자동 링크나 사용자 지정 XML 바인딩 파일을 사용해야 합니다.
CMP 엔티티 Bean을 항상 2.1 XML 배치 디스크립터 스키마 버전이 있는 모듈에 패키지해야 기존 도구를 사용하여 맵핑, 바인딩 및 확장 지원을 제공할 수 있습니다.
사용자 지정 XML 바인딩
각 인터페이스와 각 참조에 대한 자동 링크 참조 해석의 기본 바인딩은 META-INF/ibm-ejb-jar-bnd.xml 파일을 작성하여 EJB 모듈의 바인딩을 지정함으로써 대체할 수 있습니다.
- <session> 요소를 사용하는 세션 Bean
- <message-driven> 요소를 사용하는 메시지 구동 Bean
- id 속성
- name 속성
- simple-binding-name 속성
- component-id 속성
- ejb-ref 요소
- resource-ref 요소 및 해당 속성
- resource-env-ref 요소 및 해당 속성
- message-destination-ref 요소 및 해당 속성
- env-entry 요소
- data-source 요소
- id 속성
- name 속성
- jca-adapter 속성
- ejb-ref 요소 및 해당 속성
- resource-ref 요소 및 해당 속성
- resource-env-ref 요소 및 해당 속성
- message-destination-ref 요소 및 해당 속성
- env-entry 요소
- data-source 요소