Лаврищева Е.М., Грищенко В.Н. Сборочное программирование. Основы индустрии программных продуктов

Подождите немного. Документ загружается.

141

– механизмов обеспечения повторного использования;

– среды развертки компонентов;

– сервиса, поддерживаемого компонентом;

– ролей, которые выполняют компоненты в системе;

– формализованных языков описания КПИ.

Применение КПИ проводится по такой технологии:

– отображение способности КПИ анализировать себя и динамически

выполняться, т.е. управлять свойствами, событиями и методами, встроенными в

него;

– стандартизированное описание для анализа и понимания его другим лицом, а

не разработчиком;

– трансформация с возможным изменением структуры и исходного кода и с

сохранением функций;

– сохранение параметров конфигурации в постоянной памяти для повторного

использования;

– регистрация сообщений о событиях, полученных от других объектов через

механизм ссылок (например, EJB-компоненты в JAVA),

– каталогизация КПИ в архивы (например, JAR-файлы) для дальнейшего

повторного использования;

– адаптация КПИ к разным контекстам и средам использования, выделение

свойств, которые мешают повторному их применению и модификации.

Репозитарий компонентов КПИ

КПИ и другие самостоятельные компоненты многоразового использования

размещают в разных хранилищах. Ими могут быть библиотеки, репозитарии

компонентов и ресурсов в Интернете (например, GreedStone, Matlab, библиотека

классов С++ и др.).

Компоненты этих хранилищ используют много раз все желающие для

реализации своих целей, в частности при построении ПС различного назначения.

Репозитарий типа библиотеки GreenStone или Matlab предоставляет готовые

программы научного, в частности математического, типа. Они ориентированны на

математиков, физиков и других специалистов предметных областей.

В общем случае репозитарий – это система средств для хранения, пополнения

наработанных КПИ, которая содержит инфраструктуру разработки ПС из

компонентов, организацию доступа к КПИ из хранилища для дальнейшего

использования в новых программных проектах.

С функциональной точки зрения репозитарий работает по принципу

информационно-поисковой системы, объектами хранения которой есть различные

типы документов, текстов и др. Система ставит запрос пользователя в

соответствие ключевым понятиям, словам, правилам доступа, которые содержат

коллекции документов.

Разделы репозитария могут содержать:

– готовые функциональные компоненты, КПИ;

– средства безопасности, защиты и изменений для КПИ;

– терминологию специфики представителей семейства ПС;

– средства взаимодействия, синхронизации компонентов;

– новые члены семейства ПС;

142

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

В отличие от систем поиска информации в репозитарии компонентов, кроме

КПИ, размещается семантическая информация в виде поискового образа,

созданного на основе описания информационной модели каждого компонента. Эта

модель–средство построения поискового образа для каталога КПИ,

ориентированного на осмысление человеком функций КПИ и возможности их

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

Поисковый образ готовых компонентов в репозитарии может содержать:

– список ключевых слов, которые чаще всего упоминаются в тексте КПИ;

– ссылки на онтологию домена проблемной области, которой этот КПИ

принадлежит.

Информационную потребность в КПИ формулирует пользователь в виде

поискового запроса, который сопоставляют с описанием поискового образа КПИ в

репозитарии. Поиск КПИ по заданному запросу выполняют до тех пор, пока не

будет найден нужный КПИ или, наоборот, пользователем будет получает

большое количество релевантных данному запросу компонентов для отбора

нужных. При рассмотрении этих компонентов используется онтологическая,

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

каждого КПИ с унифицированной терминологией, ключевыми словами и т.п.

Информационная модель КПИ обеспечивает хранение, поиск и сопоставление

КПИ. Репозитарий разделен на разделы согласно ПрО, перечень которых

находится на первом уровне репозитария, на следующих – отдельные понятия

ПрО. Разделы репозитария заполняют согласно проведенной типизации и

классификации компонентов и КПИ.

Информационная модель поискового образа упрощает поиск необходимых

КПИ и сокращает сроки разработки ПС за счет:

