Файл: Технология COM).pdf

Технология СОМ является одной из базовых технологий Windows и для того, чтобы понять ее назначение, необходимо рассмотреть основные предпосылки ее возникновения. Если попытаться кратко сформулировать ее цель – то это способ взаимодействия клиентских приложений и серверов или предоставление сервисов одним приложением другому. Таким образом, главной предпосылкой возникновения СОМ является именно взаимодействие приложений.

Проблема взаимодействия приложений Windows имеет две стороны: взаимодействие на одном компьютере и в сети Intranet или Internet. Взаимодействие приложений, размещенных на удаленных компьютерах, обеспечивается технологией DCOM (Distributed COM – распределенная модель компонентных объектов), а также и технологией COM+. COM+ является следующим эволюционным шагом в развитии технологии СОМ. Технология COM+ не только включает в себя технологии COM и DCOM, но и имеет свои специфические особенности, облегчающие программирование взаимодействующих приложений Windows в рамках одного компьютера или в сети.

Чтобы яснее представить себе проблему взаимодействия приложений Windows, надо вспомнить следующее. Каждый процесс в 32-разрядной Windows имеет свое адресное пространство размером в 4Гб и, по этой причине, один процесс не имеет никакой возможности (и хорошо!) получить доступ к данным или функциям другого процесса, так как любой адрес в процессе ссылается на свое адресное пространство.

В логической и хронологической последовательности взаимодействие приложений Windows реализовалось с использованием следующих технологий:

1 Dynamic Link Libraries (DLL) – динамически подключаемые библиотеки.

2 Open DataBase Connectivity (ODBC) – открытый интерфейс доступа к базам данных, встроенный в Windows и Windows NT.

3 Dynamic Data Exchange (DDE) – динамический обмен данными.

4 Object Linking and Embedding (OLE1.0) – внедрение и связывание объектов.

5 OLE2.0 – OLE на базе COM.

6 Distributed COM (DCOM) – распределенная модель компонентных объектов.

7 COM+ – новейшая технология COM.

Ну хорошо, скажете Вы, а зачем вообще приложениям необходимо взаимодействовать друг с другом? Если некоторому приложению необходимо, допустим, использовать электронные таблицы Excel, то почему бы ему не подключить соответствующую библиотеку DLL? Естественно, можно, и это уже было первым подходом к решению обсуждаемой проблемы. Однако, такой подход имеет свои недостатки, главным из которых является проблема сопровождения и модификации ПП. Если разрабатывалась новая версия какой-либо функции DLL, то перестают работать приложения, которые используют старую версию библиотеки. Если новую версию функции снабдить новым именем, то необходимо разрабатывать новую документацию и включать в библиотеку обе версии функции. Несложно себе представить, в какой конгломерат превратится библиотека в течение весьма небольшого промежутка времени и насколько сложно будет ориентироваться в многочисленных версиях функций!

Главную идею технологии ODBC можно проиллюстрировать все на той же Excel. Так как это приложение должно быть способно считывать данные из БД различных форматов, необходимо или разрабатывать различные версии Excel для каждой из БД (Excel для Access, Excel для Oracle и т.д.) или заблаговременно подключать все необходимые библиотеки к Excel. Microsoft выбрала другой путь, создав промежуточный программный слой, который определяет стандартный интерфейс для приложений. На уровне вызовов этот интерфейс использует язык SQL, а реализация взаимодействия с БД обеспечивается драйверами, поставляемые в форме DLL. Таким образом, ODBC располагается между приложением и источниками данных различных форматов [8].

Технологию динамического обмена данными DDE можно рассматривать как попытку стандартизации обмена данными между приложениями. Вся идеология Windows основана на обработке сообщений (messages) и любые приложения могут обмениваться друг с другом сообщениями, используя общую очередь сообщений. Проблема, однако, состоит в том, что каждое из приложений должно знать протокол обмена данными, т.е. формат сообщений, и собственно сообщения Windows не позволяют передавать сравнительно большие объемы данных. Технология DDE как раз и предложила такой стандартный протокол, реализованный во многих приложениях. Главными недостатками DDE является сложность программирования, ненадежность и то обстоятельство, что приложения должны знать формат передаваемых данных.

Технологию внедрения и связывания объектов[1] OLE1.0 фирма Microsoft представила в 1991г. как попытку реализации объектно-ориентированного механизма взаимодействия приложений. Главной идеей OLE является концепция составного документа, который может содержать объекты других приложений.

До OLE приложения могли обмениваться статическими снимками данных через буфер обмена Windows. Однако редактирование таких данных должно выполняться тем приложением, которое их породило, а после редактирования они вновь должны быть вставлены в другой документ. Если изменяются исходные данные, то, очевидно, должны изменяться данные и в составном документе. Однако, системный буфер обмена не имеет никаких средств поддержания таких связей. Более того, проблемы возникают и при перемещении исходных данных в новое место.

Внедренный с помощью OLE1.0 объект содержит статические данные (рисунок) и данные, необходимые для его редактирования. Для редактирования объекта пользователю приложения-контейнера необходимо щелкнуть по объекту, вследствие чего в отдельном окне запускается исходное приложение, породившее эти данные. По окончании редактирования пользователь может сохранить данные и эти данные будут обновлены и в приложении-контейнере.

Недостатками технологии OLE1.0 являются:

1 Так как базовым механизмом OLE1.0 является DDE, который по своей природе асинхронен, то после вызова любой функции возврат управления происходит немедленно и требуется ожидать, в цикле, завершения требуемой операции.

