Как обеспечить преемственность?
Программно-технические комплексы, которые в настоящее время используются или которые предполагается использовать в качестве средств автоматизации деятельности предприятий, весьма разнообразны как по составу, так и по своему функциональному назначению. Немало крупных организаций имеют разветвленные вычислительные сети, “узлами” которых служат территориально распределенные и относительно автономные объекты, включающие, в свою очередь, локальные вычислительные сети (ЛВС), где функционируют компьютеры различных поколений с выполняющимися на них приложениями.
- мэйнфрейм в качестве центральной ЭВМ предприятия;
- ЛВС объекта, построенные на базе ПК и функционирующие в составе смешанной сетевой архитектуры под управлением ОС семейств Microsoft Windows, UNIX, Novell NetWare;
- выделенные ПК промежуточного класса, используемые для решения специализированных задач обслуживания каналов связи, временного хранения и преобразования данных. В настоящее время они представлены перспективными многопроцессорными комплексами на платформах Sun, HP и других.
Разнородность базовых компонентов программно-технических комплексов дополняется разнообразием номенклатуры (включающей десятки наименований) инструментальных программных средств, ранее использовавшихся в составе унаследованных систем или предлагаемых сейчас для разработки приложений.
Было бы ошибочным считать, что эта разнородность носит временный характер и спустя некоторое время проблема “рассосется” сама собой. К сожалению, этого не произойдет, и тому есть объективные причины, о которых мы поговорим ниже.
Во-первых, крупные территориально распределенные корпоративные системы, функционирующие в течение определенного временного интервала, как правило, почти математически стремятся к непрерывности процесса своей работы (24х365); их невозможно остановить для единовременной модернизации технических и программных средств. Поэтапная же замена однозначно предполагает, что унаследованные и перспективные технологии будут совместно функционировать в течение некоторого времени (какого — это зависит от финансовых возможностей самого предприятия, внешних факторов, субъективных качеств руководителей, разумности принимаемых ими решений).
Прямое следствие описанной типичной картины — это интерференция (наложение) волн модернизаций конкретной автоматизированной системы. На одних ее объектах может идти, скажем, какой-нибудь n-й этап модернизации (активные поставки средств вычислительной техники, перспективного ПО и т.п.), а в другом месте в это же время еще только “ждут перемен”.
Эффект интерференции процессов модернизации компонентов АС (пространственной и временной) может проявляться и локально — на одном компьютере, на котором присутствуют приложения, разработанные в разное время разными производителями и с использованием различных инструментальных средств, порой в самых неожиданных сочетаниях. От типа самого вычислительного средства (мэйнфрейм, мини-ЭВМ, ПК) здесь мало что зависит. Авторам этих строк приходилось, например, участвовать в создании Web-интерфейсов к вычислительным задачам образца 70-80-х гг., разработанным для отечественных мэйнфреймов архитектуры 360/370. Аналогичные интерфейсы создавались и для DOS-приложений на ПК.
Далее: сейчас очевидно, что прогресс собственно средств вычислительной техники до настоящего времени не привел (и вряд ли приведет в дальнейшем) к созданию “универсального” модуля-вычислителя с единой системой команд процессора, унифицированной ОС и интерфейсами внешних устройств; иными словами, на этом уровне унификация пока недостижима. Более того, ее перспектива все менее различима.
Процессы развития аппаратных средств и ПО слабо коррелируют между собой во времени. В некоторых случаях движущим фактором совершенствования, например, программных компонентов может выступать временное отсутствие прогресса в области технических средств; и наоборот, технологический прорыв неминуемо влечет за собой усовершенствование ПО. В любом случае требуется некоторый переходный период, позволяющий разработать и тот и другой компонент.
Сохранение гетерогенности корпоративных систем связано и с субъективным фактором. Часто это следствие того, что финансирование работ по созданию и внедрению тех или иных системотехнических решений проводится из разных источников и разными способами или отсутствует единая техническая политика развития корпоративных сетей.
Подводя некоторый итог, можно констатировать, что в целом сложившаяся ситуация напоминает классическое строение кометы, в «голове» которой так называемые продвинутые техники, твердое ядро образуют актуальные на сегодняшний день технологии и приложения, а «хвост» — унаследованные системы, постепенно рассеивающиеся в киберпространстве. И процесс этот носит вполне периодичный характер, что связано со многими факторами, в том числе с политическими и экономическими. Правда, если раньше “период обращения” исчислялся пятилетками, то теперь — годами. И, хотим мы этого или не хотим, — так будет всегда.
Практика последних лет в нашей стране знает не так уж много примеров успешного решения вышеназванной проблемы. Как правило, ответственные чиновники с легкостью отказываются от “устаревших” средств обработки данных и используемых технологий, подстегиваемые обещаниями фирм-производителей средств вычислительной техники и ПО открыть “новую эру” в вопросе автоматизации деятельности конкретного предприятия. Условие успешной реализации задуманного — замена парка “устаревшей” вычислительной техники и использование “продвинутых” технологий. Во многих случаях осуществляется банальная алгоритмическая реализация большей части функционировавших ранее задач в новой среде без достижения нового качества системы. Заказчику демонстрируются просто новые формы визуального представления данных с использованием средств графического интерфейса. В отношении вновь создаваемых систем, не отягощенных “тяжким наследием прошлого”, ситуация пока более или менее благополучная (наверное, до первой волны их модернизации).
Теперь обратимся к зарубежному опыту. Наши зарубежные коллеги много раньше столкнулись с проблемами поддержания работоспособности и одновременного развития гетерогенных автоматизированных систем. И нельзя сказать, что отечественный подход к решению данной задачи (“…до основанья, а затем…”) был в их решениях доминирующим. Как правило, они искали более экономичные подходы, включающие миграцию существующего ПО в новые среды, разработку протоколов сопряжения и унификацию интерфейсов неоднородных компонентов АС различных уровней и, наконец, создание концепции ПО промежуточного слоя (middleware).
- преемственность, то есть совместимость новых компонентов с предшествующими соглашениями (протоколами) по порядку адресации и обмена данными между субъектами распределенного вычислительного процесса (приложениями, рабочими станциями, локальными сетями, объектами АС);
- решение проблемы инкапсуляции интерфейсов унаследованных систем с новыми средствами (с сохранением, при необходимости, старых компонентов в составе вновь разработанного ПО).
Выполнение первого из этих условий обеспечивает взаимодействие субъектов вычислительного процесса (“старых” и “новых”) уровня объектов АС в целом и их совместное функционирование в течение некоторого переходного периода. Второе условие позволяет применять разработанные ранее программные компоненты (для субъектов вычислительного процесса уровня приложений, реже — рабочих станций) как некий строительный материал, в совокупности с вновь создаваемым ПО.
Понимание важности соблюдения этих условий для поддержания жизненного цикла любой крупной системы стало толчком для разработки моделей взаимодействия, средств описания интерфейсов разнородных программных компонентов, а также инструментов их поддержки, известных сейчас как технологии COM/DCOM (Component Object Model/Distributed Component Object Model), CORBA (Common Object Request Broker Architecture) и DCE (Distributed Computing Enviroment).
Хотя и с некоторым опозданием, но актуальность вышеперечисленных проблем с некоторых пор начала осознаваться и на отечественном киберпространстве. Но особенности эволюции средств вычислительной техники и ПО — сначала советского, а затем российского периода, как обычно, добавляют изрядную порцию дегтя в емкость с надеждами на скорое избавление от проблем интеграции разнородного ПО при помощи импорта готовых решений на базе упомянутых выше технологий. Дело в том, что существовавшая в былые времена практика “заимствования” за рубежом программных кодов ОС, СУБД и мониторов транзакций с последующим их “улучшением” собственными силами для адаптации к отечественной элементной базе приводила к тому, что “адаптированным” оказывался и код конечных приложений. В результате прекращения работ по развитию средств общего ПО и естественного оттока специалистов из области унаследованных систем образца 80-х годов в сферу разработки приложений для ЛВС образовался технологический барьер, преодолеть который (иными словами, достучаться до “адаптированных” отечественных приложений 80-х) готовые импортируемые решения сегодня не могут.
Весьма показателен в этом смысле пример с отечественным вариантом использования СУБД ADABAS (разработчик оригинала — фирма Software AG), функционировавшей на мэйнфреймах в среде ОС виртуальных машин СВМ ЕС, полноценно взаимодействовать с которой приложения, разработанные для ЛВС, не могут, даже используя связующие компоненты семейства EntireX от той же компании. И причина здесь вовсе не в качестве продукта известной фирмы.
К неизбежной неоднородности корпоративных информационных систем можно приспособиться, использовав набор системотехнических решений, унифицированный характер которых обеспечит преемственность процессов обновления системы и сокращение ее совокупной стоимости владения (Total Cost of Ownership, TCO). Это во-первых. Во-вторых, не слишком хорошо, когда предлагаемые решения представляют собой совокупность частных соглашений (например, по адресации), касающихся только отдельных элементов системы (допустим, только службы доставки). По опыту можем сказать, что ИТ-специалистам гораздо удобнее иметь дело с интегрированными средствами, обеспечивающими унификацию всего тракта обработки данных в корпоративной сети, включая регистрацию приложения, контроль работоспособности, доставку данных, навигацию в сети, ведение журналов и т.п. Унификация разнородных интерфейсов прикладных задач достижима на уровне ПО промежуточного слоя, решающего проблемы сопряжения разнородных компонентов. К программным продуктам данного класса относится, в частности, «ИВК ЮПИТЕР», поддерживающий каноническую схему вычислительного процесса в гетерогенной среде с использованием платформообразующей технологии.
Бесспорно, сегодня было бы преувеличением говорить о том, что изложенный подход позволяет решать любые проблемы, однако определенную стройность и порядок в совместном функционировании унаследованного, актуального и перспективного ПО навести можно. При этом не важно, идет ли речь об одном-единственном компьютере, корпоративной сети предприятия или территориально распределенной вычислительной сети автоматизированной системы федерального уровня.
| Валерий Андреев — начальник отдела маркетинга и развития ЗАО ИВК, к.ф.-м.н. Константин Здирук — руководитель группы разработчиков ЗАО ИВК. С авторами можно связаться по адресу электронной почты andreev@ivk.ru |