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

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

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

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

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

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

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

Очень важно, что в стандарте ANSI Си специфицирован не только язык, но и базовые библиотеки стандартной системы программирования (в частности, основные компоненты библиотеки ввода/вывода). Наличие стандарта на библиотечные функции и его строгое соблюдение в реализациях в ряде случаев позволяет создавать не очень сложные приложения, переносимые не только между разными аппаратными платформами, но и между различными операционными средами.
Был, наконец, принят стандарт Си++. Видимо, это означает (по крайней мере, на это можно надеяться), что через несколько лет можно будет говорить о мобильном программировании на Си++ в том же смысле, в котором можно говорить об этом сегодня по отношению к Си.
Имея в виду взаимодействия с базами данных, мы говорим почти исключительно про язык SQL. SQL с самого своего зарождения являлся сложным языком со смешанной декларативно-процедурной семантикой и не идеальным синтаксисом. Тем не менее, именно SQL стал единственным практически используемым языком реляционных баз данных, хотя имелись и другие кандидаты, в частности, язык системы Ingres Quel.
В результате длительного процесса стандартизации языка к настоящему времени имеется два принятых международных стандарта SQL - SQL/89 и SQL/92. Стандарт SQL/89 очень слабый, многие важные аспекты в нем не определены или оставлены для определения в реализации. С другой стороны, большинство современных коммерческих реляционных СУБД на самом деле соответствует стандарту SQL/89 (этого не очень сложно добиться по причине отмеченной выше слабости стандарта).
Стандарт SQL/92 является существенно более продвинутым. В нем точно специфицированы такие важные аспекты, как средства манипулирования схемой базы данных, динамический SQL, расширены возможности языка для формулировки запросов в алгебраическом стиле и т.д. Однако язык SQL/92 настолько сложен, что к настоящему времени нет практически ни одной СУБД, в которой он был бы полностью реализован (как правило, реализуется расширенное подмножество языка).
Внимательный анализ языка показывает, что имеется практическая возможность создания достаточно переносимых программ с использованием SQL/89. Для этого нужно максимально локализовать те части программы, которые содержат нестандартизованные конструкции, и стараться не использовать расширения языка, предлагаемые в конкретной реализации. Понятно, что для этого требуется хорошее знание как SQL/89, так и особенностей диалекта, реализованного в используемом продукте. К сожалению стандарт SQL/89 не слишком помогает в решении этой проблемы. В нем полностью отсутствуют какие-либо рекомендации для мобильного программирования ИС.
Если стремиться к достижению переносимости приложения, то следует стараться ограничить себя минимально достаточным набором стандартных средств. В случае, когда нестандартное решение некоторой операционной системы позволяет существенно оптимизировать работу информационной системы, разумно предельно локализовать те места программы, в которых это решение используется.

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

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

Следующим шагом (очень важным шагом) явилось появление протокола удаленного вызова процедур (Remote Procedure Calls - RPC) и его реализация. Идея этого механизма очень проста. В большинстве случаев взаимодействие программных компонентов является асимметричным. Практически всегда можно выделить клиента, которому требуется некоторая услуга, и сервер, который такую услугу способен оказать. Более того, как правило, клиент не может продолжать свое выполнение, пока сервер не произведет требуемые от него действия. Другими словами, типичным взаимодействием клиента и сервера является процедурное взаимодействие. Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы RPC. При использовании этих средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводят вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.

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

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

Серверы баз данных, интерфейс которых основан исключительно на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество - стандартность интерфейса. В пределе, хотя пока это не совсем так, клиентские части любой SQL-ориентированной СУБД могли бы работать с любым SQL-сервером вне зависимости от того, кто его произвел.

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

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

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

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

В типичном на сегодняшний день случае на стороне клиента СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается для этого к серверу с использованием языка SQL.

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

4. Требования к аппаратным возможностям и базовому программному обеспечению клиентов и серверов

Очень полезной составляющей (относительно независимой от других составляющих) семейства протоколов RPC является протокол внешнего представления данных (External Data Representation - XDR). В этом протоколе специфицировано машинно-независимое представление данных, понимаемых механизмом RPC. Идея состоит в том, что при передаче параметров вызова удаленной процедуры и при получении ее ответных параметров происходит двойное преобразование данных сначала из исходного машинно-зависимого формата в формат XDR, а затем из этого формата в машинно-зависимый целевой формат. В результате взаимодействующие программы избавлены от потребности знания специфики машинно-зависимых представлений данных. Возможно, именно протокол XDR обладает определяющим значением в связке протоколов вызова удаленных процедур (хотя, конечно, возможности XDR довольно ограничены).

