컴포넌트 객체 모델

Component Object Model
COM
컴포넌트 객체 모델
줄임말COM
상황실시중
초판1993년; 29년 전(1993년)
최신 버전생활 수준
2021
조직마이크로소프트
시리즈시스템 서비스
기본 규격MIDL, UUID
관련 기준
도메인컴포넌트 인터페이스
웹 사이트docs.microsoft.com/en-us/windows/win32/com/the-component-object-model

Component Object Model(COM; 컴포넌트 오브젝트 모델)은 Microsoft가 1993년에 도입한 소프트웨어 컴포넌트의 바이너리 인터페이스 규격입니다.광범위한 프로그래밍 언어로 프로세스 간 통신 개체를 만들 수 있도록 하기 위해 사용됩니다.COM은 OLE, OLE Automation, Browser Helper Object, ActiveX, COM+, DCOM, Windows 쉘, DirectX, UMDF 및 Windows Runtime을 포함한 여러 다른 Microsoft 기술 및 프레임워크의 기반입니다.COM의 본질은 언어 중립적인 방법으로 오브젝트를 구현하는 것입니다.개체는 작성된 환경과는 다른 환경에서도 사용할 수 있습니다.머신의 경계를 넘어서는 환경에서도 사용할 수 있습니다.적절하게 작성된 컴포넌트의 경우 COM을 사용하면 컴포넌트 구현자가 구현에서 분리된 정의된 인터페이스를 제공하도록 하기 때문에 내부 구현에 대한 지식이 없는 개체를 재사용할 수 있습니다.언어의 다른 할당 의미론은 참조 카운팅을 통해 오브젝트가 자신의 생성과 파괴를 책임지도록 함으로써 수용됩니다.오브젝트의 다른 인터페이스 간의 타입 변환 캐스팅은QueryInterface방법.COM 내의 「상속」의 바람직한 방법은, 「콜」이 위임되는 서브 오브젝트를 작성하는 것입니다.

COM은 Microsoft Windows 및 Apple Core Foundation 1.3 이후의 플러그인 애플리케이션 프로그래밍 인터페이스(API)[1]에서만 표준으로 정의 및 구현되는 인터페이스 기술입니다.후자는 COM 인터페이스 [2]전체의 서브셋만을 실장합니다.애플리케이션에 따라서는, 적어도 어느 정도는 Microsoft 에 의해서 COM 가 대체되고 있습니다.NET 프레임워크 및 Windows Communication Foundation(WCF)을 통한 웹 서비스 지원.단, COM 오브젝트는 모두와 함께 사용할 수 있습니다.NET 언어 ~NET COM 상호 운용네트워크 DCOM 에서는 바이너리 독자적인 포맷이 사용되고 있습니다만, WCF 에서는 XML 베이스의 SOAP 메시징의 사용이 권장되고 있습니다.COM은 CORBA나 Enterprise JavaBeans 등의 다른 컴포넌트 소프트웨어 인터페이스 테크놀로지와 매우 유사하지만 각각 장단점이 있습니다.C++와 달리 COM은 컴파일러 [3]릴리스 간에 변경되지 않는 안정적인 응용 프로그램 바이너리 인터페이스(ABI)를 제공합니다.이로 인해 COM 인터페이스는 다른 컴파일러 버전을 사용하여 컴파일된 클라이언트에 의해 사용되는 객체 지향 C++ 라이브러리에 매력적입니다.

역사

Windows에서 프로세스 간 통신의 첫 번째 방법 중 하나는 1987년에 [5]처음 도입된 동적 데이터 교환(DDE)[4]으로, 애플리케이션 간에 이른바 "컨버세이션"으로 메시지를 송수신할 수 있었습니다.COM 아키텍처의 작성에 관여한 Antony Williams는 소프트웨어 컴포넌트의 개념을 채택한2개의 내부 문서를 나중에 Microsoft에 배포했습니다.Object Architecture: 1988년 및 상속 시 동적으로 확장 가능한 클래스 라이브러리의 알 수 없는 유형 안전성 대처: 1990년의 의미와 사용법이것들은 COM의 배후에 있는 많은 아이디어의 토대가 되었습니다.마이크로소프트 최초의 객체 기반 프레임워크인 OLE(Object Linking and Embedding)는 DDE 위에 구축되어 복합 문서용으로 특별히 설계되었습니다.1991년 Word for Windows와 Excel에서 소개되었으며 1992년 버전 3.1부터 Windows에 포함되었습니다.복합문서의 예로는 Word for Windows 문서에 내장된 스프레드시트가 있습니다.Excel에서 스프레드시트를 변경하면 자동으로 Word 문서 내에 나타납니다.

