Объектная модель компонента

С

Объектная модель компонента
Сокращение	С
Положение дел	Действующий
Впервые опубликовано	1993 год ( 1993 )
Последняя версия	Уровень жизни 2021
Организация	Майкрософт
Ряд	Системные службы
Базовые стандарты	МИДЛ , UUID
Сопутствующие стандарты	заменено: ДДЕ на основе COM: OLE , OLE Automation , вспомогательный объект браузера , ActiveX , COM+ , DCOM , оболочка Windows , DirectX , UMDF , среда выполнения Windows .
Домен	Интерфейс компонентов
Веб-сайт	учиться .microsoft .с /en-нас /окна /win32 /с /модель-компонента-объекта

Модель компонентных объектов ( COM ) — это стандарт двоичного интерфейса для программных компонентов , представленный Microsoft в 1993 году. Он используется для межпроцессного взаимодействия (IPC) создания объектов в большом количестве языков программирования . COM является основой для нескольких других технологий и платформ Microsoft, включая OLE , OLE Automation , Browser Helper Object , ActiveX , COM+ , DCOM , оболочку Windows , DirectX , UMDF и среду выполнения Windows .

Суть COM — это нейтральный к языку способ реализации объектов, которые можно использовать в средах, отличных от той, в которой они были созданы, даже за пределами машинных границ. Для хорошо написанных компонентов COM позволяет повторно использовать объекты без знания их внутренней реализации, поскольку заставляет разработчиков компонентов предоставлять четко определенные интерфейсы , отделенные от реализации. Различная семантика распределения в языках учитывается путем возложения объектов на объекты, ответственные за их собственное создание и уничтожение посредством подсчета ссылок . Приведение типов между различными интерфейсами объекта достигается за счет QueryInterfaceметод. Предпочтительным методом « наследования » в COM является создание подобъектов, которым делегируются «вызовы» методов.

COM — это интерфейсная технология, определенная и реализованная в качестве стандарта только в Microsoft Windows и Apple Core Foundation 1.3 и более поздних версиях подключаемого интерфейса прикладного программирования (API). Последний реализует лишь часть всего COM-интерфейса. Для некоторых приложений COM был заменен, по крайней мере в некоторой степени, платформой Microsoft .NET и поддержкой веб-служб через Windows Communication Foundation (WCF). Однако COM-объекты можно использовать со всеми языками .NET через .NET COM Interop . Сетевой DCOM использует собственные двоичные форматы , а WCF поощряет использование XML на основе сообщений SOAP . COM очень похож на другие компонентного программного обеспечения технологии интерфейсов , такие как CORBA и Enterprise JavaBeans , хотя каждая из них имеет свои сильные и слабые стороны. В отличие от C++, COM предоставляет стабильный двоичный интерфейс приложения (ABI), который не меняется между выпусками компилятора. Это делает COM-интерфейсы привлекательными для объектно-ориентированных библиотек C++, которые будут использоваться клиентами, скомпилированными с использованием разных версий компилятора.

История

Одним из первых методов межпроцессного взаимодействия в Windows был динамический обмен данными (DDE). впервые представлен в 1987 году, это позволяло отправлять и получать сообщения в так называемых «разговорах» между приложениями. Энтони Уильямс , принимавший участие в создании архитектуры COM, позже распространил в Microsoft два внутренних документа, в которых рассматривалась концепция программных компонентов: « Объектная архитектура: работа с неизвестным (или) типобезопасностью в динамически расширяемой библиотеке классов в 1988 году» и О наследовании: что это значит и как его использовать в 1990 году. Они легли в основу многих идей, лежащих в основе COM. Связывание и внедрение объектов (OLE), первая объектная платформа Microsoft, была построена на основе DDE и разработана специально для составных документов . Он был представлен в Word для Windows и Excel в 1991 году, а позже был включен в Windows, начиная с версии 3.1 в 1992 году. Примером составного документа является электронная таблица , встроенная в документ Word для Windows: по мере внесения изменений в электронную таблицу в Excel они автоматически появляются внутри документа Word.

