.NET Framework Remoting 아키텍처
.NET Remoting 인프라는 추상적인 프로세스 간 통신 방법입니다. 시스템의 대부분이 특별한 처리 없이도 작동합니다. 예를 들어, 값으로 전달하거나 복사할 수 있는 개체는 서로 다른 응용 프로그램 도메인 또는 서로 다른 컴퓨터에 있는 응용 프로그램 간에 자동으로 전달됩니다. 사용자는 이 작업을 위해 사용자 지정 클래스를 serializable로 표시하기만 하면 됩니다.
그러나 원격 시스템의 진정한 장점은 서로 다른 전송 프로토콜, serialization 형식, 개체 수명 스키마 및 개체 생성 모드를 사용하는 여러 응용 프로그램 도메인 또는 프로세스에 있는 개체 간의 통신을 가능하게 할 수 있다는 점입니다. 또한 원격 서비스를 사용하면 통신 프로세스의 거의 모든 단계에 사용자가 개입할 수 있습니다.
분산 응용 프로그램을 구현한 경험이 많은 사용자이든 단지 구성 요소를 다른 컴퓨터로 이동하여 프로그램의 확장성을 향상시키는 데만 관심이 있는 사용자이든, 원격 시스템은 대부분의 시나리오를 쉽게 처리하는 일부 기본 구현이 포함된 일반적인 프로세스 간 통신 시스템으로 이해하면 쉽게 이해할 수 있습니다. 다음 항목에서는 원격 서비스를 사용한 프로세스 간 통신의 기본 사항에 대해 먼저 설명합니다.
복사와 참조 비교
프로세스 간 통신에는 프로세스 외부의 호출자에게 해당 기능이 제공되는 서버 개체, 서버 개체를 호출하는 클라이언트, 그리고 한 프로세스에서 다른 프로세스로 호출을 전달하기 위한 전송 메커니즘이 필요합니다. 서버 메서드의 주소는 논리적이며 특정 프로세스에서는 올바르게 작동하지만 다른 클라이언트 프로세스에서는 올바르게 작동하지 않습니다. 이 문제를 해결하기 위해 클라이언트에서는 개체 전체의 복사본을 만들고 해당 복사본의 메서드를 직접 호출할 수 있는 클라이언트 프로세스로 복사본을 이동함으로써 서버 개체를 호출할 수 있습니다.
그러나 대부분의 개체는 다른 프로세스로 이동하여 실행할 수 없습니다. 특히 메서드가 많이 포함된 매우 큰 개체는 다른 프로세스에 복사하거나 값으로 전달하는 데 적합하지 않습니다. 일반적으로 클라이언트에서는 서버 개체의 하나 또는 일부 메서드에서 반환하는 정보만 필요로 합니다. 클라이언트에서 필요로 하지 않는 내부 정보나 실행 구조체가 상당히 많이 포함되어 있을 수 있는 전체 서버 개체를 복사하면 클라이언트 메모리와 처리 시간뿐만 아니라 대역폭도 낭비됩니다. 또한 대부분의 개체는 공용 기능을 노출하지만 내부 실행을 위해 비공개 데이터를 필요로 합니다. 이러한 개체를 복사하면 권한이 없는 클라이언트가 내부 데이터를 확인할 수 있으므로 보안 문제가 발생할 가능성이 있습니다. 마지막으로 일부 개체에서는 이해할 수 있는 방식으로는 복사할 수 없는 데이터를 사용합니다. 예를 들어, FileInfo 개체에는 서버 프로세스의 메모리에서 고유 주소를 가지는 운영 체제 파일에 대한 참조가 포함되어 있습니다. 이 주소를 복사할 수는 있지만 다른 프로세스에서는 이 주소가 의미가 없게 됩니다.
이런 경우 서버 프로세스에서는 서버 개체의 복사본 대신 해당 개체에 대한 참조를 클라이언트 프로세스에 전달해야 합니다. 클라이언트에서는 이 참조를 사용하여 서버 개체를 호출할 수 있습니다. 이러한 호출은 클라이언트 프로세스에서 실행되지 않습니다. 대신 원격 시스템에서 호출에 대한 모든 정보를 수집하여 서버 프로세스에 보냅니다. 그러면 서버 프로세스에서는 이를 해석하고 올바른 서버 개체를 찾은 다음 클라이언트 개체를 대신해서 해당 서버 개체를 호출합니다. 그런 다음에는 호출 결과가 다시 클라이언트 프로세스로 보내져서 클라이언트에게 반환됩니다. 대역폭은 호출, 호출 인수, 반환 값 또는 예외 등의 중요한 정보에 대해서만 사용됩니다.
단순화된 원격 아키텍처
원격 서비스의 핵심은 개체 참조를 사용하여 서버 개체와 클라이언트 간에 통신하는 것입니다. 그러나 원격 아키텍처에서는 프로그래머에게 보다 단순한 프로시저를 제공합니다. 클라이언트를 올바르게 구성한 경우 사용자는 new 또는 관리되는 프로그래밍 언어의 인스턴스 생성 함수를 사용하여 원격 개체의 새 인스턴스를 만들기만 하면 됩니다. 클라이언트에서는 서버 개체에 대한 참조를 받고, 그러면 사용자는 해당 개체가 별도의 컴퓨터에서 실행되는 것이 아니라 마치 사용자의 프로세스에 있는 것처럼 해당 메서드를 호출할 수 있습니다. 원격 시스템에서는 프록시 개체를 사용하여 서버 개체가 클라이언트의 프로세스에 있는 것 같은 효과를 만듭니다. 프록시는 개체를 다른 개체로 나타내는 대리 개체입니다. 클라이언트에서 원격 형식의 인스턴스를 만들 때 원격 인프라에서는 클라이언트에게 마치 해당 원격 형식 자체인 것처럼 보이는 프록시 개체를 만듭니다. 클라이언트에서는 이 프록시에 대해 메서드를 호출하고 원격 시스템에서는 호출을 받아 서버 프로세스로 라우팅하고 서버 개체를 호출한 다음 반환 값을 클라이언트 프록시에 반환합니다. 그러면 클라이언트 프록시에서는 이 결과를 클라이언트에 반환합니다.
클라이언트와 서버 프로세스 간의 원격 호출은 몇 가지 방법으로 전달되어야 합니다. 원격 시스템을 사용자가 직접 빌드하는 경우에는 먼저 네트워크 프로그래밍과 다양한 프로토콜 및 serialization 형식 사양에 대해 알아야 합니다. .NET Remoting 시스템에서는 네트워크 연결을 열고 특정 프로토콜을 사용하여 수신 응용 프로그램에 바이트를 보내는 데 필요한 기본 기술의 조합이 전송 채널로 나타납니다.
채널은 데이터 스트림을 받아 들여 특정 네트워크 프로토콜에 따라 패키지를 만들고 이 패키지를 다른 컴퓨터에 보내는 형식입니다. 일부 채널에서는 정보를 받을 수만 있고 일부 채널에서는 정보를 보낼 수만 있지만, 기본 TcpChannel 및 HttpChannel 클래스 같은 일부 채널은 양방향으로 사용될 수 있습니다.
서버 프로세스에서는 각각의 고유 형식에 대한 모든 사항을 알고 있지만 클라이언트에서는 해당 클라이언트에 대개 다른 컴퓨터에 있는 다른 응용 프로그램 도메인의 개체에 대한 참조가 필요하다는 것만 압니다. 서버 응용 프로그램 도메인 외부에서는 URL이 개체 위치를 찾습니다. 외부의 고유 형식을 나타내는 URL은 올바른 형식에 대한 원격 호출이 가능하도록 하는 활성화 URL입니다. 자세한 내용은 활성화 URL을 참조하십시오.
전체 원격 시스템 디자인
한 컴퓨터에서 실행되는 응용 프로그램이 있으며 다른 컴퓨터에 저장된 형식에서 노출하는 기능을 사용하려는 경우를 가정합니다. 다음 그림에서는 일반적인 원격 프로세스를 보여 줍니다.
원격 프로세스
.gif)
이 관계의 양쪽이 모두 올바르게 구성된 경우 클라이언트에서는 단지 서버 클래스의 새 인스턴스를 만듭니다. 원격 시스템에서는 해당 클래스를 나타내는 프록시 개체를 만들고 클라이언트 개체에 해당 프록시에 대한 참조를 반환합니다. 클라이언트에서 메서드를 호출할 때 원격 인프라에서는 이 호출을 처리하여 형식 정보를 확인한 다음 채널을 통해 서버 프로세스에 보냅니다. 수신 채널에서는 요청을 받아 요청된 개체를 찾거나 필요하면 만든 다음 호출하는 서버의 원격 시스템에 전달합니다. 그런 다음 서버의 원격 시스템에서 응답을 메시지로 묶고 서버 채널에서 이 메시지를 클라이언트 채널로 보낼 때는 이 프로세스가 반대로 수행됩니다. 마지막으로 클라이언트의 원격 시스템에서는 프록시를 통해 호출 결과를 클라이언트 개체에 반환합니다.
이 작업을 수행하는 데는 매우 적은 실제 코드가 필요하지만 이러한 관계를 디자인하고 구성할 때는 약간 주의해야 합니다. 코드가 완전히 올바른 경우에도 URL이나 포트 번호가 올바르지 않으면 문제가 생길 수 있습니다. 자세한 내용은 구성을 참조하십시오.
지금까지 설명한 원격 프로세스의 개략적인 내용은 매우 간단하지만 보다 세부적인 내용은 매우 복잡할 수 있습니다. 원격 서비스의 주요 요소에 대한 보다 자세한 내용은 아래 열거된 다른 항목에서 설명합니다.
참고 항목
개념
경계: 프로세스 및 응용 프로그램 도메인
원격화할 수 있는 개체와 원격화할 수 없는 개체
채널
원격 작업의 보안
원격 응용 프로그램의 구성