Юпитер создаёт общее информационное пространство

“Юпитер” создаёт общее информационное пространство

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

Любая программная система через пять лет становится унаследованной. Эту истину знает опытный руководитель ИТ-направления каждой крупной компании. Компонент КИС может десятилетиями исправно “перемалывать” поступающие данные, несмотря на то что вокруг растет ПО в новой архитектуре. Обслуживание унаследованной системы становится все дороже, но выкинуть ее предприятие не может, так как на нее завязаны критические бизнес-процессы или она содержит важную информацию. Разработчик же прекращает поддержку старой версии своего ПО, исходный код у клиента отсутствует, поменять в системе уже ничего нельзя, и заказчик попадает в заложники выбранного когда-то решения. А поскольку таких систем со временем становится все больше, то ситуация постоянно усложняется, ведь помимо прочего данные оказываются еще и изолированными друг от друга, вследствие чего эффективность работы с ними снижается.

Виртуальная машина “Юпитер”

Рис. 1. Структура системы "Юпитер"

Часто применяемый выход из подобных ситуаций состоит в использовании систем интеграции приложений (Enterprise Application Integration), в первую очередь ПО класса Message Oriented Middleware (MOM). Оно позволяет создать общую шину, к которой через специальные адаптеры подключаются приложения, обменивающиеся данными. Наиболее известным продуктом этого класса является IBM WebSphere Integrator (бывший MQ Series), однако на рынке присутствует и много других подобных пакетов. Есть и российские разработки, одна из них - система “Юпитер” компании ИВК, уже несколько лет используемая для описанных целей в различных силовых ведомствах и сейчас выпускаемая на открытый рынок.

Первично “Юпитер” создавался именно как система управления очередями сообщений, но заложенная в него функциональность выходит за рамки данного класса систем middleware. Сейчас он решает несколько проблем, возникающих при построении корпоративных информационных систем, в том числе четыре ключевые: интеграция новых и унаследованных частей КИС, обеспечение унифицированного доступа приложений к разнородным источникам данных, упрощение построения новых приложений в распределенной компонентной архитектуре, а также создание кросс-платформных программ.

Основные функции и архитектура

Архитектурно система состоит из двух больших логических частей: одна обеспечивает стандартную функциональность на изолированной машине, а другая - связь разных компьютеров. На каждой машине присутствует реализация так называемой унифицированной модели вычислительного процесса: она включает среду исполнения “Юпитер” и набор библиотек. Объем функциональности библиотек таков, что можно создавать готовые приложения, опираясь только на API “Юпитер”, - такие приложения автоматически становятся кроссс-платформными (система перенесена на Windows, Red Hat Linux, OS/2, MacOS X, FreeBSD и мэйнфреймы). API содержит более 200 вызовов и обеспечивает многозадачность, управление памятью, хранилищем документов и т. п. Если какие-либо возможности на одной из платформ отсутствуют (как, например, файловая система на мэйнфреймах), то они эмулируются библиотекой.

Среда исполнения - это основа “Юпитера”. Она состоит из ряда подсистем: управления очередями сообщений, безопасности, локального хранения данных, контроля целостности приложений, транспортной и т. д.

Например, подсистема контроля целостности вычислительного процесса в начале загрузки среды исполнения “Юпитер” сканирует все приложения, установленные на ПК, на предмет того, разрешено ли им здесь находиться и не изменена ли их версия. Список разрешенных приложений, настроек и контрольных сумм модулей задает администратор. Если кто-то что-то поменял в настройках компьютера, дальнейшая его работа будет заблокирована и администратор получит уведомление о происшествии. Таким образом решаются две задачи, а именно обеспечиваются гарантии согласованности всех модулей (не секрет, что установка одних приложений на ПК может разрушить работу других) и того, что никто не заменил рабочие модули на модули с закладками.

Другая подсистема отвечает за локальное хранение данных. Это как бы аналог личного сейфа: информация в хранилище защищается специальными алгоритмами. В ней используются две метафоры - документа и файла. Разница между ними в том, что документ имеет внутреннюю структуру, с которой можно работать через специальный API “Юпитера”. Файл же - это просто элемент файловой системы. Документ может быть частью файла, занимать целый файл или быть распределенным на несколько файлов.

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

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

Любое приложение может выставить свое сообщение на шину данных “Юпитер”, адресовав его либо определенному респонденту, либо их группе, заявивших о своем интересе к теме. Виртуально такого рода взаимодействие выглядит как обмен по схеме точка - точка, ведь приложениям не важно, находится ли их визави на той же машине или где-то еще.

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

Респондентом в системе “Юпитер” выступает объект, занимающий определенную “должность” в определенном “подразделении”. Например, это может быть главный бухгалтер или старший специалист. От “должности” зависят права доступа лиц к системе. При этом параллельно со списком “должностей” существует и список реальных сотрудников организации, и администратор системы устанавливает между ними соответствие по типу многие-ко-многим. Конечно, должности по штатному расписанию и “должности” в системе могут не совпадать (как это бывает, скажем, в проектных организациях), но если такое совпадение имеет место, то сопровождение КИС резко упрощается.

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

Транспортный механизм

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

Рис. 2. Архитектура сети маршрутизации сообщений