В 1991 году Microsoft представила расширения Visual Basic (VBX) вместе с Visual Basic 1.0. VBX — это упакованное расширение в виде библиотеки динамической компоновки (DLL), которое позволяет графически размещать объекты в форме и управлять ими с помощью свойств и методов . Позже они были адаптированы для использования другими языками, такими как Visual C++ . В 1992 году, когда была выпущена версия Windows 3.1 , Microsoft выпустила OLE 2 с базовой объектной моделью . COM Двоичный интерфейс -приложения (ABI) был таким же, как MAPI ABI (выпущенный в 1992 году), и, похоже, он был основан на MSRPC и, в конечном итоге, на Open Group DCE/RPC . В то время как OLE 1 был ориентирован на составные документы, COM и OLE 2 были разработаны для работы с программными компонентами в целом. Текстовые разговоры и сообщения Windows оказались недостаточно гибкими, чтобы обеспечить надежный и расширяемый обмен функциями приложения, поэтому COM был создан в качестве новой основы, а OLE заменен на OLE2. В 1994 году были представлены пользовательские элементы управления OLE (OCX) в качестве преемника элементов управления VBX. В то же время Microsoft заявила, что OLE 2 будет называться просто «OLE» и что OLE больше не является аббревиатурой, а является названием для всех компонентных технологий компании. В начале 1996 года Microsoft нашла новое применение для пользовательских элементов управления OLE, расширив возможности своего веб-браузера по представлению контента и переименовав некоторые части OLE, относящиеся к Интернет « ActiveX », и постепенно все технологии OLE были переименованы в ActiveX, за исключением технологии составных документов, которая использовалась в Microsoft Office . Позже в том же году Microsoft расширила COM для работы по сети с помощью DCOM .

Сопутствующие технологии

COM был основной платформой разработки программного обеспечения для Windows и, как таковой, повлиял на развитие ряда вспомогательных технологий. На него также сильно повлияли более ранние технологии.

ДДЕ

COM заменил DDE в качестве предпочтительной формы межпроцессного взаимодействия.

DCE/RPC и MSRPC

В качестве межъязыковой модели компонентов COM полагается на язык определения интерфейса (IDL) для описания объектов и связанных с ними функций. IDL COM в значительной степени основан на многофункциональном IDL DCE/RPC с объектно-ориентированными расширениями. Собственная реализация DCE/RPC от Microsoft, известная как MSRPC, широко используется в качестве основного механизма межпроцессного взаимодействия для служб и внутренних компонентов Windows NT, что делает ее очевидным выбором в качестве основы.

ДКОМ

Основная статья: Объектная модель распределенных компонентов

DCOM ( Distributed COM ) расширил возможности COM от простой поддержки одного пользователя с отдельными приложениями, взаимодействующими на рабочем столе Windows, до активации объектов, работающих в разных контекстах безопасности и на разных машинах в сети. При этом были добавлены необходимые функции для настройки того, какие пользователи имеют право создавать, активировать и вызывать объекты, для идентификации вызывающего пользователя, а также указания необходимого шифрования для безопасности вызовов.

COM+

Чтобы Microsoft могла предоставить разработчикам поддержку распределенных транзакций , объединения ресурсов, автономных приложений, публикации событий и подписки, лучшего управления памятью и процессором (потоками), а также позиционировать Windows как альтернативу другим операционным системам корпоративного уровня, Microsoft представила технологию под названием Microsoft Transaction Server (MTS) в Windows NT 4. В Windows 2000 это значительное расширение COM было включено в операционную систему (в отличие от серии внешних инструментов, предоставляемых MTS ) и переименовано в COM+ . В то же время Microsoft уменьшила значение DCOM как отдельного объекта. Компоненты, использующие службы COM+, обрабатывались более непосредственно добавленным уровнем COM+, в частности, за счет поддержки перехвата операционной системой. В первом выпуске МТС был добавлен перехват - установка компонента МТС модифицировала реестр Windows для вызова программного обеспечения МТС, а не непосредственно компонента. В Windows 2000 также было изменено приложение панели управления службами компонентов, используемое для настройки компонентов COM+.

