Файл: Предпосылки возникновения технологии COM и область её использования.pdf
Добавлен: 27.06.2023
Просмотров: 84
Скачиваний: 3
СОДЕРЖАНИЕ
1. Предпосылки возникновения технологии COM и область её использования
1.1. История возникновения технологии COM
1.2. Применение технологии COM
2.1. Основные понятия технологии COM
2.2. Основные свойства, отличающие COM от ООП. Концепции технологии COM
2.4. Выделение и освобождение памяти
2.6. Портативность и коммуникабельность COM. Регистрация COM-серверов.
3.1. Сравнение COM со смежными технологиями
Чтобы зарегистрировать встроенный 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.
ЗАКЛЮЧЕНИЕ
Технология СОМ определяет общую парадигму взаимодействия программ любых типов: библиотек, приложений, операционной системы, т.е. позволяет одной части ПО использовать функции (службы), предоставляемые другой, независимо от того, функционируют ли эти части в пределах одного процесса, в разных процессах на одном компьютере или на разных компьютерах.