Component Object Model








COM (англ. Component Object Model — модель компонентного объекта; произносится как [ком]) — это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих компонентов объекта, каждый из которых может использоваться во многих программах одновременно. Стандарт воплощает в себе идеи полиморфизма и инкапсуляции объектно-ориентированного программирования. Стандарт COM мог бы быть универсальным и платформо-независимым, но закрепился в основном на операционных системах семейства Microsoft Windows. В современных версиях Windows COM используется очень широко. На основе COM были реализованы технологии: Microsoft OLE Automation, ActiveX, DCOM, COM+, DirectX, а также XPCOM.




Содержание






  • 1 История COM


    • 1.1 Путаница в названиях




  • 2 Поддержка в ОС Windows


  • 3 Принципы работы COM


  • 4 Технологии, основанные на стандарте COM


    • 4.1 DCOM


    • 4.2 COM+


    • 4.3 .NET и будущее COM


    • 4.4 DCOM через интернет и решение проблемы XP SP2


    • 4.5 OPC


    • 4.6 OLE




  • 5 Критика


  • 6 Примечания


  • 7 Ссылки


  • 8 Литература





История COM |


Стандарт COM был разработан в 1993 году корпорацией Microsoft как основа для развития технологии OLE. Технология OLE 1.0 уже позволяла создавать т. н. «составные документы» (англ. compound documents): например, в пакете Microsoft Office эта технология позволяла включать диаграммы Microsoft Excel в документы Microsoft Word.



Путаница в названиях |


В 1996 году Microsoft попыталась переименовать технологию OLE в ActiveX, но это удалось лишь частично. Например, технология OLE позволяла создавать так называемые элементы управления OLE (англ. OLE Controls, или OCX) — повторно используемые элементы пользовательского интерфейса, которые были построены на стандарте COM. Эти элементы управления OLE были переименованы в элементы управления ActiveX (англ. ActiveX controls), хотя расширение файлов «.ocx» за ними осталось. Затем Microsoft стала активно продвигать ActiveX в Интернет, включив поддержку элементов ActiveX в свой браузер Internet Explorer. В результате название OLE осталось только за технологией составных документов и локальных внедряемых объектов. А сетевые OLE-объекты стали называть по-новому — ActiveX.


Некоторая путаница между понятиями OLE и ActiveX сохраняется и до сих пор, но речь идёт об одних и тех же COM-технологиях. Причём иногда даже путают понятия OLE и COM. Так, внедряемые OLE-объекты иногда называют COM-объектами, а OLE-контейнеры — COM-контейнерами, и т. п.



Поддержка в ОС Windows |



  • Windows 7, Windows 8, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 поддерживают COM+[1].

  • Для Windows Server 2012 R2 роль сервера приложений, которая реализует COM+, объявлена устаревшей и подлежащей удалению в будущих версиях[2].



Принципы работы COM |


Основным понятием, которым оперирует стандарт COM, является COM-компонент. Программы, построенные на стандарте COM, фактически не являются автономными программами, а представляют собой набор взаимодействующих между собой COM-компонентов. Каждый компонент имеет уникальный идентификатор (GUID) и может одновременно использоваться многими программами. Компонент взаимодействует с другими программами через COM-интерфейсы — наборы абстрактных функций и свойств. Каждый COM-компонент должен, как минимум, поддерживать стандартный интерфейс «IUnknown», который предоставляет базовые средства для работы с компонентом. Интерфейс «IUnknown» включает в себя три метода: QueryInterface, AddRef, Release.


Windows API предоставляет базовые функции, позволяющие использовать COM-компоненты. Библиотеки MFC и, особенно, ATL/WTL предоставляют более гибкие и удобные средства для работы с COM. Библиотека ATL от Microsoft до сих пор остаётся самым популярным средством создания COM-компонентов. Но зачастую COM-разработка остаётся ещё довольно сложным делом, программистам приходится вручную выполнять многие рутинные задачи, связанные с COM (особенно это заметно в случае разработки на C++). Впоследствии (в технологиях COM+ и особенно .NET) Microsoft попыталась упростить задачу разработки COM-компонентов.



