이전 장에서Proxy와 Stub에 대한 소개를 했다.
이 Proxy, Stub에 관련된 주된 인터페이스는
Proxy에 관해서는 IRpcProxyBuffer와 IRpcChannelBuffer,
Stub에 관해서는 IRpcStubBuffer
라는 표준 COM 인터페이스가 존재한다.
이는 ATL을 사용할때는 내부적으로 숨겨져있어 굳이 다룰 필요가 없으므로,
자세한 설명은 피한다.
단지 인터페이스 이름이 의미하는 Rpc와 Buffer를 보면 어느정도
이 인터페이스의 역할과 내부구조를 추측할수 있을것이다.
그리고, 그 추측은 크게 틀리지 않는다.
한가지 특이한 점이 있다면, 다른 인터페이스의 경우 대부분 하나의 팩토리를 갖지만,
이녀석들은 IPSFactoruBuffer이라는 인터페이스 하나만을 사용한다는 것이 특이한 점이다.
정리하자면, COM의 Remoting Architecture는 네개의 표준 인터페이스로 이루어지며,
그 네가지는 IRpcProxyBuffer, IRpcStubBuffer, IRpcChannelBuffer, IPSFactoryBuffer이다.
이번에는 Surrogate Process를 설명해 볼까 한다.
Surrogate Process는 다음과 같은 경우에 유용하게 사용되는 기법이다.
- 이미 DLL로 포장된 COM Server를 가지고 있고,
이를 액세스하기 위한 코드를 재작성하기 싫을때
- DLL을 클라이언트로부터 독립하게 하여 COM Server가 DLL로 이루어져있음에도
COM Server가 문제가 있더라도 이를 사용하는 클라이언트가 영향을 받기 싫을떄
- DLL을 사용할때 그안의 COM Server에 자체 보안 설정을 적용하고 싶을때
(DLL이 클라이언트의 프로세스에 녹아들어가 사용되면 클라이언트 호스트의 보안 세팅이
기본으로 사용된다.)
그럼 뭐길래 위 의 경우에 사용되는 것일까?
Surrogate Process란 것은 DLL형태로 작성된 COM Server를 클라이언트가
DLL형태로 가져다 쓰지않고, EXE형태로 가져다 쓰는 것을 말한다.
다시 말해 In-Proc서버형태의 COM을 Out-Proc형태로 사용할수 있게 해주는 것이다.
원래대로라면 DLL을 사용하려면 클라이언트는 DLL을 자신의 영역에 로딩하고, 자신의
영역안에서 사용한다. 그러나 Surrogate Process에서는 클라이언트는 사용하고자 하는 DLL
을 요청하면, Windows가 자신이 프로세스를 만들어서 거기에 DLL을 로딩하고나서
자신의 프로세스와 클라이언트의 프로세스와의 통신을 통해 서비스를 이용하게 해주는 것이다.
물론 COM의 위치 독립성이라는 관점에서 Surrogate를 사용하는것과 사용하지 않을때의
코드는 거의 차이가 없다.
단지 상황에 따라, Surrogate Process를 사용하는 것이 위의 상황처럼 필요한 경우에
이를 사용하는 것이다.
그렇다면, Windows는 어떤 프로세스를 실행하는 것일까? 그 프로세스는 당연히 표준화되어
원래의 프로세스(클라이언트)와 통신할수 있는 환경을 제공하여야 한다. 그 프로세스의 이름은
dllhost.exe이다. 이 프로세스는 COM을 공부하지 않은 사람이라도 자주 볼수 있는 프로세스이다.
흔히 작업관리자를 보면 이녀석을 볼수 있는데, 이녀석이 바로 COM DLL을 EXE형태로
사용하게 해주는 유틸리티인 것이다. 가끔 웹에서 이녀석을 찾으면, 바이러스라고 나오는데...
실제로 바이러스가 아닌 윈도우가 제공하는 exe파일이며, 바이러스가 이 exe를 이용한다고 해야
옳다.