1991년 Microsoft는 Visual Basic 1.0을 사용한 VBX(Visual Basic Extensions)를 발표했습니다.VBX는 Dynamic Link Library(DLL; 동적 링크 라이브러리) 형식의 패키지 확장입니다.이 확장에서는 오브젝트를 그래픽 형식으로 배치하여 속성 및 메서드로 조작할 수 있습니다.이것들은 나중에 Visual C++와 같은 다른 언어에서 사용할 수 있도록 수정되었습니다.1992년 윈도우즈 버전 3.1이 출시되었을 때 마이크로소프트는 기본 개체 모델을 사용하여 OLE 2를 출시했습니다.COM 애플리케이션 바이너리 인터페이스(ABI)는 MAPI ABI(1992년 출시)와 동일하며 MSRPC에 기반하고 궁극적으로는 오픈 그룹의 DCE/RPC에 기반하는 것처럼 보입니다.OLE 1은 복합 문서에 초점을 맞춘 반면, COM 및 OLE 2는 일반적으로 소프트웨어 구성 요소를 다루도록 설계되었습니다.텍스트 대화와 Windows 메시지는 강력하고 확장 가능한 방식으로 애플리케이션 기능을 공유할 수 있을 만큼 유연하지 않다는 것이 입증되었기 때문에 COM은 새로운 기반으로 만들어졌고 OLE는 OLE2로 변경되었습니다.1994년 OLE 커스텀 컨트롤(OCX)이 VBX 컨트롤의 후속 제품으로 도입되었습니다.동시에, 마이크로소프트는 OLE 2가 단지 "OLE"로 알려지게 될 것이며, OLE는 더 이상 약어가 아니라 회사의 모든 구성 요소 기술에 대한 이름이라고 말했다.1996년 초, Microsoft는 웹 브라우저의 기능을 확장하여 콘텐츠를 표시하는 OLE의 일부 이름을 "ActiveX"로 변경했으며, Microsoft Office에서 사용된 복합 문서 기술을 제외한 모든 OLE 기술의 이름을 ActiveX로 점차 변경했습니다.그 해 후반, Microsoft는 COM을 DCOM과 [6]함께 네트워크 전체에서 동작하도록 확장했습니다.

관련 테크놀로지

COM은 Windows의 주요 소프트웨어 개발 플랫폼이었고, 따라서 많은 지원 기술 개발에 영향을 미쳤습니다.마찬가지로 초기 기술의 영향을 많이 받았습니다.

DDE

COM은 DDE를 프로세스 간 통신의 바람직한 형태로 대체했습니다.

DCE/RPC 및 MSRPC

COM은 크로스 언어 컴포넌트 모델로서 인터페이스 정의 언어(IDL)를 사용하여 오브젝트 및 관련 함수를 기술합니다.COM IDL은 기능이 풍부한 DCE/RPC IDL에 크게 기반하고 있으며 객체 지향 확장 기능을 갖추고 있습니다.MSRPC로 알려진 Microsoft의 DCE/RPC 실장은 Windows NT 서비스 및 내부 컴포넌트의 프로세스 간 주요 통신 메커니즘으로 많이 사용되기 때문에 확실한 기반이 됩니다.

DCOM

DCOM(Distributed COM)은 COM의 범위를 Windows 데스크톱에서 통신하는 개별 애플리케이션을 사용하여 단일 사용자를 지원하는 것뿐만 아니라 다양한 보안 컨텍스트에서 실행되는 개체를 활성화하고 네트워크상의 다른 머신에서 실행할 수 있도록 확장했습니다.이것에 의해, 오브젝트의 작성, 액티브화, 콜의 권한을 가지는 유저의 설정, 발신측 유저의 식별, 및 콜의 시큐러티에 필요한 암호화를 지정하기 위해서 필요한 기능이 추가되었습니다.

COM+

Microsoft는 분산 트랜잭션, 리소스 풀링, 접속 해제된 애플리케이션, 이벤트 퍼블리싱 및 구독, 메모리 및 프로세서(스레드) 관리 개선, 기타 엔터프라이즈 수준의 운영 체제 대체 수단으로 Windows를 포지셔닝하기 위해 테크놀로지 콜을 도입했습니다.ed Microsoft Transaction Server(MTS)를 참조하십시오.Windows 2000 에서는, (MTS가 제공하는 일련의 외부 툴과는 달리) operating system에 COM 에의 대폭적인 확장이 짜넣어져 COM+ 로 이름이 변경되었습니다.동시에, Microsoft 는 DCOM 를 다른 엔티티로서 강조하지 않게 되었습니다.COM+ 서비스를 이용하는 컴포넌트는 COM+의 추가된 레이어, 특히 인터셉트용 운영체제 지원을 통해 보다 직접적으로 처리되었습니다.MTS의 첫 번째 릴리스에서는 대행 수신이 처리되었습니다.MTS 컴포넌트를 설치하면 Windows 레지스트리가 변경되어 컴포넌트가 직접 호출되지 않습니다.Windows 2000에서는 COM+ 컴포넌트 설정에 사용하는 컴포넌트 서비스 제어판 애플리케이션도 수정되었습니다.

COM+의 장점은 "컴포넌트 팜"에서 실행할 수 있다는 것입니다.컴포넌트의 인스턴스는 올바르게 코드화되어 있으면 메모리에서 언로드하지 않고 초기화 루틴에 대한 새로운 호출에 의해 풀링되어 재사용될 수 있습니다.컴포넌트를 분산할 수도 있습니다(다른 머신에서 호출).COM+와 Microsoft Visual Studio는 클라이언트측 프록시를 쉽게 생성할 수 있는 도구를 제공했기 때문에 DCOM은 원격 호출에 사용되었지만 개발자는 쉽게 실행할 수 있었습니다.또한 COM+는 COM+ Events라는 서브스크라이버/퍼블리셔 이벤트메커니즘을 도입하여 큐잉 컴포넌트라고 불리는 컴포넌트와 함께 MSMQ(애플리케이션 간 비동기 메시징을 제공하는 기술)를 활용하는 새로운 방법을 제공하였습니다.COM+ 이벤트는 COM+ 프로그래밍 모델을 확장하여 퍼블리셔 또는 서브스크라이버와 이벤트시스템 간의 레이트바인딩(레이트바인딩 참조) 이벤트 또는 메서드콜을 지원합니다.