Технологии, основанные на стандарте COM |



DCOM |



Выпущенная в 1996 году технология DCOM (англ. Distributed COM — распределённая COM) основана на технологии DCE/RPC (разновидности RPC). DCOM позволяет COM-компонентам взаимодействовать друг с другом по сети. Главным конкурентом DCOM является другая известная распределённая технология — CORBA.


Как DCOM, так и CORBA решают задачу вызова метода объекта, расположенного на другой машине, а также передачу ссылки на объект с одной машины на другую.


Сетевой уровень DCOM называется ORPC (Object RPC) и является объектно-ориентированным расширением DCE RPC.


Технология DCOM обеспечивает базовые установки безопасности, позволяя задавать, кто и из каких машин может создавать экземпляры объекта и вызывать его методы.



COM+ |


Microsoft Transaction Server был включен в Option Pack для Windows NT4 еще в 1997 году.


В составе Windows 2000 была выпущена технология COM+, которая являлась новой версией Microsoft Transaction Server.


Технология расширяла возможности разработчиков COM-компонентов, предоставляя им некоторые готовые услуги, например:



  • автоматический пул потоков, создаваемый стандартным процессом-загрузчиком mtx.exe

  • доступ к контексту, в котором выполняется компонент (например, компоненты, используемые в ASP, могут с этой возможностью получить доступ к внутренним объектам той страницы, на которой они выполняются).

  • интеграция с транзакциями монитора MS DTC (контекст COM+ может автоматически содержать в себе транзакцию MS DTC)


MTS/COM+ использовался внутри ряда версий веб-сервера MS IIS для загрузки и исполнения веб-приложений, как бинарных по технологии ISAPI, так и скриптовых по технологии ASP (сама asp.dll есть ISAPI-приложение).


COM+ объединяет компоненты в так называемые приложения COM+, что упрощает администрирование и обслуживание компонентов. Безопасность и производительность — основные направления усовершенствований COM+. Некоторые идеи, заложенные в основу COM+, были также реализованы в Microsoft .NET.



.NET и будущее COM |


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



DCOM через интернет и решение проблемы XP SP2 |


В 2009 году DComLab опубликовал коммерческий продукт ComBridge. При использовании ComBridge для работы по DCOM через интернет не требуется CIS, не используется 135 порт, в локальной сети не требуются настройки dcomcnfg.
ComBridge встраивается в транспортный уровень DCOM, полностью выделяя весь трафик созданного объекта и всех полученных из него объектов в отдельный поток.



OPC |


OPC (OLE for Process Control) — семейство программных технологий, предоставляющих единый интерфейс для управления объектами автоматизации и технологическими процессами. Многие из OPC-протоколов базируются на Windows-технологиях: OLE, ActiveX, COM/DCOM. Такие OPC-протоколы, как OPC XML DA и OPC UA, являются платформо-независимыми.



OLE |


OLE (англ. Object Linking and Embedding, произносится как oh-lay [олэй] — Связывание и встраивание объекта) — технология связывания и внедрения объектов в другие документы и объекты, разработанные корпорацией Майкрософт.


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



Критика |


Технология часто критикуется за неоправданную сложность, конкретно:



  • необходимость использования двух языков программирования (.idl для описания интерфейсов и, обычно, C++ для написания реализаций). Необходимость возникает только при создании собственных интерфейсов, и не возникает в случае, если разработчик ограничил себя использованием готовых интерфейсов.

  • необходимость «прокладочного» кода (в его роли обычно выступает ATL) для того, чтобы создать COM-объект на базе С++ класса. Хотя этот код и тривиален в использовании для опытного человека, он не очень прост для начинающих. Как и в предыдущем пункте, эта проблема возникает только при написании собственных классов и не возникает при одном лишь использовании стандартных чужих классов (для которых Microsoft разработал библиотеку смарт-пойнтеров — comdef.h, _com_ptr_t<Interface>, эта библиотека делает использование COM-объектов тривиальным).

  • необходимость регистрации компонент в реестре операционной системы, причем при этом в качестве идентификатора класса используется нечитаемый человеком GUID (хотя его и возможно дополнить читаемым именем).

  • инфраструктура remoting (удаленного вызова методов) использует бинарный формат запросов и ответов, являясь расширением DCE RPC. Это приводит к возникновению огромной «поверхности уязвимости» с точки зрения безопасности, и не раз приводило к крупным эпидемиям вредоносного ПО (MSBlaster).

  • инфраструктура remoting использует по умолчанию (вслед за DCE RPC) динамически назначаемые номера TCP- и UDP-портов, что делает её крайне сложной в настройке при наличии межсетевых экранов.

  • обработка ошибок. В COM принято использовать 32-битные коды ошибки HRESULT, которые имеют значения вроде 0x80070123, и совершенно не читаемы человеком (хотя в последнее время все они легко ищутся поисковыми машинами Интернета).


