다음을 통해 공유

COM 기술 개요

이 항목에서는 MICROSOFT COM(구성 요소 개체 모델)에 대한 개요를 제공합니다.

COM 소개

MICROSOFT COM(구성 요소 개체 모델)은 런타임에 상호 작용하는 재사용 가능한 소프트웨어 라이브러리를 만들기 위한 이진 상호 운용성 표준을 정의합니다. COM 라이브러리를 애플리케이션으로 컴파일할 요구 없이 사용할 수 있습니다. COM은 Windows 미디어 플레이어 및 Windows Server와 같은 다양한 Microsoft 제품 및 기술의 기반입니다.

COM은 많은 운영 체제 및 하드웨어 플랫폼에 적용되는 이진 표준을 정의합니다. 네트워크 컴퓨팅의 경우 COM은 다른 하드웨어 플랫폼에서 실행되는 개체 간의 상호 작용을 위한 표준 와이어 형식 및 프로토콜을 정의합니다. COM은 구현 언어와 독립적이므로 C++ 및 .NET Framework 다른 프로그래밍 언어를 사용하여 COM 라이브러리를 만들 수 있습니다.

COM 사양은 플랫폼 간 소프트웨어를 다시 사용할 수 있도록 하는 모든 기본 개념을 제공합니다.

  • 구성 요소 간의 함수 호출에 대한 이진 표준입니다.
  • 강력한 형식의 함수를 인터페이스로 그룹화하기 위한 프로비저닝입니다.
  • 다형성, 기능 검색 및 개체 수명 추적을 제공하는 기본 인터페이스입니다.
  • 구성 요소 및 해당 인터페이스를 고유하게 식별하는 메커니즘입니다.
  • 배포에서 구성 요소 인스턴스를 만드는 구성 요소 로더입니다.

COM에는 재사용 가능한 구성 요소에서 빌드된 애플리케이션을 만들 수 있도록 함께 작동하는 여러 부분이 있습니다.

  • COM 사양을 준수하는 런타임 환경을 제공하는 호스트 시스템 입니다.
  • 기능 계약을 정의하는 인터페이스 및 인터페이스를 구현하는 구성 요소입니다.
  • 시스템에 구성 요소를 제공하는 서버와 구성 요소에서 제공하는 기능을 사용하는 클라이언트.
  • 구성 요소가 로컬 및 원격 호스트에 배포되는 위치를 추적하는 레지스트리 입니다.
  • 로컬 및 원격 호스트에서 구성 요소를 찾고 서버를 클라이언트에 연결하는 서비스 제어 관리자 입니다.
  • 호스트의 파일 시스템에서 파일 내용을 탐색하는 방법을 정의하는 구조적 스토리지 프로토콜입니다.

호스트 및 플랫폼에서 코드를 다시 사용하도록 설정하는 것은 COM의 핵심입니다. 재사용 가능한 인터페이스 구현의 이름은 구성 요소, 구성 요소 개체 또는 COM 개체입니다. 구성 요소는 하나 이상의 COM 인터페이스를 구현합니다.

라이브러리에서 구현하는 인터페이스를 디자인하여 사용자 지정 COM 라이브러리를 정의합니다. 라이브러리의 소비자는 라이브러리의 배포 및 구현 세부 정보에 대한 지식 없이 해당 기능을 검색하고 사용할 수 있습니다.

개체 및 인터페이스

COM 개체는 멤버 함수의 컬렉션인 인터페이스를 통해 해당 기능을 노출합니다. COM 인터페이스는 구성 요소의 예상 동작 및 책임을 정의하며, 작은 관련 작업 집합을 제공하는 강력한 형식의 계약을 지정합니다. COM 구성 요소 간의 모든 통신은 인터페이스를 통해 발생하며 구성 요소에서 제공하는 모든 서비스는 해당 인터페이스를 통해 노출됩니다. 호출자는 인터페이스 멤버 함수에만 액세스할 수 있습니다. 내부 상태는 인터페이스에 노출되지 않는 한 호출자가 사용할 수 없습니다.

