웹 계층과 비즈니스 계층 간에 RMI 또는 JMS를 사용할 때의 장단점은 무엇입니까?

Question

일반적인 웹 클라이언트-서블릿/WS-비즈니스 계층(Spring 또는 EJB) 앱의 경우 원격 RPC 또는 웹(서블릿) 계층에서 원격 비즈니스 계층으로의 메시징과 같은 접근 방식의 장단점은 무엇입니까? 기본 동기화/비동기 측면?

Answer 1

웹 클라이언트란 웹 브라우저를 의미합니까?그렇다면 DWR이나 JAX-RS 같은 것을 살펴보는 것이 좋습니다.RMI 또는 JMS는 양쪽이 모두 Java 코드인 경우에만 실제로 작동합니다.

원격 기술을 사용할 때 가장 큰 문제는 해당 기술이 비즈니스 개체에 얼마나 침해적인가 하는 경향이 있습니다.예를 들어어디서나 RMI 인터페이스/예외를 사용하거나 비즈니스 코드 내에서 JMS API를 사용합니다.

내 추천은 Java의 모든 곳에서 POJO를 사용한 다음 다음과 같은 기술을 사용하는 것입니다. 스프링 원격 RMI나 JMS 등 미들웨어를 계층화할 수 있습니다. 그러나 비즈니스 로직에서 미들웨어 코드를 완전히 분리하여 언제든지 기술 간에 전환할 수 있습니다(그리고 비즈니스 로직 코드를 더 단순하게 유지하고 비즈니스 문제에 집중할 수 있습니다).

예를 들어 Spring Remoting의 Camel 구현 그러면 다음을 사용할 수 있습니다. 이러한 전송 및 프로토콜 중 하나 RMI, JMS 또는 일반 HTTP, 이메일, 파일 또는 XMPP 등 - 간단한 URI 문자열 변경을 사용하여 간단하게 전환할 수 있습니다.

Answer 2

우리는 Spring을 통해 RMI를 사용하고 있으며 사용하기가 매우 쉽고 강력하며 빠릅니다.우리의 요구 사항은 상당히 반응이 빠른 링크에 대한 것이었고 실제로 메시징 구성 요소를 추가할 필요는 없었습니다.

Answer 3

SUN RMI가 우리를 위해 파산했습니다.

지속적인 메시징을 통해 매우 오랫동안 실행되는 애플리케이션에 대한 설정 및 가비지 수집입니다.지속적으로 작동되도록 패치를 진행하고 있습니다.우리가 실행하는 JMS 애플리케이션에서는 RMI와 같은 메모리 부족 오류나 gc 문제가 발생하지 않습니다.System.gc()를 주기적으로 호출해야 하고 리소스를 복구하기 위해 증분 수집과 함께 작동하지 않는 모든 항목은 잘못 코딩되었습니다.

RMI 안정성은 JDK 6 및 올바른 속성 설정으로 향상되지만 JHC는 잘못된 프레임워크입니다.nio에서 채널을 사용하고 system.gc()의 sun nio 사용을 수정하면 RMI가 크게 향상됩니다.

정답 - 도메인 코드와 별도의 통신(메커니즘)입니다.RPC는 긴밀하게 결합되어 있으므로 프로토콜과 애플리케이션이 서로 간섭할 수 있습니다.JMS는 훨씬 더 나은 패러다임인 애플리케이션과 프로토콜을 분리합니다.