[.NET] Remoting

작성날짜    : 2011-03-31

출처 : 훈수 닷넷

 

.NET Remoting

 

.NET 리모팅이란?

.NET 리모팅(.NET Remoting)은 서로 다른 프로세스 영역, 혹은 서로 다른 호스트에 존재하는 모듈간에 정보 교환을 손쉽게 할 수 있는 방법입니다. 그동안 DCOM이나 CORBA같은 기법이 제시되어 아쉬운 대로(?) 이러한 기능을 구현할 수 있었으나, 이들을 사용하기 위해서는 플랫폼부터 제약 사항이 있었고 그 안정성에 있어서도 그다지 좋은 반응을 얻지 못했습니다. .NET에서 제공하는 리모팅은 이러한 한계를 극복하고자 하는 Microsoft사의 노력의 일환이라고 할 수 있습니다. 우리가 앞서 공부했던 웹 서비스 역시 내부적으로는 리모팅을 사용하고 있으며 사실상 리모팅을 손쉽게 사용할 수 있는 일종의 껍데기에 불과합니다.

 

.NET 리모팅의 동작 원리

개발자가 기본적으로 작성해야 하는 부분은 서버 객체, 호스팅 어플리케이션, 그리고 클라이언트 어플리케이션입니다. 수행하고자 하는 서버 작업은 서버 객체가 처리하며, 말 그대로 객체이기 때문에 클라이언트로의 요청을 받아 객체의 생성과 소멸을 처리해주는 대리인이 필요합니다. 이 대리인을 호스팅 어플리케이션이라고 부르며 일반적인 Windows 응용 프로그램, Windows 서비스 등이 이러한 역할을 할 수 있습니다. 클라이언트가 호스팅 어플리케이션에게 특정 객체를 사용하겠다는 요청을 하면 호스팅 어플리케이션은 먼저 그 객체를 자기가 관리하고 있는지 체크하고 객체를 생성하여 클라이언트와 연결시켜 줍니다. 이 과정을 좀더 자세히 알아보겠습니다.

 

원격 객체(Remote Object)

리모팅이 나오게 된 가장 큰 목적 중의 하나는 원격 객체의 메서드를 호출하고 결과값을 전달받는 복잡한 과정을 개발자에게 숨기고 단순한 인터페이스를 제공하기 위함입니다. 여기서 원격 객체라 함은 클라이언트와 다른 어플리케이션 도메인에 객체가 존재한다는 의미입니다.

클라이언트에 객체를 전달하는 방식에는 객체에 대한 참조값만 넘기는 방법(Marshal By Reference 개념과 같습니다)과 객체 자체를 넘기는 방법(Marshal By Value)이 있는데, 객체와 클라이언트가 같은 어플리케이션 도메인에 있느냐 아니냐에 따라 어느 방법을 쓸 것인지가 결정됩니다. 객체와 클라이언트가 같은 어플리케이션 도메인에 있는 경우에는 객체에 대한 참조값만을 넘김으로써 클라이언트가 그 객체를 사용할 수 있으나, 서로 다른 어플리케이션 도메인에 존재하는 경우에는 반드시 객체 자체를 클라이언트로 전달해야 합니다.
이 때 .NET 프레임워크는 객체를 시리얼라이즈(serialize)하여 클라이언트에게 전달하고, 클라이언트는 그 데이터를 사용하여 객체를 생성합니다. 로컬 객체를 시리얼라이즈하기 위해서는 [serializable]이라는 속성을 부여하는데, 이 속성이 지정되지 않았거나 ISerialize 인터페이스가 구현되지 않은 객체는 시리얼라이즈가 되지 않기 때문에 원격 객체로 사용할 수 없습니다.