인터페이스는 강력한 형식입니다. 모든 인터페이스에는 사람이 읽을 수 있는 이름으로 발생할 수 있는 충돌을 제거하는 IID라는 고유한 인터페이스 식별자가 있습니다. IID는 OSF(Open Software Foundation) DCE(분산 컴퓨팅 환경)에서 정의한 UUID(유니버설 고유 ID)와 동일한 GUID(Globally Unique Identifier)입니다. 새 인터페이스를 만들 때 해당 인터페이스에 대한 새 식별자를 만들어야 합니다. 호출자가 인터페이스를 사용하는 경우 고유 식별자를 사용해야 합니다. 이 명시적 식별은 런타임 실패를 초래하는 명명 충돌을 제거하여 견고성을 향상시킵니다.

새 인터페이스를 정의할 때 IDL(인터페이스 정의 언어)을 사용하여 인터페이스 정의를 만들 수 있습니다. 이 인터페이스 정의에서 Microsoft IDL 컴파일러는 인터페이스를 사용하여 애플리케이션에서 사용할 헤더 파일과 원격 프로시저 호출을 처리하는 소스 코드를 생성합니다. Microsoft에서 제공하는 IDL은 RPC(원격 프로시저 호출) 기반 분산 컴퓨팅에 대한 업계 표준인 DCE IDL에 대한 간단한 확장을 기반으로 합니다. IDL은 인터페이스 디자이너의 편의를 위한 도구이며 COM 상호 운용성의 중심이 아닙니다. IDL을 사용하면 각 프로그래밍 환경에 대해 헤더 파일을 수동으로 만들 필요가 없습니다. 자세한 내용은 COM 인터페이스 정의를 참조하세요.

상속은 COM 인터페이스에서 드물게 사용됩니다. COM은 기본 인터페이스와 연결된 계약을 다시 사용하는 인터페이스 상속만 지원합니다. COM은 선택적 상속을 지원하지 않습니다. 따라서 한 인터페이스가 다른 인터페이스에서 상속되는 경우 기본 인터페이스에서 정의하는 모든 함수가 포함됩니다. 또한 인터페이스는 여러 상속 대신 단일 상속만 사용하여 기본 인터페이스에서 함수를 가져옵니다.

인터페이스 구현

COM 인터페이스의 instance 직접 만들 수 없습니다. 대신 인터페이스를 구현하는 클래스의 instance 만듭니다. C++에서 COM 인터페이스는 추상 기본 클래스로 모델링됩니다. 즉, 인터페이스는 순수 가상 멤버 함수만 포함하는 C++ 클래스입니다. C++ 라이브러리는 하나 이상의 인터페이스에서 멤버 함수 서명을 상속하고, 각 멤버 함수를 재정의하고, 각 함수에 대한 구현을 제공하여 COM 개체를 구현합니다.

함수 포인터의 개념을 지원하는 프로그래밍 언어를 사용하여 COM 인터페이스를 구현할 수 있습니다. 예를 들어 C에서 인터페이스는 인터페이스의 각 메서드에 대해 하나씩 함수 포인터 테이블에 대한 포인터를 포함하는 구조체입니다.

인터페이스를 구현할 때 클래스는 인터페이스의 모든 함수에 대한 구현을 제공해야 합니다. 클래스에 인터페이스 함수에서 수행할 작업이 없는 경우 구현은 단일 반환 문일 수 있습니다.

COM 클래스는 파일 시스템의 특정 배포와 클래스를 연결하는 고유한 CLSID(128비트 클래스 ID)를 사용하여 식별되며, Windows의 경우 DLL 또는 EXE입니다. CLSID는 GUID입니다. 즉, 다른 클래스에 동일한 CLSID가 없습니다. 고유 클래스 식별자를 사용하면 클래스 간의 이름 충돌을 방지할 수 있습니다. 예를 들어 두 공급업체는 CStack이라는 클래스를 작성할 수 있지만 두 클래스 모두 고유한 CLSID를 가지므로 충돌 가능성을 방지할 수 있습니다.

CoCreateGuid 함수를 사용하거나 이 함수를 내부적으로 호출하는 Visual Studio와 같은 COM 작성 도구를 사용하여 새 CLSID를 가져옵니다.

IUnknown 인터페이스

모든 COM 인터페이스는 IUnknown 인터페이스에서 상속됩니다. IUnknown 인터페이스에는 다형성 및 instance 수명 관리를 위한 기본 COM 작업이 포함되어 있습니다. IUnknown 인터페이스에는 QueryInterface, AddRef 및 Release라는 세 개의 멤버 함수가 있습니다. IUnknown 인터페이스를 구현하려면 모든 COM 개체가 필요합니다.

