Компонентная объектная модель - Component Object Model

Компонентная объектная модель (COM) это двоичный интерфейс стандарт для программные компоненты представлен Microsoft в 1993 году. Используется для включения межпроцессного взаимодействия объект создание в большом количестве языки программирования. COM является основой для нескольких других технологий и фреймворков Microsoft, включая OLE, OLE автоматизация, Объект помощника браузера, ActiveX, COM +, DCOM, то Оболочка Windows, DirectX, UMDF и Среда выполнения Windows. Сущность COM - это не зависящий от языка способ реализации объектов, которые можно использовать в средах, отличных от той, в которой они были созданы, даже за пределами машин. Для хорошо написанных компонентов COM позволяет повторно использовать объекты, не зная об их внутренней реализации, поскольку заставляет разработчиков компонентов предоставлять четко определенные интерфейсы которые отделены от реализации. Различная семантика распределения языков учитывается путем возложения на объекты ответственности за их собственное создание и уничтожение посредством подсчет ссылок. Приведение преобразования типа между различными интерфейсами объекта достигается за счет QueryInterface метод. Предпочтительный метод «наследования» в COM - это создание подобъектов, которым делегируются «вызовы» методов.

COM - это интерфейсная технология, определенная и реализованная как стандарт только на Майкрософт Виндоус и Apple Основной фундамент 1.3 и новее плагин интерфейс прикладного программирования (API).[1] Последний реализует только подмножество всего COM-интерфейса.[2] Для некоторых приложений COM был по крайней мере частично заменен Microsoft .NET framework и поддержка Веб-сервисы сквозь Фонд связи Windows (WCF). Однако COM-объекты можно использовать со всеми языками .NET через .NET. COM-взаимодействие. Сетевой DCOM использует двоичный проприетарные форматы, в то время как WCF поощряет использование XML -основан МЫЛО обмен сообщениями. COM очень похож на другие компонентное программное обеспечение интерфейсные технологии, такие как CORBA и Enterprise JavaBeans, хотя у каждого есть свои сильные и слабые стороны. В отличие от C ++, COM обеспечивает стабильную двоичный интерфейс приложения (ABI), который не меняется между выпусками компилятора.[3] Это делает COM-интерфейсы привлекательными для объектно-ориентированных библиотек C ++, которые должны использоваться клиентами, скомпилированными с использованием разных версий компилятора.

История

Один из первых способов межпроцессного взаимодействия в Windows было Динамический обмен данными (DDE),[4] впервые представлен в 1987 году,[5] что позволяло отправлять и получать сообщения в так называемых «разговорах» между приложениями. Энтони Уильямс, который участвовал в создании архитектуры 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 году, когда версия 3.1 Windows был выпущен, Microsoft выпустила OLE 2 с его базовым объектная модель. COM Бинарный интерфейс приложения (ABI) был таким же, как MAPI ABI (выпущен в 1992 г.), и, как будто он был основан на MSRPC и в конечном итоге на Открытая группа с 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.[6]

Связанные технологии

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

DDE

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

DCE / RPC и MSRPC

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

DCOM

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

COM +

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

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

.СЕТЬ

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

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

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

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

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

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

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

Технические детали

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

Интерфейсы

Все компоненты COM реализуют IНеизвестно (обычай) интерфейс, который предоставляет методы для подсчет ссылок и преобразование типов (Кастинг). А обычай 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 как объектная структура

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

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

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

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

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

учебный класс SomeClass : общественный ISomeInterface {  ...  ...};

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

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

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

ISomeInterface* interface_ptr = НОЛЬ;HRESULT час = CoCreateInstance(CLSID_SomeClass, НОЛЬ, CLSCTX_ALL,                              IID_ISomeInterface, (пустота**)&interface_ptr);

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

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

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

Ниже приведены инструкции, когда звонить. AddRef и Релиз на COM-объектах:

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

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

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

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

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

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

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

COM без регистрации (RegFree COM) - это технология, представленная в Windows XP что позволяет модели компонентных объектов (COM) составные части хранить активацию метаданные и CLSID (Учебный класс Я БЫ) для компонента без использования реестр. Вместо этого метаданные и CLSID классов, реализованных в компоненте, объявляются в манифест сборки (описано с использованием XML ), который хранится либо как ресурс в исполняемом файле, либо как отдельный файл, устанавливаемый вместе с компонентом.[15] Это позволяет устанавливать несколько версий одного и того же компонента в разные каталоги, описываемые их собственными манифестами, а также Развертывание XCOPY.[16] Этот метод имеет ограниченную поддержку для серверов EXE COM.[17] и не может использоваться для общесистемных компонентов, таких как MDAC, MSXML, DirectX или же Internet Explorer.

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

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

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

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

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

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

Резьба

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

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

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

Критика

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

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

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

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

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

DLL ад

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

Смотрите также

Примечания

  1. ^ «Архив документации». developer.apple.com.
  2. ^ «Плагины и Microsoft COM». Apple Inc. Получено 5 октября, 2010.
  3. ^ Форум Microsoft: Двоичная совместимость между версиями Visual C ++
  4. ^ «О сетевом DDE - Windows-приложениях». Microsoft.com. 30 мая 2018 года.
  5. ^ «Техника выполнения кода использует преимущества динамического обмена данными». McAfee.com. 27 октября 2017 года.
  6. ^ "draft-brown-dcom-v1-spec-03 - Протокол объектной модели распределенных компонентов - DCOM / 1.0". datatracker.ietf.org. Получено 29 августа, 2019.
  7. ^ рпетруша. "Вызываемая оболочка времени выполнения". msdn.microsoft.com.
  8. ^ рпетруша. "Вызываемая оболочка COM". msdn.microsoft.com.
  9. ^ Стейнберг, Джилл (1 марта 1997 г.). «Конкурирующие компоненты вызывают раздражение у экспертов». JavaWorld. Получено 2020-07-16.
  10. ^ "Указатель документации win32com". docs.activestate.com.
  11. ^ «Python и COM». www.boddie.org.uk.
  12. ^ "Поддержка COM компилятора". MSDN. Microsoft.
  13. ^ Microsoft MSDN: Справочник по атрибутам C ++
  14. ^ Журнал MSDN: Атрибуты C ++: упростите программирование на COM с помощью новой функции в Visual Studio .NET
  15. ^ "Манифесты сборки". MSDN. Получено 5 ноября, 2009.
  16. ^ а б c Дэйв Темплин. «Упростите развертывание приложений с помощью ClickOnce и COM без регистрации». MSDN Журнал. Получено 22 апреля, 2008.
  17. ^ «Как использовать внепроцессный COM-сервер без его tlb-файла». Получено 16 апреля, 2011.
  18. ^ «Концепции изолированных приложений и параллельных сборок». MSDN. Получено 5 февраля, 2016.
  19. ^ Архипов, Михаил (1 апреля 2005 г.). «COM без регистрации». Блоги MSDN. Получено 29 апреля, 2016.
  20. ^ "Точка входа DllGetClassObject (COM)". MSDN. Если вызов функции CoGetClassObject находит объект класса, который должен быть загружен в DLL, CoGetClassObject использует экспортированную функцию DllGetClassObject DLL.
  21. ^ Microsoft MSDN: Процессы, потоки и апартаменты
  22. ^ Microsoft MSDN: Однопоточные апартаменты
  23. ^ Microsoft MSDN: Многопоточные апартаменты
  24. ^ Microsoft MSDN: Понимание и использование моделей потоков COM
  25. ^ Кодегуру: Общие сведения о COM-апартаментах

Рекомендации

внешняя ссылка