.NET에서는 객체를 MarshalByRefObject로부터 상속시킴으로써 원격 객체를 생성할 수 있는데, 이 때 클라이언트는 이 객체에 대한 프록시를 사용하게 됩니다. 프록시와 원격 객체가 같은 어플리케이션 도메인에 있으면 프록시는 원격 객체의 메서드를 직접 호출하고 결과를 받아 클라이언트에게 돌려줍니다. 만약 프록시와 원격 객체가 별개의 어플리케이션 도메인에 존재한다면 프록시는 클라이언트의 요청을 메시지로 변환하여 원격 객체에게 전송합니다. 원격 객체쪽에서는 메시지를 자신이 이해할 수 있는 방식으로 변환한 후 클라이언트의 요청을 수행하고 결과값을 다시 메시지로 바꾸어 프록시에게 보내지요. 프록시는 이 메시지로부터 결과값을 얻어내어 클라이언트에게 넘겨줍니다.

 

프록시 객체

클라이언트가 원격 객체를 사용하고자 할 때 프록시가 생성된다. 프록시는 TransparentProxy와 RealProxy로 나뉘는데 클라이언트가 사용하는 것은 TransparentProxy이다. 원격 객체와 TransparentProxy가 같은 어플리케이션 도메인에 있으면 TransparentProxy는 원격 객체에 직접 접근하여 메서드를 호출한다. 만약 원격 객체와 TransparentProxy가 서로 다른 어플리케이션 도메인에 있으면 TransparentProxy는 클라이언트가 호출한 메서드의 매개변수를 메시지로 변환하여 RealProxy에게 전송한다. RealProxy는 원격 객체에 접근하여 매개변수가 담긴 메시지를 넘겨주며 메서드의 결과값은 RealProxy와 TransparentProxy를 거쳐 클라이언트가 받게 된다.

클라이언트가 TransparentProxy에 대해 메서드를 호출하면 그 정보는 메시지로 변환되어 RealProxy로 전달되고, RealProxy는 메시지를 포매터 싱크(formatter sink)에 넘긴다. 포매터 싱크는 하나 이상의 포매터가 파이프처럼 연결된 형태이며, 메시지를 바이너리 스트림 혹은 XML 스트림으로 변환해서 트랜스포트 싱크(transport sink)에 전달한다. 트랜스포트 싱크 역시 하나 이상의 트랜스포트 포매터로 구성되어 있는 형태이며 서버측의 트랜스포트 싱크와 연결하여 데이터를 전송하고, 서버측의 트랜스포트 싱크는 시리얼라이즈되어 전달된 데이터를 포매터 싱크로 전달한다. 포매터 싱크는 데이터 스트림을 원격 객체가 사용할 수 있는 데이터로 복원하여 원격 객체에게 전달한다. 결과값 전송은 이와 반대 순서로 진행된다. 

채널

프록시와 원격 객체가 서로 다른 어플리케이션 도메인에 존재하는 경우 클라이언트의 요청 정보와 결과값이 메시지 형태로 변환되어 전달된다고 했는데, 이 때 메시지가 전송되는 방법을 채널이라고 한다. 쉽게 말해 메시지가 지나다니는 길이라고 할 수 있으며 원격 객체는 여러 개의 채널을 사용하여 연결할 수 있다. .NET에서 기본적으로 제공하는 채널은 HTTP와 TCP이며 각각 포트 번호를 지정하도록 되어 있기 때문에 프로토콜과 포트 번호의 조합이 채널의 식별자가 된다.

채널은 원격 객체가 관리하는 부분이 아니라 호스팅 어플리케이션에서 담당한다. 호스팅 어플리케이션이 구동될 때 호스팅 어플리케이션은 자신이 관리할 원격 객체와 그 객체를 사용하기 위해 사용되는 채널을 함께 등록한다. 원격 객체가 호스팅 어플리케이션에 등록될 때 호스팅 어플리케이션은 일종의 마스터 테이블에 원격 객체와 채널을 등록시키고 그 채널을 사용하여 리스닝을 시작한다. 즉 객체가 생성되어 있지 않은 상태에서 채널은 이미 열려 있는 상태이며, 클라이언트가 이 채널을 통해 원격 객체의 메서드를 사용하려는 요청을 보냈을 때 호스팅 어플리케이션은 마스터 테이블을 뒤져서 그 객체를 생성하고 요청 데이터를 객체에게 전달해준다. 클라이언트에서는 원격 객체가 사용하는 채널을 사용하여 원격 객체에 접근할 수 있다.