QueryInterface 멤버 함수는 COM에 대한 다형성을 제공합니다. 런타임에 QueryInterface 를 호출하여 COM 개체가 특정 인터페이스를 지원하는지 여부를 확인합니다. COM 개체는 요청된 인터페이스를 구현하는 경우 매개 변수의 ppvObject 인터페이스 포인터를 반환하고, 그렇지 않으면 를 반환합니다 NULL. QueryInterface 멤버 함수를 사용하면 COM 개체가 지원하는 모든 인터페이스 간에 탐색할 수 있습니다.

COM 개체 instance 수명은 참조 횟수에 의해 제어됩니다. IUnknown 멤버 함수 AddRef 및 Release는 개수를 제어합니다. AddRef 는 개수를 증가시키고 릴리스 는 개수를 감소합니다. 참조 수가 0에 도달하면 릴리스 멤버 함수는 호출자가 사용하지 않으므로 instance 해제할 수 있습니다.

클라이언트/서버 모델

COM 클래스는 여러 COM 인터페이스를 구현합니다. 구현은 호출자가 COM 클래스의 instance 상호 작용할 때 실행되는 이진 파일로 구성됩니다. COM을 사용하면 특정 클래스에 대한 지식 없이 작성된 애플리케이션을 포함하여 다양한 애플리케이션에서 클래스를 사용할 수 있습니다. Windows 플랫폼에서 클래스는 DLL(동적 연결 라이브러리) 또는 다른 애플리케이션(EXE)에 존재합니다.

호스트 시스템에서 COM은 시스템에 설치된 COM 개체에 대한 모든 CLSID의 등록 데이터베이스를 유지 관리합니다. 등록 데이터베이스는 각 CLSID와 해당 클래스가 있는 DLL 또는 EXE의 위치 간의 매핑입니다. COM은 호출자가 COM 클래스의 instance 만들려고 할 때마다 이 데이터베이스를 쿼리합니다. 호출자는 클래스의 새 instance 요청하려면 CLSID만 알고 있어야 합니다.

COM 개체와 해당 호출자 간의 상호 작용은 클라이언트/서버 관계로 모델링됩니다. 클라이언트는 시스템에서 COM 개체를 요청하는 호출자이며 서버는 클라이언트에 서비스를 제공하는 COM 개체를 보관하는 모듈입니다.

COM 클라이언트는 COM 개체의 instance 요청하기 위해 CLSID를 시스템에 전달하는 호출자입니다. instance 만드는 가장 간단한 방법은 COM 함수인 CoCreateInstance를 호출하는 것입니다.

CoCreateInstance 함수는 지정된 CLSID의 instance 만들고 클라이언트에서 요청한 형식의 인터페이스 포인터를 반환합니다. 클라이언트는 클라이언트가 사용을 마쳤을 때 Release 함수를 호출하여 instance 수명을 관리할 책임이 있습니다. 단일 CLSID를 기반으로 여러 개체를 만들려면 CoGetClassObject 함수를 호출합니다. 이미 만들어 실행 중인 개체에 연결하려면 GetActiveObject 함수를 호출합니다.

COM 서버는 시스템에 COM 구현을 제공합니다. 서버는 CLSID를 COM 클래스와 연결하고, 클래스의 구현을 수용하며, 클래스의 인스턴스를 만들기 위한 클래스 팩터리를 구현하고, 서버 언로드를 제공합니다.

참고

COM 서버는 시스템에 제공하는 COM 개체와 동일하지 않습니다.

 

COM 개체를 만들려면 COM 서버가 IClassFactory 인터페이스의 구현을 제공해야 합니다. 클라이언트는 CreateInstance 메서드를 호출하여 COM 개체의 새 instance 요청할 수 있지만 일반적으로 이러한 요청은 CoCreateInstance 함수에 캡슐화됩니다.

COM 서버를 런타임에 클라이언트 프로세스에 로드되는 공유 라이브러리(Windows 플랫폼의 DLL) 또는 실행 모듈(Windows 플랫폼의 EXE)으로 배포할 수 있습니다. 자세한 내용은 COM 애플리케이션 등록을 참조하세요.

