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에 도입되었습니다. 클래식 네임스페이스의 대체물이 아닙니다. 오히려 클래식 네임스페이스와 함께 추가됩니다.

클래식 네임스페이스 세부사항

EJB 3.x 레벨의 경우, 이 제품은 인터페이스가 로컬 또는 원격인지 여부에 따라 EJB 인터페이스에 두 개의 별개 클래식 네임스페이스를 제공합니다. 특수 인터페이스 유형으로 간주될 수 있는 EJB 홈 및 인터페이스 없는 보기에 동일한 규정이 적용됩니다. 클래식 네임스페이스는 다음과 같습니다.
  • 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 바인딩을 지정하므로 이러한 이름 정의 방법을 이해하는 것이 중요합니다. 이 이름은 각각 문자열입니다.

Java EE 애플리케이션은 EAR(Enterprise Application Archive) 파일이라는 표준화된 형식으로 패키지됩니다. EAR은 .zip 또는 .tar 파일 형식과 유사한 팩형 파일 형식이므로 단일 실제 파일에 함께 패키지된 논리 디렉토리 및 파일 콜렉션으로 가시화할 수 있습니다. 각 EAR 파일에는 하나 이상의 Java EE 모듈 파일이 있으며 다음과 같습니다.
  • EJB 모듈용 JAR(Java Application Archive) 파일, Java EE 애플리케이션 클라이언트 모듈 및 유틸리티 클래스 모듈
  • 웹 모듈용 WAR(Web Application Archive) 파일
  • 자원 애플리케이션 아카이브(RAR) 파일과 같은 기타 기술 특정 모듈과 기타 모듈 유형
각 모듈 파일에는 일반적으로 하나 이상의 Java EE 컴포넌트가 있습니다. Java EE 컴포넌트의 예는 엔터프라이즈 Bean, 서블릿 및 애플리케이션 클라이언트 기본 클래스입니다.

Java EE 모듈은 Java EE 애플리케이션 아카이브에 패키지되고 Java EE 컴포넌트는 Java EE 모듈에 패키지되므로 각 컴포넌트의 "내포 경로"를 사용하여 해당 애플리케이션 이름, 모듈 이름 및 컴포넌트 이름에 따라 Java EE 애플리케이션 아카이브 내 모든 컴포넌트를 고유하게 식별할 수 있습니다.

클래식 바인딩에 사용되는 애플리케이션 이름

애플리케이션 이름은 다음 우선순위에 따라 정의됩니다.
  • 제품에 애플리케이션을 설치하는 동안 제품 관리 콘솔에 지정된 애플리케이션 이름 값이나 wsadmin 명령행 스크립트 도구에 제공된 appname 매개변수
  • 애플리케이션의 META-INF/application.xml 배치 디스크립터 내의 <display-name> 매개변수 값
  • EAR 파일 이름(.ear 파일 접미부 제외). 예를 들어, 이 경우 애플리케이션 EAR 파일 CustomerServiceApp.ear의 애플리케이션 이름은 "CustomerServiceApp"입니다.
Java EE 6 스펙에서 일반 양식의 EJB JNDI 검색 이름(java:global[/appName]/moduleName/beanName)을 제공합니다. 검색 이름의 appName 컴포넌트는 독립형 모듈에 배치된 Bean에 적용되지 않기 때문에 선택사항으로 표시됩니다. ".ear" 파일에 패키지된 Bean의 경우에만 java:global 검색 이름의 appName 컴포넌트를 포함합니다. appName에 대한 값을 판별하는 규칙은 애플리케이션 이름에 대해 이전에 설명한 규칙과 다릅니다. 이전에 표시된 java:global 검색 이름 템플리트에 있는 appName 값은 다음 우선순위에 따라 정의됩니다.
  • 애플리케이션의 application.xml 배치 디스크립터 내의 <application-name> 매개변수 값
  • EAR 파일 이름(.ear 파일 접미부 제외). 예를 들어, 애플리케이션 EAR 파일 CustomerServiceApp.ear의 애플리케이션 이름은 "CustomerServiceApp"입니다. 애플리케이션이 독립형 모듈일 경우 java:global 검색 이름에 애플리케이션 컴포넌트가 포함되지 않습니다.
appName 값도 Java EE 6 스펙에 따라 java:app/AppName 이름 아래에 바인드된 문자열 값입니다.

클래식 바인딩에 사용되는 모듈 이름

모듈 이름은 모듈 파일의 URI(Uniform Resource Identifier)로 정의되며 모듈이 상주하는 EAR 파일의 루트와 관련이 있습니다. 다른 방법으로 설명하면, 모듈 이름은 EAR 파일의 루트에 상대적인 모듈의 파일 이름입니다(모듈 파일이 내포된 서브디렉토리 포함). 이 네이밍 규칙은 module-name 요소를 사용하여 배치 디스크립터에 논리 모듈 이름이 명시적으로 지정된 경우에도 여전히 해당됩니다.

다음 예제에서 "CustomerServiceApp" 애플리케이션에는 이름이 AccountProcessing.jar, Utility/FinanceUtils.jarAppPresentation.war인 세 개의 모듈이 포함됩니다.
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  
Java EE 6 스펙에서 일반 양식의 EJB JNDI 검색 이름(java:global[/appName]/moduleName/beanName)을 제공합니다. 검색 이름의 appName 컴포넌트는 독립형 모듈에 배치된 Bean에 적용되지 않기 때문에 선택사항으로 표시됩니다. .ear 파일에 패키지된 Bean의 경우에만 java:global 검색 이름의 appName 컴포넌트를 포함합니다. 모듈 이름을 포함하는 다른 JNDI 검색 이름 변형은 java:app/moduleName/beanName입니다. moduleName의 값은 모듈 URI가 아닙니다. java:global 및 java:app 검색 이름 템플리트에 있는 moduleName 값은 다음 우선순위에 따라 정의됩니다.
  • 모듈의 ejb-jar.xml 또는 web.xml 배치 디스크립터 내의 <module-name> 매개변수 값
  • 모듈 URI(.jar 또는 .war 접미부 제외). 예를 들어, URI가 CustomerService.jar 또는 CustomerService.war인 모듈의 모듈 이름은 "CustomerService"입니다.
