문제

저는 웹 서비스와 RMI를 모두 처음 접했고, 이러한 응용 프로그램이 모두 Java로 작성되었을 때, 즉 다른 프로그래밍 언어가 중요하지 않은 경우(이것은 WS의 장점).

한편으로는 웹 서비스를 사용할 때 성능 오버헤드가 있다고 추측하는 반면(누가 이를 증명할 수 있는 숫자가 있습니까?), 다른 한편으로는 웹 서비스가 훨씬 더 느슨하게 결합되어 다음과 같은 용도로 사용될 수 있는 것 같습니다. 보다 서비스 지향적인 아키텍처(SOA)를 구현합니다(RMI에서는 불가능합니다. 그렇죠?).

꽤 일반적인 질문이긴 하지만, 당신의 의견은 어떻습니까?

감사해요

도움이 되었습니까?

해결책

웹 서비스는 느슨하게 결합된 아키텍처를 허용합니다.RMI를 사용하면 클래스 정의가 모든 애플리케이션 인스턴스에서 동기화 상태를 유지하는지 확인해야 합니다. 이는 클래스 정의 중 하나만 변경되더라도 항상 모든 클래스를 동시에 배포해야 함을 의미합니다(반드시 그런 것은 아니지만 직렬 UUID 등으로 인해 꽤 자주 필요함)

또한 확장성이 뛰어나지 않아 로드 밸런서를 원하는 경우 문제가 될 수 있습니다.

내 생각에는 RMI는 인터넷과 관련은 없지만 분리가 필요한 소규모 로컬 애플리케이션에 가장 적합합니다.저는 이를 전자 통신을 처리하는 Java 애플리케이션에 사용해 본 적이 있으며 그 결과에 상당히 만족했습니다.더 복잡한 배포가 필요하고 인터넷을 통해 작동하는 다른 애플리케이션의 경우 웹 서비스를 사용하는 것이 좋습니다.

다른 팁

웹 서비스를 사용할지 아니면 보다 "기본적인" 접근 방식을 사용할지 여부도 환경에 따라 다릅니다.프록시나 일부 회사 방화벽을 통과해야 하는 경우 웹 서비스는 HTTP에만 의존하므로 작동할 가능성이 더 높습니다.RMI에서는 애플리케이션을 위해 다른 포트를 열어야 하는데 이는 일부 환경에서는 (기술적으로는 아니지만) 어려울 수 있습니다.

이 문제가 문제가 되지 않는다는 것을 알고 있다면 RMI 사용을 고려해야 합니다.SOA는 좋은 서비스 디자인만큼 기술에 의존하지 않습니다.EJB 컨테이너가 있는 경우 RMI를 통해 세션 Bean을 호출하고 필요한 경우 추가로 웹 서비스로 노출할 수 있습니다.

성능은 교환하려는 데이터에 따라 다릅니다.한 응용 프로그램에서 다른 응용 프로그램으로 복잡한 개체 그물을 보내려는 경우 RMI를 사용하는 것이 더 빠를 수 있습니다. 일반적으로 이진 형식으로 전송되기 때문입니다.어쨌든 어떤 종류의 텍스트/XML 콘텐츠가 있는 경우 웹 서비스는 동등하거나 더 빠를 수 있습니다. 그러면 통신을 위해 아무것도 변환할 필요가 없기 때문입니다.

HTH,
남자 이름

RMI보다 WS를 선호하는 한 가지는 WS가 일반적으로 방화벽에서 차단되지 않는 HTTP 포트 80/443을 통해 작동하고 NAT 등 뒤에서 작동할 수 있다는 것입니다.RMI에는 RMI 포트를 열어야 하는 매우 복잡한 기본 네트워크 프로토콜이 있으며 클라이언트가 NATTED인 경우에도 작동하지 않을 수 있습니다.둘째, RMI를 사용하면 JAVA-JAVA 통신으로 자신을 제한하는 반면 Webservies에서는 그러한 제한이 없습니다.데이터는 디버깅을 위한 스니핑 도구를 통해 쉽게 캡처할 수 있는 SOAP/HTTP이므로 유선을 통해 웹 서비스를 디버깅하는 것이 훨씬 쉽습니다.RMI를 통해 이 작업을 수행하는 쉬운 방법을 모르겠습니다.게다가 RMI는 정말 오래되었고 지난 몇 년 동안 많은 관심을 받지 못했습니다.CORBA가 컸던 시절에는 컸고, 두 RMI CORBA는 모두 정말 구식 기술입니다.가장 좋은 옵션은 REST 스타일 웹 서비스입니다.