.NET은 HTTP 채널과 TCP 채널을 제공하는데 HTTP 채널은 기본적으로 SOAP 포매터를 사용하고 TCP 채널은 바이너리 포매터를 사용하다. 이것은 디폴트가 그렇다는 말이며, HTTP 채널이 바이너리 포매터를 사용하고 TCP 채널이 SOAP 포매터를 사용하는 것도 가능하다. SOAP 포매터는 메시지를 XML 형식으로, 그리고 바이너리 포매터는 메시지를 바이너리 스트림으로 시리얼라이즈시키는 역할을 한다.
HTTP 채널과 TCP 채널의 사용법은 뒤에서 설명한다.

개요

이 항목은 이전 버전의 기존 응용 프로그램과의 호환성을 위해 유지되고 있으나 새로운 개발에는 권장되지 않는 레거시 기술에 대해 설명합니다. 분산 응용 프로그램은 이제  WCF(Windows Communication Foundation)를 사용하여 개발됩니다.

.NET Remoting을 사용하면 응용 프로그램 구성 요소가 모두 한 컴퓨터에 있는지 아니면 전 세계에 분산되어 있는지에 관계없이 다양한 영역에 배포되는 응용 프로그램을 쉽게 만들 수 있습니다. 같은 컴퓨터 또는 해당 네트워크를 통해 연결할 수 있는 다른 모든 컴퓨터에 있는 다른 프로세스의 개체를 사용하는 클라이언트 응용 프로그램을 빌드할 수 있습니다. 또한 .NET Remoting을 사용하여 같은 프로세스에서 다른 응용 프로그램 도메인과 통신할 수도 있습니다.

.NET Remoting은 특정 클라이언트나 서버 응용 프로그램 도메인 및 특정 통신 메커니즘에서 원격으로 사용 가능한 개체를 분리하는 프로세스 간 통신에 대해 추상적인 접근법을 제공합니다. 따라서 매우 유연하며 손쉽게 사용자 지정할 수 있습니다. 클라이언트나 서버를 다시 컴파일 하지 않고 특정 통신 프로토콜을 다른 프로토콜로 바꾸거나 특정 serialization 형식을 다른 형식으로 바꿀 수 있습니다. 또한 원격 시스템에서는 특정 응용 프로그램 모델을 가정하지 않습니다. 즉 웹 응용 프로그램, 콘솔 응용 프로그램, Windows 서비스 등 거의 모든 방식을 사용하여 통신할 수 있습니다. 원격 서버도 모든 형식의 응용 프로그램 도메인일 수 있습니다. 모든 응용 프로그램은 원격 개체를 호스트하고 같은 컴퓨터 또는 네트워크의 모든 클라이언트에 서비스를 제공할 수 있습니다.

참고 : 보안상의 이유로 원격 끝점은 보안 채널을 통해 노출하는 것이 좋습니다. 보안이 적용되지 않는 원격 끝점을 절대 인터넷에 노출하지 마십시오.

 

.NET Remoting을 사용하여 응용 프로그램 도메인 경계를 가로질러 두 구성 요소가 통신하는 응용 프로그램을 빌드하려면 다음만 빌드하면 됩니다.

·         원격으로 사용 가능한 개체

·         해당 개체의 요청을 수신하기 위한 호스트 응용 프로그램 도메인

·         해당 개체에 대해 요청하는 클라이언트 응용 프로그램 도메인

복잡한 다중 클라이언트 또는 다중 서버 응용 프로그램의 경우에도 .NET Remoting을 이런 방식으로 생각할 수 있습니다. 호스트와 클라이언트 응용 프로그램도 원격 인프라에 맞게 구성해야 하며 원격 인프라에 수반되는 수명 및 활성화 문제를 이해해야 합니다.

 

원격 객체(Remote Object)

