Интернет-журнал 'Домашняя лаборатория', 2007 №6 - Вязовский

осуществляющее вызовы методов из компонентов, принадлежащих и поддерживаемых независимыми владельцами. Очевидно, что при реальном использовании такой архитектуры возникнет много новых вопросов, например, связанных с надежностью. Вряд ли система управления большим и сложным объектом будет основана на этой архитектуре. Но различные информационные системы являются примерами систем, которые будут проектироваться с использованием Web сервисов. Данная технология обеспечит невиданный ранее уровень повторного использования компонентов, что и гарантирует ее развитие. Система .Net от Microsoft предоставляет технологию для разработки и использования Web сервисов.

Технология COM (Component Object Model — компонентная объектная модель) от Microsoft

Перепишем приложение о книгах и журналах, используя идеологию модели СОМ — Component Object Model от Microsoft. Изложение основ этой модели будет проведено на примерах.

Интерфейсы

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

Часто базовую архитектуру СОМ определяют с помощью следующей формулы

Базовая архитектура СОМ = сервер/класс/интерфейс/метод

Компонент реализуется в виде сервера (одного из трех видов). Сервер является хранилищем для одного или нескольких классов. Каждый класс реализует один или несколько интерфейсов.

Каждый интерфейс определяет один или несколько методов и обязательно наследует от стандартного интерфейса IUnknown (прямо или косвенно).

Определим вначале абстрактный базовый интерфейс IPub (публикация), от которого далее будут порождены интерфейсы IBook и IJournal (книга и журнал). Здесь надо отметить, что в СОМ нет множественного наследования интерфейсов и каждый пользовательский интерфейс должен порождаться от какого-либо другого интерфейса (хотя бы от IUnknown). Определение этого интерфейса IPub в виде заголовочного файла для C++ (IPub.h) приводится ниже.

// IPub.h — Базовый интерфейс публикации IPub

#ifndef _IPub_

#define _IPub_

#include <windows.h> // содержит все нужное для COM

DECLARE_INT E RFAC E_(IPub, IUnknown)

{

            STDMETHOD(SetTitle)(BSTR bstrTitle) PURE;

            STDMETHOD(SetYear)(int nYear) PURE;

            STDMETHOD(Getlnfo)(BSTR * pbstrlnfo) PURE;

};

#endif

В данном примере определен интерфейс IPub, наследуемый от стандартного интерфейса IUnknown. В интерфейсе IPub определены 3 метода:

• SetTitle — задание названия публикации,

• SetYear — задание года публикации

• Getinfo — получение информации о публикации.

При описании как самого интерфейса, так и входящих в него методов использованы следующие макросы:

#define DECLARE_INTERFACE_(ifасе, baseiface)

          interface iface: public baseiface

#define STDMETHOD(method) virtual HRESULT stdcall method

#define PURE = 0

Таким образом,

DECLARE_INTERFACE_(IPub, IUnknown)

означает, что IPub есть интерфейс (то же что и struct в С), порожденный от IUnknown, а

STDMETHOD(SetTitle)(BSTR bstrTitle) PURE

означает, что чисто виртуальный метод SetTitle возвращает стандартную для СОМ величину типа HRESULT — 32-битное значение, позволяющее определить успешно или нет прошел вызов метода, и, в случае неуспеха, где произошла и какая ошибка. Очевидно, что возможность анализа ошибок очень важна в распределенных приложениях. При этом _stdcall означает, что параметры метода заносятся в стек в порядке справа налево и перед возвратом функция удаляет из стека свои параметры.

При определении интерфейсов всегда используются чисто виртуальные функции. Это означает, что не существует реализации интерфейса. Это только контракт, никак не ограничивающий конкретную реализацию. Для использования данного интерфейса нужно определить класс, наследующий этот интерфейс (и, возможно, другие интерфейсы), и уже реализовать этот класс.

Известно, что в разных языках программирования строки организованы различным образом. В СОМ выбрано представление строки, позволяющее работать с ним в программах, написанных на различных языках. Переменная типа BSTR (BASIC String) есть строка, представленная в формате Unicode (2 байта на один символ), с завершающим нулем и с префиксом (4 байта), хранящим длину строки (что позволяет сохранять внутри строки нулевые символы). Имеется ряд функций, облегчающих работу с такими строками (которые для C++ будут продемонстрированы в последующих примерах).

И, наконец, напомним, что в реализации данного примера средствами ООП в описании класса CPublication имелся метод Display, который обеспечивал вывод информации о публикации на терминал.

В данном случае мы описываем интерфейсы, которые будут реализованы в классах, размещенных на сервере. Размещение самого сервера для клиента прозрачно — это может быть сервер в процессе клиента, или другой процесс на этой же машине, или процесс на удаленном компьютере. В этих условиях методы интерфейса не должны выполнять вывод на терминал, а должны возвращать результаты своей работы клиенту через параметры. В связи с этим здесь используется метод GetInfо, семантика которого — возвращение клиенту строки с полным описанием публикации.

Теперь определим интерфейс IBook, производный от IPub.

// IBook.h — интерфейс книги IBook

#ifndef _IBook_

#define _IBook_

#include "IPub.h" // IPub

DECLARE_INTERFACE_(IBook, IPub)

{

              STDMETHOD(SetAuthor)(BSTR bstrAuthor) PURE;

};

#endif

Здесь просто добавляется новый метод SetAuthor, позволяющий задавать имя автора книги, которого, в общем случае, могло и не быть у публикации.

Аналогично определяется интерфейс IJournal, также производный от IPub, расширяющий последний методом SetNumber — задание номера журнала.

// IJournal.h — интерфейс журнала IJournal

#ifndef _IJournal_

#define _IJournal_

#include "IPub.h" // IPub

DEC LARE_INT E RFAC E_(IJournal, IPub)

{

               STDMETHOD(SetNumber)(int nNumber) PURE;

};

#endif

В рамках модели COM каждый интерфейс должен иметь уникальный в пространстве и времени идентификатор — IID (Interface IDentifier). Идентификатор генерируется и присваивается интерфейсу при его создании и более никогда не меняется. Все реализации данного интерфейса должны использовать этот идентификатор. Пользователи обращаются к данному интерфейсу по его идентификатору. Все это позволяет не беспокоиться по поводу присваивания одного и того же имени различными разработчиками различным интерфейсам.

Существует спецификация DCE (Distributed Computing Environment — распределенная среда вычислений) от Open Software Foundation, котрая определяет UUID — Universally Unique IDentifiers (универсально уникальные идентификаторы). Эти идентификаторы формируются на основе сетевого адреса машины и точного времени, что и обеспечивает их уникальность. В СОМ эти идентификаторы получили название GUID — Globally Unique IDentifiers (глобально уникальные идентификаторы). Каждый такой идентификатор представляется 128-битным числом. В связи с тем, что не все языки программирования, поддерживающие СОМ, могут оперировать с такими большими числами, для хранения GUID используется следующая структура

typedef struct _GUID