RMI 및 웹 서비스에 대한 나의 경험은 위의 추측을 반영합니다.일반적으로 RMI의 성능은 웹 서비스를 훨씬 능가하지만 인터페이스 사양은 웹 서비스에 대해 명시적으로 명시되어 있습니다.

이 프로토콜 중 어느 것도 필요하다 양쪽의 애플리케이션은 Java입니다.나는 인터페이스를 구현하는 외부 파트너가 한 명 이상 있을 때 웹 서비스를 사용하는 경향이 있지만 연결의 양쪽 끝을 제어할 수 있는 경우에는 RMI를 사용합니다.

복잡한 상태를 유지해야 하는 경우 RMI가 더 나은 방향일 수 있습니다.

@마틴 클린케

"성능은 교환하려는 데이터에 따라 달라집니다.한 응용 프로그램에서 다른 응용 프로그램으로 복잡한 개체 그물을 보내려는 경우 RMI를 사용하는 것이 더 빠를 수 있습니다. 일반적으로 이진 형식으로 전송되기 때문입니다.어쨌든 어떤 종류의 텍스트/XML 콘텐츠가 있다면 웹 서비스는 동등하거나 더 빠를 수 있습니다. 그러면 (통신을 위해) 아무것도 변환할 필요가 없기 때문입니다."

알 수있는 한, 성능 문제가 직렬화 설명 중에 차이를 만듭니다. 다시 말해서 마샬링 디 마블링 프로세스. 분산 프로그래밍 에서이 용어가 동일한 BTW인지 확신하지 못합니다. 동일한 JVM에서 발생하는 프로세스에 대해 이야기하지 않습니다. 데이터를 복사하는 방법에 관한 것입니다. 그것은 값으로 값으로 전달되거나 참조로 통과합니다 .Binary Format은 전달 값에 해당합니다. 즉, 바이너리의 원격 서버에 객체를 복사하는 것을 의미합니다.

마샬링-디마샬링 또는 직렬화-역직렬화 측면에서 바이너리 형식과 텍스트/xml 콘텐츠로 보내는 것의 차이점은 무엇입니까?

나는 단지 추측일 뿐입니다. 어떤 종류의 데이터를 보내느냐에 달려 있지 않습니다. 어떤 데이터 유형을 보내든 그것은 마샬링-디마샬링 프로세스의 일부가 될 것이고 마지막에는 바이너리로 전송될 것입니다. 그렇죠?

Hakki를 건배합니다

Spring Remoting은 어떻습니까?이는 REST와 유사한 HTTP 프로토콜을 RMI의 바이너리 형식과 결합합니다.나에게 완벽하게 작동합니다.

Spring 편협함과 수년간 SOA의 옹호자로서 나는 Spring Remoting을 조언하고 싶습니다.이 서비스 수출업체의 특징은 RMI에 대한 트릭을 수행할 것입니다.

org.springframework.remoting.rmi.RmiServiceExporter

물론 다른 교통수단도 이용 가능합니다.인터페이스(엔드포인트)와 DTO의 버전을 현명하게 관리하고 직렬화 UUID를 적절하게 관리하면 직렬화 작업을 상당히 관리하기 쉽습니다.우리는 인터페이스와 객체에 'Alpha', 'Bravo'라는 접미사를 붙이고 필요할 때마다 증가, 감소 및 재창조합니다.또한 직렬화 UUID를 1로 수정하고 변경 사항이 추가되는지 확인합니다. 그렇지 않으면 'Bravo'에서 'Charlie'로 이동합니다.Enterprise 설정에서 모두 관리 가능합니다.

Spring Remoting(HTTP Invoker를 의미하는 것으로 추측됩니다)의 경우 논의할 수 있는 경우 양측 모두 Spring을 사용해야 합니다.

Java-Java 애플리케이션의 경우 RMI가 좋은 솔루션입니다. 클라이언트가 제어할 수 없거나 다른 플랫폼으로 이동할 수 있는 경우 Java-Java 통신용 JAX-RPC 또는 JAX-WS를 피해야 합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top