moduleName 값도 Java EE 6 스펙에 따라 java:module/moduleName 이름 아래에 바인드된 문자열 값입니다. 또한 클라이언트 모듈에도 적용됩니다. 클라이언트 모듈의 경우, <module-name> 매개변수는 application-client.xml 배치 디스크립터 파일에 있습니다.

클래식 바인딩에 사용되는 EJB 컴포넌트 이름

EJB 컴포넌트 이름은 다음 값에 따라 정의됩니다(우선순위 순으로 정렬).
  • ejb-jar.xml 배치 디스크립터(존재하는 경우)의 Bean과 연관된 ejb-name 태그 값
  • Bean과 연관된 @Stateless 또는 @Stateful 어노테이션에서 "name" 매개변수(있는 경우) 값
  • 패키지 레벨 규정자가 없는 Bean 구현 클래스 이름

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 컨텍스트에 바인드되지 않습니다. 축약형 기본 바인딩은 서버 루트 컨텍스트의 루트에 있습니다. 모든 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입니다.

표 1. 기본 바인딩 패턴. 기본 바인딩 패턴
바인딩 패턴 설명
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).

기본 클래식 바인딩에 대한 명시적 지정 효과

인터페이스, 홈 또는 인터페이스 없는 보기에 대한 바인딩 정의를 명시적으로 지정하는 경우, 해당 인터페이스 또는 인터페이스 없는 보기에 대해 축약형 또는 긴 기본 클래식 바인딩이 수행되지 않습니다.
지원된 구성 지원된 구성: 이는 명시적 바인딩을 지정하는 특정 인터페이스 또는 인터페이스 없는 보기에만 적용됩니다. 명시적으로 지정된 바인딩이 없는 해당 엔터프라이즈 Bean의 기타 인터페이스는 기본 클래식 바인딩 이름을 사용하여 바인드됩니다. sptcfg

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 컴포넌트 이름>입니다.

예를 들어, Bean 컴포넌트 MyBeanComponent는 하나의 com.foo.MyBeanComponentLocalInterface 인터페이스만 표시하며 myApp.ear 파일의 myModule.jar 모듈에 패키지됩니다. 그 결과, 다음 바인딩이 java:[범위] 네임스페이스에 작성됩니다.
  • 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
MyBeanComponent Bean은 다음 기술 중 하나를 사용하여 java:[범위] 네임스페이스에서 얻을 수 있습니다.
  • @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 네임스페이스로 범위가 지정된 동일한 이름의 참조와 충돌하지 않습니다.

어노테이션을 사용하여 java:global 네임스페이스에서 참조를 선언할 수 있습니다. 예를 들면, 다음과 같습니다.
@EJB(name="java:global/env/myBean")
ejb-jar.xml 파일에서 참조를 선언할 수 있습니다. 예를 들면, 다음과 같습니다.
<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에 바인드됩니다.

ibm-ejb-jar-bnd.xml 파일은 제품에서 실행되는 EJB 3.0 이상 모듈에 사용되는 반면에, ibm-ejb-jar.bnd.xmi 파일은 EJB 3.0 이전 모듈과 웹 모듈에 사용됩니다. ibm-ejb-jar.bnd.xml 파일의 바인딩 파일 형식은 다음과 같은 이유로 XMI 파일 형식과 다릅니다.
  • 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 파일을 사용할 수 있습니다. 따라서 이제 개발자는 애플리케이션 서버 인프라에 관계없이 바인딩 및 확장 파일을 생성하고 편집할 수 있습니다.
다음 표는 EJB 인터페이스 및 홈(EJB 3.x 모듈의 경우)과 인터페이스 없는 보기(EJB 3.1 모듈의 경우)에 바인딩을 지정하는 데 사용되는 ibm-ejb-jar-bnd.xml 요소 및 속성을 나열합니다.
표 2. ibm-ejb-jar-bnd.xml 요소 및 속성. ibm-ejb-jar-bnd.xml 요소 및 속성
요소 또는 속성 사용 방법 예제 주석
<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를 사용합니다.
<session name="AccountServiceBean" 
component-id="Dept549/AccountProcessor"/>

이전 예제를 실행하면 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 3.x 비즈니스 인터페이스 구현
  • 동위 EJB 홈으로 EJB 3.0 이전 스타일 컴포넌트 인터페이스(로컬, 원격 또는 두 가지 유형 모두) 구현
속성 값은 엔터프라이즈 Bean 비즈니스 인터페이스의 바인딩 위치 또는 Enterprise JavaBeans 로컬 및/또는 원격 홈의 바인딩 위치로 사용됩니다. 바인딩은 클래식 ejblocal: namespace에 배치되고(인터페이스 또는 홈이 로컬인 경우) 클래식 글로벌 범위 JNDI 네임스페이스의 Application Server 루트 컨텍스트에 배치됩니다(인터페이스 또는 홈이 원격인 경우).
<session name="AccountServiceBean"
simple-binding-name="ejb/AccountService"/>
이 예제를 실행하면 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 컨텍스트에 그룹화되지 않습니다.
또한 패키지 규정 클래스 이름 포함은 긴 양식 기본 클래식 바인딩에만 발생하는 반면, simple-binding-name을 사용하는 경우에는 명확성을 부여해야 하는 오류 조건에서만 발생합니다. 보다 많거나 적은 인터페이스를 구현하도록 Bean이 변경되는 경우 그 영향 발생이 변경될 수 있기 때문에 명확성을 부여하여 작성된 바인딩 이름에 의존하지 마십시오.
local-home-binding-name 엔터프라이즈 Bean 로컬 홈의 바인딩 위치를 지정하는 속성입니다.
<session name="AccountServiceBean"
 local-home-binding-name="ejblocal:AccountService"/>
simple-binding-name 속성과 함께 사용되지 않습니다. 로컬 홈은 항상 클래식 JVM 범위 네임스페이스에 바인드되어야 하므로 해당 값은 ejblocal: 접두부로 시작해야 합니다.
remote-home-binding-name 엔터프라이즈 Bean 원격 홈의 바인딩 위치를 지정하는 속성입니다.
<session name="AccountServiceBean"
 remote-home-binding-name=
 "ejb/services/AccountService"/>