Преимущество COM+ заключалось в том, что его можно было запускать в «фермах компонентов». Экземпляры компонента, если они закодированы правильно, могут быть объединены в пул и повторно использованы новыми вызовами его процедуры инициализации без выгрузки его из памяти. Компоненты также могут быть распределены (вызваны с другой машины). COM+ и Microsoft Visual Studio предоставили инструменты, упрощающие создание прокси на стороне клиента, поэтому, хотя для удаленного вызова использовался DCOM, разработчикам было легко это сделать. COM+ также представил механизм событий подписчика/издателя под названием COM+ Events и предоставил новый способ использования MSMQ (технологии, обеспечивающей асинхронный обмен сообщениями между приложениями) с компонентами под названием Queued Components . События COM+ расширяют модель программирования COM+ для поддержки событий позднего связывания (см. Позднее связывание ) или вызовов методов между издателем или подписчиком и системой событий.

.NET

Основная статья: .NET Framework

Microsoft .NET предоставляет средства как для обеспечения технологии компонентов, так и для взаимодействия с COM+ (через сборки COM-взаимодействия); .NET предоставляет оболочки для большинства часто используемых элементов управления COM. Microsoft .NET скрывает большую часть деталей при создании компонентов и, следовательно, упрощает разработку. .NET может использовать COM+ через пространство имен System.EnterpriseServices, а некоторые службы, предоставляемые COM+, были продублированы в последних выпусках .NET. Например, пространство имен System.Transactions в .NET предоставляет класс TransactionScope, который обеспечивает управление транзакциями без использования COM+. Аналогично, компоненты в очереди могут быть заменены Windows Communication Foundation транспортом MSMQ . (Однако MSMQ является собственным компонентом COM.) Поддержка обратной совместимости ограничена. COM-объект можно использовать в .NET путем реализации вызываемой оболочки среды выполнения (RCW). NET-объекты, соответствующие определенным ограничениям интерфейса, можно использовать в COM-объектах путем вызова вызываемой оболочки COM (CCW). Как со стороны COM, так и со стороны .NET объекты, использующие другую технологию, отображаются как собственные объекты. См. COM-взаимодействие .

WCF (Windows Communication Foundation) упрощает ряд проблем удаленного выполнения COM. Например, это упрощает прозрачную маршализацию объектов по значениям между границами процесса или машины.

Среда выполнения Windows

Основная статья: Среда выполнения Windows

Модель программирования и приложений Microsoft Windows Runtime (или WinRT, не путать с Windows RT ) по существу представляет собой API на основе COM, хотя и опирается на расширенный COM. Благодаря своей основе, подобной COM, среда выполнения Windows обеспечивает относительно простой интерфейс с несколькими языками, как и COM, но по сути это неуправляемый собственный API. Однако определения API хранятся в файлах «.winmd», которые закодированы в формате метаданных ECMA 335, том же формате метаданных CLI , который использует .NET, с некоторыми изменениями. Этот общий формат метаданных позволяет значительно снизить накладные расходы, чем P/Invoke, когда WinRT вызывается из приложений .NET, а его синтаксис намного проще.

Nano-COM (он же XPCOM)

Основная статья: XPCOM

Nano-COM — это чрезвычайно небольшое подмножество компонентной объектной модели, ориентированное исключительно на двоичным интерфейсом приложения аспекты COM, связанные с (ABI), которые позволяют вызывать функции и методы в независимо скомпилированных модулях/компонентах. Nano-COM можно легко выразить в одном заголовочном файле C++, который можно переносить на все компиляторы C++. Nano-COM расширяет собственный ABI базовой архитектуры команд и ОС, добавляя поддержку ссылок на типизированные объекты (типичные ABI ориентированы только на атомарные типы, структуры, массивы и соглашения о вызове функций). Основа Nano-COM использовалась Mozilla для загрузки Firefox (называемого XPCOM ), и в настоящее время используется в качестве базовой технологии ABI для DirectX / Direct3D / DirectML .

Заголовочный файл Nano-COM определяет или называет как минимум три типа:

• GUID для идентификации типов интерфейсов — фактически это 128-битное число;
• HRESULT для идентификации кодов ошибок из вызовов методов — это фактически стандартизированное использование 32-битных целых чисел для хорошо известных значений (S_OK, E_FAIL, E_OUTOFMEMORY и т. д.);
• IUnknown как базовый тип для всех ссылок на типизированные объекты — это фактически абстрактные виртуальные функции для поддержки. dynamic_cast<T>-стиль приобретения новых типов интерфейса и подсчета ссылок а-ля shared_ptr<T>.

