Файл: Предпосылки возникновения технологии COM и область её использования.pdf

Чтобы зарегистрировать встроенный COM-сервер в системном реестре, необходимо вызвать функцию DllRegisterServer, находящуюся внутри DLL-модуля COM-сервера. Это можно сделать в приложении, предва-рительно загрузив DLL, или с помощью стандартной утилиты Windows RegSvr32.exe, выполнив команду:

RegSvr32 -s <имя сервера>

При удалении встроенного сервера из системы необходимо запустить функцию DllUnregisterServer. В Windows удаление сервера осуществляется командой:

RegSvr32 -u <имя сервера>

Для регистрации внешних COM-серверов требуется запустить приложение, включив в командную строку запуска ключ /regserver, a для удаления нужно использовать ключ /unregserver. Встроенный COM-сервер регистрируется и при первом запуске приложения без всяких дополнительных ключей в командной строке, но после этого сервер будет продолжать работать.

3. Анализ технологии COM

3.1. Сравнение COM со смежными технологиями

3.1.1. CORBA

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

Наиболее известным конкурентом технологии COM является архитектура брокеров объектных запросов Common Object Request Broker Architecture (CORBA), которую развивает Консорциум OMG [11].

Функции CORBA и COM – это функции промежуточного программного обеспече­ния объектной среды. Для того чтобы обеспечить взаимодействие объектов и их инте­грацию в цельную систему, архитектура промежуточного уровня должна реализовать несколько базовых принципов:

- независимость от физического размещения объекта: компоненты программного обеспечения не обязаны находиться в одном исполняемом файле, выполняться в рамках одного процесса или размещаться на одной аппаратной системе;

- независимость от платформы: компоненты могут выполняться на различных ап­паратных и операционных платформах, взаимодействуя друг с другом в рамках единой системы;

- независимость от языка программирования: различия в языках, которые исполь­зуются при создании компонентов, не препятствуют их взаимодействию друг с другом.

CORBA и COM отличаются, однако сходны в том, каким образом в них достигается реализация базовых принципов. Это клиент-серверные технологии, в которых функ­циональность объекта предоставляется клиенту посредством обращения к абстракт­ным интерфейсам. Интерфейс определяет набор методов, которые реализуют функ­ции, присущие данному классу объектов. Интерфейс дает клиенту возможность толь­ко вызывать тот или иной метод, скрывая от него все детали его реализации. В обеих технологиях взаимодействие между клиентским процессом и сервером объекта, т. е. процессом, который порождает и обслуживает экземпляры объекта, использует меха­низм объектного варианта вызова удаленной процедуры (remote procedure call – RPC). Он реализует схему передачи сообщений, в соответствии с которой в распределенном клиент-серверном приложении процедура-клиент передает специальное сообщение с па­раметрами вызова по сети в удаленную серверную процедуру, а результаты ее выпол­нения возвращаются в другом сообщении клиентскому процессу.

Для того чтобы реализовать эту схему, на стороне клиента и на стороне сервера поддерживаются специальные компоненты, носящие название клиентский и серверный суррогаты (client stub и server stub). Для того чтобы вызвать ту или иную функ­цию, клиент обращается к клиентскому суррогату, который упаковывает аргументы в сообщение-запрос и передает их на транспортный уровень соединения. Серверный суррогат распаковывает полученное сообщение и в соответствии с переданными аргу­ментами вызывает нужную функцию или нужный метод объекта, если речь идет об объектном варианте RPC. В СОМ клиентский суррогат называется proxy, а сервер­ный – stub. В CORBA клиентский суррогат не имеет специального названия, а сервер­ный обозначают термином skeleton [11].

Параметры вызова могут формироваться в отличной от серверной языковой и опе­рационной среде, поэтому на клиентский и серверный суррогаты возлагаются функции преобразования аргументов и результатов в универсальное, не зависящее от конкрет­ной архитектуры представление. Тем самым достигается возможность взаимодействия клиента и сервера на различных платформах. Одной из последних технологий для рас­пределенных вычислений является Windows Communication Foundation (WCF) от ком­пании Microsoft. Тотальное принятие стандартных способов реализации распределен­ных вычислений поменяло мир разработки приложений. К примеру, функции, пред­ставляемые в настоящее время, включают в себя безопасность, координацию распреде­ленных транзакций и надежные соединения. Полезные изменения в программировании сервисов должны быть отражены в инструментах, используемых разработчиками. WCF призван предоставить управляемый подход к распределенным вычислениям, широкой функциональной совместимости и прямую поддержку сервисов.