리모팅이 나오게 된 가장 큰 목적 중의 하나는 원격 객체의 메서드를 호출하고 결과값을 전달받는 복잡한 과정을 개발자에게 숨기고 단순한 인터페이스를 제공하기 위함입니다. 여기서 원격 객체라 함은 클라이언트와 다른 어플리케이션 도메인에 객체가 존재한다는 의미입니다.

클라이언트에 객체를 전달하는 방식에는 객체에 대한 참조값만 넘기는 방법(Marshal By Reference 개념과 같습니다)과 객체 자체를 넘기는 방법(Marshal By Value)이 있는데, 객체와 클라이언트가 같은 어플리케이션 도메인에 있느냐 아니냐에 따라 어느 방법을 쓸 것인지가 결정됩니다. 객체와 클라이언트가 같은 어플리케이션 도메인에 있는 경우에는 객체에 대한 참조값만을 넘김으로써 클라이언트가 그 객체를 사용할 수 있으나, 서로 다른 어플리케이션 도메인에 존재하는 경우에는 반드시 객체 자체를 클라이언트로 전달해야 합니다.
이 때 .NET 프레임워크는 객체를 시리얼라이즈(serialize)하여 클라이언트에게 전달하고, 클라이언트는 그 데이터를 사용하여 객체를 생성합니다. 로컬 객체를 시리얼라이즈하기 위해서는 [serializable]이라는 속성을 부여하는데, 이 속성이 지정되지 않았거나 ISerialize 인터페이스가 구현되지 않은 객체는 시리얼라이즈가 되지 않기 때문에 원격 객체로 사용할 수 없습니다.

.NET에서는 객체를 MarshalByRefObject로부터 상속시킴으로써 원격 객체를 생성할 수 있는데, 이 때 클라이언트는 이 객체에 대한 프록시를 사용하게 됩니다. 프록시와 원격 객체가 같은 어플리케이션 도메인에 있으면 프록시는 원격 객체의 메서드를 직접 호출하고 결과를 받아 클라이언트에게 돌려줍니다. 만약 프록시와 원격 객체가 별개의 어플리케이션 도메인에 존재한다면 프록시는 클라이언트의 요청을 메시지로 변환하여 원격 객체에게 전송합니다. 원격 객체쪽에서는 메시지를 자신이 이해할 수 있는 방식으로 변환한 후 클라이언트의 요청을 수행하고 결과값을 다시 메시지로 바꾸어 프록시에게 보내지요. 프록시는 이 메시지로부터 결과값을 얻어내어 클라이언트에게 넘겨줍니다.

 

프록시 객체

클라이언트가 원격 객체를 사용하고자 할 때 프록시가 생성된다. 프록시는 TransparentProxy와 RealProxy로 나뉘는데 클라이언트가 사용하는 것은 TransparentProxy이다. 원격 객체와 TransparentProxy가 같은 어플리케이션 도메인에 있으면 TransparentProxy는 원격 객체에 직접 접근하여 메서드를 호출한다. 만약 원격 객체와 TransparentProxy가 서로 다른 어플리케이션 도메인에 있으면 TransparentProxy는 클라이언트가 호출한 메서드의 매개변수를 메시지로 변환하여 RealProxy에게 전송한다. RealProxy는 원격 객체에 접근하여 매개변수가 담긴 메시지를 넘겨주며 메서드의 결과값은 RealProxy와 TransparentProxy를 거쳐 클라이언트가 받게 된다.

클라이언트가 TransparentProxy에 대해 메서드를 호출하면 그 정보는 메시지로 변환되어 RealProxy로 전달되고, RealProxy는 메시지를 포매터 싱크(formatter sink)에 넘긴다. 포매터 싱크는 하나 이상의 포매터가 파이프처럼 연결된 형태이며, 메시지를 바이너리 스트림 혹은 XML 스트림으로 변환해서 트랜스포트 싱크(transport sink)에 전달한다. 트랜스포트 싱크 역시 하나 이상의 트랜스포트 포매터로 구성되어 있는 형태이며 서버측의 트랜스포트 싱크와 연결하여 데이터를 전송하고, 서버측의 트랜스포트 싱크는 시리얼라이즈되어 전달된 데이터를 포매터 싱크로 전달한다. 포매터 싱크는 데이터 스트림을 원격 객체가 사용할 수 있는 데이터로 복원하여 원격 객체에게 전달한다. 결과값 전송은 이와 반대 순서로 진행된다. 이 과정은 다음과 같이 나타낼 수 있다.

 