Многие варианты использования Nano-COM также определяют две функции для обращения к буферам памяти, выделенным вызываемому абоненту, в качестве результатов.

• <NanoCom>Alloc — вызывается реализациями метода для выделения необработанных буферов (не объектов), которые возвращаются вызывающему объекту.
• <NanoCom>Free – вызывается вызывающими методами для освобождения буферов, выделенных вызываемым объектом, когда они больше не используются.

Некоторые реализации Nano-COM, такие как Direct3D, избегают функций распределителя и ограничиваются использованием только буферов, выделяемых вызывающей стороной.

В Nano-COM нет понятия классов, квартир, маршалинга, регистрации и т. д. Вместо этого ссылки на объекты просто передаются через границы функций и выделяются с помощью стандартных языковых конструкций (например, оператора new C++).

Безопасность

Компоненты COM и ActiveX запускаются как собственный код на компьютере пользователя, без изолированной программной среды . Поэтому существует мало ограничений на то, что может делать код. Таким образом , предыдущая практика встраивания компонентов ActiveX в веб-страницы с помощью Internet Explorer приводила к проблемам с заражением вредоносным ПО . Microsoft осознала проблему ActiveX еще в 1996 году, когда Чарльз Фицджеральд сказал: «Мы никогда не заявляли заранее, что ActiveX по своей природе безопасен». Недавний версии Internet Explorer запрашивают у пользователя перед установкой элементов управления ActiveX, что позволяет пользователю запретить установку элементов управления с сайтов, которым пользователь не доверяет. Элементы управления ActiveX подписываются цифровыми подписями , гарантирующими их подлинность. Также можно полностью отключить элементы управления ActiveX или разрешить только некоторые из них. Прозрачная поддержка внепроцессных COM-серверов по-прежнему способствует безопасности программного обеспечения с точки зрения изоляции процессов . Это может быть полезно для разделения подсистем большого приложения на отдельные процессы. Изоляция процессов не позволяет повреждению состояния в одном процессе негативно повлиять на целостность других процессов, поскольку они взаимодействуют только через строго определенные интерфейсы. Таким образом, для восстановления допустимого состояния необходимо перезапустить только затронутую подсистему. Это не относится к подсистемам одного и того же процесса, где несанкционированный указатель в одной подсистеме может случайно повредить другие подсистемы.

Технические подробности

, поддерживающие COM Программисты COM создают свое программное обеспечение, используя компоненты . Различные типы компонентов идентифицируются идентификаторами классов (CLSID), которые являются глобальными уникальными идентификаторами (GUID). Каждый COM-компонент реализует свою функциональность через один или несколько интерфейсов . Различные интерфейсы, поддерживаемые компонентом, отличаются друг от друга с помощью идентификаторов интерфейсов (IID), которые также являются GUID. COM-интерфейсы имеют привязки на нескольких языках, таких как C , C++ , Visual Basic , Delphi , Python. и несколько языков сценариев, реализованных на платформе Windows. Весь доступ к компонентам осуществляется через методы интерфейсов. Это позволяет использовать такие методы, как межпроцессное или даже межкомпьютерное программирование (последнее использует поддержку DCOM).

Интерфейсы

Все компоненты COM реализуют интерфейс IUnknown ( custom ), который предоставляет методы для подсчета ссылок и преобразования типов (приведения). интерфейс Пользовательский IUnknown состоит из указателя на таблицу виртуальных методов , содержащую список указателей на функции, реализующие функции, объявленные в интерфейсе, в том же порядке, в котором они объявлены в интерфейсе. Таким образом, накладные расходы на внутрипроцессный вызов сравнимы с вызовами виртуальных методов в C++ . Помимо пользовательских интерфейсов, COM также поддерживает интерфейсы диспетчеризации , унаследованные от IDispatch . Интерфейсы диспетчеризации поддерживают позднее связывание для OLE-автоматизации . Это позволяет обеспечить естественный доступ к диспетчерским интерфейсам из более широкого диапазона языков программирования, чем к пользовательским интерфейсам.

