RPC(Remote Procedure Call Protocol)
RPC는 C/S 모드를 사용하며 http 프로토콜을 사용하여 서버에 요청을 보내고 서버가 결과를 반환할 때까지 기다립니다. 요청에는 일반적으로 "classname.methodname" 형식의 매개변수 세트와 텍스트 세트가 포함됩니다. 장점은 크로스언어, 크로스플랫폼이고 C사이드와 S사이드의 독립성이 크다는 점이다. 단점은 객체를 지원하지 않고 컴파일러에서는 오류를 확인할 수 없고 확인만 가능하다는 점이다. 런타임에.
웹 서비스
웹 서비스에서 제공하는 서비스는 웹 컨테이너를 기반으로 하며, 하위 계층은 일기 예보 서비스와 같은 원격 서비스 제공자와 유사한 http 프로토콜을 사용합니다. , 다양한 장소에서 클라이언트에게 서비스를 제공하는 것은 시스템 간 및 플랫폼 간 요청 응답 메커니즘입니다. 서비스를 제공하는 것은 서블릿을 통해서이다.
먼저 클라이언트는 서버에서 WebService로 WSDL을 보내고 동시에 클라이언트에서 프록시 클래스(프록시 클래스)를 요청합니다. 이 프록시 클래스는 요청 및 응답을 수행하는 역할을 담당합니다. WebService
a 데이터(XML 형식)가 SOAP 형식의 데이터 스트림으로 캡슐화되어 서버로 전송되면 프로세스 개체가 생성되고 요청으로 수신된 SOAP 패킷이 구문 분석됩니다. 처리가 완료되면 프로세스 객체가 처리되며, 계산 결과는 SOAP
로 패키징되어 클라이언트의 프록시 클래스(Proxy Class)로 전달됩니다. )를 응답으로 사용하여 프록시 클래스도 SOAP 패키지를 구문 분석하고 후속 작업을 수행합니다. 이것은 WebService가 실행되는 프로세스입니다.
웹 서비스는 일반적으로 5가지 수준으로 나뉩니다.
1. Http 전송 채널
2. XML 데이터 형식
3 . 캡슐화 형식
4. WSDL 설명 방법
5. UDDI UDDI는 기업이 웹 서비스를 등록하고 검색하는 데 사용할 수 있는 디렉토리 서비스입니다.
RMI(Remote Method Invocation) )
RMI는 스텁과 스켈레톤을 사용하여 원격 개체와 통신합니다. 스텁은 원격 개체의 클라이언트 프록시 역할을 하며 원격 개체에 대한 호출은 실제로 개체의 클라이언트 프록시 개체 스텁을 호출하여 완료됩니다. 이 메커니즘을 통해 RMI는 마치 작동합니다. 이는 로컬 작업입니다. TCP/IP 프로토콜인 경우 클라이언트는 서버에서 일부 메소드를 직접 호출합니다. 장점은 강력한 형식이고 컴파일 중에 오류를 확인할 수 있다는 점입니다. 단점은 JAVA 언어에만 기반할 수 있고 클라이언트와 서버가 긴밀하게 결합되어 있다는 것입니다.
JMS(Java 메시징 서비스)
JMS는 Java 메시징 서비스입니다. JMS 클라이언트는 JMS 서비스를 통해 비동기 메시지를 전송할 수 있습니다. JMS는 지점 간(P2P) 및 게시/구독(Pub/Sub)의 두 가지 메시지 모델, 즉 지점 간 및 게시-구독 모델을 지원합니다.
이들 사이의 차이점과 연결
1. RPC와 RMI
(1) RPC는 언어 간이지만 RMI는 Java만 지원합니다.
(2) RMI는 원격 객체 메소드를 호출하여 메소드가 Java 객체 및 기본 데이터 유형을 반환할 수 있도록 하는 반면, RPC는 객체 개념을 지원하지 않습니다. RPC 서비스로 전송되는 메시지는 외부 데이터( 엔디안 클래스와 데이터 유형 구조 간의 차이점을 추상화하는 XDR(External Data Representation) 언어 표현입니다. XDR에서 정의한 데이터 유형만 전달할 수 있습니다. RMI는 객체 지향 Java RPC라고 할 수 있습니다.
(3) 메소드 호출 측면에서 RMI에서는 원격 인터페이스를 통해 각 원격 메소드가 메소드 서명을 가질 수 있습니다. 서버에서 메소드가 실행되지만 일치하는 서명이 원격 인터페이스에 추가되지 않으면 RMI 클라이언트에서 새 메소드를 호출할 수 없습니다.
RPC에서 요청이 RPC 서버에 도착하면 요청에는 일반적으로 "classname.methodname" 형식의 매개변수 세트와 텍스트 값이 포함됩니다. 이는 요청된 메서드가 "methodname"이라는 클래스에 있음을 RPC 서버에 나타냅니다. 그런 다음 RPC 서버는 일치하는 클래스와 메서드를 검색하고 이를 해당 메서드 매개 변수 유형에 대한 입력으로 사용합니다. 여기의 매개변수 유형은 RPC 요청의 유형과 일치합니다. 일치가 성공하면 이 메서드가 호출되고 결과가 인코딩되어 클라이언트에 반환됩니다.
2. JMS 및 RMI
JMS 서비스를 사용하면 객체가 네트워크의 JVM에서 다른 JVM(메시지 알림 메커니즘)으로 직접 비동기식으로 이동됩니다.
RMI 객체는 로컬 JVM에 바인딩되어 있으며 함수 매개변수와 반환 값만 네트워크를 통해 전송됩니다(요청 응답 메커니즘입니다).
RMI는 일반적으로 동기식입니다. 즉, 클라이언트가 서버의 메서드를 호출할 때 클라이언트를 계속 실행하려면 상대방이 돌아올 때까지 기다려야 합니다. 이 프로세스는 동일하게 느껴집니다. 이는 RMI의 기능이기도 합니다.
JMS는 일반적으로 메시지를 한 지점에서 메시지 서버로 보낸 후 일반적으로 누가 메시지를 사용하는지 신경 쓰지 않습니다.
따라서 일반적으로 RMI 애플리케이션은 긴밀하게 결합되어 있는 반면, JMS 애플리케이션은 비교적 느슨하게 결합되어 있습니다.
3. 웹 서비스 및 RMI
RMI는 TCP 프로토콜을 통해 직렬화 가능한 Java 개체를 전송합니다. 이는 클라이언트가 언어, 클라이언트 및 서비스를 바인딩하는 데에만 사용할 수 있습니다. Java
Webservice는 언어와 플랫폼에 관계없이 http 프로토콜을 통해 xml 텍스트 파일을 전송합니다.
4. >Webservice는 원격 서비스 호출에 중점을 두고 있으며, jms는 정보 교환에 중점을 두고 있습니다.
대부분의 경우 웹 서비스는 두 시스템(소비자 lt;--gt; 생산자) 간의 직접적인 상호 작용인 반면, 대부분의 경우 jms는 3자 시스템 상호 작용(소비자 lt;--브로커-)입니다. gt; 물론 JMS는 소비자나 생산자가 브로커 역할을 하는 한 요청-응답 모드 통신을 구현할 수도 있습니다.
JMS는 클라이언트와 서비스 제공자를 완전히 분리하는 비동기식 호출을 달성할 수 있으며 트래픽 피크를 견딜 수 있습니다. WebService 서비스는 일반적으로 동기식으로 호출되며 이제 JSON과 비교하면 복잡한 개체 변환이 필요합니다. 좋은 HTTP 아키텍처 솔루션(예를 들어 분산형 전자상거래 시스템에는 결제 시스템과 비즈니스 시스템이 있습니다. 결제 시스템은 사용자 결제를 담당합니다. 사용자가 은행에서 결제한 후 각 비즈니스 시스템에 알려야 합니다. 그런 다음 이때 동기식 또는 비동기식을 사용할 수 있습니다. 비동기식을 사용하면 웹 사이트의 일시적인 트래픽 피크에 대처할 수 있거나 느린 소비자에 대처할 수 있다는 것입니다.)
JMS는 에 대한 메시지 사양입니다. 자바 플랫폼. 일반적으로 jms 메시지는 xml이 아니라 Java 객체입니다. 분명히 jms는 이기종 시스템을 고려하지 않습니다. 직설적으로 말하면 JMS는 Java가 아닌 것을 고려하지 않습니다. 그러나 다행스럽게도 대부분의 jms 제공자(즉, JMS의 다양한 구현 제품)는 이질적인 문제를 해결했습니다. WebService의 크로스 플랫폼과 비교하면 각각 고유한 장점이 있습니다.