채널

프록시와 원격 객체가 서로 다른 어플리케이션 도메인에 존재하는 경우 클라이언트의 요청 정보와 결과값이 메시지 형태로 변환되어 전달된다고 했는데, 이 때 메시지가 전송되는 방법을 채널이라고 한다. 쉽게 말해 메시지가 지나다니는 길이라고 할 수 있으며 원격 객체는 여러 개의 채널을 사용하여 연결할 수 있다. .NET에서 기본적으로 제공하는 채널은 HTTP와 TCP이며 각각 포트 번호를 지정하도록 되어 있기 때문에 프로토콜과 포트 번호의 조합이 채널의 식별자가 된다.

채널은 원격 객체가 관리하는 부분이 아니라 호스팅 어플리케이션에서 담당한다. 호스팅 어플리케이션이 구동될 때 호스팅 어플리케이션은 자신이 관리할 원격 객체와 그 객체를 사용하기 위해 사용되는 채널을 함께 등록한다. 원격 객체가 호스팅 어플리케이션에 등록될 때 호스팅 어플리케이션은 일종의 마스터 테이블에 원격 객체와 채널을 등록시키고 그 채널을 사용하여 리스닝을 시작한다. 즉 객체가 생성되어 있지 않은 상태에서 채널은 이미 열려 있는 상태이며, 클라이언트가 이 채널을 통해 원격 객체의 메서드를 사용하려는 요청을 보냈을 때 호스팅 어플리케이션은 마스터 테이블을 뒤져서 그 객체를 생성하고 요청 데이터를 객체에게 전달해준다. 클라이언트에서는 원격 객체가 사용하는 채널을 사용하여 원격 객체에 접근할 수 있다.

.NET은 HTTP 채널과 TCP 채널을 제공하는데 HTTP 채널은 기본적으로 SOAP 포매터를 사용하고 TCP 채널은 바이너리 포매터를 사용하다. 이것은 디폴트가 그렇다는 말이며, HTTP 채널이 바이너리 포매터를 사용하고 TCP 채널이 SOAP 포매터를 사용하는 것도 가능하다. SOAP 포매터는 메시지를 XML 형식으로, 그리고 바이너리 포매터는 메시지를 바이너리 스트림으로 시리얼라이즈시키는 역할을 한다.
HTTP 채널과 TCP 채널의 사용법은 뒤에서 설명한다.

 

.NET Framework Remoting 아키텍처

.NET Remoting 인프라는 프로세스 간 통신에 대한 추상적인 접근 방법입니다. 값으로 전달하거나 복사할 수 있는 개체는 다른 응용 프로그램 도메인이나 다른 컴퓨터의 응용 프로그램 간에 자동으로 전달됩니다. 이렇게 하려면 사용자 지정 클래스를 serializable로 표시합니다.

그러나 원격 시스템의 중요한 장점은 다른 응용 프로그램 도메인의 개체나 다른 전송 프로토콜, serialization 형식, 개체 수명 체계 및 개체 생성 모드를 사용하는 프로세스 간의 통신을 지원하는 기능에 있습니다. 또한 원격 서비스를 사용하면 통신 프로세스의 거의 모든 단계에 개입할 수 있습니다.

여러 개의 분산 응용 프로그램을 구현한 경우이든, 프로그램 확장성을 높이기 위해 구성 요소를 다른 컴퓨터로 이동하려는 경우이든 원격 시스템을 이해할 때 대부분의 시나리오를 쉽게 처리하는 기본 구현이 포함된 프로세스 간 통신의 일반 시스템으로 생각하면 이해하기가 쉽습니다. 다음 단원에서는 먼저 원격 서비스를 사용하는 프로세스 간 통신의 기본 사항에 대해 설명합니다.

 

