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

Здесь стоит отметить, что роль интерфейсов в СОМ значительно более важная, чем роль посредника. Все в СОМ начинается с интерфейсов. Они определяются первыми и задают семантику некоторого сервиса. Различные классы могут реализовывать заданный интерфейс, обеспечивая тем самым полиморфизм на новом уровне.

Имеются различные технологии, реализующие парадигму компонентного программирования. Среди них COM (DCOM, СОМ+), С ORB A, Net.

Для определенности остановимся на подходе, используемом в СОМ.

Компонент — это хранилище (в виде DLL или EXE файла) для одного или нескольких классов. Все, что знает клиент о классе, это его уникальный идентификатор и один или несколько интерфейсов, обеспечивающих доступ к реализованным данным классом методам. Допускается реализация компонента и использующего его клиента на различных языках (Visual C++, Visual Basic). В реестре системы хранится информация о местоположении компонента, содержащего данный класс (на локальном или удаленном компьютере). Это позволяет системе прозрачно для клиента перенаправлять вызовы методов к нужному компоненту и возвращать результаты.

Таким образом, обеспечивается выполнение двух важных принципов компонентного программирования:

• независимость от языка программирования,

Основные особенности компонентного программирования можно коротко охарактеризовать следующим образом:

• Инкапсуляция

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

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

• Наследование интерфейсов

В отличие от ООП, технология компонентного программирования не поддерживает наследование реализации класса. Наследуются только интерфейсы. Каждый интерфейс получает свой уникальный идентификатор и может реализовываться в различных классах, включаемых в различные компоненты. Новый интерфейс может наследовать ранее описанным интерфейсам. Например, в СОМ, любой интерфейс должен наследовать стандартному интерфейсу IUnknown. Наследование интерфейса в частности означает, что при реализации методов нового интерфейса будут реализованы и все методы, описанные в наследуемом интерфейсе.

А как же быть с идеей повторного использования кода? В рамках технологии компонентного программирования разработчик нового компонента не использует исходный код ранее реализованного компонента. Но он (разработчик) может добавить функциональность старого компонента к функциональности нового. Это делается с помощью одного из двух методов:

♦ Контейнеризация

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

♦ Агрегация

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

• Полиморфизм

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

• Бинарное представление

Как уже отмечалось ранее, компоненты распространяются и используются в бинарном виде, т. е. в виде "черного ящика". Это позволяет решить многие проблемы, упомянутые ранее при описании недостатков ООП, и, кроме того, дает новые возможности. Например, использование различных языков программирования при реализации компонентов и использующих их клиентов.

• Инфраструктура для распределенных приложений

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

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

Эволюция распределенных систем

Коротко напомним напомним эволюцию, которую претерпели распределенные системы:

• Одноуровневая система

Все пользователи работают на терминалах, подключенных к одному компьютеру. Если кто-то запустил задачу, требующую много процессорного времени, все остальные пользователи это сразу же замечают.

• Локальная вычислительная сеть персональных компьютеров

Пользователи работают на персональных машинах и совместно используют файловый сервер, принтер.

• Архитектура клиент/сервер

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

Еще один пример системы с такой архитектурой — поисковые системы типа Alta Vista, Google, Yandex. В отличие от традиционных клиентов для работы с сервером баз данных (как правило, "толстых" клиентов, требующих специальной процедуры установки на машине пользователя), упомянутые поисковые системы работают с "тонким" клиентом, например, с браузером Internet Explorer, не зависящим от конкретного приложения.

Однако, в поисковых системах заранее фиксирована так называемая бизнес-логика, что и позволяет обойтись тонким клиентом. В более сложных случаях приложений на уровне предприятий в рамках архитектуры клиент/сервер используются толстые клиенты, реализующие бизнез-логику конкретного рабочего места.

• Трехзвенная архитектура клиент/бизнес-логика/данные

Это современная архитектура, в которой бизнес-логика отделена от клиента и от данных. Отделение бизнес-логики от клиента позволяет использовать тонких клиентов для работы со сложными приложениями, что весьма актуально, т. к. в этом случае пользователи могут подключаться к системе через Интернет. Хранилища совместно используемых данных тоже не являются подходящими средами для реализации бизнес-логики. Это часто наследуемые системы, не поддерживающие современные технологии. Отсюда логически вытекает необходимость отдельной реализации бизнес-логики, и компонентное программирование может служить подходящей технологией для ее реализации.

• Web сервисы

Это новая перспективная архитектура, обеспечивающая распределенность на новом уровне. Вместо покупки компонентов и их встраивания в приложение предлагается покупать время их работы и формировать приложение,