COM의 소개(파트 2) - COM 서버의 이면 (7)

COM의 소개(파트 2) – COM 서버의 이면

본 게시물은 ‘codeproject.com’에 게시된 글 ‘Introduction to COM Part II - Behind the Scenes of a COM Server’을 번역한 것입니다.

원 게시물은 https://www.codeproject.com/Articles/901/Introduction-to-COM-Part-II-Behind-the-Scenes-of-a에 게재되어 있습니다. 최대한 원문에 적힌 의도를 반영하고자 하였으나, 우리말로 읽었을 때 보다 자연스럽게 하고자 부득이 어순과 어휘를 조정한 부분도 있음을 양해 바랍니다.

또한 본 게시물에서 언급하고 있는 예제 소스 코드는 Visual C++ 6.0을 기준으로 작성되어 있기 때문에 후속 버전의 Visual Studio(또는 Visual Studio .NET)에서 자동 생성되는 COM 코드와는 다소 차이가 있음을 감안하고 읽으시기 바랍니다.

1. COM의 소개(파트 2) – COM 서버의 이면 (1)
2. COM의 소개(파트 2) – COM 서버의 이면 (2)
3. COM의 소개(파트 2) – COM 서버의 이면 (3)
4. COM의 소개(파트 2) – COM 서버의 이면 (4)
5. COM의 소개(파트 2) – COM 서버의 이면 (5)
6. COM의 소개(파트 2) – COM 서버의 이면 (6)
7. COM의 소개(파트 2) – COM 서버의 이면 (7)
8. COM의 소개(파트 2) – COM 서버의 이면 (8)
9. COM의 소개(파트 2) – COM 서버의 이면 (9) [完]

 

COM 객체 만들기 - 클래스팩토리

우리가 COM의 클라이언트 사이드를 보던 때로 돌아가서, 필자는 COM이 COM 객체를 생성하거나 파괴하기 위한 언어 독립적인 과정을 갖는다고 설명하였습니다. COM 클라이언트는 COM 객체를 새로 만들기 위하여 CoCreateInstance를 호출합니다. 지금부터는 우리는 이것을 서버 사이드에서 보도록 하겠습니다.

여러분이 coclass를 구현할 때마다, 여러분은 또한 가장 최초의 coclass 인스턴스 생성을 담당하는 동반 coclass를 작성하게 됩니다. 이 동반 coclass는 해당 coclass의 ‘클래스팩토리(class factory)’라고 부르며 이것의 유일한 목적은 COM 객체를 생성하는 것입니다. 클래스팩토리를 갖는 이유 또한 언어 독립성을 지키기 위함입니다. COM 그 자체는 COM 객체를 생성할 수 없습니다. 왜냐하면 그렇게 하는 것은 언어 독립적(language independent)이지도 않고, 구현 독립적(implementation independent)이지도 않기 때문입니다.

COM 클라이언트가 COM 객체를 생성할 때, COM 라이브러리는 COM 서버에 있는 클래스팩토리에게 이를 요청합니다. 그러면 클래스팩토리는 COM 클라이언트가 반환 받을 수 있는 COM 객체를 생성합니다. 이와 같은 연동 메커니즘이 바로 내보내기되는 함수인 DllGetClassObject입니다.

사족: “클래스팩토리(class factory)”와 “클래스 객체(class object)”는 사실상 같은 대상을 지칭하는 말입니다. 그러나 두 용어 모두 클래스팩토리의 목적을 정확하게 묘사하지는 못하고 있습니다. 왜냐하면 클래스팩토리는 COM 클래스를 만드는 것이 아니라 COM 객체를 만들기 때문입니다. 따라서 “클래스팩토리(class factory)”라는 용어를 접했을 때 여러분은 머릿속으로 “객체 팩토리(object factory)”로 치환해서 생각하는 것이 도움이 될 수 있습니다. (사실 MFC에서는 클래스팩토리 구현체에 COleObjectFactory라는 이름을 붙임으로써 실제로 이를 시전한 바 있습니다.) 그러나 공식적인 용어가 “클래스팩토리”인 만큼, 필자도 본 글에서는 “클래스팩토리” 용어에 따르겠습니다.

COM 라이브러리가 DllGetClassObject를 호출할 때 클라이언트가 요구한 CLSID를 함께 전달합니다. COM 서버는 요청 받은 CLSID에 해당하는 클래스팩토리를 생성하고 이를 전달할 책임이 있습니다. 클래스팩토리는 그 자체로 coclass이고 IClassFactory 인터페이스를 구현하고 있습니다. DllGetClassObject의 작동이 성공하면 COM 서버는 COM 라이브러리에게 IClassFactory의 포인터를 반환합니다. 그러면 IClassFactory의 메소드를 통해 클라이언트가 요구한 COM 객체 인스턴스가 만들어집니다.

IClassFactory 인터페이스는 다음과 같이 생겼습니다.

struct IClassFactory : public IUnknown {
    HRESULT CreateInstance(IUnknown * pUnkOuter, REFIID riid, void ** ppvObject);
    HRESULT LockServer(BOOL fLock);
};

 

CreateInstance는 새로운 COM 객체를 생성하는 메소드입니다. LockServer는 필요 시 COM 라이브러리가 COM 서버에 대한 레퍼런스 카운트를 증감할 수 있게 합니다.

 

계속 읽기

이전 게시글: COM의 소개(파트 2) – COM 서버의 이면 (6)

다음 게시글: COM의 소개(파트 2) – COM 서버의 이면 (8)