Между хостами сообщение передается по кратчайшему пути. Если оно должно быть доставлено на хост того же подразделения, то оно передается через очередь на ГС этого подразделения, где осуществляется промежуточное хранение. Если конечный хост находится в другом структурном подразделении или “объекте”, сообщение последовательно маршрутизируется через главные серверы - сначала вверх по иерархии, а затем вниз. Если же между какими-либо компьютерами объекта или других объектов нет связи, то сообщение будет храниться на ближайшем к получателю ГС, до тех пор пока эту связь не восстановят. При этом транспортная подсистема “Юпитера” будет пытаться использовать для отсылки все имеющиеся в ее распоряжении линии связи, подключаемые к витруальной машине через транспортные “задачи” (их проще всего представить как драйверы протоколов), реализация которых существует для TCP/IP, IPX, линий связи типа канал - канал, применяемых в мэйнфреймах, прочих типов сетей. Способ написания таких адаптеров документирован.

Стоит заметить, что выбранная архитектура сети “Юпитер” позволяет изолировать потоки сообщений между подразделениями, что важно для обеспечения безопасности (этот момент особенно актуален для силовых структур, где “Юпитер” активно внедряется). Оборотной стороной использования этой архитектуры оказывается либо быстрый рост числа задействованных серверов (если в каждом подразделении ставится выделенный головной сервер), либо вынужденное совмещение ролей головного сервера и клиентского хоста.

Гарантированная доставка и обработка

Отсылая что-то, например, главному бухгалтеру, клиент не знает, кто в действительности им является, где его рабочее место, на какой машине он зарегистрирован и когда начнет работу. Однако при этом клиент может быть уверен, что сообщение будет доставлено и обработано. Более того, благодаря выбранной системе именования хостов “Юпитер” способен определить направление, где находится получатель, и максимально приблизить сообщение к нему до того, как тот войдет в систему.

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

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

Приложения-обработчики вызываются последовательно, и, как только все они завершаются, источнику сообщения отсылается дополнительное уведомление. Так действует третий механизм гарантий системы - механизм гарантированной обработки. (Естественным было бы добавить в эту схему механизм workflow. Однако создатели “Юпитера” пошли другим путем: они предлагают использовать продукты workflow сторонних производителей и рассматривать их как приложения “Юпитера”, дирижирующие другими приложениями посредством отсылки и приема управляющих сообщений. - В. Б.)

Интеграция приложений

В “Юпитере” предусмотрено три уровня интеграции приложений: минимальный, стандартный, расширенный. Минимальный уровень предполагает использование всего пяти основных функций системы: регистрация приложения, его дерегистрация, опрос входной очереди, помещение информации в очередь, опрос флага принудительного завершения (все процессы, работающие в “Юпитере”, должны подчиняться флагу принудительного завершения - это важно для распределенных сетей). Все эти вызовы не обязательно должны быть встроены в код - их можно реализовать и на уровне макросов, как, например, это сделано для Microsoft Word.

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

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

Для написания “обертки” DOS-программ ИВК предлагает набор блоков, позволяющих включиться в адресное пространство унаследованной DOS-программы.

Что касается приложений для мэйнфреймов, то здесь возможны два варианта: программа может изначально предназначаться для вызова из других приложений, а может быть как бы “вещью в себе”. В первом случае ПО имеет документированный интерфейс (примерами являются монитор транзакций CICS или СУБД ADABAS) и создание для него “обертки” не представляет особой сложности. Во втором случае специалистам клиента необходимо разобраться в структуре получаемых и отдаваемых приложением наборов данных и разработать “обертку”, формирующую входной набор и разбирающую выходной набор данных. Для упрощения решения этих задач специалистами ИВК предлагаются заготовки для написания обоих типов “оберток”.

Другие задачи

“Юпитер” можно использовать не только для интеграции приложений. Например, с его помощью несложно создавать компонентные распределенные приложения или разбивать на куски монолитные приложения. В этом случае не просто решается проблема логической перегруженности кода, но и появляется возможность выносить наиболее важные части приложений на самые мощные серверы, адресно повышая их производительность. Поскольку сообщение гарантированно попадает к адресату, разработчик может не беспокоиться о тех проблемах, что возникают, в частности, при использовании Microsoft DCOM.

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

И наконец, система нашла применение в области консолидации данных. В этом смысле показателен ОКР-проект, осуществляемый в МВД. Здесь имеется большое число разобщенных баз данных, и “Юпитер” должен помочь свести их воедино.

История продукта

Изначально технологии, на основе которых создана система “Юпитер”, были разработаны и опробованы в проектах, которые ИВК выполняла для организаций Министерства обороны. В 90-е годы здесь активно шла замена оборудования, однако все имевшиеся программы были сделаны для ЕС ЭВМ, что не позволяло эффективно использовать новую технику. “Юпитер” позволил интегрировать старый софт и ПО, работающее на новых машинах. На сегодняшний день на базе этой системы реализовано более десяти проектов, причем в самом крупном из них задействовано 600 лицензий - половина из проданных. В декабре должна выйти пятая версия “Юпитера”, в которой система безопасности поднята на новый уровень. Ожидается также получение сертификата Гостехкомиссии. В дальнейшем ИВК планирует усовершенствовать хранилище документов системы, положив в его основу многомерную СУБД собственной разработки.