Кроме того, runtime type information в COM, известная под названием type libraries, поддерживается только для т. н. Automation-compatible интерфейсов, имеющих огромные ограничения на типы параметров (массивы — только SAFEARRAY, строки — только BSTR, никаких произвольных структур, только числа, дата/время, массивы, строки и ссылки на другие Automation-compatible объекты).


Заметно, однако, что многие из этих недостатков являются платой за достоинство COM — независимость от языка программирования и исполняющей среды, и не существуют в «истинно объектных» языках, таких, как C#, или же (прекращенная) реализация Java компании Microsoft. Эти языки предоставляют и полную runtime type information, и отсутствие необходимости регистрации, и возможность написания как интерфейсов, так и классов стандартным для языка образом, без «прокладок» вроде ATL. Так, в MS J++ любой класс Java тривиально публиковался внешнему миру как класс COM, достаточно было лишь регистрации. То же существует и в C#.


С противоположной стороны, «истинно объектные» языки либо вообще не способны стыковаться с компонентами из других объектных языков и требуют написания всей системы (и нижележащих подсистем и фреймворков) «сверху донизу» на одном языке в одной исполняющей среде (Java, Objective C), либо же налагают такое же требование хотя и не на язык, но на исполняющую среду (.NET, языки C#, C++ managed и VB.NET).


Более новые аналогичные технологии (например, в мире .NET) пытаются решить эти проблемы. Там обычно стек remoting полиморфен и кастомизируем, что дает возможность самостоятельно выбирать формат вопросов/ответов и транспортный протокол (по умолчанию используется уже не DCE RPC, а SOAP, в качестве формата данных — XML, а в качестве транспорта — HTTP, который не полагается на динамические номера портов).


Использование механизма позднего связывания может существенно снизить производительность по сравнению, например, с вызовом экспортируемой функции из динамической библиотеки. Однако этот механизм применяется только в скриптовых языках, и только в том случае, если язык не поддерживает объявление ссылок на объекты как ссылок на COM-интерфейсы из type libraries (в виде Dim obj As Excel.Workbook), а поддерживает только абстрактные COM-объекты (в виде Dim obj As Object). Кроме того, такой же подход применяется в Objective C и Cocoa.



Примечания |





  1. ↑ Manage COM+ Applications. Microsoft TechNet. Microsoft Corp. (22 февраля 2013). Проверено 31 августа 2018.


  2. ↑ Features Removed or Deprecated in Windows Server 2012 R2. Microsoft TechNet. Microsoft Corp. (31 августа 2016). Проверено 31 августа 2018.




Ссылки |




  • Раздел разработки Win32 и COM в библиотеке MSDN (англ.)


  • Раздел COM в библиотеке MSDN (англ.)


  • Раздел COM+ в библиотеке MSDN (англ.)


  • Раздел DCOM в библиотеке MSDN (англ.)


  • раздел COM/DCOM/COM+ на сайте RSDN (рус.)


  • Концепция COM (англ.)


  • Программирование COM-интерфейсов (англ.)


  • Подборка статей о COM (рус.)



Литература |


  • Роберт Дж. Оберг. Технология COM+. Основы и программирование = Understanding and Programming COM+: A Practical Guide to Windows 2000 First Edition. — М.: «Вильямс», 2000. — С. 480. — ISBN 0-13-023114-2.








Popular posts from this blog

Котор

Шёнбрунн

Вологодский район