EJB에서 다른 클라이언트 뷰가 필요한 이유와 목적을 이해하려고합니다. 누군가 설명하려고 할 수 있습니까?
답변:
원격 클라이언트보기
EJB와 클라이언트가 분산 환경에있을 때-EJB와 클라이언트가 별도의 Java 가상 머신에 상주하게됩니다. 예 : WebSphere Application Server에서 호스팅되는 EJB 및 Tomcat 서버에서 호스팅되는 EJB API를 사용하는 서블릿.
로컬 클라이언트보기
다른 엔터프라이즈 빈 또는 클라이언트가 단일 JVM 내에서만 빈 주소를 지정한다는 것이 보장되는 경우에만. 예를 들어, EJB와 동일한 WebSphere 서버에 배포 된 서블릿.
인터페이스 없음보기
로컬 클라이언트보기와 거의 동일하지만 차이점이 있습니다. 이 경우 클라이언트 뷰 인터페이스를 구현하는 데 빈 클래스가 필요하지 않습니다. Bean 클래스의 모든 공용 메소드는 자동으로 호출자에게 노출됩니다. 인터페이스없는보기는 삽입 또는 JNDI 조회를 통해 로컬 또는 원격보기와 마찬가지로 항상 EJB 참조를 획득합니다. 그러나 EJB 참조의 Java 유형은 로컬 인터페이스 유형이 아니라 Bean 클래스 유형입니다. 이것은 Java EE6의 일부로 도입 된 편의입니다.
로컬 클라이언트보기와 인터페이스없는보기의 차이점
인터페이스가없는보기의 경우 클라이언트와 대상 Bean이 동일한 애플리케이션 (EAR)에 패키지되어야합니다. 로컬보기의 경우 클라이언트는 엔터프라이즈 응용 프로그램이 아닌 별도의 응용 프로그램으로 패키지화 될 수 있습니다. 따라서 구성 요소를 세분화하는 측면에서 더 많은 유연성을 제공합니다.
API 사용 시나리오에 따라 로컬 클라이언트보기와 인터페이스없는보기를 사용할 수 있습니다. 인터페이스가없는보기가 향후 사양에서 유연한 기능을받을 가능성이 매우 높습니다.
이유
역사적 으로든 그렇지 않든, EJB 서비스를 사용하려는 클라이언트는 컨테이너에서 빈을 "조회"해야했습니다 (특정 초기 컨텍스트 사용). 모든 호출이 컨테이너에서 제공하는 특수 EJB 참조 (프록시)를 통해 이루어지기 때문입니다. 이를 통해 컨테이너는 풀링, 컨테이너 관리 트랜잭션 등과 같은 모든 추가 빈 서비스를 제공 할 수 있습니다. 따라서 클라이언트는 new
운영자 로 EJB를 명시 적으로 인스턴스화 할 수 없습니다 . 클라이언트보기는 클라이언트가 액세스 할 수있는 특정 인터페이스를 통해 제공됩니다. 서버 측에서 프록시 실현은 이러한 인터페이스를 기반으로 수행됩니다. 위에서 언급 한대로 서로 다른 배포 시나리오에 대해 서로 다른 클라이언트보기가 정의됩니다.
new
하면 새 인스턴스를 얻게됩니다. 그게 다야. 이 새 인스턴스는 풀링, 컨텍스트 설정 등의 측면에서 컨테이너의 "지원"을 갖지 않습니다. 자체적으로 실행됩니다.
EJB 3.1 사양의 섹션 3.2.2에 따라 :
로컬 클라이언트보기를 통한 엔터프라이즈 Bean에 대한 액세스는 로컬 클라이언트보기를 제공하는 엔터프라이즈 Bean과 동일한 애플리케이션 내에 패키지 된 로컬 클라이언트에 대해서만 지원되어야합니다. 이 사양을 준수하는 구현은 선택적으로 다른 응용 프로그램에 패키지 된 로컬 클라이언트에서 엔터프라이즈 빈의 로컬 클라이언트보기에 대한 액세스를 지원할 수 있습니다. 로컬 클라이언트보기에 대한 응용 프로그램 간 액세스를위한 구성 요구 사항은 공급 업체별로 다르며이 사양의 범위를 벗어납니다. 로컬 클라이언트보기에 대한 응용 프로그램 간 액세스에 의존하는 응용 프로그램은 이식 할 수 없습니다.
인터페이스가없는보기는 빈이 별도의 인터페이스를 선언하지 않고도 로컬 클라이언트보기를 노출 할 수있는 편리한 기능입니다.