서비스 제어 관리자

SCM(서비스 제어 관리자)은 COM 개체의 instance 대한 클라이언트 요청을 처리합니다. 다음 목록에서는 이벤트 시퀀스를 보여 줍니다.

  • 클라이언트는 COM 개체의 CLSID를 사용하여 CoCreateInstance 와 같은 함수를 호출하여 COM 라이브러리에서 COM 개체에 대한 인터페이스 포인터를 요청합니다.
  • COM 라이브러리는 SCM을 쿼리하여 요청된 CLSID에 해당하는 서버를 찾습니다.
  • SCM은 서버를 찾고 서버에서 제공하는 클래스 팩터리에서 COM 개체 만들기를 요청합니다.
  • 성공하면 COM 라이브러리는 클라이언트에 대한 인터페이스 포인터를 반환합니다.

COM 시스템이 서버 개체를 클라이언트에 연결한 후 클라이언트와 개체는 직접 통신합니다. 중간 런타임을 통해 호출하는 오버헤드가 추가되지 않습니다.

COM 서버를 호스트 시스템에 등록하는 경우 서버를 활성화하는 다양한 방법을 지정할 수 있습니다. 다음 목록에서는 SCM이 COM 서버를 활성화할 수 있는 세 가지 방법을 보여줍니다.

  • In-process: SCM은 개체 서버 구현을 포함하는 DLL의 파일 경로를 반환합니다. COM 라이브러리는 DLL을 로드하고 클래스 팩터리 인터페이스 포인터에 대해 쿼리합니다.
  • 로컬: SCM은 시작 시 클래스 팩터리를 등록하는 로컬 실행 파일을 시작하고 시스템 및 클라이언트에서 해당 인터페이스 포인터를 사용할 수 있습니다.
  • 원격: 로컬 SCM은 원격 컴퓨터에서 실행되는 SCM에서 클래스 팩터리 인터페이스 포인터를 가져옵니다.

클라이언트가 COM 개체를 요청하면 COM 라이브러리가 로컬 호스트의 SCM에 연결합니다. SCM은 로컬 또는 원격일 수 있는 적절한 COM 서버를 찾고 서버는 서버의 클래스 팩터리에 대한 인터페이스 포인터를 반환합니다. 클래스 팩터리를 사용할 수 있는 경우 COM 라이브러리 또는 클라이언트는 클래스 팩터리를 사용하여 요청된 개체를 만들 수 있습니다. 자세한 내용은 IClassFactory 구현을 참조하세요.

재사용 가능성

COM은 재사용 가능한 구성 요소의 구현 세부 정보가 클라이언트에 노출되지 않음을 의미하는 블랙박스 재사용성을 지원합니다. 블랙박스 재사용 가능성을 달성하기 위해 COM은 한 개체가 다른 개체를 다시 사용할 수 있는 두 가지 메커니즘을 지원합니다. 두 가지 형태의 재사용 이름은 포함 및 집계입니다. 규칙에 따라 재사용되는 개체의 이름은 내부 개체이고 내부 개체를 사용하는 개체의 이름은 외부 개체입니다.

포함에서 외부 개체는 내부 개체의 클라이언트로 동작합니다. 외부 개체는 내부 개체에 대한 논리적 컨테이너이며 외부 개체가 내부 개체의 서비스를 사용하는 경우 외부 개체는 내부 개체의 인터페이스에 구현을 위임합니다. 즉, 외부 개체는 내부 개체의 서비스 측면에서 구현됩니다. 외부 개체는 내부 개체와 동일한 인터페이스를 지원하지 않을 수 있으며 외부 개체는 외부 개체에서 다른 인터페이스의 일부를 구현하는 데 도움이 되도록 내부 개체의 인터페이스를 사용할 수 있습니다.

집계에서 외부 개체는 외부 개체에서 구현된 것처럼 내부 개체의 인터페이스를 노출합니다. 이 기능은 외부 개체가 해당 인터페이스 중 하나의 모든 호출을 내부 개체의 동일한 인터페이스에 항상 위임하는 경우에 유용합니다. 집계는 외부 개체가 추가 구현 오버헤드를 방지할 수 있도록 하는 편리한 기능입니다.

자세한 내용은 개체 재사용을 참조하세요.