simple-binding-name 속성과 함께 사용되지 않습니다. 원격 홈은 클래식 ejblocal: namespac에 바인드될 수 없으므로 해당 값은 클래식 ejblocal: 접두부로 시작할 수 없습니다.
<interface> 특정 EJB 비즈니스 인터페이스 또는 인터페이스 없는 보기에 바인딩을 지정하는 <session> 요소의 하위 요소. simple-binding-name, local-home-binding-name 및 remote-home-binding-name 속성과 달리 binding-name 매개변수와 클래스 매개변수가 모두 필요합니다. 실제로 이러한 차이로 인해 속성이 아닌 별도 XML 요소가 필요합니다. 클래스 매개변수는 바인드될 비즈니스 인터페이스 또는 인터페이스 없는 보기 클래스의 패키지 규정 이름을 지정합니다.
<interface class="com.ejbs.InventoryService" 
binding-name="ejb/Inventory"/> 
(<session> 요소 내에 하위 요소로 선언됨)
simple-binding-name 속성과 함께 사용되지 않습니다. 로컬 인터페이스 및 인터페이스 없는 보기는 항상 클래식 JVM 범위 네임스페이스에 바인드되어야 하므로 이 요소가 로컬 인터페이스 또는 인터페이스 없는 보기에 적용되는 경우 binding-name 값은 ejblocal: 접두부로 시작해야 합니다.
binding-name <interface> 요소를 사용하여 바인드된 비즈니스 인터페이스의 바인딩 위치를 지정하는 속성입니다.
<interface class="com.ejbs.InventoryService" 
binding-name="ejb/Inventory"/>
(<session> 요소 내에 하위 요소로 선언됨)
<interface> 요소와 함께 필요하며 해당 요소에서만 사용됩니다. 로컬 인터페이스는 항상 클래식 JVM 범위 네임스페이스에 바인드되어야 하므로 로컬 인터페이스에 적용되는 경우 binding-name 값은 ejblocal: 접두부로 시작해야 합니다.

바인딩 파일 예제 1

다음 예제는 EJB 인터페이스 및 인터페이스 없는 보기에 바인딩 이름을 지정하는 요소와 속성만 포함된 기본 ibm-ejb-jar-bnd.xml 파일입니다. 이 파일은 이름이 S01인 엔터프라이즈 Bean의 기본 바인딩에 사용되는 컴포넌트 ID를 대체하고, 이 모듈에서 S02S03 엔터프라이즈 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="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에 바인드됩니다.
이러한 Bean의 기타 모든 비즈니스 인터페이스, 홈 및 인터페이스 없는 보기(있는 경우)에는 기본 클래식 바인딩이 지정됩니다. com.ejbs.BankAccountService 인터페이스는 이 예제에서 ejblocal: namespace에 지정되었으므로 로컬로 가정합니다. 이 인터페이스가 로컬이 아니면 오류가 발생합니다.

다음 절은 이 예제의 확장으로서, XML 배치 디스크립터에서 또는 어노테이션을 통해 선언되는 다양한 유형의 참조 및 인젝션 항목의 대상을 해석하는 요소에 대해 설명합니다.

참조 및 인젝션 대상을 해석하는 사용자 정의 바인딩

이전 절에서는 비즈니스 인터페이스, 홈 및 인터페이스 없는 보기에 대해 사용자 정의 바인딩 이름을 지정하는 방법을 설명했습니다. 이 절에서는 참조, 인젝션 지시문 및 메시지 구동 Bean 대상의 연계 대상을 해석하는 방법을 설명합니다.

표 3. 참조 및 인젝션 대상의 연계 대상 해석을 위한 요소 및 속성. 참조 및 인젝션 대상의 연계 대상 해석을 위한 요소 및 속성
요소 또는 속성 사용 방법 예제 주석
<jca-adapter> 메시지 구동 Bean으로 메시지를 전달하기 위한 JCA 1.5 어댑터 활성화 스펙과 메시지 대상 JNDI 위치를 정의합니다.
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
destination-binding-name="jms/ServiceQueue"/>
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의 이름을 연결합니다.
<ejb-ref name="com.ejbs.BankAccountServiceBean/s02Ref" 
binding-name="ejb/session/S02"/>
name 및 binding-name 속성이 필요합니다.
<message-driven> 메시지 구동 Bean의 바인딩 지정 그룹을 선언합니다.
<message-driven name="EventRecorderBean">
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec" 
destination-binding-name="jms/ServiceQueue"/>
</message-driven>
name 속성 및 <jca-adapter> 하위 요소가 필요합니다.
<message-destination> Java EE 모듈 배치 디스크립터에 정의된 논리 이름인 메시지 대상 이름과 JNDI 네임스페이스의 실제 이름인 특정 글로벌 JNDI 이름을 연관시킵니다. 그러면 Java EE 모듈 배치 디스크립터의 <message-destination-ref> 요소 또는 메시지 대상을 삽입하는 @Resource 인젝션 지시문이 <message-destination-line> 요소를 사용하여 대상 논리 이름으로 이 메시지 대상을 참조할 수 있습니다. 이 경우 정의된 각 message-destination-ref에 대한 개별 <message-destination-ref> 바인딩 항목이 바인딩 파일에서 필요하지 않습니다.
<message-destination name="EventProcessingDestination" 
binding-name="jms/ServiceQueue"/>
name 및 binding-name 속성이 필요합니다.
<message-destination-ref> @Resource 어노테이션 또는 ejb-jar.xml의 message-destination-ref를 통해 선언된 message-destination-ref 선언의 대상을 해석하여 컴포넌트 범위 java:comp/env 네임스페이스에 선언된 이름과 글로벌 JNDI 네임스페이스의 대상 자원 환경의 이름을 연결합니다.
<message-destination-ref
name="com.ejbs.BankAccountServiceBean/serviceQueue"
binding-name="jms/ServiceQueue"/>
name 및 binding-name 속성이 필요합니다.
<resource-ref> @Resource 어노테이션 또는 ejb-jar.xml의 resource-ref를 통해 선언된 resource-ref 선언의 대상을 해석하여 컴포넌트 범위 java:comp/env 네임스페이스에 선언된 이름과 글로벌 JNDI 네임스페이스의 대상 자원의 이름을 연결합니다.
<resource-ref name="com.ejbs.BankAccountServiceBean/dataSource"
binding-name="jdbc/Default"/>
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 네임스페이스의 대상 자원 환경의 이름을 연결합니다.
<resource-env-ref 
name="com.ejbs.BankAccountServiceBean/dataFactory"
binding-name="jdbc/Default"/>
name 및 binding-name 속성이 필요합니다.
<env-entry> 문자열 형식으로 표시된 지정된 값 또는 기본 초기 컨텍스트에 적용된 지정된 검색 이름에서 JNDI 검색을 사용하여 액세스할 수 있는 오브젝트로 환경 항목을 대체합니다.
<env-entry name="java:module/env/taxYear" value="2010"/>
<env-entry name="java:module/env/taxYear" binding-name="cell/persistent/MyApp/MyModule/taxYear"/
이름 속성 및 값 또는 바인딩 이름 속성이 필요하지만 둘 다 필요하지는 않습니다.
<data-source> @DataSourceDefinition 어노테이션 또는 애플리케이션의 데이터 소스 요소를 통해 선언된 데이터 소스 정의 또는 모듈 배치 디스크립터를 관리 자원으로 대체합니다.
<data-source name="java:module/env/myDS" 
binding-name="jdbc/DB2DS"/>
name 및 binding-name 속성이 필요합니다.
이름 참조/대상 연계의 "소스" 측을 정의하고 일반적으로 컴포넌트 특정 java:comp/env 네임스페이스에서 이름 지정 위치를 식별하는 속성입니다(예를 들어, ejb-ref, resource-ref, resource-env-ref, message-destination 또는 message-destination-ref에서).
<ejb-ref name="com.ejbs.BankAccountServiceBean/goodBye"
binding-name="ejb/session/S02"/>
 
