Переносимость и интероперабельность информационных систем и международные стандарты

Продукты, которые сегодня принято называть информационными системами, появились много лет назад. В основе первых информационных систем находились мэйнфреймы компании IBM, файловая систем ОС/360, а впоследствии ранние СУБД типа IMS и IDMS. Эти системы прожили долгую и полезную жизнь, многие из них до сих пор эксплуатируются. Но с другой стороны, полная ориентация на аппаратные средства и программное обеспечение IBM породила серьезную проблему "унаследованных систем" (legacy systems). Увы, производственный процесс не позволяет прекратить или даже приостановить использование морально устаревших систем, чтобы перевести их на новую технологию. Многие серьезные исследователи сегодня заняты попытками решить эту проблему.

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

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

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

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

Соответственно, прежде всего следует обращать внимание на степень стандартизированности используемого языка программирования. На сегодняшний день приняты международные стандарты языков Фортран, Паскаль, Ада, Си и, совсем недавно, Си++. Понятно, что Фортран, даже в своем наиболее развитом виде Фортран-95, не является языком, подходящим для программирования информационных систем. Паскаль - очень приятный язык, но чтобы не испортить впечатление от его приятности, в стандарт не включены средства раздельной компиляции. Конечно, в принципе можно оформить полный исходный текст в виде одного текстового файла, но вряд ли это разумно и практично. Язык Ада, вообще говоря, пригоден для любых целей. На нем можно писать и информационные системы (что, кстати и делают американские и некоторые отечественные военные). Но что-то я не видел счастливых прикладных программистов, использующих язык Ада. Уж больно он громоздкий... Наиболее хороший стандарт, на мой взгляд, на сегодняшний день существует для языка Си. Опыт нескольких лет, прошедших после принятия стандарта, показывает, что при грамотном использовании стандарта Си ANSI/ISO проблемы переноса программ, связанные с особенностями аппаратуры или компиляторов практически не возникают (если учитывать имеющиеся в самом стандарте рекомендации по созданию переносимых программ). Прошлым летом был, наконец, принят стандарт Си++. Видимо, это означает (по крайней мере, я на это надеюсь), что еще через несколько лет можно будет говорить о мобильном программировании на Си++ в том же смысле, в котором можно говорить об этом сегодня по отношению к Си.

Почему, имея в виду взаимодействия с базами данных, мы говорим про язык SQL и что с ним происходит? Здесь все не очень просто. SQL с самого своего зарождения являлся сложным языком со смешанной декларативно-процедурной семантикой, не идеальным синтаксисом, а кроме того, всегда содержал ряд темных мест (объем этой заметки не позволяет даже привести примеры). Тем не менее, судьба распорядилась так, что именно SQL (хотя были и другие кандидаты) стал единственным практически используемым языком реляционных баз данных. К настоящему времени имеется два принятых стандарта SQL- SQL/89 и SQL/92. Стандарт SQL/89 очень слабый, многие важные аспекты в нем не определены или отданы на определение в реализации. С другой стороны, большинство современных коммерческих реляционных СУБД на самом деле соответствуют стандарту SQL/89. Стандарт SQL/92 является существенно более продвинутым, но язык SQL/92 настолько сложен, что к настоящему времени нет практически ни одной СУБД, в которой он был бы полностью реализован (как правило, реализуется расширенное подмножество языка). Ситуация не из приятных. Но тем не менее, внимательный анализ языка показывает, что имеется практическая возможность создания достаточно переносимых программ с использованием SQL/89. Для это нужно максимально локализовать те части программы, которые содержат не стандартизованные конструкции, и стараться не использовать расширения языка, предлагаемые в конкретной реализации.

Между прочим, аналогичная ситуация существует и в области операционных систем. Существующий сегодня набор стандартов происходит от интерфейсов операционной системы Unix (SVID, POSIX, XPG и т.д.). В большинстве современных операционных систем эти стандарты поддерживаются, но, как правило, любая ОС содержит множество дополнительных средств. Если стремиться к достижению переносимости приложения, следует стараться ограничить себя минимально достаточным набором стандартных средств. В случае, когда нестандартное решение некоторой операционной системы позволяет существенно оптимизировать работу информационной системы, разумно предельно локализовать те места программы, в которых это решение используется.

Конечно, следовало бы поговорить и о системных или "полусистемных" (middleware) средствах поддержки интероперабельности программных компонентов, начиная от средств межпроцессных взаимодействий, проходя через механизм вызова удаленных процедур и заканчивая (сегодня!) Common Object Request Broker Architecture (CORBA).

Завершим эту небольшую заметку тем, что для создания переносимых интероперабельных информационных систем необходимо иметь или придумать для себя то, что принято называть профилем (а может быть, лучше профайлом?) стандартов, в окружении которых разрабатывается система. Чем правильнее выбран профиль, тем более вероятно вашей системе удастся прожить долгую и счастливую жизнь. А как хочется, чтобы наши творения жили долго и счастливо...

ComputerWorld #4/96