.그물

주요 기사:NET 프레임워크

Microsoft.NET은 컴포넌트 테크놀로지를 제공하는 수단과 (COM-interop-assembly를 통해) COM+와의 상호작용을 모두 제공합니다.NET은 일반적으로 사용되는 대부분의 COM 컨트롤에 래퍼를 제공합니다.Microsoft.NET은 컴포넌트 작성으로부터 대부분의 세부사항을 숨김으로써 개발을 용이하게 합니다.NET은 시스템을 통해 COM+를 활용할 수 있습니다.Enterprise Services 네임스페이스 및 COM+가 제공하는 서비스의 일부는 의 최신 릴리스에서 복제되었습니다.NET. 예를 들어 시스템.트랜잭션 이름 공간입니다.NET은 TransactionScope 클래스를 제공합니다.이 클래스는 COM+에 의존하지 않고 트랜잭션 관리를 제공합니다.또한 큐에 있는 컴포넌트는 MSMQ 트랜스포트로 Windows Communication Foundation으로 대체할 수 있습니다.(단, MSMQ는 네이티브 COM 컴포넌트입니다.하위 호환성에 대한 지원은 제한되어 있습니다.COM 오브젝트는 에서 사용할 수 있습니다.Runtime Callable Wrapper(RCW;[7] 런타임 콜 가능 래퍼)를 실장하는 것에 의해서, NET.특정 인터페이스 제한에 준거한NET 오브젝트는 COM Callable Wrapper(CCW;[8] 콜 가능 래퍼)를 호출하여 COM 오브젝트에서 사용할 수 있습니다.COM 및 양쪽에서NET 측에서는 다른 기술을 사용하는 개체가 네이티브 개체로 나타납니다.「COM Interop」을 참조해 주세요.WCF(Windows Communication Foundation)는 COM의 많은 원격 실행 과제를 완화합니다.예를 들어 프로세스 또는 머신의 경계를 넘어 오브젝트를 값별로 투명하게 정렬할 수 있습니다.

윈도 런타임

주요 기사:윈도 런타임

Microsoft의 Windows Runtime(또는 Windows RT와 혼동하지 않는 WinRT) 프로그래밍 및 애플리케이션 모델은 확장 COM에 의존하지만 기본적으로 COM 기반 API입니다.COM과 같은 기반 때문에 Windows Runtime은 COM과 마찬가지로 여러 언어에서 비교적 쉽게 인터페이스할 수 있지만 기본적으로는 관리되지 않는 네이티브 API입니다.단, API 정의는 ".winmd" 파일에 저장됩니다.이 파일들은 ECMA 335 메타데이터 형식으로 인코딩되어 있습니다.이 형식은 와 같은 CLI 메타데이터 형식입니다.NET은 몇 가지 변경을 가하여 사용합니다.이 일반적인 메타데이터 형식을 사용하면 에서 WinRT가 호출될 때 P/Invoke보다 훨씬 적은 오버헤드를 실현할 수 있습니다.NET 어플리케이션의 구문은 매우 간단합니다.

Nano-COM(XPCOM이라고도 함)

Nano-COM은 컴포넌트 오브젝트 모델의 극히 작은 서브셋으로 독립적으로 컴파일된 모듈/컴포넌트 간에 함수 및 메서드 호출을 가능하게 하는 COM의 Application Binary Interface(ABI; 응용 프로그램바이너리 인터페이스) 측면에만 초점을 맞추고 있습니다.Nano-COM은 모든 C++ 컴파일러에 이식 가능한 단일 C++ 헤더 파일로 쉽게 표현할 수 있습니다.나노-COM은 기본 명령 아키텍처와 OS의 네이티브 ABI를 확장하여 유형화된 객체 참조를 지원합니다(일반적인 ABI는 원자 유형, 구조, 어레이 및 함수 호출 규칙에만 초점을 맞춥니다).Nano-COM의 기반은 Mozilla에 의해 Firefox(XPCOM으로 불림) 부트스트랩에 사용되었으며 현재는 DirectX/Direct3D/DirectML의 기반 ABI 기술로 사용되고 있습니다.

Nano-COM 헤더파일은 적어도 다음 3가지 유형을 정의 또는 명명합니다.

  • 인터페이스 유형을 식별하기 위한 GUID - 이는 사실상 128비트 수치입니다.
  • 메서드 호출로부터의 에러 코드를 식별하는 HRESULT - 이는 32비트 int를 기존 값(S_OK, E_FAIL, E_OUTOF MEMORY 등)에 대해 효과적으로 표준화한 것입니다.
  • IUn은 모든 유형의 객체 참조의 기본 유형으로 알려져 있습니다. 이는 효과적으로 지원하는 추상 가상 함수입니다.dynamic_cast<T>- 새로운 인터페이스 타입의 취득과 참조 카운팅 a lashared_ptr<T>

Nano-COM 의 많은 사용법에서는, 착신측이 할당한 메모리 버퍼에 대처하기 위한 2 개의 기능도 정의되고 있습니다.

  • <나노콤>[Alocate] : 메서드 구현에 의해 호출되어 발신자에게 반환되는 미가공 버퍼(개체가 아님)를 할당합니다.
  • <나노콤>[Free] : 메서드 발신자에 의해 호출되어 사용되지 않게 된 착신측 할당 버퍼를 해방합니다.

Direct3D등의 Nano-COM 의 실장에서는, 할당 기능을 회피해, 발신자가 할당한 버퍼만을 사용하도록 제한됩니다.

나노컴은 클래스, 아파트, 마셜링, 등록 등의 개념이 없다.오히려 객체 참조는 단순히 함수 경계를 넘어 표준 언어 구성(예: C++ 새 연산자)을 통해 할당됩니다.

보안.

COM 및 ActiveX 구성 요소는 샌드박스 없이 사용자 시스템에서 네이티브 코드로 실행됩니다.따라서 코드가 수행할 수 있는 작업에 대한 제한은 거의 없습니다.따라서 Internet Explorer를 사용하여 ActiveX 컴포넌트를 웹 페이지에 삽입하는 이전 방법은 말웨어 감염 문제를 야기했습니다.마이크로소프트는 1996년 찰스 피츠제럴드가 "우리는 ActiveX가 본질적으로 [9]안전하다고 주장하지 않았다"고 말했을 때 ActiveX의 문제를 인식했다.최신[when?] 버전의 Internet Explorer에서는 ActiveX 컨트롤을 설치하기 전에 사용자에게 프롬프트가 표시되므로 사용자가 신뢰하지 않는 사이트에서 컨트롤을 설치할 수 없습니다.ActiveX 컨트롤은 디지털서명으로 서명되어 신뢰성을 보증합니다.ActiveX 컨트롤을 모두 비활성화하거나 선택한 일부만 허용할 수도 있습니다.프로세스 외 COM 서버에 대한 투과적인 지원은 여전히 프로세스 격리 측면에서 소프트웨어 안전을 촉진합니다.이것은, 대규모 애플리케이션의 서브 시스템을 다른 프로세스로 분리하는 경우에 편리합니다.프로세스 분리는 엄격하게 정의된 인터페이스를 통해서만 통신하기 때문에 프로세스 내의 상태 파손이 다른 프로세스의 무결성에 부정적인 영향을 미치는 것을 제한합니다.따라서 유효한 상태를 회복하려면 영향을 받는 서브시스템만 재시작해야 합니다.이것은, 같은 프로세스내의 서브 시스템의 경우는 다릅니다.이 경우, 1개의 서브 시스템의 부정한 포인터가 다른 서브 시스템의 랜덤으로 파손될 가능성이 있습니다.

기술적 세부사항

COM 프로그래머는 COM 인식 컴포넌트를 사용하여 소프트웨어를 구축합니다.다양한 컴포넌트 유형은 Class ID(CLSID; 클래스 ID)로 식별됩니다.클래스 ID는 GUID(Global Unique Identifier)입니다.각 COM 컴포넌트는 1개 이상의 인터페이스를 통해 기능을 공개합니다.컴포넌트에서 지원되는 다양한 인터페이스는 Interface ID(IID; 인터페이스 ID)를 사용하여 서로 구별됩니다.이것도 GUID입니다.COM 인터페이스는 C, C++, Visual Basic, Delphi, Python[10][11] 및 Windows 플랫폼에 구현된 여러 스크립트 언어 등의 여러 언어로 바인딩을 합니다.컴포넌트에 대한 모든 액세스는 인터페이스 방식을 통해 이루어집니다.이를 통해 프로세스 간 또는 컴퓨터 간 프로그래밍(DCOM의 지원을 사용하는 후자)과 같은 기술을 사용할 수 있습니다.

인터페이스

모든 COM 컴포넌트는 IUnknown(커스텀) 인터페이스를 구현하고 있습니다.이 인터페이스를 통해 참조 카운트와 타입 변환(캐스팅) 방식이 공개됩니다.커스텀 IUnknown 인터페이스는 인터페이스에서 선언된 함수를 구현하는 함수에 대한 포인터 목록을 포함하는 가상 메서드테이블로의 포인터로 구성됩니다.따라서 처리 중인 호출 오버헤드는 C++의 가상 메서드 호출과 비슷합니다.커스텀 인터페이스와 더불어 COM은 IDispatch에서 상속되는 디스패치인터페이스도 지원합니다.디스패치 인터페이스는 OLE Automation의 레이트바인딩을 지원합니다.이를 통해 디스패치인터페이스는 커스텀인터페이스보다 폭넓은 프로그래밍 언어에서 네이티브로 액세스 할 수 있습니다.

반

COM 클래스("coclass")는 하나 이상의 인터페이스를 구체적으로 구현한 것으로 객체 지향 프로그래밍 언어의 클래스와 매우 유사합니다.클래스는 클래스 ID(CLSID) 또는 프로그램 식별자 문자열(ProgID)에 따라 생성됩니다.많은 객체 지향 언어와 마찬가지로 COM은 인터페이스를 구현에서 분리합니다.이 구별은 특히 오브젝트에 직접 액세스할 수 없고 인터페이스를 통해서만 액세스할 수 있는 COM에서 두드러집니다.또, COM 에서는, 같은 인터페이스의 복수의 실장을 서포트하고 있기 때문에, 클라이언트는 런타임시에, 인스턴스화할 인터페이스의 실장을 선택할 수 있습니다.

인터페이스 정의 언어 및 유형 라이브러리

형식 라이브러리에는 COM 유형을 나타내는 메타데이터가 포함되어 있습니다.이러한 타입은, Microsoft Interface Definition Language(MSIDL/IDL)를 사용해 설명합니다.IDL 파일은 객체 지향 클래스, 인터페이스, 구조, 열거 및 기타 사용자 정의 유형을 언어에 구애받지 않는 방식으로 정의합니다.IDL은 인터페이스나 클래스의 컬렉션을 정의하기 위한 「interface」나 「library」등의 키워드를 추가하는 C++ 선언과 외관이 비슷합니다.IDL은 선언 전에 괄호로 묶은 속성을 사용하여 인터페이스 GUID 및 포인터 파라미터와 길이 필드의 관계 등 추가 정보를 제공합니다.IDL 파일은 MIDL 컴파일러에 의해 컴파일 됩니다.C/C++의 경우 MIDL 컴파일러는 선언된 인터페이스의 vtbls와 일치하는 구조 정의를 포함하는 컴파일러에 의존하지 않는 헤더 파일과 인터페이스 GUID 선언을 포함하는 C 파일을 생성합니다.프록시 모듈의 C++ 소스 코드도 MIDL 컴파일러에 의해 생성할 수 있습니다.이 프록시에는 COM 콜을 리모트프로시저 콜로 변환하여 프로세스 외 통신에 DCOM을 유효하게 하기 위한 메서드스텁이 포함되어 있습니다.IDL 파일은 MIDL 컴파일러에 의해 타입 라이브러리(TLB)로 컴파일 할 수도 있습니다.TLB 파일에는 다른 언어 컴파일러 및 런타임 환경(VB, Delphi 등)에서 처리할 수 있는 바이너리 메타데이터가 포함되어 있습니다.NET 등). TLB에서 정의된 COM 유형을 나타내는 언어 고유의 구성을 생성합니다.C++ 의 경우는, TLB 가 IDL 표현으로 변환됩니다.