binding-name ejb-ref, resource-ref, resource-env-ref, message-destination 또는 message-destination-ref에서와 같이 참조/대상 연계의 "대상" 측을 정의하는 클래식 ejblocal: 또는 클래식 글로벌 범위 JNDI 네임스페이스 또는 java:global 네임스페이스에서 네이밍 위치를 식별하는 속성입니다.
<ejb-ref name="com.ejbs.BankAccountServiceBean/goodBye"
binding-name="ejb/session/S02"/>
 
value env-entry 바인딩에 사용할 값을 지정하는 속성입니다.
<env-entry name="java:module/env/taxYear" value="2010"/>
 
activation-spec-binding-name 메시지 구동 Bean으로 메시지를 전달하는 데 사용할 JCA 1.5 어댑터와 연관된 활성화 스펙의 JNDI 위치를 식별하는 속성
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
destination-binding-name="jms/ServiceQueue"/>
이 이름은 WebSphere Application Server에 정의하는 JCA 1.5 활성화 스펙의 이름과 일치해야 합니다.
activation-spec-auth-alias JCA 자원 어댑터에 대한 연결 인증에 사용되는 J2C 인증 별명의 이름을 식별하는 선택적 속성. J2C 인증 별명은 JCA 자원 어댑터에 새 연결 작성을 인증하는 데 사용되는 사용자 ID 및 비밀번호를 지정합니다.
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
activation-spec-auth-alias="jms/Service47Alias"
destination-binding-name="jms/ServiceQueue"/>
이 이름은 WebSphere Application Server에 정의하는 J2C 권한 별명 이름과 일치해야 합니다.
destination-binding-name 메시지 구동 Bean이 JNDI 네임스페이스에서 해당 JMS 대상을 찾기 위해 사용하는 JNDI 이름을 식별하는 속성
<jca-adapter 
activation-spec-binding-name="jms/InternalProviderSpec"
destination-binding-name="jms/ServiceQueue"/>
이 이름은 WebSphere Application Server에 정의하는 JMS 큐 또는 토픽의 이름과 일치해야 합니다.
authentication -alias <resource-ref> 바인딩 요소의 선택적 하위 요소입니다. 자원 참조가 연결 팩토리용인 경우 선택적 JAAS 로그인 구성을 지정할 수 있습니다(이 경우 단순 인증 별명 이름).
<resource-ref name="com.ejbs.BankAccountServiceBean/dataSource"
binding-name="jdbc/Default">
<authentication-alias name="defaultAuth"/>
<resource-ref>
이 이름은 WebSphere Application Server에 정의하는 JAAS 인증 별명의 이름과 일치해야 합니다.
custom-login-configuration <resource-ref> 바인딩 요소의 선택적 하위 요소입니다. 자원 참조가 연결 팩토리용인 경우 선택적 JAAS 로그인 구성을 지정할 수 있습니다(이 경우 한 세트의 특성 - 이름/값 쌍).
<resource-ref name="com.ejbs.BankAccountServiceBean/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>
이 이름은 WebSphere Application Server에 정의하는 JAAS 로그인 구성의 이름과 일치해야 합니다.

바인딩 파일 예제 2

다음 예제는 예제 1에서 설명한 기본 ibm-ejb-jar-bnd.xml 파일의 확장입니다.
<?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>
이 바인딩 결과는 다음과 같습니다.
  1. S01, S02 및 S03 세션 Bean에 대한 비즈니스 인터페이스, 홈 및 인터페이스 없는 보기 바인딩은 이전 예제와 같습니다.
  2. 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 인젝션으로도 정의될 수 있습니다.
  3. ejb-name이 M01인 메시지 구동 Bean에 대한 바인딩이 정의됩니다. MDB는 JCA 1.5 활성화 스펙이 jms/InternalProviderSpec을 이름으로 하여 WebSphere Application Server에 정의된 JCA 1.5 어댑터를 사용하여 WebSphere Application Server에 정의된 JMS 대상(JNDI 이름이 jms/ServiceQueue임)에서 메시지를 수신합니다.
  4. 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이라는 단순 인증 별명을 사용하여 이 자원에 연결됩니다.
  5. 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 컴포넌트를 찾으려고 시도하면 런타임 시 이 예외가 발생합니다.

EJB 링크 기능은 세 개의 서로 다른 형식을 지원합니다.
  • 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를 JNDI를 통해서 액세스할 수 있는 다른 오브젝트에 대한 참조로 구성할 수 있습니다. JNDI 검색에서 리턴된 오브젝트를 env-entry 값으로 사용합니다. 해당 옵션의 요소 양식은 다음과 같습니다.
<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에 해당합니다.

클러스터 및 서버 간 환경의 이름 지정 고려사항