Классы

Класс COM («кокласс») представляет собой конкретную реализацию одного или нескольких интерфейсов и очень похож на классы объектно-ориентированных языков программирования. Классы создаются на основе их идентификатора класса ( CLSID ) или на основе их строки программного идентификатора ( ProgID ). Как и многие объектно-ориентированные языки, COM обеспечивает отделение интерфейса от реализации. Это различие особенно сильно проявляется в COM, где к объектам нельзя получить прямой доступ, а только через их интерфейсы. COM также поддерживает несколько реализаций одного и того же интерфейса, так что клиенты во время выполнения могут выбирать, какую реализацию интерфейса создавать.

определения интерфейса и

Библиотеки типов содержат метаданные для представления типов COM. Эти типы описываются с использованием языка определения интерфейса Microsoft (MSIDL/IDL). Файлы IDL определяют объектно-ориентированные классы, интерфейсы, структуры, перечисления и другие определяемые пользователем типы независимым от языка способом. IDL внешне похож на объявления C++ с некоторыми дополнительными ключевыми словами, такими как «интерфейс» и «библиотека», для определения интерфейсов и коллекций классов. IDL также поддерживает использование атрибутов в скобках перед объявлениями для предоставления дополнительной информации, такой как GUID интерфейса и связи между параметрами указателя и полями длины. Файлы IDL компилируются компилятором MIDL . Для C/C++ компилятор MIDL генерирует независимый от компилятора заголовочный файл, содержащий определения структур, соответствующие vtbls объявленных интерфейсов, и файл C, содержащий объявления GUID интерфейсов . Исходный код C++ для прокси-модуля также может быть сгенерирован компилятором MIDL. Этот прокси-сервер содержит заглушки методов для преобразования вызовов COM в удаленные вызовы процедур, позволяющие использовать DCOM для связи вне процесса. Файлы IDL также могут быть скомпилированы компилятором MIDL в библиотеку типов (TLB). Файлы TLB содержат двоичные метаданные, которые могут обрабатываться различными языковыми компиляторами и средами выполнения (например, VB, Delphi, .NET и т. д.) для создания специфичных для языка конструкций для представления типов COM, определенных в TLB. Для C++ это приведет к преобразованию TLB обратно в его представление IDL.

Структура объекта

Поскольку COM — это среда выполнения, типы должны быть индивидуально идентифицируемыми и определяемыми во время выполнения. Для этого глобальные уникальные идентификаторы используются (GUID). Каждому типу COM назначается собственный GUID для идентификации во время выполнения. Чтобы информация о типах COM была доступна как во время компиляции, так и во время выполнения, COM использует библиотеки типов. Именно благодаря эффективному использованию библиотек типов COM достигает своих возможностей в качестве динамической среды для взаимодействия объектов.

Рассмотрим следующий пример определения coclass в IDL:

кокласс   SomeClass   { 
    [по умолчанию]   интерфейс   ISomeInterface; 
  }; 
 

Приведенный выше фрагмент кода объявляет COM-класс с именем SomeClass который реализует интерфейс с именем ISomeInterface.

Это концептуально эквивалентно определению следующего класса C++:

класс   SomeClass   :   public   ISomeInterface   { 
   ... 
   ... 
 }; 

C++ где ISomeInterface — это чистый виртуальный класс (иногда называемый абстрактным базовым классом).

Файлы IDL, содержащие интерфейсы и классы COM, компилируются в файлы библиотек типов (TLB), которые позже могут анализироваться клиентами во время выполнения, чтобы определить, какие интерфейсы поддерживает объект, и вызывать методы интерфейса объекта.

В C++ экземпляры COM-объектов создаются с помощью CoCreateInstanceфункция, которая принимает идентификатор класса (CLSID) и идентификатор интерфейса (IID) в качестве аргументов. Создание экземпляра SomeClass можно реализовать следующим образом:

ISomeInterface  *   интерфейс_ptr   =   NULL  ; 
  HRESULT   hr   =   CoCreateInstance  (  CLSID_SomeClass  ,   NULL  ,   CLSCTX_ALL  , 
                               IID_ISomeInterface  ,   (  void  **  )  &  interface_ptr  ); 

