마샬링 세부 정보
표준 마샬링을 사용하는 경우 COM은 여기에 설명된 모든 세부 정보를 처리합니다. 그러나 이러한 세부 정보와 기본 정보에 관심이 있는 프로그래머가 거의 없습니다. 마샬링 은 원격 프로시저 호출이 수행되도록 매개 변수를 패키징하고 패키징 해제하는 프로세스입니다.
다른 매개 변수 형식은 다양한 방식으로 마샬링됩니다. 예를 들어 정수 매개 변수를 마샬링하려면 값을 메시지 버퍼에 복사하기만 하면 됩니다. 이 간단한 경우에도 컴퓨터 간 호출에서 처리할 바이트 순서와 같은 문제가 있습니다. 그러나 배열을 마샬링하는 것은 더 복잡한 프로세스입니다. 배열 멤버는 다른 쪽 배열을 정확 하 게 재구성 수 있도록 특정 순서에 따라 복사 됩니다. 포인터가 마샬링되면 포인터가 가리키는 데이터는 구조체에서 중첩된 포인터를 처리하기 위한 규칙 및 규칙에 따라 복사됩니다. 각 매개 변수 형식의 마샬링을 처리하는 고유한 함수가 있습니다.
표준 마샬링을 사용하면 프록시 및 스텁은 인터페이스에 대한 시스템 전체 리소스이며 표준 프로토콜을 통해 채널과 상호 작용합니다. 표준 마샬링 은 다음과 같이 표준 COM 정의 인터페이스와 사용자 지정 인터페이스 모두에서 사용할 수 있습니다.
- 대부분의 COM 인터페이스의 경우 표준 마샬링을 위한 프록시 및 스텁은 Ole32.dll COM에서 제공하는 시스템 전체 DLL에서 로드되는 in-process 구성 요소 개체입니다.
- 사용자 지정 인터페이스의 경우 표준 마샬링에 대한 프록시 및 스텁은 인터페이스 디자이너에서 생성되며, 일반적으로 MIDL을 사용합니다. 이러한 프록시 및 스텁은 레지스트리에서 정적으로 구성되므로 잠재적인 클라이언트는 프로세스 경계를 넘어 사용자 지정 인터페이스를 사용할 수 있습니다. 이러한 프록시 및 스텁은 마샬링하는 사용자 지정 인터페이스에 대해 IID(인터페이스 ID)를 사용하여 시스템 레지스트리를 통해 있는 DLL에서 로드됩니다.
- MIDL을 사용하여 사용자 지정 인터페이스에 대한 프록시 및 스텁을 생성하는 대신 형식 라이브러리를 생성할 수 있으며 제공된 시스템인 type-library 기반 마샬링 엔진이 인터페이스를 마샬링합니다.
표준 마샬링 대신 인터페이스(표준 또는 사용자 지정)는 사용자 지정 마샬링을 사용할 수 있습니다. 사용자 지정 마샬링을 사용하면 개체가 지원하는 각 인터페이스에 대해 런타임에 프록시를 동적으로 구현합니다. 지정된 인터페이스에 대해 개체는 COM 제공 표준 마샬링 또는 사용자 지정 마샬링을 선택할 수 있습니다. 이 선택은 인터페이스별로 개체에 의해 결정됩니다. 지정된 인터페이스에 대해 선택한 후에는 개체의 수명 동안 계속 적용됩니다. 그러나 개체의 한 인터페이스는 사용자 지정 마샬링을 사용할 수 있고 다른 인터페이스는 표준 마샬링을 사용할 수 있습니다.
사용자 지정 마샬링 은 기본적으로 구현하는 개체에 고유합니다. 개체에 의해 구현되고 런타임에 요청 시 시스템에 제공되는 프록시를 사용합니다. 사용자 지정 마샬링을 구현하는 개체는 IMarshal 인터페이스를 구현해야 하지만 표준 마샬링을 지원하는 개체는 구현하지 않습니다.
사용자 지정 인터페이스를 작성하려는 경우 사용자 지정 인터페이스에 대한 마샬링 지원을 제공해야 합니다. 일반적으로 디자인하는 인터페이스에 대한 표준 마샬링 DLL을 제공합니다. 프록시/스텁 코드와 프록시/스텁 DLL을 만들거나 COM에서 데이터 기반 마샬링을 수행하는 데 사용할 형식 라이브러리를 만들 수 있습니다(형식 라이브러리의 데이터를 사용).
클라이언트가 다른 프로세스의 개체에서 인터페이스 메서드를 호출하려면 여러 구성 요소의 협력이 포함됩니다. 표준 프록시는 클라이언트의 프로세스 공간에 상주하고 전송을 위한 인터페이스 매개 변수를 준비하는 인터페이스별 코드의 한 조각입니다. 이를 패키지하거나 마샬링하여 수신 프로세스에서 다시 만들고 이해할 수 있도록 합니다. 인터페이스 관련 코드의 일부이기도 한 표준 스텁은 서버의 프로세스 공간에 상주하며 프록시의 작업을 반대로 합니다. 스텁은 전송된 매개 변수를 압축 풀거나 unmarshals하여 개체 애플리케이션에 전달합니다. 또한 회신 정보를 패키지하여 클라이언트로 다시 보냅니다.
참고
COM보다 RPC에 더 익숙한 독자는 클라이언트 스텁 및 서버 스텁이라는 용어를 보는 데 사용할 수 있습니다. 이러한 용어는 프록시 및 스텁과 유사합니다.
Interprocess Communications의 구성 요소
다음 다이어그램은 관련된 구성 요소 간의 통신 흐름을 보여 줍니다. 프로세스 경계의 클라이언트 쪽에서 클라이언트의 메서드 호출은 프록시를 통과한 다음 COM 라이브러리의 일부인 채널로 이동합니다. 채널은 마샬링된 매개 변수가 포함된 버퍼를 프로세스 경계를 넘어 전송하는 RPC 런타임 라이브러리로 보냅니다. RPC 런타임 및 COM 라이브러리는 프로세스의 양쪽에 존재합니다. 채널과 RPC 런타임 간의 구분은 이 구현의 특징이며 COM 클라이언트/서버 개체에 대한 프로그래밍 모델 또는 개념적 모델의 일부가 아닙니다. COM 서버에는 프록시 또는 스텁만 표시되고 간접적으로 채널이 표시됩니다. 향후 구현에서는 채널 아래에 다른 계층을 사용하거나 레이어를 사용하지 않을 수 있습니다.
관련 항목