이전 섹션의 클래식 글로벌 JNDI 이름 지정 규칙은 비클러스터 환경과 찾아보기 대상이 찾아보기 소스와 동일한 클러스터에 있는 경우에만 적용됩니다. 특정 클러스터에 있는 바인딩의 클러스터 외부에서 찾아보기를 수행하는 경우 다음 규칙에 따라 대상이 상주하는 클러스터의 이름을 나타내도록 찾아보기 문자열을 규정해야 합니다.
cell/clusters/<cluster-name>/<name-binding-location>   
예를 들어, Application Server 루트 컨텍스트 내부에 EJB 인터페이스 바인딩 위치를 지정하는 경우:
ejb/Department549/AccountProcessors/CheckingAccountReconciler 
이 인터페이스를 구현하는 EJB가 Cluster47 클러스터의 멤버인 Application Server에 지정되는 경우 해당 클러스터의 외부에 있는 찾아보기 문자열은 다음과 같습니다.
cell/clusters/Cluster47/ejb/Department549/AccountProcessors/CheckingAccountReconciler
Application Server 프로세스에서 찾아보기를 수행하는 경우 다음 규칙에 따라 대상이 상주하는 노드 및 서버의 이름을 나타내도록 찾아보기 문자열을 규정해야 합니다.
cell/nodes/<node-name>/servers/<server-name>/<name binding location> 
또한 Application Server 루트 컨텍스트 내부에 EJB 인터페이스 바인딩 위치를 지정하는 경우:
ejb/Department549/AccountProcessors/CheckingAccountReconciler 
이 인터페이스를 구현하는 엔터프라이즈 Bean이 S47NLA1 노드에 있는 Server47A1 Application Server에 지정되는 경우 서버 간 찾아보기 문자열은 다음과 같습니다.
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.xmlibm-ejb-jar-ext-pme.xml입니다.

참고: 이 파일의 접미부는 이전 버전의 WebSphere Application Server와 마찬가지로 XMI가 아닌 XML입니다.
ibm-ejb-jar-ext.xmlibm-ejb-jar-ext-pme.xml 파일은 WebSphere Application Server에서 실행되는 EJB 3.x 모듈에 사용되는 반면에, ibm-ejb-jar-ext.xmiibm-ejb-jar-ext-pme.xmi 파일은 3.0 이전 EJB 모듈에 사용됩니다. WebSphere Application Server 버전 8.0은 다음과 같은 이유로 이전 .xmi 파일 형식 대신 새로운 XML 기반 확장 파일 형식을 사용합니다.
  1. xmi 파일 형식에 선언된 바인딩과 확장은 해당 파일의 요소에 첨부된 고유 ID 번호를 명시적으로 참조하는, 대응하는 ejb-jar.xml 배치 디스크립터 파일의 존재 여부에 따라 다릅니다. 이 시스템은 더 이상 EJB 3.0 이상 모듈에 실행할 수 없으므로 더 이상 모듈에 ejb-jar.xml 배치 디스크립터가 포함되지 않아도 됩니다.
  2. xmi 파일 형식은 WebSphere 개발 도구와 시스템 관리 기능만으로 시스템을 편집할 수 있도록 디자인되었습니다. 이는 실질적으로 WebSphere 내부 구현의 일부이며 파일 구조는 외부적으로 문서화되지 않았습니다. 이로 인해 개발자가 바인딩 또는 확장 파일을 수동으로 작성 또는 편집하거나, 지원되는 방법을 사용하여 WebSphere 독립 빌드 프로세스의 일부로 작성할 수 없었습니다.
  3. XML 기반 확장 파일 형식은 ejb-jar.xml에 인코드된 ID 번호를 참조하지 않고 해당 EJB 이름으로 EJB 컴포넌트를 참조합니다. 모듈의 각 EJB 컴포넌트는 기본적으로 또는 개발자가 명시적으로 지정하여 고유한 EJB 이름을 가지므로, 바인딩 및 확장자를 대상으로 지정하는 명확한 방법을 제공합니다.
  4. 새 바인딩 및 확장 파일 형식은 XML을 기반으로 하며, 구조를 외부적으로 문서화하는 XSD(XML Schema Definition) 파일이 제공됩니다. 일반적인 많은 XML 파일 편집기가 이러한 .xsd 파일을 이용하여 구문 확인 및 코드 완료 기능을 지원할 수 있습니다. 따라서 이제 개발자는 WebSphere Application Server 인프라에 관계없이 일반 XML 편집기 또는 자신이 선택한 스크립트 시스템을 사용하여 바인딩 및 확장 파일을 생성하고 편집할 수 있습니다.

META-INF/ibm-ejb-jar-ext.xml에 정의된 확장자

다음 표는 META-INF/ibm-ejb-jar-ext.xml 파일에 배치해야 하는 확장자 요소 및 속성을 설명합니다. 다음 절에는 별도의 파일인 META-INF/ibm-ejb-jar-ext-pme.xml에 나타나는 요소 및 속성이 나열되어 있습니다.
표 4. META-INF/ibm-ejb-jar-ext.xml 파일의 요소 및 속성. META-INF/ibm-ejb-jar-ext.xml 파일의 요소 및 속성
요소 또는 속성 설명 예제 사용법 참고
<session> 세션 Bean의 확장 설정 그룹을 선언합니다.
<session name="AccountServiceBean"/>
name 속성이 필요합니다. 유효하려면 하나 이상의 확장 설정 정의 하위 요소도 포함시키십시오.
<message-driven> 메시지 구동 Bean의 확장 설정 그룹을 선언합니다.
<message-driven name="EventProcessorBean"/>
name 속성이 필요합니다. 유효하려면 하나 이상의 확장 설정 정의 하위 요소도 포함시키십시오.
표 5. META-INF/ibm-ejb-jar-ext.xml 파일의 요소 및 속성. META-INF/ibm-ejb-jar-ext.xml 파일의 요소 및 속성
요소 또는 속성 설명 예제 사용법 참고
<time-out> <session> 요소의 하위 요소로, 이 시간이 지나면 Stateful 세션 Bean을 더 이상 사용할 수 없게 되는 메소드 호출 간격(초)을 선택적으로 선언합니다.
<session
 name="ShoppingCartBean">
 <time-out value="600"/>
</session>
value 속성(양의 정수)이 필요합니다.
참고: Stateful 세션 Bean에만 적용 가능하며, Stateless Bean에서 사용해서는 안됩니다.

속성 기본값: 300(5분)