– отображения базовых функций и понятий компонента;

– засекречивания представления данных, операций обновления и получения

доступа к этим данным;

– обработки исключительных ситуаций, которые происходят в процессе

выполнения и др.

5.3. ИНФОРМАЦИОННЫЕ РЕСУРСЫ (ИР). КЛАССИФИКАЦИЯ И

ТИПИЗАЦИЯ

Информационный ресурс – это логически упорядоченная совокупность данных и

средств их представления, обеспечивает создание, хранение и использование

информации об определенных предметных и проблемных областях, отдельных

аспектах и свойствах, коллекциях объектов данных, количественных и

качественных характеристик и показателей и т.п.

Это определение носит обобщенный характер и обеспечивает широкий спектр

интерпретации ресурсов для сложных информационно-вычислительных систем.

Главное назначение ресурса – предоставление информации клиенту по его

запросу. Механизмы создания, формирования данных, а также хранения и

представления ресурсов носит произвольный характер. Главное – получить ответ на

запрос ресурса. В частности, ресурсом может быть прикладная программа, которая

генерирует выходную информацию, воспринимающая извне как данные ресурса.

143

Классификация ИР – совокупность принципов типизации и упорядочения

множества информационных ресурсов соответственно их функциональности,

методов и средств представления, алгоритмов, схем и механизмов получения

данных, доступа к информации. Согласно приведенного определения,

классификаций информационных ресурсов существует довольно много. Наиболее

распространенные строятся по таким признакам:

– типизация объектов данных (документы, таблицы, коллекции и т.п.);

– структурные признаки (файлы, каталоги, разделы и т.д.);

– методы формирования (базы данных, веб-сайты, прикладные программы и

приложения и т.п.).

Тип ИР определяет класс информационных ресурсов, заданный конкретными

значениями классификационных признаков относительно их определенной

классификации. Типизация информационных ресурсов определяет методы и

механизмы реализации ресурса, представление информации, а также доступа к

ней. Пример – реляционные БД, где представление данных осуществляется на

основе реляционной модели, механизмом реализации ресурса является

реляционная СУБД, а методами доступа к информации – язык SQL.

Другим примером может быть файл данных в формате XML, основанный на

языке разметки XML. Средством создания XML-файла является соответствующий

генератор или редактор XML-данных, а механизмы доступа построены на

специальных средствах, которые называются парсерами.

Типизация ИР заключается в унификации и стандартизации методов создания,

представления и использования данных для определенного подмножества ИР

согласно их функциональной сущности, техническим и технологическим

особенностям.

Менеджер ИР – программный объект информационно-вычислительной

системы, который обеспечивает управление и применение соответствующего

информационного ресурса на основе стандартизированных правил и механизмов

доступа к данным ресурса. Менеджер ИР по сути – это оболочка ресурса,

реализующая стандартизованные интерфейсы для обеспечения процессов

интеграции.

Тип менеджера ИР – класс программных объектов, который определяется

совокупностью унифицированных и стандартизованных методов применения и

доступа к ресурсам определенного типа. В частном случае конкретный тип может

состоять только из одного экземпляра. Такая ситуация бывает, когда в состав

интегрированной среды включена существующая система, которая создана на

старых платформах и ЯП. В этом случае разрабатывается менеджер ресурсов для

обеспечения взаимодействия только с такой системой.

Главная цель типизации менеджеров ИР состоит в упорядочении и унификации

всех интерфейсов, которые соединяют менеджера с определенным классом ИР и с

интегрированной средой. Пример типизации – это менеджер работы с XML-

файлами в ОО программной системе. Такой менеджер взаимодействует с ресурсом

на основе методов и средств языка XML. Со стороны интегрированной среды

существует требование представления данных ресурса как отдельных объектов.

Поэтому менеджер выбирает из XML-файла данные и подает в виде объектов,

например, на основе DOM-модели.

144

5.3.1. ТИПОВАЯ СХЕМА СВЯЗИ С МЕНЕДЖЕРОМ ИР

Типовая схема соединения интегрированной среды с менеджером ИР представлена

