Liberty에서 원격 인터페이스로 Enterprise JavaBeans 사용
EJB(Enterprise Java™ Bean)가 동일한 JVM(Java Virtual Machine) 내의 다른 JVM이나 애플리케이션에 의해 호스팅되는 경우 원격 인터페이스를 사용하여 원격에서 EJB 메소드에 액세스할 수 있습니다. WebSphere® Application Server는 RMI-IIOP 기술을 사용하여 원격 EJB 인터페이스를 구현합니다. ejbRemote-3.2 기능을 사용하여 원격 EJB 지원을 가능하게 할 수 있습니다.
이 태스크 정보
원격 EJB 지원이 사용되는 애플리케이션을 실행하도록 Liberty 서버를 구성하려면 ejbRemote-3.2 기능을 설정해야 합니다.
원격 EJB 인터페이스를 사용할 경우 다음 고려사항을 검토하십시오.
- 네이밍
java: 네임스페이스 사용
EJB 스펙에서는 원격 인터페이스가 java:네임스페이스에 바인드되어야 합니다. 예를 들면 다음과 같습니다.java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface java:app/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface java:module/ExampleBean!com.ibm.example.ExampleRemoteInterface
EJB 컴포넌트는 WebSphere® Application Server Traditional에서처럼 기본 JNDI(Java Naming and Directory Interface) 네임스페이스에는 바인드되지 않으므로 ibm-*-bnd.xml 파일의 @EJB 검색과 바인딩에서는 이 네임스페이스를 사용하지 않아야 합니다. 이러한 검색에서 동일한 서버 내에서 호스팅되는 EJB 컴포넌트에는 java: 이름을 사용해야 하고 다른 서버에서 호스팅되는 EJB 컴포넌트에는 corbaname: URL을 사용해야 합니다.
- corbaname: URL 사용또한 인터페이스는 java:global 네임스페이스에서 사용된 인터페이스와 유사한 컨텍스트에서 ORB CosNaming 이름 서비스에 바인드됩니다. 이러한 인터페이스는 corbaname: URL을 사용하여 JNDI를 통해 액세스할 수 있습니다. 예를 들면 다음과 같습니다.
corbaname::test.ibm.com:2809#ejb/global/ExampleApp/ExampleModule/ExampleHomeBean!com.ibm.example.ExampleEJBHomecorbaname:rir:#ejb/global/ExampleApp/ExampleModule/ExampleHomeBean!com.ibm.example.ExampleEJBHome
서버에서 URL의 rir: 양식은 로컬 이름 서비스를 사용합니다. 클라이언트에서는 기본값 또는 구성된 원격 이름 서비스를 사용합니다.
- corbaname: URL 이스케이프
OMG(Object Management Group) Naming Service 스펙에 따라 corbaname: URL의 일부 문자는 이스케이프되어야 합니다. Liberty는 java:global 네임스페이스에서 파생된 corbaname: URL이 이스케이프 처리되어야 하는지 여부의 판별을 시도한 후에 이를 자동으로 이스케이프 처리합니다. 모든 경우에 이스케이프를 수행할 수 있는 것은 아닙니다. 예를 들어, 이름에 마침표(.)가 포함되어 있고 올바르지 않은 문자가 없는 경우에는 자동으로 이스케이프할 수 없습니다. 특별한 방법으로 이름이 해석되도록 강제 실행하려면 OMG Naming Service 스펙에 설명된 대로 URL을 수동으로 이스케이프 처리해야 합니다.
엔터프라이즈 Bean에 대해서는 다음 java:global 이름을 고려하십시오.
corbaname: URL의 단순 양식은 다르지만 유효한 위치를 나타내기 때문에 이를 자동으로 이스케이프할 수 없습니다. 따라서 다음 URL은 예상대로 작동하지 않습니다.java:global/TestApp/TestModule/TestBean!test.TestRemoteInterface
대신에 이 URL은 다음과 같이 수동으로 이스케이프 처리해야 합니다.corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test.TestRemoteInterface
corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test%5c.TestRemoteInterface
corbaname: URL 이스케이프를 위한 구문은 OMG Naming Service 스펙에 전부 설명되어 있습니다.
- 프로그래밍 방식으로 JNDI 이름 사용이 예의 모든 URL과 JNDI 이름은 InitialContext에서 프로그래밍 방식으로 찾을 수 있습니다. java: 이름을 검색할 경우 결과 오브젝트를 예상 유형으로 직접 캐스트할 수 있습니다. 예를 들면 다음과 같습니다.
그러나 corbaname: URL을 사용하여 오브젝트를 검색할 경우, narrowing이라는 캐스팅의 RMI 스타일을 사용해야 합니다. 예를 들면 다음과 같습니다.Object found = new InitialContext().lookup("java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface"); ExampleRemoteInterface bean = (ExampleRemoteInterface) found;
Object found = new InitialContext().lookup("corbaname:rir:#ejb/global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface"); ExampleRemoteInterface bean = (ExampleRemoteInterface)PortableRemoteObject.narrow(found, ExampleRemoteInterface.class);
- 상호 운용성
- IIOP 프로토콜을 지원하는 제품은 버전 2.0 배치 디스크립터로 EJB JAR 모듈에서 패키징될 때 EJBHome 및 EJBObject와 함께 EJB 2.x 원격 프로그래밍 모델을 사용하는 엔터프라이즈 Bean을 호출할 수 있습니다. WLP_INSTALL_DIR/clients/ejbRemotePortable.jar 파일은 원격 클라이언트의 클래스 경로에 포함되어야 합니다. 이 파일에는 Liberty 서버와의 통신에 필요한 시스템 값 클래스가 포함됩니다. WebSphere Application Server Liberty 또는 WebSphere Application Server Traditional에서 원격으로 EJB 컴포넌트에 액세스할 때는 이 파일이 필요하지 않습니다. Liberty에서 EJB 3 원격 프로그래밍 모델을 사용하는 EJB 컴포넌트는 WebSphere Application Server 프로세스에 의한 원격 액세스가 가능합니다. Liberty는 독립형 Java 프로세스에서 EJB 컴포넌트를 시작할 수 있도록 씬 클라이언트를 제공하지 않습니다. Liberty는 WebSphere Application Server Traditional에서 호스팅되는 EJB 컴포넌트를 시작할 때를 포함하여 원격 EJB 컴포넌트에 대해 워크로드 관리 또는 장애 복구 기능을 제공하지 않습니다.
- 스텁 클래스
- WebSphere Application Server에서 호스팅되는 원격 EJB를 시작할 때 클라이언트는 스텁 클래스를
포함해야 합니다. 클라이언트가 WebSphere Application Server인 경우에는
제품에서 올바른 스텁 클래스를 자동 생성합니다.
- 클라이언트 애플리케이션이 동일한 애플리케이션 내에 포함된 원격 EJB를 시작하는 경우, Liberty는 스텁 클래스를 자동 생성합니다.
- 대상 EJB가 별도 애플리케이션에서 실행 중이며 EJBHome 및 EJBObject와 함께 EJB 2.x 원격 프로그래밍 모델을 사용 중인 경우, 클라이언트는 해당 클래스 경로에 스텁 클래스를 포함해야 합니다. EJB가 WebSphere Application Server Traditional에서 호스팅되는 경우, ejbdeploy 명령으로 EJB가 처리된 후 EAR의 애플리케이션에서 EJB 클라이언트 JAR를 복사할 수 있습니다. EJB가 Liberty에서 호스팅된 경우에는 Java SDK에 포함된 rmic 프로그램을 사용하여 대상 EJB에 대한 스텁 클래스를 생성한 후에 클라이언트에서 스텁 클래스를 포함해야 합니다.
- 대상 EJB가 별도의 애플리케이션에서 실행 중이며 EJB 3 원격 프로그래밍 모델을 사용 중인 경우, 클라이언트 Liberty 또는 WebSphere Application Server Traditional 프로세스는 스텁 클래스를 자동 생성합니다. Liberty에서 EJB 3 원격 프로그래밍 모델을 사용하는 EJB 컴포넌트는 WebSphere Application Server 또는 WebSphere Application Client 프로세스에 의해서만 원격으로 액세스가 가능합니다.
- 트랜잭션 전파
- Liberty는 아웃바운드 또는 인바운드 트랜잭션 전파를 지원하지 않습니다. 또한 EJB 스펙을 사용하려면 제품이 아웃바운드 트랜잭션 전파를 지원하더라도 여전히 널 트랜잭션 컨텍스트를 보내야 합니다. 이 컨텍스트는 Required(기본값), Mandatory 또는 Supports 트랜잭션 속성을 사용하는 EJB 컴포넌트에 의해 거부되어야 합니다. 클라이언트 또는 서버가 Liberty에 있는 경우, 활성 글로벌 트랜잭션의 클라이언트는 기본 트랜잭션 속성의 EJB를 시작할 수 없습니다. EJB가 RequiresNew 또는 NotSupported 트랜잭션 속성을 사용하도록 변경되는 경우, 클라이언트는 EJB를 시작할 수 있습니다. 그러나 EJB로 수행되는 트랜잭션 작업은 클라이언트 트랜잭션의 일부로 커미트되지 않습니다.
- 비동기 메소드
- EJB 원격 인터페이스에는 Future 유형의 리턴값을 가진 비동기 메소드가
있을 수 있습니다. 서버는 Future 오브젝트를
클라이언트에 리턴하며, 이 오브젝트는 값을 검색하는 데 사용됩니다. 요구되지 않은 결과가 축적되면 메모리를 고갈시킬 수 있으므로 원격 비동기 메소드는
권장하지 않습니다. 이 문제점을 완화하기 위해 클라이언트가 24시간 내에 결과를 검색하지 못하거나 요구되지 않은 결과의 최대 수가 1,000개를 초과하는 경우
서버 결과는 만료됩니다. 이 값은 server.xml 파일에서 조정할 수 있습니다. 예를 들면 다음과 같습니다.
<ejbContainer> <async maxUnclaimedRemoteResults="10"unclaimedRemoteResultTimeout="10m"/> </ejbContainer>