스토리지 및 스트림 개체

COM 개체는 파일 시스템 의미 체계를 사용하여 파일 내용을 탐색할 수 있는 영구 스토리지의 한 형태인 구조적 스토리지를 사용하여 상태를 파일에 저장합니다. 이러한 방식으로 파일의 콘텐츠를 처리하면 증분 액세스, 트랜잭션 및 프로세스 간 공유와 같은 기능을 사용할 수 있습니다.

COM 영구 스토리지 사양은 스토리지 개체 및 스트림 개체의 두 가지 유형의 스토리지 요소를 제공합니다. 이러한 개체는 COM 라이브러리에 의해 구현되며 사용자 애플리케이션은 이러한 스토리지 요소를 거의 구현하지 않습니다. 스토리지 개체는 IStorage 인터페이스를 구현하고 스트림 개체는 IStream 인터페이스를 구현합니다.

스트림 개체는 데이터를 포함하며 개념적으로 파일 시스템의 단일 파일과 유사합니다. 각 스트림에는 액세스 권한과 단일 검색 포인터가 있습니다. IStream 인터페이스를 통해 스트림의 기본 데이터에 대한 다른 작업을 읽고, 쓰고, 찾고, 수행할 수 있습니다. 스트림의 이름은 텍스트 문자열을 사용하여 지정됩니다. 바이트의 플랫 스트림이므로 내부 구조를 포함할 수 있습니다. 또한 IStream 인터페이스의 함수는 ANSI C 런타임 라이브러리의 함수와 같은 표준 파일 핸들 기반 함수와 유사합니다.

스토리지 개체는 개념적으로 파일 시스템의 디렉터리와 비슷합니다. 각 스토리지에는 임의의 수의 하위 스토리지 개체와 개수의 스트림이 포함될 수 있습니다. 각 스토리지에는 자체 액세스 권한이 있습니다. IStorage 인터페이스를 통해 요소 열거, 이동, 복사, 이름 바꾸기, 만들기 및 삭제와 같은 작업을 수행할 수 있습니다. 스토리지 개체는 애플리케이션 정의 데이터를 저장하지 않지만 포함된 요소(스토리지 및 스트림)의 이름을 암시적으로 저장합니다.

스토리지 및 스트림 개체는 호스트 플랫폼의 COM 사양에 따라 구현될 때 프로세스 간에 공유할 수 있습니다. 이렇게 하면 In-Process 또는 out-of-process를 실행하는 개체가 파일 스토리지에 대해 동일한 증분 액세스 권한을 가질 수 있습니다. COM은 각 프로세스에 별도로 로드되므로 운영 체제에서 지원하는 공유 메모리 메커니즘을 사용하여 열린 요소의 상태와 프로세스 간의 액세스 모드를 전달합니다.

구조화된 파일의 모든 스토리지 및 스트림 개체에는 이를 식별하는 이름이 있습니다. 이름은 특정 규칙을 따르는 문자열입니다. 자세한 내용은 Storage 개체 명명 규칙을 참조하세요. 이름은 IStorage 함수에 전달되어 작업할 스토리지의 요소를 지정합니다. 루트 스토리지 개체의 이름은 기본 파일 시스템의 파일 이름과 동일하며 이러한 이름은 파일 시스템의 규칙 및 제한을 따라야 합니다. 이름 파일이 해석이나 변경 없이 파일 시스템으로 전달되는 스토리지 관련 함수에 전달되는 문자열입니다.

스토리지 개체 내에 포함된 요소의 이름은 해당 스토리지 개체의 구현에 의해 관리됩니다. 스토리지 개체의 모든 구현은 길이가 32자인 요소 이름을 지원해야 하며 일부 구현은 더 긴 이름을 지원할 수 있습니다. 이름은 대/소문자를 유지하면서 저장되지만 대/소문자를 구분하지 않는 것으로 비교됩니다. 스토리지 요소 이름을 정의하는 애플리케이션은 두 경우 모두 작동하는 이름을 선택해야 합니다.

