4.3.1.4. Интерфейс
По своей сути интерфейс - это договор между COM-объектом и клиентским приложением, в котором COM-объект гарантирует клиенту предоставление некоторых услуг. Услуги - это определенные в интерфейсе методы. Но хотя интерфейс и имеет право объявлять заголовки методов, но ни один из его методов не имеет описания. Это объясняется тем, что у интерфейса нет раздела реализации, он лишь декларирует названия методов и перечень параметров. Клиенты могут получить доступ к данным COM-объекта только с помощью указателя на интерфейс.
Другим значимым аспектом интерфейса является то, что если COM-объект заявляет о существовании у него определенного интерфейса, то объявленный интерфейс должен обязательно поддерживаться внутренними методами объекта и возвращать какие-либо значения, пусть хотя бы банальное сообщение об ошибке.
Интерфейсы могут наследоваться - дочерний интерфейс должен включать все методы своего предка. Все существующие интерфейсы наследуются от базового интерфейса IUnknown.
Следует указать еще на два правила, соблюдение которых необходимо при проектировании COM-объекта:
Единожды опубликованный интерфейс не может быть изменен. При необходимости дополнить существующий интерфейс новыми функциональными возможностями следует создать новый интерфейс. Выполнение этого правила гарантирует, что запрашивающее конкретный интерфейс клиентское приложение получит именно то, на что оно рассчитывает.
В рамках отдельной системы каждый интерфейс должен иметь уникальный идентификатор GUID и название, начинающееся с символа «I».
4.3.1.5. Порядок вызова сервера клиентским приложением
Для того чтобы модель COM начала функционировать, клиентское приложение должно отправить запрос на услуги COM-сервера. Каким образом клиентское приложение получит доступ к интересующему его COM-серверу? В особенности если COM-клиент работает в другом адресном пространстве? Ответ на эти вопросы надо искать в системном реестре Windows.
ё
Рис. 8. Порядок обращения клиента к серверу
Во время установки COM-приложения в реестр операционной системы вносится информация об имеющихся в наличии COM-объектах. В первую очередь это идентификатор, однозначно определяющий класс объекта (Class Identifier, CLSID). Идентификаторы классов хранятся в следующей ветви реестра Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Имя_клacca\CLSID\
Аналогичные данные можно найти и в ветви HKEY_CLASSES_ROOT. Кроме того, в реестре хранится имя модуля, содержащего сервер, или сетевой адрес, если сервер выполняется на другой машине.
Идентификатор CLSID - это разновидность уже встречавшихся ранее глобальных уникальных идентификаторов (Global Unique Identifier, GUID). Это уникальное 128- битное число, применяемое для идентификации интерфейсов, объектов и классов. Уникальность достигается за счет использования оригинального алгоритма генерации числа, обеспечиваемого функцией Win32 API CoCreateGuid().
В процессе запуска COM-объекта непосредственное участие принимает системная библиотека COM. На рис. 8 схематично представлена последовательность действий клиента, библиотеки и сервера COM при создании первого экземпляра COM-объекта.
4.3.2. СОМ - ориентированные технологии
Под термином «СОМ-ориентированные технологии» (COM-based) подразумевается набор разнообразных программных технологий, опирающихся на модель COM как на некий фундамент (Рис. 9). В этот набор входит широкий спектр технологий корпорации Microsoft:
а) серверы и клиенты COM;
б) программные компоненты (элементы управления) ActiveX и автоматизация (Automation) в виде OLE-automation;
в) связывание и внедрение объектов (OLE - Object Linking and Embedding);
г) технология COM+ (включая сервер транзакций Microsoft (MTS - Microsoft Transaction Server) и служба очередей сообщений Microsoft (MSMQ - Microsoft Message Queue));
д) распределенная модель компонентных объектов (DCOM - Distributed COM).
е) расширения графической библиотеки DirectX, широко используемой при разработке приложений, связанных с динамической компьютерной графикой, например, игр;
ж) Технологии доступа к данным в БД OLE DB (базовая упрощенная спецификация COM и интерфейс API для доступа к данным) и ADO (ActiveX Data Objects - объекты данных ActiveX).
Рис. 9. COM-технологии
Дадим характеристику основным технологиям из приведенного выше списка, применяемым при создании информационных систем электронного документооборота.
4.3.2.1. DCOM
СОМ - объекты могут быть реализованы в любом файле .exe или .dll. При этом реализация объекта остается для пользователя объекта совершенно прозрачной благодаря предлагаемому COM - сервису, называемому маршалингом (marshalling).
Механизм маршалинга COM берет на себя всю организацию взаимного вызова функций между независимыми процессами и даже различными компьютерами, вследствие чего становится возможным, например, использование 32-разрядных объектов в 16-разрядных приложениях, а также доступ к объекту, расположенному на компьютере А, из приложения, запущенного на компьютере Б. Такое межкомпьютерное взаимодействие называется распределенной моделью компонентных объектов - Distributed COM, или DCOM.
4.3.2.2. COM+
COM+ - это, фактически, обычная спецификация COM, внутри которой реализованы некоторые дополнительные COM - ориентированные службы Microsoft. Другими словами, COM+ - это COM с некоторыми дополнениями, связанными с сервером транзакций Microsoft (MTS - Microsoft Transaction Server) и очередью сообщений Microsoft (MSMQ - Microsoft Message Queue).
Интеграция этих технологий со стандартными средствами COM означает, что все разработчики COM+ смогут воспользоваться преимуществами этих средств, например:
а) управление транзакциями;
б) поддержка безопасности;
в) удаленное администрирование;
г) обслуживание очереди компонентов;
Спецификация COM+ полностью совместима с COM, и работа с ней в Delphi нисколько не сложнее работы с COM. Все возможности COM+ доступны разработчикам Delphi в полном объеме.
Поскольку модель COM+ состоит в основном из имеющихся в наличии частей, то это означает полную обратную совместимость, в результате которой все существующие приложения COM автоматически становятся приложениями COM+.
При работе с COM+ ключевую роль выполняют транзакции. Для их управления и администрирования служит сервер транзакций Microsoft (MTS). Транзакция представляет собой совокупность программных команд, которая либо выполняется полностью от начала и до конца, либо не выполняется вообще. Без поддержки транзакций объекты из коллекций не смогли бы взаимодействовать со сложными коммерческими приложениями. Например, в обработке транзакции, которая открывается при интерактивной покупке какого-либо товара, принимают участие несколько объектов, связанных с одной или несколькими базами данных. Эти объекты отвечают за прием запроса, проверку наличия товара, определение остатка денег на кредитной карточке, обновление данных по счету и оформление заказа. Причем все указанные действия должны быть согласованы. В противном случае может возникнуть сбой в процессе покупки, в результате чего все объекты и данные должны быть возвращены в состояние, которое они имели до начала транзакции. Если при этом, кроме всего прочего, объекты находятся на множестве различных компьютеров, то процесс управления еще более усложняется.
В основе компонентов для работы с очередями (queued components) лежит технология очереди сообщений Microsoft (MSMQ — Microsoft Message Queue), которая предоставляет клиентам COM+ возможность асинхронного вызова методов компонентов сервера COM+. По существу это означает, что клиенты могут создавать экземпляры серверных объектов и вызывать их методы независимо от того, доступен сервер или нет. Средства COM+ осуществляют управление этим процессом, размещая вызовы методов в очереди, а непосредственное выполнение этих методов происходит в дальнейшем при восстановлении подключения к серверу. Серверным объектам фактически «безразлично», вызываются ли их методы непосредственно или через очередь COM+.
4.3.2.3. OLE
Появившаяся еще в ранних версиях Windows технология связывания и внедрения объектов (OLE, Object Link and Embedding) произвела настоящий фурор в кругах пользователей. Тем более, что сама идея (обмен данными между приложениями и предоставление служб одного программного продукта другому) в те времена была просто революционной. Теперь какой-либо объект (например, файл мультимедиа), подготовленный сторонним приложением, может быть использован другим программным продуктом или даже внедрен в состав его документа. Причем приложение- получатель услуг OLE не обязано знать, каким образом был создан внедренный в него объект, и уж тем более вникать в особенности его работы. Единственная обязанность приложения - иметь представление об элементарных методах современной версии OLE - OLE 2.0.
Главное действующее лицо технологии OLE - OLE-объект (OLE object). Это совокупность данных, которые совместно используются несколькими приложениями. Объекты могут внедряться в документы (вспомните пункт меню Вставка - Объект текстового процессора Microsoft Word).
Документ, содержащий OLE-объекты, называют составным документом (compound document).
Приложения, способные содержать OLE-объект, называются OLE- контейнерами (OLE container).
Приложения, способные создавать собственные OLE-объекты, именуют OLE-серверами (OLE server).
Как следует из названия технологии, объект OLE может быть связан (linked) или внедрен (embedded) в составной документ.
Связанные объекты сохраняются в отдельном файле на диске. Благодаря средствам связывания объектов несколько контейнеров - или даже приложение-сервер - могут быть связаны с одним и тем же объектом OLE, расположенным на диске. Если одно из приложений модифицирует связанный объект, внесенные изменения распространяется на все приложения, связанные с данным объектом.
Внедренные объекты хранятся непосредственно в приложениях, являющихся контейнерами OLE. Только контейнерное приложение будет способно осуществлять редактирование внедренного объекта OLE. Внедрение не позволяет другим приложениям осуществлять доступ к импортированным данным (а следовательно, модифицировать или разрушать их), но это существенно усложняет управление данными, помещенными в контейнер.
Одно из основных различий между объектами OLE, ассоциированными с 16- разрядными серверами OLE 1 и с 32- разрядными серверами OLE 2, заключается в способе их активизации. Когда активизируется объект, созданный для сервера OLE 1, запускается и получает фокус ввода приложение-сервер, а объект OLE появляется в нем в готовом для редактирования виде. Когда активизируется объект OLE 2, приложение-сервер OLE 2 становится активным неявно, "внутри" приложения-контейнера. Это называется активизацией по месту вставки (in-place activation), или визуальным редактированием (visual editing).
При активизации объекта OLE 2 меню и панели инструментов приложения- сервера заменяются или сливаются с соответствующими элементами приложения- клиента, а часть окна приложения-клиента, по сути, становится окном приложения- сервера.