오브젝트 프레임워크

COM은 런타임 프레임워크이기 때문에 유형은 런타임에 개별적으로 식별 및 지정 가능해야 합니다.이를 위해 Global Unique Identifier(GUID; 글로벌 고유 식별자)가 사용됩니다.각 COM 타입은 실행 시 식별을 위해 자체 GUID로 지정됩니다.COM 타입의 정보는 컴파일 시간과 실행 시 모두 액세스 할 수 있도록 하기 위해 COM 타입 라이브러리를 사용합니다.COM이 오브젝트의 상호작용을 위한 동적 프레임워크로서의 기능을 달성하는 것은 타입 라이브러리의 효과적인 사용을 통해서이다.

IDL 의 coclass 정의의 예를 다음에 나타냅니다.

coclass SomeClass { [ default ]인터페이스 ISomeInterface ; } ;

위의 코드 fragment는 다음 이름의 COM 클래스를 선언합니다.SomeClass에서는, route 라고 하는 이름의 인터페이스가 실장됩니다.ISomeInterface.

이는 개념적으로 다음 C++ 클래스를 정의하는 것과 동일합니다.

학급 썸클래스 : 일반의 ISOME 인터페이스 {   ...   ... };

여기서 ISomeInterface는 C++ 순수 가상 클래스(추상 베이스 클래스라고도 불립니다)입니다.

