Существующее положение

Не так давно компьютерная общественность отметила знаменательный юбилей – 40-летие существования и развития архитектуры IBM 360. Если не вдаваться в технические подробности, то это была первая промышленная технология, ориентированная на максимальную преемственность и сохранение инвестиций. Конечно, ЭВМ семейства IBM 360 обладали и многими другими достоинствами – продуманной структурой системы ввода-вывода, остроумными принципами адресации, применением специального оборудования для разграничения доступа к данным и программам в памяти и так далее, всего не перечислить. Именно поэтому за ними закрепилось наименование «мэйнфреймов» - то есть базовых элементов корпоративной (в данном случае – вычислительной) инфраструктуры.Однако в настоящий момент хочется остановить внимание именно на преемственности. С одной стороны преемственность – безусловное благо. Никакая архитектура не накопила такого количества человеческого опыта и знаний, сохраненных в программах, как архитектура 360. И никакая архитектура не хранит к началу XXI века такое количество морально устаревших подходов. Преемственность как бы вынужденно «законсервировала» приемы программирования и реализации проектов, применяемые в прошлом, и позволила накапливать не только находки, но и ошибки. В результате сегодня никого не удивляет, что для ЭВМ-наследников архитектуры IBM 360 существуют и активно применяются программы, срок жизни которых превысил пару десятилетий, и уже нет ни тех, кто их разработал, ни тех, кто их сопровождал, да и исходные коды с проектной документацией зачастую утеряны.

Кроме того, внедрение современных программных средств для современныхпотомков IBM 360 тоже, к сожалению, затруднено. Причин тому множество. С одной стороны,данной платформе присущи сравнительно высокие разовые первоначальные платежи за новую технику и существенные лицензионные выплаты. Конечно, учитывая российскую специфику и длительныхсрок эксплуатации мэйнфреймов, эти расходы могут быть существенно снижены. Но необходимо учитывать, что, например, отказ от лицензионных выплат приводит к потере связей с фирмой-поставщиком программного обеспечения и лишает заказчиков каналов получения новых версий продуктов и качественного сопровождения. А это, опять-таки, мешает внедрению на мэйнфреймах современного программного обеспечения и новых приемов реализации информационных проектов. Определенный оптимизм внушает перенос на IBMS/390 ОС Linux, но прямое портирование самой ОС и ее приложений привело к скачкообразному повышению требований к быстродействию аппаратного обеспечения, а это неизбежно приводит к росту цены на оборудование. И, самое главное, внедрение и использование ОС Linux не решает проблемы дальнейшего эффективного использования огромного парка унаследованного программного обеспечения.

Пару слов о еще одной проблеме, оказывающей влияние на применение ЭВМ IBM 360/390 – о персонале. Как и упомянутые выше относительно высокая стоимость оборудования и программного обеспечения, кадры - одна из острейших проблем, присущая мэйнфреймам. Данная архитектура почти полностью выпала из программ обучения в ВУЗах, нет и курсов повышения квалификации для подготовки уже работающих с мэйнфреймами специалистов. Определенная инертность в развитии и замкнутость программных средств данной платформы создает мощный психологический барьер для молодых специалистов, а меньшее количество вычислительных установок упомянутой архитектуры сужает потенциальный рынок применения их трудовых навыков.

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

Возможные способы решения.

В настоящее время существует некоторый опыт решенияподобных проблем. Как известно, основным способом взаимодействия человека с мэйнфреймом до недавнего времени был интерфейс дисплея 3270. Именно для него было написано большинство применяемых в настоящий момент на «больших» ЭВМ программ. Даже самые старые пакетные задачи, написанные во времена использование перфокарт, могут быть запущены и обработаны с применением этого интерфейса. Поэтому неудивительно, что именно на интерфейсе 3270 сконцентрировались те из разработчиков, кто, с одной стороны, старался избежать изменений в унаследованном ПО, а с другой – пытались решить задачу интеграции унаследованного ПО в новую инфраструктуру.Условно можно разделить все варианты взаимодействия современных программных средств с мэйнфреймом на три группы:

·программы, разработанные на основе HLLAPI и его аналогов и работающие с применением прямой эмуляции 3270;

·программы, преобразовывающие «на лету» трафик 3270 в какой-либо другой, который можно обработать современными программными средствами;

·многофункциональные прикладные сервера, которые полностью замыкают трафик 3270 в себе, обладают достаточным «интеллектом» для коммуникации с мэйнфреймомна основесвоего рода предопределенных сценариев и предоставляют пользователям и прикладным программам только требуемые данные.

Рассмотрим подробнее эти три подхода.