COM에서 구현하는 함수 및 인터페이스를 사용하여 구조화된 스토리지 파일의 모든 요소에 액세스합니다. 즉, 다른 애플리케이션은 디렉터리 같은 서비스를 제공하는 IStorage 인터페이스 함수를 사용하여 탐색하여 파일을 검색할 수 있습니다. 또한 다른 애플리케이션은 파일을 작성한 애플리케이션을 실행하지 않고도 파일의 데이터를 사용할 수 있습니다. COM 애플리케이션이 다른 애플리케이션의 구조적 스토리지 파일에 액세스하는 경우 표준 Windows 액세스 권한이 적용되고 애플리케이션에 충분한 권한이 있어야 합니다.

COM 개체는 영구 스토리지를 읽고 쓸 수 있습니다. 클라이언트는 작업의 컨텍스트에 따라 COM 개체의 지속성 관련 인터페이스 중 하나를 쿼리합니다. COM 개체는 다음 인터페이스의 조합을 구현할 수 있습니다.

  • IPersistStorage: COM 개체는 영구 상태를 읽고 스토리지 개체에 씁니다. 클라이언트는 이 인터페이스를 통해 개체에 IStorage 포인터를 제공합니다. 증분 액세스에 대한 의미 체계를 포함하는 유일한 지속성 인터페이스입니다.
  • IPersistStream: COM 개체는 해당 영구 상태를 읽고 스트림 개체에 씁니다. 클라이언트는 이 인터페이스를 통해 개체에 IStream 포인터를 제공합니다.
  • IPersistFile: COM 개체는 해당 영구 상태를 읽고 기본 시스템의 파일에 직접 씁니다. 이 인터페이스는 이러한 인터페이스를 통해 기본 파일에 액세스하지 않는 한 IStorage 또는 IStream 을 포함하지 않지만 IPersistFile 인터페이스에는 스토리지 및 스트림에 대한 의미 체계가 없습니다. 클라이언트는 개체에 파일 이름을 제공하고 저장 또는 로드 함수를 호출합니다.

데이터 전송

구조적 스토리지는 균일한 데이터 전송이라는 COM 개체와 프로세스 간의 데이터 교환을 위한 기초를 제공합니다. COM이 OLE 2에서 구현되기 전에 Windows의 데이터 전송은 클립보드 및 끌어서 놓기 프로토콜과 같은 전송 프로토콜에 의해 지정되었습니다. 각 전송 프로토콜에는 프로토콜을 쿼리에 바인딩하는 자체 함수 집합이 있으며 각 프로토콜 및 교환 프로시저를 처리하는 데 특정 코드가 필요했습니다. 균일한 데이터 전송은 일반적인 데이터 교환 작업을 전송 프로토콜과 구분하는 IDataObject 인터페이스를 사용하여 모든 데이터 전송을 나타냅니다.

IDataObject 인터페이스는 데이터, 쿼리 및 열거형 및 개체에서 데이터가 변경되는 시기를 감지하는 알림에 대한 표준 가져오기 및 설정 작업을 캡슐화합니다. 균일한 데이터 전송을 사용하면 데이터 형식에 대한 풍부한 설명과 데이터 전송을 위해 다양한 스토리지 미디어를 사용할 수 있습니다.

균일한 데이터 전송 중에 모든 프로토콜은 IDataObject 인터페이스에 대한 포인터를 교환합니다. 서버는 데이터의 원본이며 데이터 교환 프로토콜에서 사용할 수 있는 하나의 데이터 개체를 구현합니다. 클라이언트는 데이터를 사용하고 모든 프로토콜에서 IDataObject 포인터를 받을 때 데이터 개체에서 데이터를 요청합니다. 포인터 교환이 발생한 후 양측은 IDataObject 인터페이스를 통해 데이터 교환을 균일한 방식으로 처리합니다.

COM은 균일한 데이터 전송을 가능하게 하는 두 가지 데이터 구조를 정의합니다. FORMATETC 구조체는 일반화된 클립보드 형식을 나타내고 STGMEDIUM 구조체는 전송 매체를 메모리 핸들로 나타냅니다.

클라이언트는 데이터 원본에서 요청하는 데이터 형식을 나타내는 FORMATETC 구조를 만들고 데이터 원본에서 제공하는 형식을 설명하는 데 사용됩니다. 클라이언트는 IEnumFORMATETC 인터페이스를 요청하여 사용 가능한 형식에 대해 데이터 원본을 쿼리합니다. 자세한 내용은 FORMATETC 구조를 참조하세요.