В этом примере подсистема COM используется для получения указателя на объект, реализующий ISomeInterface интерфейс, и требуется конкретная реализация этого интерфейса сокласса CLSID_SomeClass.

Подсчет ссылок

Все COM-объекты используют подсчет ссылок для управления временем жизни объектов. Счетчики ссылок контролируются клиентами с помощью методов AddRef и Release в обязательном интерфейсе IUnknown, который реализуют все COM-объекты. COM-объекты затем отвечают за освобождение своей памяти, когда счетчик ссылок падает до нуля. Некоторые языки (например, Visual Basic ) обеспечивают автоматический подсчет ссылок, поэтому разработчикам COM-объектов не нужно явно поддерживать какой-либо внутренний счетчик ссылок в своих исходных кодах. В C++ программист может либо выполнять явный подсчет ссылок, либо использовать интеллектуальные указатели для автоматического управления счетчиком ссылок.

Ниже приведены рекомендации относительно того, когда вызывать AddRef и Release для COM-объектов.

• Функции и методы, которые возвращают ссылки на интерфейс (через возвращаемое значение или через параметр «out»), перед возвратом должны увеличивать счетчик ссылок возвращаемого объекта.
• Release должен быть вызван для указателя интерфейса до того, как указатель будет перезаписан или выйдет за пределы области действия.
• Если копия сделана в указателе ссылки на интерфейс, AddRef должен быть вызван для этого указателя.
• AddRef и Release должны вызываться для конкретного интерфейса, на который ссылаются, поскольку объект может реализовать подсчет ссылок для каждого интерфейса, чтобы выделить внутренние ресурсы только для интерфейсов, на которые ссылаются.

Не все вызовы счетчика ссылок передаются удаленным объектам по проводной сети; прокси-сервер сохраняет только одну ссылку на удаленный объект и поддерживает собственный счетчик локальных ссылок. Чтобы упростить разработку COM, Microsoft представила ATL (библиотеку активных шаблонов) для разработчиков C++. ATL обеспечивает парадигму разработки COM более высокого уровня. Это также защищает разработчиков клиентских приложений COM от необходимости напрямую поддерживать подсчет ссылок, предоставляя объекты интеллектуальных указателей . Другие библиотеки и языки, поддерживающие COM, включают классы Microsoft Foundation , поддержку COM компилятора VC , VBScript , Visual Basic , ECMAScript ( JavaScript ) и Borland Delphi .

Программирование

COM — это независимый от языка двоичный стандарт, который можно разработать на любом языке программирования, способном понимать и реализовывать двоично определенные типы данных и интерфейсы. Реализации COM отвечают за вход в среду COM и выход из нее, создание экземпляров COM-объектов и подсчет ссылок, запрос объектов для поддерживаемых интерфейсов, а также обработку ошибок. Компилятор Microsoft Visual C++ поддерживает расширения языка C++, называемые атрибутами C++ . Эти расширения предназначены для упрощения разработки COM и удаления большей части шаблонного кода, необходимого для реализации COM-серверов на C++.

Использование реестра

В Windows классы COM, интерфейсы и библиотеки типов перечислены по GUID в реестре , в разделе HKEY_CLASSES_ROOT\CLSID для классов и HKEY_CLASSES_ROOT\Interface для интерфейсов. Библиотеки COM используют реестр для поиска либо правильных локальных библиотек для каждого COM-объекта, либо сетевого расположения для удаленной службы.

COM без регистрации

COM без регистрации (RegFree COM) — это технология, представленная в Windows XP модели компонентных объектов (COM) , которая позволяет компонентам хранить метаданные активации и CLSID ( Class ID) для компонента без использования реестра . Вместо этого метаданные и CLSID классов, реализованных в компоненте, объявляются в манифесте сборки (описанном с помощью XML ), который хранится либо как ресурс в исполняемом файле, либо как отдельный файл, установленный вместе с компонентом. Это позволяет устанавливать несколько версий одного и того же компонента в разные каталоги, описываемые собственными манифестами, а также развертывание XCOPY . Этот метод имеет ограниченную поддержку серверов EXE COM. и не может использоваться для общесистемных компонентов, таких как MDAC , MSXML , DirectX или Internet Explorer .