복사본 및 참조

프로세스 간 통신을 수행하려면 프로세스 외부의 호출자에 해당 기능을 제공하는 서버 개체, 서버 개체를 호출하는 클라이언트 및 한쪽에서 다른 쪽으로 호출을 전달하는 전송 메커니즘이 필요합니다. 서버 메서드의 주소는 논리적이며, 한 프로세스에서는 올바로 작동하지만 다른 클라이언트 프로세스에서는 작동하지 않습니다. 이 문제를 줄이기 위해 클라이언트는 개체의 전체 복사본을 만들고 클라이언트 프로세스로 이동하여 서버 개체를 호출할 수 있습니다. 이 경우 클라이언트 프로세스에서 복사본의 메서드를 직접 호출할 수 있습니다.

그러나 많은 개체는 실행을 위해 복사하여 다른 프로세스로 이동할 수 없거나 이동하면 안 됩니다. 많은 메서드가 있는 큰 개체는 복사하거나 값으로 다른 프로세스에 전달하면 안 됩니다. 일반적으로 클라이언트는 서버 개체의 하나 또는 몇몇 메서드가 반환하는 정보만 필요로 합니다. 클라이언트의 요구 사항과 관련이 없는 많은 양의 내부 정보나 실행 파일 구조를 포함하여 전체 서버 개체를 복사하는 경우 대역폭과 클라이언트 메모리 및 처리 시간을 낭비하게 됩니다. 또한 많은 개체는 공용 기능을 노출하지만 내부 실행을 위해 전용 데이터가 필요합니다. 이러한 개체를 복사하면 권한이 없는 클라이언트가 내부 데이터를 확인할 수 있으므로 잠재적으로 보안 문제가 발생할 수 있습니다. 마지막으로 일부 개체는 이해할 수 있는 방식으로 복사할 수 없는 데이터를 사용합니다. 예를 들어 FileInfo개체는 서버 프로세스의 메모리에 고유 주소가 있는, 운영 체제 파일에 대한 참조를 포함합니다. 이 주소는 복사할 수 있지만 다른 프로세스에서 유효하지 않습니다.

이 경우 서버 프로세스에서 개체의 복사본이 아니라 서버 개체에 대한 참조를 클라이언트 프로세스에 전달해야 합니다. 클라이언트는 이 참조를 사용하여 서버 개체를 호출할 수 있습니다. 이러한 호출은 클라이언트 프로세스에서 실행되지 않습니다. 대신 원격 시스템이 호출에 대한 모든 정보를 수집하여 서버 프로세스로 보내면 여기서 이 정보를 해석하고, 올바른 서버 개체를 찾고, 클라이언트 개체를 대신하여 서버 개체를 호출합니다. 호출 결과는 다시 클라이언트 프로세스로 전송되어 클라이언트에 반환됩니다. 대역폭은 호출, 호출 인수, 반환 값 또는 예외 같은 중요한 정보에만 사용됩니다.

 

단순한 원격 아키텍처

원격 서비스의 핵심은 개체 참조를 사용하여 서버 개체와 클라이언트 간에 통신하는 기능입니다. 그러나 원격 아키텍처는 프로그래머에게 보다 기본적인 프로시저를 제공합니다. 클라이언트를 올바르게 구성하는 경우new(또는 관리되는 프로그래밍 언어의 인스턴스 생성 함수)를 사용하여 원격 개체의 새 인스턴스를 만들기만 하면 됩니다. 클라이언트가 서버 개체에 대한 참조를 받은 다음 개체가 별도 컴퓨터에서 실행되지 않고 사용자 프로세스에 있는 것처럼 해당 메서드를 호출할 수 있습니다. 원격 시스템은 프록시 개체를 사용하여 서버 개체가 클라이언트 프로세스에 있는 것 같은 환경을 만듭니다. 프록시는 자신을 다른 개체로 표시하는 개체입니다. 클라이언트가 원격 형식의 인스턴스를 만들면 원격 인프라가 클라이언트에 원격 형식처럼 표시되는 프록시 개체를 만듭니다. 클라이언트가 해당 프록시에서 메서드를 호출하면 원격 시스템에서 호출을 받아 서버 프로세스로 라우팅하고, 서버 개체를 호출하고, 반환 값을 클라이언트 프록시로 반환합니다. 그런 다음 클라이언트 프록시가 그 결과를 클라이언트로 반환합니다.