클라이언트는 STGMEDIUM 구조를 만들어 GetData 메서드에 전달하고 데이터 개체는 제공된 STGMEDIUM 구조체의 데이터를 반환합니다.

STGMEDIUM 구조를 사용하면 클라이언트와 데이터 원본 모두 가장 효율적인 교환 매체를 선택할 수 있습니다. 예를 들어 교환할 데이터가 매우 큰 경우 데이터 원본은 기본 메모리 대신 디스크 기반 매체를 기본 형식으로 나타낼 수 있습니다. 이러한 유연성을 통해 IStorage 또는 IStream에 포인터를 전달하는 것만큼 빠를 수 있는 효율적인 데이터 교환이 가능합니다. 자세한 내용은 STGMEDIUM 구조를 참조하세요.

데이터 원본의 클라이언트는 데이터가 변경되면 알림이 필요할 수 있습니다. COM은 IAdviseSink 인터페이스를 구현하는 advise 싱크 개체를 사용하여 데이터 변경 알림을 처리합니다. advise 싱크 개체 및 IAdviseSink 인터페이스는 IAdviseSink 포인터를 데이터 원본에 전달하는 클라이언트에 의해 구현됩니다. 데이터 원본이 기본 데이터의 변경 사항을 감지하면 IAdviseSink 메서드를 호출하여 클라이언트에 알립니다. 자세한 내용은 데이터 알림을 참조하세요.

원격 통신

COM을 사용하면 원격 및 분산 계산을 사용할 수 있습니다. 인터페이스 원격 을 사용하면 멤버 함수가 다른 프로세스 또는 다른 호스트 컴퓨터에 있는 COM 개체에 대한 인터페이스 포인터를 반환할 수 있습니다. 인터페이스 원격을 수행하는 인프라는 클라이언트와 개체 서버 모두에 투명합니다. 클라이언트와 서버 모두 원격 인터페이스를 통해 통신하기 위해 서로의 배포 세부 정보가 필요하지 않습니다. 클라이언트는 동일한 인터페이스에서 멤버 함수를 호출하여 로컬 호스트 또는 원격 컴퓨터에서 처리 중이거나 처리되지 않는 COM 개체와 통신합니다. 동일한 인터페이스의 로컬 및 원격 호출은 클라이언트와 구별할 수 없습니다.

COM 개체와 통신하기 위해 클라이언트는 항상 In-Process 구현을 호출합니다. COM 개체가 진행 중이면 호출이 직접 수행됩니다. COM 개체가 out-of-process 또는 remote인 경우 COM은 RPC(원격 프로시저 호출) 프로토콜을 사용하여 개체에 대한 호출을 전달하는 프록시 구현을 제공합니다.

COM 개체는 항상 프로세스 내 구현을 통해 클라이언트에서 호출을 받습니다. 호출자가 진행 중이면 호출이 직접 수행됩니다. 호출자가 out-of-process 또는 remote인 경우 COM은 클라이언트 프로세스의 프록시에서 원격 프로시저 호출을 수신하는 스텁 구현을 제공합니다.

마샬링 은 프록시에서 스텁으로 전송하기 위한 호출 스택을 패키징하는 절차입니다. unmarshaling 은 수신 끝에서 발생하는 패키지 해제입니다. 반환 값은 스텁에서 프록시로 마샬링되고 마샬링되지 않습니다. 이러한 종류의 통신을 유선으로 전화를 보내는 것이라고도 합니다.

각 데이터 형식에는 마샬링에 대한 규칙이 있습니다. 인터페이스 포인터에는 CoMarshalInterface 함수에 캡슐화된 마샬링 프로토콜도 있습니다. 대부분의 경우 시스템에서 제공하는 표준 인터페이스 마샬링만으로도 충분하지만 COM 개체는 필요에 따라 사용자 지정 인터페이스 마샬링을 구현하여 자체에 대한 원격 개체 프록시 생성을 제어할 수 있습니다. 자세한 내용은 개체 간 통신을 참조하세요.

보안

COM은 두 가지 형태의 애플리케이션 보안을 제공합니다. 하나는 새 개체를 만드는 방법, 클라이언트가 새 개체와 기존 개체에 연결하는 방법, 클래스 테이블 및 실행 중인 개체 테이블과 같은 특정 공용 서비스의 보안을 지정하는 활성화 보안입니다. 다른 하나는 COM 개체에 대한 클라이언트 간의 설정된 연결에서 보안이 작동하는 방식을 지정하는 호출 보안입니다.