на рис.5.3.

Унифицированный запрос к менеджеру ресурса отображает структуру запроса со

стороны интегрированной среды к менеджерам ресурсов определенного типа. При

компонентной ориентации унифицированный запрос – это обращение к методу из

входного интерфейса компонента–менеджера ресурса.

Типизированный запрос имеет структуру, которую непосредственно понимает

конкретный ИР. Одна из функций менеджера ИР – трансформация

унифицированного запроса в один или в последовательность типизированных

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

информацию из ресурса. Например, унифицированный запрос к БД

трансформируется в SQL-запрос для получения информации из реляционной БД.

Реализация механизма типизированного запроса в целом может отличаться от

механизма компонентного взаимодействия. Этот факт рассматривается как

внутренний аспект в концепции представления менеджера ресурсов как

обобщенного интерфейса, который инкапсулирует внутренние особенности

реализации.

Ответ на типизированный запрос определяется структурой данных, которую

формирует ИР согласно своей функциональности. Например, результат обработки

SQL-запрос к БД подается в табличной форме (в случае, если ресурс содержит

необходимую информацию).

Ответ на унифицированный запрос – структура данных, стандартизированная для

определенной интегрированной среды, как типичный ответ для менеджера ресурсов.

Например, таблица из предыдущего примера может оставаться без изменений или

трансформироваться в XML-структуру данных, или быть представлена как HTML-

страница и т.п. Механизм реализации ответа на унифицированный запрос – это

составляющая механизма компонентного взаимодействия.

Проведем сравнительный анализ между схемой, которая приведена на рис.5. 3,

и компонентной средой. Основу последнего составляет компонентный framework,

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

между собой, а также совокупность компонентных сервисов. Между компонентами

и компонентным framework существуют стандартизированные механизмы

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

Как следствие, сервера интеграции – это компонентные серверы, а общесистемные

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

компонентов. Менеджер ресурсов – компонент, который независим от методов

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

компонентной основе, так и на произвольной платформе).

Типичная процедура включения ресурса в интегрированную среду содержит

следующие процессы:

– развертывание менеджера на одном из компонентных серверов согласно

общим правилам развертывания компонентов;

– организация взаимодействия менеджера с ресурсом с учетом особенностей

последнего (выбор адаптера или драйвера, связь с местонахождением ресурса и

т.п.);

– конфигурирование менеджера в компонентной среде для обеспечения доступа

145

к нему со стороны других компонентов.

5.3.2. ТИПОВОСТЬ СТРУКТУРЫ И ИНТЕРФЕЙСА МЕНЕДЖЕРА ИР

Менеджер ИР – это подсистема, которая состоит из нескольких компонентов

(рис.5.3), в которую входят следующие:

– контейнер, создающий и обеспечивающий управление вариантами

соединений с ИР;

– интерфейсы с ИР, которые обеспечивают реализацию функциональности

доступа к ресурсу;

– компонент управления взаимодействием для определенного соединения;

– адаптер доступа к ресурсу;

– дескриптор ИР, который является информационной базой для создания

соединения и организации взаимодействия.

Рис.5.3. Типовая структура менеджера ИР

Роли и функциональность между компонентами менеджера ресурсов

распределены следующим образом. Дескриптор ИР является информационной

базой, которая поддерживает функционирование самого ресурса и его менеджера

на протяжении всего ЖЦ. В частности, она содержит такую информацию:

– описание параметров развертывания менеджера как компонента;

– описание местонахождения или адреса ресурса, а также параметров доступа к

нему;

– тип и характеристики менеджера ресурса;

– описание интерфейсов, методов, структур входных и выходных параметров;

– фрагменты документации менеджера и информационного ресурса.

Менеджер как типовой выступает в качестве контейнера экземпляров, каждый

из которых является реализацией определенного соединения с ресурсом. Экземпляр

создается во время инициации соединения и существует до вызова метода

завершения соединения с ресурсом.

Экземпляр соединения состоит из нескольких компонентов, типовыми из