Программы, разработанные на основе HLLAPI и его аналогов через и работающие с применением прямой эмуляции 3270. Это один из самых старых и самых дешевых способов решение задачи взаимодействия с унаследованным ПО. Обратим внимание:дешево – не всегда плохо. При этом прикладная программа, используя предоставленные разработчиком эмулятора 3270 библиотечные функции, имитирует взаимодействие пользователя с мэйнфреймом – выдачу команд, заполнение полей, интерпретацию ответов и прочее. Данные, выдаваемые на экран унаследованной программой, могут быть считаны в новую прикладную программу и обработаны. Основные недостатки такого рода решений – большой объем кода, который нужно разработать, необходимость самостоятельно обрабатывать аварийные ситуации (например, потери связи, аварийное завершение унаследованной задачи, и т.д.) и привязка к конкретному диалекту HLLAPI, а иногда и к версии эмулятора. Таким образом это достаточно «низкоуровневое», но очень гибкое решение, которое вполне подходит для решения небольшого количества частных задач.

Программы, преобразовывающие «на лету» трафик 3270 в какой-либо другой. Это, если можно так выразиться, «косметический» уровень взаимодействия с унаследованным программным обеспечением, хотя и на его основе могут быть созданы серъезные системы обработки информации. Примером таких программных средств могут быть средства преобразования трафика 3270 в HTML-интерфейс. При этом у пользователя отпадает необходимость в использовании эмуляционных программ -взаимодействие может осуществляться через WWW-браузер.Кроме того, у подобного рода программ обычно имеется возможность осуществлять преобразования на основе некоторой логики -например, обеспечить заполнение некоторого HTML-шаблона либо сохранение информации в промежуточном хранилище. Это также позволяет осуществлять вызов ряда функций, связанных с обменом информацией, из прикладных программ, что создает возможности интеграции унаследованных приложений в новую информационную структуру. К достоинствам данных программных средств можно отнести возможность создания более дружественного пользовательского интерфейса, существенно меньший объем разрабатываемого кода (иногда - вообще без его разработки) и более высокий уровень обрабатываемых событий: программисту не нужно предусматривать обработку типовых аварийных ситуаций – это делается автоматически. Основным же недостатком является определенная замкнутость данных средств на проблеме нового представления информации – возможности автоматизированной обработки трафика очень ограничены. Поэтому преобразующие программы, как правило, не дают нового качества в интеграции унаследованных приложений в современную информационную среду, однако они являются абсолютно оправданным выбором в том случае, если функций мэйнфреймовских приложений вполне достаточно и требуется только их современное представление, возможно, с незначительной промежуточной обработкой.

Отдельным и самым интересным способом обеспечения взаимодействия с мэйнфреймом является использование специальных прикладных серверов. При этом, как и в предыдущем случае, в инфраструктуре обработки информации появляется новый элемент – специальный «фасадный» сервер (front-endserver). Основное их отличие от программных средств предыдущего класса – наличие у фасадных серверов развитых возможностей по автоматизированной обработке информации, отображаемой на дисплеях 3270. Это может быть осуществлено на основе специальных сценариев. При этом сценарии могут быть достаточно разветвленными и охватывать целые ветви унаследованных приложений. Данные, которыми обменивается сервер с мэйнфреймом, могут быть получены и сохранены в промежуточных хранилищах - базах данных, плоских файлах, разделяемых переменных и проч. Фактически применение подобных прикладных серверов позволяет реализовать самую современную идею взаимодействия современных программных средств с мэйнфреймом – представление «больших ЭВМ» в виде совокупности доступных для вызова из различных сред прикладныхсервисов. В этом случае фасадный серверобеспечивает отображение прикладных сервисов на сценарии, осуществляющие взаимодействие с унаследованными приложениями при помощи 3270-трафика, при необходимости полностью изолируя пользователя либо программу от взаимодействия с мэйнфреймом. Достоинства данного подхода очевидны – это наиболее гибкий и интеллектуальный путь интеграции мейнфреймовских унаследованных приложений в новую среду.При этом целесообразный уровень того, насколькомэйнфрейм будет «спрятан» от пользователей и их приложений, полностью определяется администратором фасадного сервера. Еще одно неоспоримое достоинство – высокий уровень безопасности данного решения. Зачастую невозможно качественно повысить уровень защищенностиунаследованных приложений без серьезной доработки самих приложений либо операционной системы на мэйнфрейме. Применение фасадного сервера, который может располагаться в защищенной среде рядом с мэйнфреймом и предоставлять только необходимые прикладные функции в сочетании с современными средствами защиты информации позволяет решить данную проблему. Однако этот подход, как и любой другой, имеет свои недостатки. В первую очередь – стоимость реализующих упомянутый выше подход программных продуктов. Конечно, эта стоимость намного ниже стоимости переделки ПО, лицензий на новые ОС и средства разработки для мэйнфрейма, однако она выше стоимости любого из эмуляторов. Сложность таких продуктов тоже выше, чем у продуктов из других групп, что предполагает необходимость обучения персонала – администраторов и разработчиков. Необходимо еще учесть стоимость самого программного и аппаратного обеспечения фасадного сервера – он должен быть достаточно мощным, чтобы обеспечить требующуюся пропускную способность и скорость выполнения сценариев. Поэтому применение фасадных серверов в первую очередь оправданно в тех случаях, когда необходимо обеспечить интенсивный доступ к унаследованному ПО на мэйнфрейме при условии активного обмена данными между ними и задачами, функционирующими на других аппаратных платформах. Рассмотрим подробнее данный подход на примере программного продукта ApplinX.