<bean-cache> Stateful 세션 Bean의 Bean 활성화/비활성화 설정을 선언하는 데 사용되는 <session> 요소의 하위 요소입니다.
<session
 name="ShoppingCartBean">
 <bean-cache
  activation-policy="TRANSACTION"/>
</session>
적용하려면 activation-policy 속성도 포함시켜야 합니다.
activation-policy Bean 인스턴스를 활성화 및 비활성화할 수 있는 조건을 선언하는 <bean-cache> 요소의 속성입니다. Stateful 세션 Bean에만 적용 가능합니다. 허용 가능한 값과 의미는 다음과 같습니다.
  • TRANSACTION: Bean이 트랜잭션 시작 시 활성화되고 트랜잭션 종료 시 비활성화됨(활성 EJB 인스턴스 캐시에서 제거됨)을 표시합니다.
  • ONCE: Bean이 서버 프로세스에서 처음 Bean에 액세스할 때 활성화되고 캐시가 가득 차면 컨테이너 재량에 따라 비활성화됨(활성 EJB 인스턴스 캐시에서 제거됨)을 표시합니다.
  • ACTIVITY_SESSION: 다음과 같이 Bean이 활성화되고 비활성화되는 것을 표시합니다.
    1. ActivitySession 경계에서 ActivitySession 컨텍스트가 활성화에 표시되는 경우
    2. 트랜잭션 경계에서 트랜잭션 컨텍스트(ActivitySession 컨텍스트는 아님)가 활성화에 표시되거나 또는
    3. 호출 경계에 표시되는 경우
<session
 name="ShoppingCartBean">
 <bean-cache
  activation-policy="ONCE"/>
</session>
속성 기본값: Stateful 세션 Bean의 경우 ONCE
표 6. META-INF/ibm-ejb-jar-ext.xml 파일의 요소 및 속성. META-INF/ibm-ejb-jar-ext.xml 파일의 요소 및 속성
요소 또는 속성 설명 예제 사용법 참고
<global-transaction> (글로벌 트랜잭션 제한시간의 서버 설정을 대체하여) 이러한 특정 EJB 유형으로 시작된 트랜잭션에서 사용할 트랜잭션 제한시간(초)을 선언하는 데 사용할 수 있고 이 EJB 유형이 이기종 웹 서비스 환경에서 웹 서비스 원자적 트랜잭션을 통해 수신된 글로벌 트랜잭션 컨텍스트를 전파하는지 여부를 선언할 수도 있는 <session> 및 <message-driven> 요소의 하위 요소.
<session
 name="AccountServiceBean"
 <global-transaction
  <global-transaction
 transaction-time-out="180" 
  send-wsat-context="FALSE"/>
</session>
transaction-time-out 또는 send-wsat-context 속성 중 최소한 하나가 필요합니다.

속성 기본값: transaction-time-out에 대한 서버 트랜잭션 제한시간 설정(send-wsat-context의 경우 FALSE)

<local-transaction> 로컬 트랜잭션과 관련된 설정을 선언하는 데 사용할 수 있는 <session> 및 <message-driven> 요소의 하위 요소입니다. 지원되는 속성은 boundary, resolver 및 unresolved-action입니다. 이러한 속성은 컴포넌트에 대해 글로벌 트랜잭션이 없을 때마다 컨테이너가 설정하는 컨테이너의 로컬 트랜잭션 포함(LTC) 환경 작동을 구성합니다. 각 속성의 의미는 다음과 같습니다.

경계

이 설정은 모든 포함된 자원 관리자 로컬 트랜잭션(RMLT)을 완료해야 하는 포함 경계를 지정합니다. 가능한 값은 다음과 같습니다.
  • BEAN_METHOD: 기본값입니다. 이 옵션을 선택하면, RMLT는 RMLT가 시작된 동일한 Bean 메소드 내에서 해결되어야 합니다.
  • ACTIVITY_SESSION: RMLT는 RMLT가 시작된 ActivitySession 범위 내, 또는 ActivitySession 컨텍스트가 없는 경우 RMLT가 시작된 동일한 Bean 메소드 내에서 해결되어야 합니다.

분석기

이 설정은 RMLT 시작 및 종료의 책임을 지는 컴포넌트를 지정합니다. 가능한 값은 다음과 같습니다.
  • APPLICATION: 기본값입니다. 애플리케이션이 RMLT를 시작하고 로컬 트랜잭션 포함(LTC) 경계 내에 완료하는 책임을 집니다. LTC 경계 끝까지 완료되지 않은 RMLT는 Unresolved action 속성 값에 따라 컨테이너에 의해 정리됩니다.
  • CONTAINER_AT_BOUNDARY: 컨테이너가 RMLT를 시작하고 LTC 경계 내에 완료하는 책임을 집니다. 컨테이너는 연결이 처음에 LTC 범위 내에서 사용될 때 RMLT를 시작하고 LTC 범위 끝에 자동으로 RMLT를 완료합니다. 경계가 ActivitySession으로 설정되면, RMLT는 ActivitySession 자원으로 참여하며 ActivitySession에 의해 완료하도록 지시받습니다. Boundary가 BeanMethod로 설정되면, RMLT는 컨테이너에 의해 메소드 종료 시 커미트됩니다.

분석되지 않은 조치

이 설정은 해당 트랜잭션이 LTC 경계 범위 끝에 해결되지 않고 분석기가 애플리케이션으로 설정된 경우 컨테이너가 RMLT에 요청하는 지시를 지정합니다. 가능한 값은 다음과 같습니다.
  • ROLLBACK: 기본값입니다. LTC 경계 범위의 끝에서, 컨테이너는 모든 분석되지 않은 RMLT가 롤백되도록 지시합니다.
  • COMMIT: LTC 경계 범위의 끝에서, 컨테이너는 모든 분석되지 않은 RMLT가 커미트되도록 지시합니다. 컨테이너는 처리되지 않은 예외가 없는 경우에만 RMLT가 커미트되도록 지시합니다. 로컬 트랜잭션 컨텍스트 아래에서 실행하는 애플리케이션 메소드가 예외로 종료되면 컨테이너가 분석되지 않은 RMLT를 롤백합니다. 이는 글로벌 트랜잭션의 경우와 동일한 작동입니다.
<session
 name>="AccountServiceBean">
 <local-transaction boundary="BEAN_METHOD" 
  resolver="APPLICATION" 
  unresolved-action="ROLLBACK"/>