которых есть компонент управления взаимодействием с ресурсом и адаптер ИР.

Компонент управления взаимодействием с ресурсом обеспечивает реализацию

входного интерфейса менеджера ресурсов, который определяет функциональность

процедур доступа к ресурсу. К его функциям, в частности, относят:

146

– преобразование входных параметров унифицированного запроса к менеджеру

в структуры данных адаптера ресурса;

– организация взаимодействия с адаптером ресурса;

– преобразование результатов выполнения запроса в структуры данных для

выходных параметров.

В частном случае этот компонент может отсутствовать, если входные

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

и воспринимаются адаптером ресурса непосредственно.

Адаптер ресурса взаимодействует с ИР соответственно механизмам доступа,

реализованных в средствах управления ресурсом, например, средствах СУБД для

доступа к БД.

Интерфейсы менеджера ИР. В компонентной структуре взаимодействие между

всеми компонентами происходит с помощью интерфейсов. Поскольку менеджер ИР

также представляется как компонент, то его функциональность рассматривается как

реализация определенных интерфейсов.

Согласно общей архитектуре основными функциями и принципами построения

функциональности менеджера ИР является реализация определенной совокупности

типовых интерфейсов, обеспечивающих:

– соединение с менеджером ИР;

– взаимодействие с менеджером;

– представление данных.

Интерфейс соединения с менеджером ИР – это интерфейс контейнера

соединений согласно типовой структуре менеджера. Он обеспечивает реализацию

следующих основных типовых функций:

– поиск необходимого менеджера в интегрированной среде;

– создание экземпляра соединения для менеджера (одновременно с менеджером

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

обращений к нему);

– установка системных контрактов, в частности, для поддержки транзакций и

безопасности.

Интерфейс обеспечения взаимодействия с менеджером – это прикладной

интерфейс, который реализует экземпляр соединения и выполняет такие типовые

функции:

– получение информации об описании экземпляра соединения, в частности

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

ресурса;

– обращение к методам для получения необходимых данных из ИР.

Интерфейс представления данных – это прикладной интерфейс, он реализует

экземпляр соединения и осуществляет:

– формирование типовых структур данных для информации, полученной из

ресурса;

– преобразование между разными структурами данных и их представлением;

– операции с дескрипторами и метаданными для типовых структур данных.

Для отдельных или разных реализаций ПС концепция интеграции на основе

менеджеров ресурсов может существовать с другими свойственными им

интерфейсами.

147

5.3.3. АСПЕКТЫ ПРИМЕНЕНИЯ МЕНЕДЖЕРА ИР

Сущность концепции построения ПС на основе интеграции менеджеров ресурсов

состоит в том, что разработчик отдельной программы или подсистемы вместе со

средствами, которые непосредственно реализуют основную функциональность,

создает специальный программный элемент - менеджер ресурсов, с помощью

которого и происходит взаимодействие.

На свойства менеджера ресурсов влияют много факторов, например, основные из

них:

– целевая среда, в рамках которой интегрируются программы и подсистемы;

– механизмы установления соединений и организации взаимодействия;

– наличие типовых и стандартизированных прикладных интерфейсов (API);

– способы и методы представления данных для работы с менеджерами

ресурсов;

– обеспечение поддержки протоколов взаимодействия и общесистемных

сервисов, на основе которых функционирует целевая среда;

– уровень унификации и типизации информационных ресурсов, которые

интегрируются в среду.

В зависимости от выбора основных воздействующих факторов и уровня решения

соответствующих проблем существуют много концепций применения менеджеров

ИР.

Типичным примером архитектурных и структурных решений на основе

применения менеджеров ИР является концепция связи открытых баз данных -

ODBC (Open DataBase Connectivity), позволяющая единообразно обращаться

к ресурсам БД. Данной концепции соответствует стандарт, который определяет

архитектуру и принципы реализации ПС, взаимодействующих с БД в сетевой среде.

В этой архитектуре типовым клиентом является конкретное приложение, которое

с помощью прикладного интерфейса API обращается к специальному менеджеру –