Общий обзор программного средства ApplinX

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

- ApplinX Сервер (Server) –кроссплатформенный многопотоковый сервер, который осуществляет обработку запросов пользователей и прикладных программна доступ к мэйнфрейму, используя специально подготовленную базу данных. В этой базе хранятся описания сценариев приложений, правил преобразования, алгоритмов интерпретации содержимого полей и т.д. В составApplinXСервера входят компоненты обеспечения связи с мэйнфреймами и серверами разнообразных архитектур (так называемые «адаптеры»), компонента балансирования рабочей нагрузки, компонентауправления пользовательскими сеансами, компонента связи с созданными программными объектами и проч. Будучи реализованным на Java, ApplinX Сервер может выполняться в самых разнообразных вычислительных средах (MicrosoftWindows, Linux, SunSolaris, HP/UX, IBMOS/400, IBMAIX, NovellNetware и проч.) с применением любого J2EE прикладного сервера-контейнера (Oracle9iAS, IBMWebSphere, BEAWeblogic и проч.).

- ApplinX Хранилище (Repository) – место хранения различных структур, описывающих взаимодействие с унаследованными приложениями. В Хранилище располагаются, в частности, идентификаторы экранов, описания и атрибуты полей на экранах, сценарии приложений, служебные данные и проч. Создание данных в Хранилище осуществляется с помощью модуля Формирователь, описанного ниже. ApplinX Хранилище может располагаться в любой популярной базе данных, включая MicrosoftAccess, SQLServer, Oracle, DB2 и любой другой JDBC/ODBC-совместимой базе данных.

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

- ApplinX Формирователь (Composer) – основное средство разработки в среде ApplinX. С помощью Формирователя разработчик может быстро, с помощью визуальных средств, создать описание экранов и сценариев, сформировать новые экранные формы, задать реакции на значения тех или иных полей, определить действия в аварийных ситуациях и проч. Кроме того, с помощью специальных средств возможно осуществить запись типовых путей прохождения унаследованных приложений для последующего их анализа, обработки и создания на их основесценариев ApplinX. Именно в среде Формирователя осуществляется генерация прикладных программных объектов доступа к мэйнфрейму и WEB-сервисов, причем с минимальными усилиями и, в основном, без разработки программного кода. Формирователь поставляется в виде Java-апплета для работы в среде браузера и в виде отдельной компоненты.

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

Для взаимодействия с мэйнфреймами ApplinX использует протокол TCP/IP, поэтому в тех случаях, когда необходимо обеспечить связь с системами, где отсутствует этот протокол, необходимо предпринять некоторые дополнительные усилия. Например, выходом в такой ситуации может являться использование ОС VM либо программно-аппаратных коммуникационных шлюзовых станций. В процессе своей работы ApplinX Сервер использует специальный распределенный высокоуровневый интерфейс ApplinXBaseObject (ABO), который существенно упрощает для разработчика возможности включения собственных программных объектов. Все компоненты ApplinX разработаны с учетом поддержки национальных кодовых таблиц и обеспечивают преобразования текстовой информации «на лету». Основные возможности ApplinX по коммуникации с комплексами унаследованного программного обеспечения показаны на рисунке:

При этом типовые сценарии взаимодействия с унаследованными приложениями (включая начальный и конечный экраны, ввод и вывод данных, обработку аварийных ситуаций в виде обрыва связи либо аварийных сообщений) инкапсулируются в специальные высокоуровневые объекты, применяемые в процессе разработки с использованием Формирователя – ApplinXCompositeObject, ACO. Кроме того, порождается целый ряд стандартных объектов, которые могут быть использованы в программных продуктах, применяемых для разработки (смотри рисунок).

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

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

Выводы

1. Выбор средств интеграции унаследованных приложений в современную информационную инфраструктуру должен осуществляться с учетом многих факторов – сложности и объема унаследованных приложений, опыта персонала, пожеланий разработчиков, перспектив применения и прочее. Важное место занимает и аспект стоимости как самих унаследованных приложений, так и инструментальных средств интеграции.
2. В случае неправильного выбора средств интеграцииэкономия средств на инструментарии может привести к лавинообразному росту расходов в процессе самой разработки из-за высокой трудоемкости кодирования и большого объема требуемого программного кода.
3. Применение фасадных серверов, даже с учетом их относительно высокой стоимости, абсолютно оправданно в случае необходимости быстрой интеграции большого объема унаследованных приложений в динамически развивающуюся информационную среду. В этом случае существует возможность представить центральный компьютер в виде набора сервисных служб, которые могут быть быстро созданы и оперативно изменены в режиме реального времени с минимальной долей ручного кодирования.