Критика

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

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

· необходимость " прокладочного" кода (в его роли обычно выступает ATL) для того, чтобы создать COM-объект на базе Си++ класса. Хотя этот код и тривиален в использовании для опытного человека, он не очень прост для начинающих. Как и в предыдущем пункте, эта проблема возникает только при написании собственных классов и не возникает при одном лишь использовании стандартных чужих классов (для которых MS разработал библиотеку смарт-пойнтеров - 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 на официальном веб-сайте корпорации Майкрософт (англ.)

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

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

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

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

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

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

· Использование COM объектов без регистрации в реестре (рус.)

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

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

· ComBridge от DComLab (англ.)

Литература

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