어떤 방식으로든 클라이언트와 서버 프로세스 간에 원격 호출이 전달되어야 합니다. 직접 원격 시스템을 빌드하는 경우 먼저 네트워크 프로그래밍과 다양한 프로토콜 및 serialization 형식 사양에 대해 알아볼 수 있습니다. .NET Remoting 시스템에서는 네트워크 연결을 열고 특정 프로토콜을 사용하여 바이트를 수신 응용 프로그램으로 보내는 데 필요한 내부 기술의 조합이 전송 채널로 표시됩니다.

채널은 데이터 스트림을 사용하고, 특정 네트워크 프로토콜에 따라 패키지를 만들고, 패키지를 다른 컴퓨터로 보내는 형식입니다. 어떤 채널은 정보를 받을 수만 있고 어떤 채널은 정보를 보낼 수만 있지만, 기본 TcpChannel및HttpChannel클래스와 같은 채널은 양방향으로 사용할 수 있습니다.

서버 프로세스는 각 고유 형식에 대한 모든 사항을 알고 있지만 클라이언트는 다른 컴퓨터에 있을 수도 있는 다른 응용 프로그램 도메인의 개체에 대한 참조가 필요하다는 것만 알고 있습니다. URL은 서버 응용 프로그램 도메인의 외부에서 개체를 찾습니다. 외부에 고유 형식을 나타내는 URL은 원격 호출이 올바른 형식에 대해 수행되도록 하는 활성화 URL입니다. 자세한 내용은 활성화 URL을 참조하십시오.

 

전체 원격 시스템 디자인

한 컴퓨터에 응용 프로그램이 실행되고 있으며 다른 컴퓨터에 저장된 형식으로 노출된 기능을 사용하려고 한다고 가정합니다. 다음 그림은 일반적인 원격 프로세스를 보여 줍니다.

관계의 양쪽을 올바르게 구성하면 클라이언트는 서버 클래스의 새 인스턴스를 만듭니다. 원격 시스템은 클라이언트를 나타내는 프록시 개체를 만들고 프록시에 대한 참조를 클라이언트 개체에 반환합니다. 클라이언트가 메서드를 호출하면 원격 인프라가 호출을 처리하고, 형식 정보를 확인하며, 채널을 통해 호출을 서버 프로세스로 보냅니다. 수신 대기 채널이 요청을 수집하여 서버 원격 시스템으로 전달하며, 여기서 요청된 개체를 찾거나 필요한 경우 새로 만들어 호출합니다. 그런 다음 프로세스가 반대로 수행되어 서버 원격 시스템이 응답을 모아서 메시지를 작성하며 서버 채널이 이 메시지를 클라이언트 채널로 보냅니다. 마지막으로 클라이언트 원격 시스템이 프록시를 통해 호출 결과를 클라이언트 개체에 반환합니다.

이 작업에 필요한 실제 코드는 거의 없지만 관계를 디자인하고 구성할 때 몇 가지 사항에 주의해야 합니다. 코드가 올바른 경우에도 URL이나 포트 번호가 잘못되어 실패할 수 있습니다. 자세한 내용은 구성을 참조하십시오.

원격 프로세스의 고수준 개요는 비교적 단순하지만 저수준 세부 사항은 매우 복잡할 수 있습니다. 원격 서비스의 주요 요소에 대한 자세한 내용은 다음 참고 항목 섹션에 나열된 것처럼 다른 항목에서 제공됩니다.