Наконец, видимо наиболее перспективным на сегодняшний день является подход, предложенный и специфицированный международным консорциумом Object Management Group (OMG). Опять- таки, основная идея проста. Как бы мы не стремились выработать единые языковые средства для разработки распределенных информационных систем, похоже реально унификация невозможна. Имеется много разных подходов, каждый из которых в чем-то превосходит другие. Нельзя сказать, что какой-то подход является определяющим. Пожалуй, единственное, на чем сходится подавляющее большинство исследователей и разработчиков распределенных программных систем, это склонность к использованию парадигмы объектной ориентации.
Достоинство этой парадигмы в том, что объектно-ориентированный стиль проектирования и разработки программных систем (и в особенности информационных систем) стимулирует повторное использование программных компонентов (за счет наличия механизма наследования классов), обеспечивает независимость использования информационных ресурсов от особенностей их реализации (за счет применения принципов инкапсуляции), наконец, при проектировании и разработке информационных систем позволяет производить комплексную разработку структур данных и управляющих ими процедур (с применением технологии объектно-ориентированных систем баз данных).
Но проблема состоит в том, что отсутствует общая объектная модель. В разных объектно-ориентированных системах программирования и системах баз данных гораздо больше общего, чем различного, но их различия часто принципиальны настолько, что объекты, разработанные и созданные в разных системах, не способны взаимодействовать. Они не интероперабельны. Это, конечно, очень плохо. И особенно плохо по той причине, что постоянное наращивание возможностей Internet делает принципиально возможным использование информационных ресурсов вне зависимости от их реального расположения.
Активность OMG предлагает ограниченное, но практически достижимое решение этой проблемы. Это общая архитектура Object Management Architecture (OMA) и ее конкретное воплощение Common Object Request Broker Architecture (CORBA). Мы остановимся только на наиболее ключевых аспектах. Прежде всего, поскольку на сегодня отсутствует (и вряд ли появится в ближайшем будущем) объектная модель, которая могла бы служить "общей крышей" для существующих объектно-ориентированных языков и систем программирования, то единственным практически возможным выходом была выработка минимальной объектной модели, обладающей ограниченными возможностями, но имеющая явные аналоги в наиболее распространенных объектных системах. В архитектуре CORBA такая минимальная модель называется Core Object Model, и ей соответствует язык спецификации (не программирования!) интерфейсов объектов Interface Definition Language (IDL).
Чтобы обеспечить возможность взаимодействия объекта, существующего в одной системе программирования, с некоторым объектом из другой системы программирования, в исходный текст первого объекта (правильнее сказать, его класса) должна быть помещена спецификация на языке IDL интерфейса того объекта, метод которого должен быть вызван. Аналогичная спецификация должна быть помещена на стороне вызываемого объекта. Далее исходные тексты должны быть обработаны соответствующим прекомпилятором IDL (таких прекомпиляторов должно иметься ровно столько, сколько поддерживается интероперабельных объектных сред; специфицированы правила встраивания IDL в программы на языках Си, Си++ и Smalltalk). Спецификация интерфейса объекта на языке IDL представляет собой главным образом набор сигнатур методов объекта. В каждой сигнатуре определяется имя метода, список имен и типов данных входных параметров, а также список имен и типов данных результатов выполнения метода. Кроме того, IDL позволяет определять структурные типы данных (конечно, прекомпилятор IDL на основе определений таких типов производит спецификации типов целевой системы программирования).
Что же является результатом работы прекомпилятора? Все очень похоже на RPC. На стороне клиента генерируется текст объекта-stub, который играет роль локального представителя удаленного объекта. Работа с этим объектом-посредником происходит по правилам соответствующей системы программирования: в среде Си++ stub - это объект Си++, в среде Smalltalk stub - это объект Smalltalk и т.д. С другой стороны, в коде, генерируемом в stub, заложены знания о том, что требуется сделать для обращения к методу удаленного объекта.
На стороне сервера генерируется текст объекта-sceleton, своего рода посредника при доступе к удаленному объекту. С одной стороны, sceleton "знает", что обращение является удаленным. С другой стороны такой посредник умеет обращаться к удаленному объекту по правилам его системы программирования.
Конечно, для доставки сообщения от клиента к серверу и получения ответных результатов должен существовать системный (вернее, полусистемный - middle-ware) компонент, отвечающий именно за выполнение таких функций. В архитектуре CORBA такой компонент называется брокером объектных заявок (Object Request Broker - ORB). В функции ORB главным образом входит передача данных в машинно-независимом формате от клиента серверу и от сервера клиенту. Кроме того, ORB отвечает за правильное указание сетевого адреса объекта-сервера.
Интерфейс между stub, sceleton и ORB основан на специфицированном в описании архитектуры CORBA интерфейсе прикладного уровня (Application Programmer Interface - API). Этот интерфейс открыт для программистов. На нем основан метод динамического вызова объектов без потребности спецификации их интерфейсов на языке IDL. Естественно, программирование на уровне API ORB является гораздо более обременяющим делом, чем, если бы использовался IDL. Однако иногда интерфейсы вызываемых удаленных объектов просто неизвестны в статике; их можно получить только на стадии выполнения программы, и тогда без использования API обойтись не удается.

OMG не обладает правами международной организации по стандартизации. Тем не менее, принимаемые в этой организации документы обладают исключительно высоким международным авторитетом и становятся фактическими стандартами. Проблемой стандарта OMG CORBA было то, что отсутствовала стандартизация взаимодействий уровня ORB-ORB. В результате ORB'ы, производимые разными компаниями, не могли совместно работать. Теперь уже ORB'ы не понимали друг друга. В прошлом году OMG приняла новый стандарт CORBA-2, в котором специфицирован протокол взаимодействий между ORB'ами. Реализации этого протокола уже появились, и имеется надежда на реальное использование информационных ресурсов Internet.
Конечно, CORBA - это далеко не все, что требуется. На сегодня это сложная и далеко непонятная тема - семантическая интероперабельность объектных систем.

1. С. Кузнецов. Переносимость и интероперабельность информационных систем и международные стандарты.
2. С. Кузнецов. СУБД в архитектуре "клиент-сервер"