Java EE를 처음 접했고 로컬 인터페이스 및 원격 인터페이스의 개념을 이해하려고합니다. Java EE의 가장 큰 장점 중 하나는 확장이 쉽다는 것입니다 (다른 서버에 다른 구성 요소를 배포 할 수 있다고 생각합니다). 원격 및 로컬 인터페이스가있는 곳입니까? 응용 프로그램의 서버마다 다른 구성 요소가있을 것으로 예상되는 경우 원격 인터페이스를 사용해야합니까? 응용 프로그램이 하나의 서버에만 상주 할 경우 로컬 인터페이스를 사용 하시겠습니까?
위의 가정이 정확하다면 트래픽 양이 무엇인지 확실하지 않은 새 응용 프로그램에 로컬 또는 원격 인터페이스를 사용할지 여부를 선택하는 방법은 무엇입니까? 로컬 인터페이스를 사용하여 시작하고 적용 가능한 경우 점차 원격 인터페이스로 업그레이드합니까?
설명과 제안에 감사드립니다.
답변:
Java EE를 처음 접했고 로컬 인터페이스 및 원격 인터페이스의 개념을 이해하려고합니다.
EJB 사양의 초기 버전에서 EJB는 "원격 구성 요소"라고 가정했으며,이를 호출하는 유일한 방법은 RMI 의미와 모든 오버 헤드 (모든 네트워크 호출 및 객체 직렬화)를 사용하여 원격 호출을하는 것입니다. 메소드 호출). EJB 클라이언트는 EJB 컨테이너와 동일한 가상 머신에 배치 된 경우에도이 성능 저하를 지불해야했습니다.
나중에 Sun은 대부분의 비즈니스 응용 프로그램이 실제로 다른 계층에 EJB를 배포하지 않는다는 것을 깨달았고 EJB 컨테이너를 사용하여 동일한 가상 시스템에 배치 된 클라이언트가 EJB 컨테이너를 사용하여 EJB를 호출 할 수 있도록 로컬 인터페이스 개념을 도입하여 사양을 수정했습니다 (EJB 2.0). 직접 메소드 호출, RMI 시맨틱 (및 관련 오버 헤드)을 완전히 무시합니다.
Java EE의 가장 큰 장점 중 하나는 확장이 쉽다는 것입니다 (다른 서버에 다른 구성 요소를 배포 할 수 있다고 생각합니다)
Java EE는 확장 할 수 있지만 반드시 컴포넌트 배포를 의미하지는 않습니다 . 웹 계층과 EJB 계층을 분리하지 않고 클러스터에서 Web + EJB 애플리케이션을 실행할 수 있습니다.
응용 프로그램의 서버마다 다른 구성 요소가있을 것으로 예상되는 경우 원격 인터페이스를 사용해야합니까? 응용 프로그램이 하나의 서버에만 상주 할 경우 로컬 인터페이스를 사용 하시겠습니까?
클라이언트가 동일한 JVM에 있지 않으면 원격 인터페이스를 사용하십시오 (단 하나의 서버 / JVM 만 사용하는 것은 아닙니다).
(...) 로컬 인터페이스를 사용하여 시작하고 적용 가능한 경우 점차 원격 인터페이스로 업그레이드합니까?
아마도 로컬 인터페이스를 사용하여 시작할 것입니다. 이미 암시 한 것처럼 원격 인터페이스로 전환하는 것이 항상 필수는 아닙니다 ( 배치 된 구조를 클러스터링 할 수 있음 ).
아래 언급 된 리소스를 확인하는 것이 좋습니다 (첫 번째 2 개는 꽤 오래되었지만 여전히 관련이 있으며 2 개는 더 최신입니다).
It seems like there are a couple ways of scaling a web application (...) and I suppose you could use a combination of both?예, 바로 그거야. Do you, by chance know of good books on this topic?슬프게도, "ZE"절대 자원이 있다면, 나는 모른다. 그래도 몇 가지 참고 자료로 더 많은 리소스를 추가했습니다.
위에 쓰여진 내용의 대부분에 동의하지만 "시작하는 방법"아이디어를 약간 수정하고 싶습니다.
내 제안은 코드 내에서 EJB 인터페이스에 직접 프로그래밍 하지 않는 것 입니다 . 항상 일반적인 비즈니스 지향 인터페이스를 사용하고 프로그램을 작성하고 (비즈니스 지향 인터페이스에서 코드 호출 메소드를 가짐) EJB "접착제"코드를 플러그 가능한 구현으로 제공하십시오. 프로그램은 EJB와 같은 구현 세부 사항이 아닌 비즈니스 로직에 중점을 두어야합니다.
이렇게하면 원격과 로컬 구현간에 쉽게 전환 할 수 있으며 Spring과 같은 IoC 컨테이너를 사용하는 경우 구성을 통해서만 수행 할 수 있습니다.
로컬에서 원격으로 전환하는 것에 대한 특별 참고 사항 : 둘 사이에는 의미 상 몇 가지 차이점이 있습니다. 예를 들어, "원격 인터페이스"를 통해 EJB 메소드를 호출하면 값에 의해 인수가 전달되고 "로컬 인터페이스"를 통해 호출하면 인수가 참조에 의해 전달됩니다. 이것은 중요한 차이점입니다. 따라서 "로컬로 시작"하는 경우 "원격"의미를 고려하는 방식으로 시스템을 설계해야합니다.
디자인이 전달 된 객체를 변경하는 EJB 메소드에 의존하는 경우 나중에 "원격으로 전환"하는 것이 까다로울 수 있습니다. 아마도 불가능할 수도 있습니다.
행운을 빕니다.
EJB 사양 3.2에 따르면 EJB는 로컬 이거나 원격 일 수 있습니다 . 비즈니스 인터페이스는 동시에 로컬 및 원격 일 수 없습니다.
@Local 주석이 달린 Bean은 동일한 애플리케이션에있는 경우에만 액세스 할 수 있습니다.
@Remote 어노테이션이있는 Bean은 다른 응용 프로그램, 다른 jvm 또는 응용 프로그램 서버에 상주하여 액세스 할 수 있습니다.
따라서 명심해야 할 중요한 사항은 다음과 같습니다.
@Remote주석이 포함 된 경우 구현 된 모든 인터페이스는 원격이어야합니다.@Local어노테이션이 지정된 경우 구현 된 모든 인터페이스는 로컬 인 것으로 가정합니다.@Local다른 애플리케이션 (JAR, WAR, EAR)에서 동일한 JVM에서 EJB를 호출하는 데 사용할 수 있습니까 ?
이것은 당신의 우려에 답할 수 있습니다 :
일반적으로 Enterprise Java Bean은 분산 환경에서 Bean을 사용하려는 경우 원격 클라이언트보기가 필요합니다. 특히, 작업 할 클라이언트가 다른 JVM (Java Virtual Machine)에있는 경우입니다. 원격 클라이언트보기의 경우 원격 홈 인터페이스 및 / 또는 원격 컴포넌트 인터페이스에서 메소드를 호출하면 RMI (Remote Method Invocation)를 통해 처리됩니다.
EJB는 다른 엔터프라이즈 Bean 또는 클라이언트가 단일 JVM 내에서만 Bean을 처리하도록 보장 된 경우에만 로컬 클라이언트보기를 사용할 수 있습니다. 이 경우 RMI 대신 직접 메소드 호출을 사용하여 이러한 액세스가 수행됩니다.
출처 : http://www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page=last&x-showcontent=text