Во время загрузки приложения загрузчик Windows ищет манифест. Если он присутствует, загрузчик добавляет информацию из него в контекст активации. Когда фабрика классов COM пытается создать экземпляр класса, сначала проверяется контекст активации, чтобы определить, можно ли найти реализацию CLSID. Только если поиск не удался, реестр сканируется.

Создание экземпляров COM-объектов вручную

COM-объекты также можно создавать вручную, учитывая путь к файлу DLL и GUID объекта. Для этого не требуется регистрация DLL или GUID в системном реестре и не используются файлы манифеста. COM DLL экспортирует функцию с именем DllGetClassObject. Вызов DllGetClassObject с нужным GUID и IID_IClassFactory предоставляет экземпляр объекта фабрики . Объект Factory имеет метод CreateInstance, который может создавать экземпляры объекта с учетом GUID интерфейса. Это тот же процесс, который используется внутри компании при создании экземпляров зарегистрированных COM-компонентов.

Если созданный COM-объект создает экземпляр другого COM-объекта с помощью универсального API CoCreateInstance, он попытается сделать это обычным универсальным способом, используя файлы реестра или манифеста. Но он может создавать внутренние объекты (которые могут быть вообще не зарегистрированы) и передавать к ним ссылки на интерфейсы, используя свои собственные знания.

Прозрачность процессов и сети

Объекты COM могут быть прозрачно созданы и на них можно ссылаться внутри одного и того же процесса (внутри процесса), за пределами границ процесса (вне процесса) или удаленно по сети (DCOM). Внепроцессные и удаленные объекты используют маршалинг для сериализации вызовов методов и возврата значений через границы процесса или сети. Эта сортировка невидима для клиента, который обращается к объекту, как если бы он был локальным внутрипроцессным объектом.

Нарезка

В COM многопоточность рассматривается с помощью концепции, известной как апартаменты . Отдельный COM-объект находится ровно в одном апартаменте, который может быть однопоточным или многопоточным. В COM существует три типа апартаментов: однопоточные апартаменты (STA) , многопоточные апартаменты (MTA) и нейтрально-потоковые апартаменты (NA). Каждая квартира представляет собой один механизм, посредством которого внутреннее состояние объекта может быть синхронизировано между несколькими потоками. Процесс может состоять из нескольких COM-объектов, некоторые из которых могут использовать STA, а другие — MTA. Все потоки, обращающиеся к COM-объектам, аналогично живут в одном апартаменте. Выбор места для COM-объектов и потоков определяется во время выполнения и не может быть изменен.

Тип квартиры	Описание
Однопоточная квартира ( STA ), (ThreadingModel= Квартира )	Один поток предназначен для выполнения методов объекта. При таком расположении вызовы методов из потоков за пределами подразделения маршалируются и автоматически ставятся в очередь системой (через стандартную очередь сообщений Windows). Таким образом, среда выполнения COM обеспечивает автоматическую синхронизацию, чтобы гарантировать, что каждый вызов метода объекта всегда выполняется до завершения, прежде чем будет вызван другой. Поэтому разработчику не нужно беспокоиться о блокировке потоков или условиях гонки.
Многопоточная квартира ( MTA ), (ThreadingModel= Бесплатно )	Среда выполнения COM не обеспечивает синхронизацию, и нескольким потокам разрешено одновременно вызывать объекты COM. Поэтому COM-объектам необходимо выполнять собственную синхронизацию, чтобы предотвратить одновременный доступ из нескольких потоков, вызывающий состояние гонки. Вызовы объекта MTA из потока в STA также маршалируются.
Динамически определяемая квартира (ThreadingModel= Both )	В режиме «Оба подразделения» сервер автоматически выбирает STA или MTA при создании объекта в соответствии с типом подразделения вызывающего потока. Это может быть полезно, чтобы избежать накладных расходов на маршаллинг, когда к серверам MTA обращается поток STA.
Потоко-нейтральная квартира ( NA ), (ThreadingModel= Neutral )	Особая квартира без каких-либо закрепленных тем. Когда поток STA или MTA вызывает объект NA в том же процессе, вызывающий поток временно покидает свою квартиру и выполняет код непосредственно в NA без какого-либо переключения потоков. Следовательно, NA можно рассматривать как оптимизацию для эффективных вызовов межапартаментных методов.