ODBC Driver Manager (рис.5.4). Этот менеджер, являясь типовым элементом,

реализует интерфейс с разными СУБД на уровне типовых функций и структур

данных с учетом конкретной БД. Фактически ODBC Driver Manager вместе с

ODBC-драйвером по сути являются менеджером ресурса для соответствующей БД.

Другой пример подобной архитектуры – концепция JDBC (Java DataBase

Connectivity — соединение с базами данных на Java) — платформенно-

независимый промышленный стандарт взаимодействия Java-приложений с

различными СУБД и основана на драйверах, позволяющих получать

соединение с БД с помощью URL [25, 26, 161, 209].

Провайдеры данных в технологиях OLE DB [209] или ADO.NET [176] также

являются примером менеджеров ресурсов для доступа к БД, документам, файлам и

т.д.

Реализованная с помощью концепции менеджера ресурсов архитектура

коннектора, является составляющей Java-среды J2EE [25]. Основная цель

архитектуры коннектора – обеспечить унифицированный подход к интеграции

различных программных средств и систем на основе типовых механизмов

взаимодействия, стандартных интерфейсов и сервисов, единых методов построения

интегрированных сред. Сфера применения – корпоративные системы, которые

состоят из разнообразных программных средств и объектов, охватывающих

148

существующие корпоративные ИР, созданные в разное время и на разных

платформах (рис.5.4.).

Для каждого ИР необходимо существование специальной подсистемы доступа

к нему, принципы построения и функционирования которой определяются

архитектурой конектора. Спецификация включает в себя также такие понятия, как

ресурс корпоративной информационной системы (EIS Resource), менеджер ресурсов

(Resource Manager), адаптер ресурсов (Resource Adapter), системный и прикладной

контракты (System and Application Contracts) и др.

ODBC-драйвер

СУБД 1

ODBC Driver

Manager

ODBC API

приложение 1

ODBC API

приложение 2

СУБД 2

ODBC-драйвер

СУБД 2

СУБД 1

Рис.5.4. Архитектура ODBC-доступа к БД

Особенностями упомянутой архитектуры является спецификация таких

элементов, как обеспечение условий соответствия адаптера ресурсов требованиям

общих системных сервисов (соединений, транзакций, безопасности), ЖЦ адаптера

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

роботами и др.

Общая схема построения среды на основе интеграции ресурсов корпоративной

системы приведена на рис.5.5. Ядро интеграции – сервер приложений, который

функционирует как J2 EE-сервер. Он построен на основе Java-технологий,

обеспечивающих поддержку стандартных механизмов взаимодействия Java-

объектов и реализацию основных общесистемных сервисов, таких, как именование,

транзакции, безопасность и др. В частности, сервер приложений имеет специальное

расширение, которое поддерживает реализацию определенных API,

обеспечивающих стандартные методы работы с адаптерами ИР.

Кроме того, адаптеры, непосредственно взаимодействующие с ресурсами,

также должны удовлетворять требованиям их интерфейсов и условиям поддержки

общесистемных сервисов. Стандартизация механизмов взаимодействия позволяет

интегрировать одни серверы приложений с несколькими корпоративными ИР, а

также интегрировать определенный ресурс с несколькими J2 EE-серверами.

5.4. ИНТЕГРАЦИЯ МЕНЕДЖЕРОВ РЕСУРСОВ

Существует много реализаций интеграции менеджеров ресурсов в

интегрированных средах. Каждый из них имеет свои особенности, обусловленные

149

решением конкретных задач, выбором базовых объектов для интеграции, способов и

механизмов взаимодействия и т.п. Сфера применения каждого подхода зависит от

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

этого подхода. Реализация концепции ODBC предназначена для решения проблемы

интеграции баз данных, и сфера ее применения полностью определяется целью

создания соответствующей архитектуры (рис.5.5).

Рис.5.5. Общая схема интеграции ресурсов в архитектуре коннектора

Кроме различий в целях и задачах, отдельные подходы к интеграции могут иметь

разные теоретические и методические основы и быть построены с применением