COM 인터페이스 및 클래스를 포함하는 IDL 파일은 Type Library(TLB; 유형 라이브러리) 파일로 컴파일되며 나중에 런타임에 클라이언트가 이를 해석하여 개체가 지원하는 인터페이스를 결정하고 개체의 인터페이스 메서드를 호출할 수 있습니다.

C++에서는 COM 오브젝트는 COM 오브젝트에 의해 인스턴스화 됩니다.CoCreateInstanceClass ID(CLSID; 클래스 ID) 및 Interface ID(IID; 인터페이스 ID)를 인수로 사용하는 함수.의 인스턴스화SomeClass는 다음과 같이 실장할 수 있습니다.

ISOME 인터페이스* 인터페이스_ptr = 특수한 순서; 결과 시간 = CoCreateInstance(CLSID_Some Class, 특수한 순서, CLSCTX_ALL,                               IID_ISOME 인터페이스, (무효**)&인터페이스_ptr);

이 예에서는 COM 서브시스템을 사용하여 구현된 객체에 대한 포인터를 가져옵니다.ISomeInterfacecoclass CLSID_SomeClass의 특정 인터페이스 구현이 필요합니다.

참조 카운트

모든 COM 개체는 참조 카운트를 사용하여 개체의 수명을 관리합니다.참조 카운트는 모든 COM 오브젝트가 실장하는 필수 IUnknown 인터페이스의 AddRef 및 Release 메서드를 통해 클라이언트에 의해 제어됩니다.COM 오브젝트는 참조 카운트가 0으로 떨어지면 자신의 메모리를 해방합니다.특정 언어(예: Visual Basic)는 COM 객체 개발자가 소스 코드에 내부 참조 카운터를 명시적으로 유지할 필요가 없도록 자동 참조 카운트를 제공합니다.C++ 에서는, 코더는 명시적인 참조 카운트를 실행하거나, 스마트 포인터를 사용해 참조 카운트를 자동적으로 관리할 수 있습니다.

