Технология Клиент-Сервер 1999'1

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

Репозитарий приложений - ядро компонентной архитектуры ProFIX

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

Данная статья представляет собой описание компонентной архитектуры компании ProFIX и ее центрального звена - репозитария приложений, а также реализованных в ее рамках коммерчески доступных решений.

Компонентная архитектура ProFIX

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

И хотя будущее за первыми - вторые имеют на сегодняшний день в своем активе больше законченных решений промышленного уровня. Кроме того, второе не исключает первого. Все как один, производители готовых систем на базе собственных стандартов заявляют об открытости API и о поддержке в своих продуктах тех или иных (а то и всех сразу) компонентных архитектур, претендующих на титул "открытый промышленный стандарт".

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

Следование общеотраслевым тенденциям для отечественных разработчиков не обошлось без некоторых особенностей

положительных:

  1. Отсутствие груза унаследованных систем
  2. Мобильность и класс разработчиков
  3. Сравнительно небольшие объемы данных, которыми предстоит управлять законченным системам

и отрицательных:

Эти и другие факторы определяют лицо отечественных систем управления данными уровня предприятия:

Компонентная архитектура компании ProFIX, работающей на рынке Украины более трех лет, имеет следующие черты:

Компоненты со стороны клиента

Клиентская компонентная архитектура получила в компании название ProFIX/PlugIns. Клиент представляет собой небольшую оболочку (~ 40 Kб) содержащую API для динамической загрузки, выгрузки и управления компонентами и контейнер компонентов. Оболочка является единственным исполняемым файлом со стороны клиента. Компоненты могут быть:

Бинарные компоненты хранятся в своем естественном виде на сервере и по запросу динамически загружаются и выгружаются из памяти. Таблицы сервера БД содержат ссылки на бинарные компоненты. Компоненты реализованные на языках скриптов хранятся в таблицах сервера БД. В функции оболочки входит формирование внешнего вида интерфейса (системы меню и инструментальных панелей) на основании информации о зарегистрированных компонентах, правах доступа и функциях приложения. Размер бинарного компонента, как правило, не превышает 50 Кб, что облегчает его загрузку с корпоративного сервера, где бы он не находился. Естественно на клиентской стороне располагаются гораздо более массивные run-time модули и библиотеки доступа к БД. И те и другие устанавливаются один раз и не изменяются в течении всего жизненного цикла приложения.

Компоненты со стороны сервера

В рамках выбранной нами архитектуры, большая часть бизнес логики реализуется средствами хранимых процедур сервера БД (INFORMIX ONLINE). Вся функциональность, которая находится за рамками возможностей языка хранимых процедур ,сосредоточена в специализированном сервере сообщений (ProFIX/MessageServer). Сервер сообщений представляет собой набор тесно связанных серверных компонентов, компилируемых под целевую платформу (используется только ANSI C). Структуру сервера можно условно представить следующим образом:

Протокол взаимодействия с сервером БД Процессор форматов сообщений Протокол взаимодействия с клиентскими приложениями
Прикладная логика сервера
Процессор очередей сообщений
Сервер безопасности (электронная подпись, шифрование, управление ключами, архивирование)
Интерпретатор ProFIX/Script
Библиотека доступа к серверу БД
Рисунок 1. Структура сервера сообщений

Весьма поверхностно, работу служб (компонентов) сервера сообщений можно иллюстрировать следующим образом:

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

Сервер сообщений взаимодействует с сервером БД через библиотеку доступа к БД посредством вызова хранимых процедур. Настройка на форматы сообщений и синтаксис вызова хранимых процедур происходит на уровне специализированного тегового языка.

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

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

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

Языки скриптов - связующее звено между компонентами

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

Поддерживаются следующие языки:

Программы на языках скриптов хранятся в таблицах сервера БД и редактируются средствами, входящими в состав (с клиентской стороны) ядра компонентной архитектуры ProFIX - "репозитария приложений".

Репозитарий приложений

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

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

Хранение компонентов в базе данных

Как уже говорилось ранее, физически, компоненты (или ссылки на компоненты) хранятся в таблицах БД Informix. Набор таблиц позволяет описывать:

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

Визуальный инструментарий располагается, естественно, на клиенте и включает в себя:

Взаимодействие с контейнером компонентов (на клиенте)

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

Бинарные компоненты могут визуально подключаться друг к другу (например, через локальное меню). При этом, подключенный компонент наследует источники данных (DataSouce).

Взаимодействие с интерпретаторами языков программирования (на клиенте и на сервере)

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

Решения

На сегодняшний день существует три коммерчески доступных программных продукта, реализованных с использованием "компонентной архитектуры ProFIX":

Расчетная палата коммерческого банка

Расчетная палата устанавливается в головном офисе банка и предназначена для решения следующих задач:

В рамках данного программного продукта существует около 20 приложений, выполненных в виде клиентских и серверных компонентов (в том числе и силами клиентов компании ProFIX). На момент написания данной статьи расчетная палата установлена в четырех достаточно крупных банках Украины

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

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

Программный продукт установлен в Главном вычислительном центре железной дороги Украины и предназначен для решения следующих задач:

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

Источники информации:

В рамках данного программного продукта существует 15 приложений, выполненных в виде клиентских и серверных компонентов (все разработаны силами компании ProFIX).

Информационная система энергетической компании

Данный программный продукт является последним и самым новым, выполненным с использованием "компонентной архитектуры ProFIX". Система предназначена для решения следующих задач:

Источники информации:

Реальные технические параметры системы, установленной в региональной энергетической компании:

по материалам Informix Magazine/RE

Copyright © 1994-2016 ООО "К-Пресс"