Страница 175 из 372
• Бинарное представление
Как уже отмечалось ранее, компоненты распространяются и используются в бинарном виде, т. е. в виде "черного ящика". Это позволяет решить многие проблемы, упомянутые ранее при описании недостатков ООП, и, кроме того, дает новые возможности. Например, использование различных языков программирования при реализации компонентов и использующих их клиентов.
• Инфраструктура для распределенных приложений
Многое из этой области включается в саму архитектуру системы, реализующей технологию компонентного программирования, многое обеспечивается в виде дополнительных сервисов.
Например, в случае СОМ, при размещении компонента и клиента в различных процессах (на одном или на разных компьютерах), автоматически формируется канал передачи данных, который обеспечивает вызов методов, передачу параметров и возврат результатов. В качестве примера дополнительных сервисов, реализованных в СОМ+, можно упомянуть обеспечение таких важных для распределенного приложения сервисов как безопасность, транзакции, балансировка загрузки серверов, асинхронный доступ к компонентам, поддержка публикации и подписки на события и т. п.
Эволюция распределенных систем
Коротко напомним напомним эволюцию, которую претерпели распределенные системы:
• Одноуровневая система
Все пользователи работают на терминалах, подключенных к одному компьютеру. Если кто-то запустил задачу, требующую много процессорного времени, все остальные пользователи это сразу же замечают.
• Локальная вычислительная сеть персональных компьютеров
Пользователи работают на персональных машинах и совместно используют файловый сервер, принтер.
• Архитектура клиент/сервер
Это так называемая двухзвенная архитектура. Сервер (например, баз данных) ожидает запросы клиентов (например, выраженные на SQL), обрабатывает запрос и возвращает результат клиенту. Клиенты работают с сервером независимо. Целостность данных обеспечивается механизмом транзакций.
Еще один пример системы с такой архитектурой — поисковые системы типа Alta Vista, Google, Yandex. В отличие от традиционных клиентов для работы с сервером баз данных (как правило, "толстых" клиентов, требующих специальной процедуры установки на машине пользователя), упомянутые поисковые системы работают с "тонким" клиентом, например, с браузером Internet Explorer, не зависящим от конкретного приложения.
Однако, в поисковых системах заранее фиксирована так называемая бизнес-логика, что и позволяет обойтись тонким клиентом. В более сложных случаях приложений на уровне предприятий в рамках архитектуры клиент/сервер используются толстые клиенты, реализующие бизнез-логику конкретного рабочего места.
• Трехзвенная архитектура клиент/бизнес-логика/данные
Это современная архитектура, в которой бизнес-логика отделена от клиента и от данных. Отделение бизнес-логики от клиента позволяет использовать тонких клиентов для работы со сложными приложениями, что весьма актуально, т. к. в этом случае пользователи могут подключаться к системе через Интернет. Хранилища совместно используемых данных тоже не являются подходящими средами для реализации бизнес-логики. Это часто наследуемые системы, не поддерживающие современные технологии. Отсюда логически вытекает необходимость отдельной реализации бизнес-логики, и компонентное программирование может служить подходящей технологией для ее реализации.
• Web сервисы
Это новая перспективная архитектура, обеспечивающая распределенность на новом уровне. Вместо покупки компонентов и их встраивания в приложение предлагается покупать время их работы и формировать приложение, осуществляющее вызовы методов из компонентов, принадлежащих и поддерживаемых независимыми владельцами. Очевидно, что при реальном использовании такой архитектуры возникнет много новых вопросов, например, связанных с надежностью. Вряд ли система управления большим и сложным объектом будет основана на этой архитектуре. Но различные информационные системы являются примерами систем, которые будут проектироваться с использованием 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 означает, что параметры метода заносятся в стек в порядке справа налево и перед возвратом функция удаляет из стека свои параметры.