다음으로 COM 오브젝트에서 AddRef 및 Release를 호출하는 타이밍에 관한 가이드라인을 나타냅니다.

  • 인터페이스 참조를 반환하는 함수 및 메서드(return value 또는 "out" 파라미터를 통해)는 반환되기 전에 반환된 객체의 참조 카운트를 증가시켜야 합니다.
  • 포인터를 덮어쓰거나 범위를 벗어나기 전에 인터페이스 포인터로 릴리스를 호출해야 합니다.
  • 인터페이스 참조 포인터로 복사가 이루어지는 경우 해당 포인터로 AddRef를 호출해야 합니다.
  • 오브젝트는 참조되고 있는 인터페이스에만 내부 리소스를 할당하기 위해 인터페이스 단위의 참조 카운트를 구현할 수 있으므로 참조되고 있는 특정 인터페이스에서 AddRef 및 Release를 호출해야 합니다.

모든 참조 카운트콜이 회선을 통해 리모트오브젝트로 송신되는 것은 아닙니다.프록시는 리모트오브젝트에 참조를 1개만 유지하고 자체 로컬 참조 카운트를 유지합니다.COM 개발을 간소화하기 위해 Microsoft는 C++ 개발자를 위한 ATL(Active Template Library)을 도입했습니다.ATL은 보다 높은 수준의 COM 개발 패러다임을 제공합니다.또한 스마트 포인터 객체를 제공함으로써 COM 클라이언트 애플리케이션 개발자가 참조 카운트를 직접 유지할 필요가 없도록 보호합니다.COM 인식 라이브러리 및 언어에는 Microsoft Foundation Class, VC 컴파일러 COM 지원,[12] VBScript, Visual Basic, ECMAScript(JavaScript), Borland Delphi 등이 있습니다.

프로그래밍

COM은 언어에 구애받지 않는 바이너리 표준으로 바이너리 정의 데이터 타입과 인터페이스를 이해하고 구현할 수 있는 모든 프로그래밍 언어로 개발 가능합니다.COM 실장은 COM 환경의 입출금, COM 오브젝트의 인스턴스화와 참조 카운트, 지원되는 인터페이스의 오브젝트 쿼리 및 오류 처리를 담당합니다.Microsoft Visual C++ 컴파일러는 C++ [13]Attributes라고 불리는 C++ 언어에 대한 확장을 지원합니다.이러한 확장 기능은 COM 개발을 단순화하고 C++[14]에서 COM 서버를 구현하기 위해 필요한 보일러 플레이트 코드를 대부분 삭제하도록 설계되었습니다.

레지스트리 사용 현황

Windows 에서는, COM 클래스, 인터페이스, 및 타입 라이브러리는, 레지스트리의 GUID 마다, 클래스의 경우는 HKEY_CLASSES_ROOT\CLSID, 인터페이스의 경우는 HKEY_CLASSES_ROOT\Interface 에 표시됩니다.COM 라이브러리는 레지스트리를 사용하여 각 COM 오브젝트의 올바른 로컬라이브러리 또는 리모트서비스의 네트워크 위치를 찾습니다.

등록이 필요 없는 COM

Registration-Free COM(RegFree COM)은 Windows XP에서 도입된 테크놀로지입니다.COM(컴포넌트 오브젝트 모델) 컴포넌트에서는 액티베이션메타데이터와 CLSID를 저장할 수 있습니다.Class ID)를 참조해 주세요.대신 컴포넌트에 구현된 클래스의 메타데이터 및 CLSID는 어셈블리 매니페스트(XML을 사용하여 설명됨)에 선언되며 실행 파일의 리소스로 저장되거나 [15]컴포넌트와 함께 설치된 별도의 파일로 저장됩니다.이를 통해 동일한 컴포넌트의 여러 버전을 XCOPY [16]배치뿐만 아니라 자체 매니페스트에서 설명하는 서로 다른 디렉토리에 설치할 수 있습니다.이 기술은 EXE COM[17] 서버 지원이 제한되어 MDAC, MSXML, DirectX, Internet Explorer 등의 시스템 전체 컴포넌트에는 사용할 수 없습니다.

응용 프로그램을 로드하는 동안 윈도우즈 로더는 [18]매니페스트를 검색합니다.존재하는 경우 로더는 이 정보를 액티베이션콘텍스트에 [16]추가합니다.COM 클래스 팩토리가 클래스를 인스턴스화하려고 하면 먼저 액티베이션콘텍스트가 체크되어 CLSID의 실장이 검출되는지 여부를 확인합니다.조회가 실패한 경우에만 레지스트리가 검사됩니다.[16]

COM 오브젝트의 수동 인스턴스화