WCF упрощает разработку связанных приложений с помощью новой, ориентирован­ной на сервисы, модели. Он поддерживает множество стилей для разработки распре­деленных приложений, создавая слоистую архитектуру. В основе архитектура каналов WCF дает асинхронную, нетипизированную передачусообщений. Над этим надстраи­вается архитектура для защищенного, надежного, транзакционного обмена данными, дающего большие возможности передачи и кодировки данных. WCF включает в се­бя возможности сериализации, которая позволяет избежать стыковки и версионирова-ния, и предоставляет интеграцию и функциональную совместимость с существующими распределенными системами .NET, такими как очередь сообщений (MSMQ), COM+, ASP.NET, сетевые сервисы, улучшенные сетевые сервисы (WSE).

3.1.2. Компоненты .NET

Приложения .NET состоят из компонент. Все .NET-объекты имеют такие важные атрибуты как свойства, методы и события, кото­рые определяют концепцию объектно-ориентированного программирования. Если речь идет о программировании на Visual Basic, то важным вопросом остается реализация программного интерфейса, который будут использовать другие программисты в сво­их приложениях. Б´ольшую часть времени разработки будут занимать проектирование объектов и написание соответствующего программного кода.

Обычно реализация простого объектно-ориентированного приложения .NET заклю­чается в создании класса, добавлении необходимых полей, методов и свойств и исполь­зовании этого класса в различных модулях приложения. Компонентное программиро­вание максимально выделяет такую концепцию. Несмотря на то, что компонентный подход подразумевает также написание классов, компоненты, используемые в различ­ных приложениях, идут перед ними.

Компонент – особый тип исполняемого .NET модуля. На такой компонент обычно имеются ссылки из других приложений, которые его используют. Во многих интернет-сервисах компоненты применяются для работы с данными, графикой, текстом. В ло­кальных приложениях компоненты играют туже роль, что и в Интернете, но в более сокращенном варианте.

Компоненты предоставляют программный интерфейс, используемый приложени­ями. Он обладает набором методов, свойств, классов. Другими словами, компонент компилируется из набора классов, по средствам которых предоставляются необходи­мые методы и свойства.

Компонента является библиотекой с расширением dll. Во время исполнения такая библиотека подгружается к исполняемому модулю. Обычно компоненты компилируют­ся и тестируются как отдельные проекты, а не в составе использующих их модулей. После компиляции компонент может быть добавлен во многие проекты [9, с.11].

3.1.3. JavaBeans

Еще одним инструментом разработки компонентных модулей служит технология JavaBeans – классы в языке Java, написанные по конкретным правилам. Они применяются для объединения нескольких объектов в один (bean) для удобной передачи данных.

Спецификация Sun Microsystems определяет JavaBeans как «универсальные про­граммные компоненты, которые могут управляться с помощью графического интер­фейса» («reusable software components that can be manipulated visually in a builder tool»).

JavaBeans обеспечивает основу для многократно используемых, встраиваемых и мо­дульных компонентов программного обеспечения. Компоненты JavaBeans могут при­нимать различные формы, но наиболее широко они применяются в элементах графиче­ского пользовательского интерфейса. Одна из целей создания JavaBeans – взаимодей­ствие с похожими компонентными структурами. Например, Windows-программа при наличии соответствующего моста или объекта-обёртки может использовать компонент JavaBeans так, будто бы он является компонентом COM или ActiveX [4].

3.2. Достоинства и недостатки COM

Достоинства­ми технологии COM являются комплексность и универсальность подходов в рамках COM-модели.

COM очень прост для простых небольших приложений и чрезвычайно сложен как инструмент создания комплекс­ных систем. Он содержит большое количество «узких» мест – недостаточно гибкую стандартную схему маршалинга, отсутствие состояния объектов, низкую устойчивость к сбоям. Технология не является объектно-ориентированной в классическом смысле этого слова, что в общем случае не способствует простоте ее применения [6].

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

- необходимость использования двух языков программирования (.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.

ЗАКЛЮЧЕНИЕ

Технология СОМ определяет общую парадигму взаимодействия программ любых типов: библиотек, приложений, операционной системы, т.е. позволяет одной части ПО использовать функции (службы), предоставляемые другой, независимо от того, функционируют ли эти части в пределах одного процесса, в разных процессах на одном компьютере или на разных компьютерах.