</session>
boundary, resolver 또는 unresolved-action 속성 중 최소한 하나가 필요합니다.
속성 기본값:
boundary="BEAN_METHOD"; 
resolver="APPLICATION"; 
unresolved-action=
"ROLLBACK"
표 7. META-INF/ibm-ejb-jar-ext.xml 파일의 요소 및 속성. META-INF/ibm-ejb-jar-ext.xml 파일의 요소 및 속성
요소 또는 속성 설명 예제 사용법 참고
<method> <method-session-attribute> 및 <run-as-mode> 요소의 하위 요소로, 정해진 설정이 적용되는 메소드 이름, 메소드 서명 또는 메소드 유형을 지정하는 데 사용됩니다. 지원되는 속성은 type, name 및 params입니다. 각 속성은 다음과 같이 설명됩니다.

유형

  • UNSPECIFIED: 이 설정은 인터페이스 유형에 관계없이 name 및 params 속성과 일치하는 모든 메소드에 적용됩니다.
  • REMOTE: 이 설정은 name 및 params 속성과 일치하는 원격 비즈니스 인터페이스 및 원격 컴포넌트 인터페이스 메소드에 적용됩니다.
  • LOCAL: 이 설정은 name 속성, params 속성 또는 둘 다와 일치하는 로컬 비즈니스 인터페이스, 로컬 컴포넌트 인터페이스 메소드 및 인터페이스 없는 보기에 적용됩니다.
  • HOME: 이 설정은 name 및 params 속성과 일치하는 원격 홈 인터페이스 메소드에 적용됩니다.
  • LOCAL_HOME: 이 설정은 name 및 params 속성과 일치하는 로컬 홈 인터페이스 메소드에 적용됩니다.
  • SERVICE_ENDPOINT: 이 설정은 name 및 params 속성과 일치하는 JAX-RPC 서비스 엔드포인트 인터페이스의 메소드에 적용됩니다.

name

설정이 적용되는 메소드 이름, 또는 이름에 관계없이 설정이 모든 메소드에 적용될 경우에는 별표(*)입니다.

params

설정이 적용되는 메소드의 매개변수 서명입니다. 이 서명을 사용하여 두 개 이상의 단일 메소드가 동일한 이름을 사용하는 경우 특정 메소드를 고유하게 규정할 수 있습니다. 매개변수 서명은 쉼표로 분리된 Java 유형 목록입니다. 기본 유형은 이름만 사용하여 지정됩니다. 기본이 아닌 유형은 Java 패키지를 포함하는 완전한 클래스 또는 인터페이스 이름을 사용하여 지정되며, Java 유형 배열은 배열 요소 유형 뒤에 하나 이상의 대괄호 쌍을 사용하여 지정됩니다(예: int[][]).

<session
 /name="AccountServiceBean">
 <method-session-attribute
  type="REQUIRES_NEW">
 <method type="LOCAL" name="debitAccount" 
  params="java.lang.String[], int, 
     com.xyz.CustomerInfo"/>
 </method-session-attribute;>
</session>
 
<run-as-mode> <session> 및 <message-driven> 요소의 하위 요소로, 메소드가 실행되는 동안 정해진 EJB 메소드가 다른 메소드 호출 시에 사용되도록 보안 ID를 선언하는 데 사용할 수 있습니다. 호출자 ID(mode = CALLER_IDENTITY), EJB 서버 ID(mode = SYSTEM_IDENTITY) 또는 특정 보안 역할의 ID(mode = SPECIFIED_IDENTITY)를 사용하도록 ID를 설정할 수 있습니다.
<session
 name="AccountServiceBean">
 <run-as-mode
   mode="SPECIFIED_IDENTITY">
 <specified-identity
   role="admin"/>
 <method type="UNSPECIFIED" 
   name="testRunAsRole"/>
 </run-as-mode>
</session>
mode 속성 및 <method> 하위 요소가 필요합니다. mode가 SPECIFIED_IDENTITY이면, <specified-identity 하위 요소도 필요합니다.
<start-at-app-start> 애플리케이션에서 EJB 유형이 처음 사용된 시점이 아니라 애플리케이션이 처음 시작된 시점에서 지정된 EJB 유형이 초기화된 EJB 컨테이너를 알려주는 데 사용할 수 있는 <session> 및 <message-driven> 요소의 하위 요소.
<session
 name="AccountServiceBean">
 <start-at-app-startvalue="TRUE"/>
</session>
value 속성이 필요합니다.

속성 기본값: 메시지 구동 Bean 이외의 Bean의 경우 FALSE(애플리케이션이 EJB를 처음으로 사용할 때 EJB 유형을 초기화함). 메시지 구동 Bean의 경우 항상 TRUE입니다.

<resource-ref> <session> 및 <message-driven> 요소의 하위 요소로, Java EE 자원 참조에 추가 설정(예: 참조별로 참조하는 연결을 통해 구동된 트랜잭션에서 사용될 분리 레벨)을 선언하는 데 사용할 수 있습니다. 허용 가능한 속성으로는 isolation-level이 있습니다. 속성은 다음과 같이 정의됩니다.
isolation-level
  • TRANSACTION_REPEATABLE_READ: 이 분리 레벨은 더티 읽기 및 반복 불가능한 읽기를 금지하지만 팬텀 읽기는 허용합니다.
  • TRANSACTION_READ_COMMITTED: 이 분리 레벨은 더티 읽기를 금지하지만 반복 불가능한 읽기 및 팬텀 읽기는 허용합니다.
  • TRANSACTION_READ_UNCOMMITTED: 이 분리 레벨은 커미트되지 않은 변경사항(아직 진행 중인 다른 트랜잭션이 변경한 데이터) 읽기를 허용합니다. 더티 읽기, 반복 불가능한 읽기 및 팬텀 읽기도 허용합니다.
  • TRANSACTION_SERIALIZABLE: 이 격리 레벨은 다음 유형의 읽기를 금지합니다.
    1. 더티 읽기 - 트랜잭션이 두 번째 트랜잭션에서 커미트되지 않은 변경사항이 포함된 데이터베이스 행을 읽는 경우
    2. 반복 불가능 읽기 - 임의 트랜잭션이 행을 읽고 두 번째 트랜잭션이 동일 행을 변경하며 첫 번째 트랜잭션이 행을 다시 읽고 다른 값을 가져오는 경우
    3. 팬텀 읽기 - 하나의 트랜잭션이 SQL WHERE 조건을 충족시키는 행을 모두 읽고 제2의 트랜잭션이 역시 WHERE 조건을 충족시키는 행을 삽입하며, 첫 번째 트랜잭션이 동일한 WHERE 조건을 적용하고 두 번째 트랜잭션이 삽입한 행을 가져오는 경우
  • TRANSACTION_NONE: 이 분리 레벨은 이 자원 유형에서 트랜잭션이 지원되지 않음을 표시합니다.