DLL 파일의 경로와 개체의 GUID를 지정하면 COM 개체를 수동으로 만들 수도 있습니다.이를 위해 DLL 또는 GUID를 시스템 레지스트리에 등록할 필요가 없으며 매니페스트 파일을 사용하지 않습니다.COM DLL은 DllGetClassObject라는 이름의 함수를 내보냅니다.원하는 GUID 및 IID_를 사용하여 DllGetClassObject 호출IClassFactory는 팩토리 객체의 인스턴스를 제공합니다.Factory 개체에는 CreateInstance 메서드가 있습니다.이 메서드는 인터페이스 [19]GUID가 지정된 개체의 인스턴스를 만들 수 있습니다.이는 등록된 COM [20]컴포넌트의 인스턴스를 작성할 때 내부적으로 사용되는 프로세스와 동일합니다.

작성된 COM 오브젝트가 범용 CoCreateInstance API를 사용하여 다른 COM 오브젝트를 인스턴스화할 경우 레지스트리 또는 매니페스트 파일을 사용하여 일반적인 방법으로 COM 오브젝트를 인스턴스화하려고 합니다.그러나 내부 객체(전혀 등록되지 않을 수도 있음)를 생성하여 자신의 개인 지식을 사용하여 인터페이스에 대한 참조를 배포할 수 있습니다.

프로세스와 네트워크의 투과성

COM 오브젝트는, 같은 프로세스내(프로세스중), 프로세스 경계내(프로세스외), 또는 네트워크(DCOM)를 개입시켜 투과적으로 인스턴스화 및 참조할 수 있습니다.프로세스외 오브젝트 및 리모트오브젝트는 마샬링을 사용하여 메서드콜을 시리얼화하고 프로세스 또는 네트워크 경계를 통해 값을 반환합니다.이 마샬링은 클라이언트에 의해 보이지 않습니다.클라이언트는 이 오브젝트에 로컬 처리 중인 오브젝트인 것처럼 접근합니다.

스레드화

COM에서는 스레드화는 [21]아파트로 알려진 개념을 통해 처리됩니다.개별 COM 오브젝트는 정확히 1개의 아파트에 살고 있습니다.단일 스레드 또는 멀티 스레드 중 하나입니다.COM에는 싱글 스레드 아파트(STA), 멀티 스레드 아파트(MTA), 스레드 뉴트럴 아파트(NA)의 세 가지 유형의 아파트가 있습니다.각 아파트는 객체의 내부 상태를 여러 스레드에 걸쳐 동기화할 수 있는 하나의 메커니즘을 나타냅니다.프로세스는 여러 COM 오브젝트로 구성될 수 있으며, 그 중 일부는 STA를 사용하고 나머지는 MTA를 사용할 수 있습니다.COM 오브젝트에 액세스하는 모든 스레드는 마찬가지로 하나의 아파트에 거주합니다.COM 오브젝트 및 스레드의 아파트 선택은 런타임에 결정되며 변경할 수 없습니다.

