Microsoft вики
в: Страницы с ошибками скриптов, Технологии программного обеспечения Microsoft, Объектно-ориентированное программирование,
и 2 других

Component Object Model

Править

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

История COM[]

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

Путаница в названиях[]

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

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

Принципы работы 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[]

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

Выпущенная в 1996 году технология DCOM (Шаблон:Lang-en — распределённая 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.

Ссылки[]

Литература[]

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

Шаблон:Microsoft APIs

Материалы сообщества доступны в соответствии с условиями лицензии CC-BY-SA, если не указано иное.