разных моделей и платформ, функционировать на основе разных механизмов и

технологий и т.п. Выше приведены основные факторы, которые влияют на

менеджеров ресурсов на конкретные реализации разных подходов к интеграции.

Детализация воздействия на процесс интеграции факторов и их свойств

определяет конкретный метод интеграции на основе менеджеров ресурсов.

Разнообразие в методах подходов и реализациях создает определенные

трудности при распространении и расширении сферы применения концепции

менеджеров ресурсов и их интеграции. Различные среды интеграции, разные

типы прикладных интерфейсов и правила взаимодействия – все это ограничивает

возможности интеграции разнородных ресурсов. Например, если в состав

конкретной среды входят разные типы серверов интеграции, то для каждого

информационного ресурса должны быть разработаны несколько типов менеджеров

ресурсов, что значительно усложняет применение упомянутой концепции,

увеличивает объем работ программированию, усложняет также правила создания

интегрированной среды и взаимодействия его отдельных элементов.

Выход из этой ситуации – применение таких теоретических и практических

основ, которые бы максимальным образом способствовали решению проблемы, а

также наиболее широко охватывали различные аспекты концепции в целях

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

правил интеграции, прикладных интерфейсов и др. Одним из более перспективных

подходов является компонентный подход, который способствует решению

вопросов практической реализации концепции интеграции менеджеров ИР на

150

единой теоретической, методической и прикладной основе.

Метод построения ПС на основе компонентной интеграции менеджеров

ресурсов базируется на таких основных аспектах [209]:

– все объекты интеграции – суть компоненты, в том числе и менеджеры ИР;

– интегрированная среда – это компонентный framework ;

– серверы приложений и их общесистемные сервисы содержат

необходимые операции по развертыванию, функционированию и

взаимодействию компонентов;

– механизмом взаимодействия в интегрированной среде является их

интерфейс;

– менеджеры ИР инкапсулируют ресурсы интегрированной среды и выступают

как обобщенные интерфейсы;

– каждый компонент имеет типовую структуру, которая определяет его

свойства, механизмы функционирования и ЖЦ (это, в частности, наличие

контейнера и компонентных реализаций, существование механизма создания

экземпляров компонента на основе фабрики компонентов, схема взаимодействия

компонентов согласно интерфейсам и общесистемным сервисам и т.д.).

Концепции и принципы создания среды на основе интеграции менеджеров

ресурсов положены в основу разработки веб-приложения для навигации и доступа

к ИР в сети Интернета. Программные средства используют компонентный подход

к разработке веб-приложений, который определяет, регламентирует и

поддерживает выполнение типовых функций и операций в сети Интернета.

Основой интегрированной среды – веб-сервер, в рамках которого реализован

компонентный framework, разработанный согласно компонентному подходу [67],

веб-приложение для навигации и доступа к ИР реализовано как совокупность

компонентов, которые функционируют в серверной компонентной среде согласно

правилам и схемам обработки данных, определенных в компонентном framework.

Пример описания веб-приложения методом интеграции менеджеров ИР приведен в

Приложении 1.

Интегрированная среда содержит три типа менеджеров ИР:

– веб-сайтов;

– веб-приложений;

– удаленного доступа к БД.

Структура унифицированного запроса определяется стандартным для веб-среды

CGI-механизмом. Аналогично форматом ответа на унифицированный запрос

является HTML-страница.

Структуры типизированных запросов к ИР и ответы на них зависят от типа

менеджера ресурсов.

Дескрипторы ресурсов подаются как XML-файлы, определяющие основные

характеристики, по которым создаются соответствующие соединения с ресурсами,

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

дескриптора, применяет DOM-модель для XML-файлов. Перечни всех ресурсов,

которые составляют общую систему ИР, также представлены в виде XML-файлов,

распределенных между несколькими веб-серверами, на каждом из которых развернут

отдельный экземпляр веб-приложения для навигации и доступа к ИР. Каждый перечень

определяет совокупность ресурсов, связанных с конкретным сервером.