아파트 타입 묘사
싱글 스레드 아파트[22](STA), (스레딩 모델=아파트) 단일 스레드는 객체의 메서드를 실행하기 위한 전용 스레드입니다.이와 같이 아파트 외부의 스레드로부터의 메서드 콜은 시스템에 의해 (표준 윈도 메시지 큐를 통해) 마샬링되고 자동으로 큐잉됩니다.따라서 COM 런타임에는 자동 동기화가 제공되므로 객체의 각 메서드콜이 항상 완료되기 전에 실행됩니다.따라서 개발자는 나사산 잠금이나 레이스 조건에 대해 걱정할 필요가 없습니다.
멀티 스레드 아파트[23](MTA), (스레딩 모델=무료) COM 런타임은 동기화를 제공하지 않으며 여러 스레드가 COM 개체를 동시에 호출할 수 있습니다.따라서 COM 오브젝트는 여러 스레드로부터의 동시 액세스가 레이스 상태를 발생시키지 않도록 자체 동기화를 수행해야 합니다.STA 스레드에서 MTA 오브젝트에 대한 콜도 마샬링됩니다.
동적으로 결정되는 아파트(슬레딩 모델=양쪽 모두 Both aparty 모드에서는 서버는 오브젝트 작성 시 STA 또는 MTA를 자동으로 선택하여 호출 [24]스레드의 아파트유형에 일치시킵니다.이는 MTA 서버가 STA 스레드에 의해 액세스될 때 오버헤드를 마샬링하지 않도록 하는 데 도움이 됩니다.
스레드 뉴트럴 아파트(NA), (스레딩 모델=중립) 쓰레드도 없는 특별한 아파트.STA 또는 MTA 스레드가 같은 프로세스에서 NA 오브젝트를 호출하면 발신측 스레드는 일시적으로 아파트를 떠나 스레드 [25]전환 없이 NA에서 직접 코드를 실행합니다.따라서 NA는 효율적인 부문간 메서드콜을 위한 최적화라고 생각할 수 있습니다.

같은 아파트에 속하는 스레드와 오브젝트는 같은 스레드액세스 규칙을 따릅니다.따라서 같은 아파트 내에서 이루어지는 메서드콜은 COM의 도움 없이 직접 실행됩니다.아파트 전체의 메서드 콜은 마샬링을 통해 이루어집니다.이를 위해서는 프록시 및 스터브를 사용해야 합니다.

비판

COM의 실장은 매우 복잡하기 때문에 프로그래머는 몇 가지 '플럼핑' 문제로 주의가 분산될 수 있습니다.

메시지 펌핑

STA가 초기화되면 숨겨진 창이 생성됩니다.이 창은 구획 간 및 프로세스 간 메시지라우팅에 사용됩니다.이 창은 메시지 큐를 정기적으로 "펌프"해야 합니다.이 구조를 "메시지 펌프"라고 합니다.이전 버전의 Windows에서는 그렇지 않으면 시스템 전체의 교착 상태가 발생할 수 있습니다.이 문제는 구현의 일부로 COM을 초기화하는 일부 Windows API에 의해 복잡해지고 구현 세부 정보가 "누출"됩니다.

참조 카운트

COM 내의 참조 카운트에 의해서, 복수의 오브젝트가 순환적으로 참조되고 있는 경우, 문제가 발생할 가능성이 있습니다.오브젝트가 고립되지 않도록 애플리케이션 설계에서는 이 점을 고려해야 합니다.COM "이벤트 싱크" 모델이 사용되는 경우 객체에 활성 기준 카운트가 남아 있을 수도 있습니다.이벤트를 실행하는 개체는 이벤트에 반응하는 개체에 대한 참조가 필요하므로, 이벤트에 반응하는 개체에 대한 참조 수는 0에 도달하지 않습니다.참조 사이클은 일반적으로 아웃 오브 밴드 종료 또는 분할 ID 중 하나를 사용하여 끊어집니다.대역외 종단 기술에서 객체는 호출되었을 때 강제로 다른 객체에 대한 참조를 드롭하여 사이클을 중단하는 메서드를 노출합니다.스플릿 아이덴티티 기술에서는 1개의 구현으로2개의 개별 COM 오브젝트(아이덴티티라고도 불립니다)가 공개됩니다.이로 인해 COM 개체 간에 약한 참조가 생성되어 참조 사이클이 방지됩니다.

DLL 헬

처리 중인 COM 컴포넌트는 DLL 파일에 구현되며 등록 시 CLSID당 단일 버전만 허용되므로 상황에 따라서는 "DLL Hell" 효과가 발생할 수 있습니다.등록이 필요 없는 COM 기능을 사용하면 프로세스 내 컴포넌트에서 이 문제가 해소됩니다.등록이 필요 없는 COM은 프로세스 외 서버에서는 사용할 수 없습니다.

「 」를 참조해 주세요.

메모들

  1. ^ "Documentation Archive". developer.apple.com.
  2. ^ "Plug-ins and Microsoft's COM". Apple Inc. Retrieved October 5, 2010.
  3. ^ Microsoft 포럼: Visual C++ 버전 간의 바이너리 호환성
  4. ^ "About Network DDE - Windows applications". Microsoft.com. May 30, 2018.
  5. ^ "Code Execution Technique Takes Advantage of Dynamic Data Exchange". McAfee.com. October 27, 2017.
  6. ^ Brown, Nina; Kindel, Charlie (March 11, 1998). "draft-brown-dcom-v1-spec-03 - Distributed Component Object Model Protocol -- DCOM/1.0". datatracker.ietf.org. Retrieved August 29, 2019.
  7. ^ rpetrusha. "Runtime Callable Wrapper". msdn.microsoft.com.
  8. ^ rpetrusha. "COM Callable Wrapper". msdn.microsoft.com.
  9. ^ Steinberg, Jill (March 1, 1997). "Competing components make for prickly panelists". JavaWorld. Retrieved 2020-07-16.
  10. ^ "win32com Documentation Index". docs.activestate.com.
  11. ^ "Python and COM". www.boddie.org.uk.
  12. ^ "Compiler COM Support". MSDN. Microsoft.
  13. ^ Microsoft MSDN: C++ 속성 레퍼런스
  14. ^ MSDN 매거진:C++ 속성: Visual Studio의 새로운 기능으로 COM 프로그래밍을 쉽게 할 수 있습니다.네트워크
  15. ^ "Assembly Manifests". MSDN. Retrieved November 5, 2009.
  16. ^ a b c Dave Templin. "Simplify App Deployment with ClickOnce and Registration-Free COM". MSDN Magazine. Retrieved April 22, 2008.
  17. ^ "How to use an out-of-process COM server without its tlb file". Retrieved April 16, 2011.
  18. ^ "Concepts of Isolated Applications and Side-by-side Assemblies". MSDN. Retrieved February 5, 2016.
  19. ^ Arkhipov, Mikhail (April 1, 2005). "Registration-free COM". MSDN Blogs. Retrieved April 29, 2016.
  20. ^ "DllGetClassObject entry point (COM)". MSDN. If a call to the CoGetClassObject function finds the class object that is to be loaded in a DLL, CoGetClassObject uses the DLL's exported DllGetClassObject function.
  21. ^ Microsoft MSDN: 프로세스, 스레드 및 아파트
  22. ^ Microsoft MSDN: 싱글 스레드 아파트
  23. ^ Microsoft MSDN: 멀티스레드 아파트
  24. ^ Microsoft MSDN: COM 스레드화 모델의 이해와 사용
  25. ^ Codeguru: COM 아파트에 대해서

레퍼런스

외부 링크