2 Так как для передачи данных между приложениями используется разделяемая глобальная память, то данные сначала копируются в нее, откуда они тут же могут быть вытолкнуты Windows в файл подкачки, вследствие чего замедляется работа приложения.

3 Связи OLE1.0 легко разрываются при перемещении файлов.

4 Пользователю неудобно редактировать данные в отдельном окне.

1.3 Введение в COM технологии

Далее рассмотрим основные понятия и определения.

COM (Component Object Model) – модель компонентных объектов Microsoft. Стандартный механизм, включающий интерфейсы, с помощью которых одни объекты предоставляют свои сервисы другим. Является основой многих объектных технологий, в том числе OLE и ActiveX. Другой перевод: многокомпонентная модель объектов.

DCOM (Distributed Component Object Model) – распределенная модель компонентных объектов. Расширение модели COM фирмы Microsoft, ориентированное на поддержку и интеграцию распределенных объектных приложений, функционирующих в сети.

COM представляет собой основанную на объектах клиент-серверную модель, разработанную Microsoft для обеспечения взаимодействия между компонентами программного обеспечения и приложениями. Microsoft расширила эту технологию добавлением элементов ActiveX, которые представляют результат развития технологий OLE и OCX. OCX (OLE Custom eXtension) – это программируемые компоненты-приложения с интерфейсом на базе OLE, позволяющим легко включать их в другие приложения. С 1996 года они стали называться ActiveX.

Сейчас Microsoft предлагает использовать термин Active technologies вместо ActiveX, включая в новые технологии такие составляющие:

1. Active Documents (активные документы).

2. ActiveX (управляющие элементы).

3. Active Scripting controls.

4. Automation (автоматизация, прежде известная как OLE Automation).

Ключевым аспектом COM является то, что эта технология обеспечивает связь между клиентами и серверами посредством интерфейсов. Именно интерфейс предоставляет клиенту способ "узнать" у сервера, какие именно возможности он поддерживает на этапе выполнения. Для расширения возможностей сервера необходимо просто добавить новый интерфейс к существующим.

Delphi предоставляет программисту мастеров (wizards) и классы, которые облегчают разработку приложений, основанных на технологиях COM. Мастера позволяют создавать:

1) простые COM–совместимые классы для использования в одном приложении;

2) полновесные серверы COM;

3) серверы автоматизации (Automation servers) и контроллеры автоматизации (Automation controller);

4) управляющие элементы ActiveX;

5) активные формы ActiveForms.

Технология COM как спецификация и реализация. COM является одновременно и спецификацией и реализацией. Спецификация COM определяет правила создания объектов и их взаимодействия, способ связи между объектами. В соответствии со спецификацией объекты COM могут быть написаны на различных языках, выполняться в адресном пространстве различных процессов и на разнообразных платформах. До тех пор, пока объекты полностью соответствуют спецификации, они могут взаимодействовать. Это позволяет объединять унаследованный код как компонент с новыми компонентами, разработанными в любом из объектно-ориентированных языков.

COM как реализация представляет собой библиотеку (файлы OLE32.dll OLEAut32.dll), которая предоставляет ряд основных служб, поддерживающих описанные спецификации. Библиотека COM содержит набор стандартных интерфейсов, определяющих основную функциональность объектов COM, и небольшой набор функций API, разработанных для целей создания и управления объектами COM.

Интерфейсы объектов Delphi, как и язык Object Pascal, соответствуют COM спецификации. Реализация COM в Delphi называется DAX (Delphi ActiveX framework – базовая структура (каркас) элементов ActiveX Delphi). Основная часть реализации этой структуры находится в модуле AxCtrls.

Когда программист использует мастеров Delphi или объекты библиотеки VCL в своем приложении, он использует реализацию COM спецификаций. Кроме того, Delphi предоставляет ряд упаковщиков (wrapper) для таких служб COM, которые не реализуются непосредственно, например, активные документы (Active Documents). Эти упаковщики включены в модуль ComObj

Так как COM является развивающейся технологией, она может быть расширена за рамки базисных служб. COM является основой для других технологий, таких как автоматизация (Automation – вместо прежнего термина OLE Automation), элементы ActiveX и активные документы (Active Documents).

Кроме того, в настоящее время возможно создание таких объектов COM, которые могут взаимодействовать с Microsoft Transaction Server (MTS). MTS – это система обработки транзакций, предназначенная для построения, развертывания и управления большими Intranet и Internet приложениями-серверами. Хотя MTS архитектурно и не является частью COM, она разработана для расширения возможностей COM в большой, распределенной среде.

Delphi снабжает программиста мастерами, облегчающими разработку приложений, которые объединяют упомянутые выше технологии – Automation, ActiveX, Active Documents и MTS [9].

1.4 Составляющие приложений COM

При разработке приложений, использующих технологию COM, используются структурные элементы, приведенные в таблице 1.

Таблица 1- Структурные элементы технологии COM

Клиент взаимодействует с объектом COM посредством интерфейса, который представляет собой набор функционально или семантически связанных подпрограмм, с помощью которых обеспечивается связь клиента с провайдером сервисов (сервером). Стандартный способ изображения интерфейса приведен на рис.1.

Рис. 1. Интерфейс COM [10]

Например, каждый COM объект имеет базовый интерфейс IUnknown, который сообщает, какие интерфейсы объекта доступны клиенту. Любой интерфейс сообщает клиенту, какие возможности он предоставляет.

Ключевыми аспектами интерфейсов объектов COM являются следующие:

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