활성화 보안은 SCM(서비스 제어 관리자)에 의해 자동으로 적용됩니다. SCM은 COM 개체 검색 요청을 받으면 레지스트리에 저장된 보안 정보에 대해 요청을 확인합니다.

SCM 구현은 일반적으로 배포된 클래스를 관리하고 호스트의 특정 사용자 계정에 대한 레지스트리 기반 구성을 제공합니다. 자세한 내용은 활성화 보안을 참조하세요.

호출 보안은 자동으로 적용되거나 애플리케이션에 의해 적용됩니다. 애플리케이션에서 설정 정보를 제공하는 경우 COM은 애플리케이션을 보호하는 데 필요한 검사를 수행합니다.

자동 메커니즘은 프로세스에 대한 보안을 검사하지만 개별 개체 또는 메서드는 검사하지 않습니다. 애플리케이션에 보다 세분화된 보안이 필요한 경우 COM은 애플리케이션에서 자체 보안 검사를 수행하는 데 사용할 수 있는 기능을 제공합니다.

자동 및 사용자 지정 메커니즘을 함께 사용할 수 있으므로 애플리케이션은 COM에 자동 보안 검사를 수행한 다음 자체적으로 수행하도록 요청할 수 있습니다.

COM 호출 보안 서비스는 다음 범주로 나뉩니다.

  • 클라이언트와 서버 모두에서 호출되는 일반 함수로, 자동 보안 메커니즘을 초기화하고 자동 인증 서비스를 등록할 수 있습니다. 일반적인 호출 보안 API는 CoInitializeSecurity 및 CoQueryAuthenticationServices 함수입니다.
  • 클라이언트 프록시의 인터페이스 - 클라이언트가 개별 인터페이스 호출 시 보안을 제어할 수 있도록 합니다. IClientSecurity 인터페이스 및 CoQueryProxyBlanket, CoSetProxyBlanket 및 CoCopyProxy 함수는 원격 개체에 대한 호출 보안을 제공합니다.
  • 서버 쪽 함수 및 호출 컨텍스트 인터페이스를 사용하면 서버가 호출에 대한 보안 정보를 검색하고 호출자를 가장할 수 있습니다. IServerSecurity 인터페이스 및 CoGetCallContext, CoImpersonateClient 및 CoRevertToSelf 함수는 서버 쪽 호출 보안을 제공합니다.

종종 클라이언트는 원격 계층에 의해 로컬로 구현되는 IClientSecurity 인터페이스에 대한 COM 개체를 쿼리합니다. 클라이언트는 인터페이스 중 하나에서 호출하기 전에 이 인터페이스를 사용하여 COM 개체에서 개별 인터페이스 프록시의 보안을 제어합니다.

호출이 서버에 도착하면 서버는 CoGetCallContext 함수를 호출하여 IServerSecurity 인터페이스를 검색할 수 있습니다. 이를 통해 서버는 클라이언트의 인증을 검사 필요한 경우 클라이언트를 가장할 수 있습니다. IServerSecurity 개체는 호출 기간 동안 유효합니다.

CoInitializeSecurity 함수를 호출하여 보안 계층을 초기화하고 지정된 값을 보안 기본값으로 설정합니다. 프로세스가 CoInitializeSecurity를 호출하지 않는 경우 COM은 인터페이스가 처음 마샬링되거나 마즈헤이징되지 않을 때 자동으로 호출하여 시스템 기본 보안을 등록합니다. CoInitializeSecurity 함수를 사용하면 클라이언트가 프로세스에 대한 기본 호출 보안을 설정할 수 있으므로 개별 프록시에서 IClientSecurity를 사용하지 않습니다. CoInitializeSecurity 함수를 사용하면 서버에서 프로세스에 대한 자동 인증 서비스를 등록할 수 있습니다. 자세한 내용은 CoInitializeSecurity를 사용하여 Process-Wide 보안 설정을 참조하세요.

COM 클라이언트 및 서버

COM 인터페이스 정의

COM 애플리케이션 등록

COM의 보안

프로세스, 스레드 및 아파트

 

 

  • Last updated on