Потоки и объекты, принадлежащие одному и тому же подразделению, подчиняются одним и тем же правилам доступа к потокам. Таким образом, вызовы методов, выполняемые внутри одного и того же подразделения, выполняются напрямую, без какой-либо помощи со стороны COM. Вызовы методов, выполняемые между квартирами, достигаются посредством маршалинга. Для этого необходимо использовать прокси и заглушки.

Критика

Поскольку COM имеет довольно сложную реализацию, программисты могут отвлекаться на некоторые «сантехнические» проблемы.

Перекачка сообщений

Когда STA инициализируется, она создает скрытое окно, которое используется для маршрутизации сообщений между подразделениями и процессами. Очередь сообщений этого окна должна регулярно «накачиваться». Эта конструкция известна как « насос сообщений ». В более ранних версиях Windows невыполнение этого требования могло привести к общесистемным взаимоблокировкам. Эта проблема усложняется тем, что некоторые API-интерфейсы Windows инициализируют COM как часть своей реализации, что приводит к «утечке» деталей реализации.

Подсчет ссылок

Подсчет ссылок в COM может вызвать проблемы, если на два или более объектов имеются циклические ссылки . При разработке приложения это необходимо учитывать, чтобы объекты не оставались бесхозными. Объекты также могут оставаться с активными счетчиками ссылок, если используется модель «приемника событий» COM. Поскольку объекту, который запускает событие, необходима ссылка на объект, реагирующий на событие, счетчик ссылок последнего никогда не достигнет нуля. Опорные циклы обычно разрываются с помощью внеполосного завершения или разделения идентификаторов. В методе внеполосного завершения объект предоставляет метод, который при вызове заставляет его удалить ссылки на другие объекты, тем самым разрывая цикл. В методе разделенной идентификации одна реализация предоставляет два отдельных COM-объекта (также известных как идентификаторы). Это создает слабую ссылку между COM-объектами, предотвращая цикл ссылок.

DLL Ад

Поскольку внутрипроцессные COM-компоненты реализуются в файлах DLL, а регистрация допускает только одну версию для каждого CLSID, в некоторых ситуациях они могут подвергаться эффекту « DLL Hell ». Возможность COM без регистрации устраняет эту проблему для компонентов, находящихся в процессе обработки; COM без регистрации недоступен для серверов вне процесса.

См. также

• Соглашение о вызовах
• Common Language Infrastructure — межъязыковая и кроссплатформенная объектная модель .NET.
• CORBA — открытая, кросс-языковая, кросс-платформенная объектная модель.
• D-Bus — открытая, кросс-языковая, кросс-платформенная объектная модель.
• Внешний функциональный интерфейс
• Механизм интернет-коммуникаций
• Удаленный вызов метода Java
• KDE-фреймворки
• Языковая привязка
• Искажение имени
• Переносной объект (вычисления) — определение межъязыковой и кроссплатформенной объектной модели.
• IBM System Object Model (SOM) — многофункциональная альтернатива COM
• SWIG - генератор автоматических привязок интерфейсов с открытым исходным кодом со многих языков на другие языки.

Ссылки

• «COM: Краткое введение (PowerPoint)» (Прямая ссылка на файл PowerPoint (PPT)) . Проверено 7 марта 2006 г.
• Бокс, Дон (1998). Необходимый COM . Аддисон-Уэсли. ISBN  978-0-201-63446-4 .
• Чаппелл, Дэвид (1996). Понимание ActiveX и OLE . Майкрософт Пресс. ISBN  978-1-57231-216-6 .
• «Интеграция и миграция служб COM+ в WCF» . Проверено 15 апреля 2010 г.

Внешние ссылки

• Объектная модель компонентов в MSDN
• Интервью с Тони Уильямсом, соавтором COM (веб-трансляция, август 2006 г.)
• Информация: разница между элементами управления OLE и элементами управления ActiveX от Microsoft
• Спецификация формата данных TypeLib (неофициальная) с утилитой дампера с открытым исходным кодом.
• Глоссарий COM/DCOM (archive.org)