<session
 name="AccountServiceBean">
 <resource-ref  name="jdbc/Default" 
  isolation-level="TRANSACTION_NONE">
</session>
name 속성이 필요합니다. 적용하려면 isolation-level 속성도 포함시켜야 합니다.

META-INF/ibm-ejb-jar-ext-pme.xml 파일에 정의된 확장기능

다음 표는 META-INF/ibm-ejb-jar-ext-pme.xml 파일에 배치해야 하는 확장자 요소 및 속성을 나열합니다.
표 8. META-INF/ibm-ejb-jar-ext-pme.xml에 정의된 확장자. META-INF/ibm-ejb-jar-ext-pme.xml에 정의된 확장자
요소 또는 속성 설명 예제 사용법 참고
<internationalization> EJB 유형이 사용할 수 있는 로케일(호출자 로케일 또는 서버 로케일)을 선언하는 데 사용할 수 있는 요소입니다.
<internationalization>
  <application>
   <ejb name="S01"/>
   <ejb name="S02"/>
  </application>
  <run-as-caller>
   <method type="LOCAL" name="getFoo" params="int">
     <ejb name="C01"/>
   </method>
  </run-as-caller>
  <run-as-server>
   <method type="LOCAL" name="getBar" params="int">
    <ejb name="C02"/>
   </method>
  </run-as-server>
  <run-as-specified name="North American English">
   <locale lang="en" country="US" variant="foo"/>
   <locale lang="en" country="CA" variant="bar" /> 
   <time-zone name="GMT"/> 
   <method type="LOCAL" name="getFoo" params="int"> 
    <ejb name="C03"/>
   </method>
  </run-as-specified>
  <run-as-specified name="North American French"> 
   <locale lang="fr" country="US" variant="foo"/>
   <locale lang="fr" country="US" variant="bar" /> 
   <time-zone name="GMT"  /> 
   <method type="LOCAL" name="getBar" params="int"> 
   <ejb name="C04"/>
   </method>
  </run-as-specified>
</internationalization>
이 확장자에 대한 정보는 컨테이너 국제화 속성: WebSphere Application Server의 내용을 참조하십시오.

이 기능의 복잡도로 인해 Rational® Application Developer와 같이 WebSphere Application Server용으로 고안된 도구를 사용하여 원하는 확장 파일 스탠자를 생성한 후 원하는 대로 XML 파일을 수정할 수 있습니다.

<activity-sessions> 지정된 세션 Bean(BEAN 또는 CONTAINER)에서 사용될 활동 세션 관리 유형, 컨테이너 관리 활동 세션의 경우 컨테이너가 제공할 활동 세션 작동 유형을 선택적으로 선언하는 요소입니다.
<activity-sessions>
 <container-activity-session 
  name="Foo" type="NOT_SUPPORTED">
  <methodtype="HOME" name="findByPrimaryKey" 
    params="int">
   <ejb name="C01"/>
  </method>
 </container-activity-session>
<./activity-sessions>
이 확장자에 대한 정보는 EJB 모듈 ActivitySession 배치 속성 설정을 참조하십시오.

이 기능의 복잡도로 인해 Rational Application Developer와 같이 WebSphere Application Server용으로 고안된 도구를 사용할 수 있습니다.

<app-profiles> 하나 이상의 EJB 파일에 대한 애플리케이션 프로파일 설정을 선택적으로 선언하는 요소입니다.
<app-profiles>
 <defined-access-intent-policy name="foo">
  <collection-scope type"SESSION"/>
  <optimistic-read/>
  <read-ahead-hint hint="foo.bar.baz"/>
 </defined-access-intent-policy>
 <run-as-task 
  name="TestEJB1.ejbs.C01LocalHome.createjava.lang.Integer" 
  type="RUN_AS_SPECIFIED_TASK">
  <task name=“/>
  <method type="LOCAL" name="getFoo" params="int">
   <ejb name="C01"/>
  </method>
 </run-as-task>
 <ejb-component-extension ejb="C01"> 
  <task name="SomeTask"/>
 </ejb-component-extension>
</app-profiles>
이 기능의 복잡도로 인해 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 모듈의 바인딩을 지정함으로써 대체할 수 있습니다.

형식을 설명하는 스키마 파일은 <WAS_HOME>/properties/schemas 디렉토리에 있습니다. 이 바인딩 스펙 양식은 XML 배치 디스크립터 또는 EJB 3.x 배치 디스크립터를 포함하지 않는 모듈에만 사용할 수 있습니다.
참고: 모든 바인딩을 지정할 필요는 없습니다. 정의되지 않은 바인딩 이름 또는 참조는 기본 바인딩 및 자동 링크 지원을 사용합니다.
바인딩을 지정할 수 있는 Bean은 다음과 같습니다.
  • <session> 요소를 사용하는 세션 Bean
  • <message-driven> 요소를 사용하는 메시지 구동 Bean
<session> 요소에 지원되는 유일한 속성 및 하위 요소는 다음과 같습니다.
  • id 속성
  • name 속성
  • simple-binding-name 속성
  • component-id 속성
  • ejb-ref 요소
  • resource-ref 요소 및 해당 속성
  • resource-env-ref 요소 및 해당 속성
  • message-destination-ref 요소 및 해당 속성
  • env-entry 요소
  • data-source 요소
<message-driven> 요소에 지원되는 유일한 속성 및 하위 요소는 다음과 같습니다.
  • id 속성
  • name 속성
  • jca-adapter 속성
  • ejb-ref 요소 및 해당 속성
  • resource-ref 요소 및 해당 속성
  • resource-env-ref 요소 및 해당 속성
  • message-destination-ref 요소 및 해당 속성
  • env-entry 요소
  • data-source 요소

주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_bindingsejbfp
파일 이름:cejb_bindingsejbfp.html