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

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

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

  • Кто является потенциальным потребителем информации?
  • Ограничено ли число потенциальных пользователей системы?
  • Какие методы обработки информации должны быть унаследованы системой, а какие - нет, каково расширение функциональности?
  • Планируется ли обмен информацией (или методами обработки информации) с другими информационными системами, если да, то с какими и по каким протоколам?
  • Является ли информация открытой и, если нет, то какой уровень защиты информации должен быть обеспечен?
  • На какие затраты готова пойти организация в связи с реконструкцией системы?

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

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

1. Тиражирование. Подход применим, в основном, к небольшим информационным системам с относительно статичной информацией и несложной функциональностью (например, телефонный справочник). Самодостаточная копия информационной системы распространяется или по сети, или какими-либо другими средствами (например, на CD-ROM).

2. Интерфейс для удаленных пользователей интегрируется в оригинальную систему. Это наиболее трудоемкий путь, влекущий за собой как изменение внутренней организации системы, так и создание необходимой сетевой инфраструктуры.

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

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

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

Объектная модель

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

Рассмотрим теперь, как реально может происходить взаимодействие систем. Предположим, что система A содержит информацию об экологической обстановке и декларирует сервис «получить процент содержания окиси углерода в атмосфере», а в качестве параметров используются географические координаты места и дата. Система B содержит статистику по легочным заболеваниям и декларирует сервис «получить число людей, заболевших астмой», а в качестве параметров используются название города и интервал дат. Система C декларирует сервис «получить географические координаты», в качестве параметра используется название населенного пункта. Система D, не обладая никакими собственными информационными ресурсами, может, тем не менее, вычислить влияние содержания окиси углерода в атмосфере на заболеваемость астмой, пользуясь сервисами, предоставленными системами A, B и C. Больше того, если предположить, что существуют системы, которые декларируют сервиса ориентированные на статистическую обработку и визуализацию информации, разработчики системы D могут воспользоваться и ими, тем самым сводя к минимуму затраты на реализацию. Таким образом, процесс проектирования нового приложения сводится к анализу применимости уже существующих объектов для реализации требуемой функциональности и интеграции их в законченный программный продукт. Недостающие компоненты могут быть разработаны и включены в проект как локальные или, по желанию разработчика, они могут быть оформлены как объекты, доступные для использования в других приложениях.

Сегодня существует несколько идеологий подобного «объектного мира», наиболее известна и проработана из которых идеология, предложенная консорциумом Object Management Group - стандарт Common Object Request Broker Architecture (CORBA) [2].

CORBA

Основная идея, активно развиваемая в CORBA - это возможность построения законченного приложения на основе независимых и распределенных объектов. Разработчик в общем случае ничего не знает о том, как реализован объект и где он физически расположен, ему известно лишь стандартное описание методов объекта (интерфейс). Для определения интерфейсов объектов OMG имеется специальный язык - Interface Definition Language (IDL) и отображения этого языка во многие реальные языки программирования (например, в C++). Описание объекта на языке IDL может выглядеть следующим образом:

// test.idl
// Описание объекта Test 
// c единственным методом Say
interface Test {
string Say(in string mesg);
};

Для облегчения процесса создания приложений OMG разработала и включила в CORBA несколько объектных служб (Object Services) - совокупностей объектов, реализующих определенную функциональность. Например, служба времени (Time Service) обеспечивает синхронизацию в распределенной системе.

Рис. 1. Структура интерфейсов ORB

Базой, обеспечивающей работу приложений, спроектированных на основе CORBA, является Брокер Объектных Заявок (Object Request Broker - ORB). Схема работы приложения, состоящего из распределенных объектов, приведена на рис.1. Как видно из рисунка, приложение (Client) обращается к методам объекта через ORB, в задачи которого входит:

  • прием от клиента информации о запрашиваемом методе (в том числе и параметров);
  • поиск реализации объекта (Object Implementation) в распределенной среде;
  • при необходимости - активизация объекта (порождение экземпляра объекта и выделение ему необходимых вычислительных ресурсов);
  • передача экземпляру объекта параметров запроса;
  • получение и передача результата обратно клиенту;
  • при необходимости - уничтожение порожденного экземпляра объекта.

Стандарт CORBA предполагает несколько вариантов запросов методов объекта.

В простейшем случае - это обращение через статический интерфейс, когда клиент, ORB и реализация объекта находятся в одном адресном пространстве.

В этом случае ORB и реализация объекта могут представлять собой набор библиотек, компонуемых с приложением, а связи устанавливаются на этапе компиляции и компоновки. Интерфейс объекта при этом описывается на языке IDL, после чего из этого описания генерируется IDL Stub - отображение интерфейса в язык программирования, на котором написано приложение. ORB использует заранее заготовленный Static IDL Skeleton (интерфейс обращения к реализации объекта в конкретной вычислительной среде) для активизации методов объекта. Для более сложных случаев предусмотрены динамические вызовы.

В этом случае, с кодом приложения компонуется библиотека, обеспечивающая обращения к ORB на этапе исполнения и обеспечивается взаимодействие ORB и реализация объекта посредством объектного адаптера (Object Adapter), специфичного для конкретной реализации объекта. Для обеспечения динамических обращений стандарт CORBA предусматривает наличие специальной службы, интегрированной в ORB, - хранилища интерфейсов (Interface Repository - IR). Эта служба обеспечивает хранение IDL интерфейсов объектов в форме, пригодной для использования во время исполнения программ. Наличие этой службы позволяет приложению обращаться к методам даже таких объектов, о существовании которых не было известно на этапе компиляции.

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

Для осуществления подобного взаимодействия стандартом CORBA определен протокол межброкерного взаимодействия - General Inter-ORB Protocol (GIOP) и его разновидность, предназначенная для передачи данных по протоколу TCP/IP - Internet Inter-ORB Protocol (IIOP). Это достаточно простой протокол (определены всего семь типов сообщений) подразумевает наличие двух участников взаимодействия: клиента и сервера. В случае межброкерного взаимодействия один ORB выступает в роли клиента, другой - в роли сервера. Протокол позволяет клиенту передать запрос на исполнение метода объекта, управляемого сервером, и принять результаты. Кроме того, протокол обеспечивает оповещение клиента об исключительных ситуациях, которые могут возникнуть при работе метода. Запрос формируется клиентом на основе информации, которою он может извлечь из интерфейса объекта. Разумеется, для формирования корректного запроса клиент должен иметь интерфейс объекта определенной формы, не говоря уже о том, что он хотя бы должен знать о существовании объекта. Стандарт CORBA не определяет четкого механизма распространения брокерами информации о доступных сервисах, однако, рекомендует использовать для этой цели интероперабельные объектные ссылки (Interoperable Object Reference - IOR). IOR формируется из хранящейся в IR брокера объектной ссылки (той, что используется при динамическом вызове методов) и содержит помимо интерфейса объекта его местоположение в распределенной системе. Сформированная IOR распространяется для использования другими ORB.

Рассмотрим теперь во что, в общем случае, трансформируется классическая архитектура клиент-сервер с точки зрения CORBA (рис.2). Пунктиром обозначен логический запрос клиента к серверу.

Рис. 2. Архитектура клиент-сервер в CORBA

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

Enterprise JavaBeans

Рис. 3. Структура EJB

Архитектура Enterprise JavaBeans (EJB) [3], предложенная компанией Sun Microsystems, является наиболее близкой по идеологии к CORBA и предназначена для построения распределенных объектно-ориентированных приложений. Основное отличие состоит в том, что в качестве языка программирования используется Java [4] и не предусмотрены отображения интерфейсов объектов в какие-либо другие языки. Соответственно, подразумевается, что функциональная часть системы будет изначально разрабатываться (или уже разработана) на Java, однако, потребителем не обязательно является Java клиент: спецификацией предусмотрены различные шлюзы, в том числе и для доступа по протоколу IIOP. Обращение клиента к реализации объекта осуществляется не напрямую, а посредством EJB сервера, сходного по своей функциональности с ORB в стандарте CORBA. В работе [3] приводится схема системы, построенной по технологии EJB, которая, для полноты изложения, представлена здесь на рис.3.

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

1. EJB Provider - разработчик enterprise beans. Конечный результат деятельности - ejb-jar файл, содержащий один или несколько компонентов, реализующих ту или иную бизнес функцию.

2. Application Assembler - разработчик приложения. Результат деятельности - законченное приложение, собранное из различных компонентов, представленных EJB Provider.

3. Deployer. Результат деятельности - адаптированные для конкретной вычислительной среды компоненты, представленные как EJB Provider, так и как Application Assembler.

4. EJB Service Provider. На сегодняшний момент, спецификация EJB подразумевает, что роль EJB Service Provider совмещена с EJB Container Provider.

5. EJB Container Provider - поставщик законченных и адаптированных компонентов конечным потребителям. Обеспечивает весь технологический цикл использования Enterprise Beans.

6. System Administrator - обеспечивает функционирование вычислительной и сетевой инфраструктуры, необходимой для работы EJB сервисов.

Архитектура EJB базируется на системах правил, определяющих схемы взаимодействия участников (contract, в терминологии EJB). Например, Client-view contract декларирует набор правил, позволяющих клиенту использовать представленные Container Provider компоненты в своем приложении. В терминах CORBA, Client view - это интерфейс объекта и его IOR. Client-view включает в себя: Home interface; Remote interface; Object identity; Handle; Metadata interface.

Home interface определяет методы, необходимые клиенту для порождения, уничтожения и поиска объектов одного типа (реализованных в пределах одного enterprise bean). Remote interface определяет методы, реализующие те или иные бизнес функции, предоставляемые клиенту. Object identity - уникальный идентификатор объекта в пределах одного enterprise bean. На основе информации, содержащейся в Object identity, клиент формирует статический идентификатор для доступа к экземпляру объекта (Handle). Первые четыре компонента Client-view обеспечивают клиенту доступ к объектам, о существовании которых было известно на этапе разработки приложения (аналог статического интерфейса в CORBA). Metadata interface обеспечивает механизм динамических вызовов (аналогичный механизму динамических вызовов в CORBA).

Рис. 4. Схема распределенной системы, использующей компоненты EJB

Для построения распределенных систем, спецификацией EJB предусмотрены механизмы взаимодействия EJB серверов между собой и механизмы для распространения информации об имеющихся enterprise beans: служба Java Naming and Directory Interface (JNDI). Кроме того, EJB изначально предусматривает механизмы построения распределенных систем, основанные на протоколе IIOP, что подтверждает желание разработчиков стандарта обеспечить максимальную совместимость с CORBA. Схема подобной распределенной системы приведена на рис.4.

Другие технологии

Помимо описанных технологий построения интероперабельных информационных систем, объектная модель может быть реализована с использованием протоколов, изначально ориентированных на работу в системах клиент-сервер. Подобные технологии применимы в том случае, когда разработчики различных компонентов информационной системы работают в тесном сотрудничестве друг с другом, а проблема стандартизации и семантической интерпретации интерфейсов объектов не является основной. Примером такого протокола может служить ONC Remote Procedure Call (RPC) [5], разработанный для удаленного вызова процедур в распределенной вычислительной среде. Данный протокол широко используется сегодня для обеспечения вычислительной и сетевой инфраструктуры на нижнем уровне. С его помощью реализованы, например, сетевые файловые системы (NFS).

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

Интегрирующим ядром различных информационных систем может служить и протокол HTTP [6] - основа технологии WWW. В этом случае, обращение к методу объекта есть ни что иное, как запрос к Web-серверу (объекту) с указанием требуемой страницы (метода) и соответствующих параметров. К достоинствам этого протокола можно отнести его широкую распространенность и сложившуюся систему уникальных имен. К недостаткам - отсутствие четкой типизации параметров и методов распространения семантической информации.

Реконструкция систем клиент-сервер

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

  • получение «сырой» информации из различных источников в различных форматах;
  • обработку «сырой» информации, преобразование ее во внутренний формат представления данных и внесение в систему;
  • обеспечение посредством автоматизированного рабочего места (АРМ) администратора управления информационным массивом;
  • обеспечение посредством АРМ пользователя доступа к информации.
Рис. 5. Структура унаследованной системы

При этом система рассчитана на ограниченное число одновременно работающих пользователей и АРМ спроектированы для работы в локальной сети с использованием собственных протоколов передачи информации.

Локальные клиенты (Local Client) - это АРМ пользователя и АРМ администратора. Загрузчик (Loader) - программные компоненты, обеспечивающие загрузку «сырой» информации в систему.

Цель реконструкции - предоставление всем пользователям глобальной сети ограниченного набора функций АРМ локального пользователя без нарушения работоспособности системы. Для достижения этой цели предлагается использовать структуру, приведенную на рис.6.

Рис. 6. Структура реконструированной системы

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

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

  • формализация методов обработки информации, предоставляемых удаленным клиентам;
  • выбор стандарта интерфейсов этих методов и протокола доступа для глобальных сетей.

Наиболее распространенным решением этих задач сегодня является оформление методов обработки информации в виде динамических HTML страниц и предоставления к ним доступа по протоколу HTTP. В этом случае, программное обеспечение шлюза делится на две составляющие: программное обеспечение Web сервера и программное обеспечение, позволяющее организовать генерацию динамических HTML страниц на основе обращения к серверу информационной системы по «родному» протоколу (Native Protocol).

Такой подход ориентирован на то, что в качестве удаленных клиентов рассматриваются конечные пользователи системы, а в качестве программного обеспечения АРМ удаленного пользователя используется стандартная программа просмотра HTML страниц. Если же в качестве удаленных клиентов рассматривать не только конечных пользователей, но и другие информационные системы, то возможностей, предоставляемых протоколом HTTP, может оказаться недостаточно. В этом случае следует обратить внимание на более общую схему построения шлюза, основанную на одном из стандартов, описывающих объектную модель. На рис.7 приведена схема построения шлюза с использованием технологий CORBA.

Рис. 7. Схема построения IIOP-шлюза

Основными компонентами этого шлюза являются диспетчер (Dispatcher), способный принимать запросы клиентов по протоколу IIOP и объектный адаптер, осуществляющий преобразование IIOP «Native Protocol. Формальное описание сервисов, предоставляемых информационной системой, в данном случае должно быть оформлено с помощью языка IDL и полученные интерфейсы должны быть доступны удаленным клиентам. Диспетчер в данной схеме может (при необходимости) иметь более сложную функциональность, чем просто поддержка протокола IIOP, например, обеспечения механизма транзакций, контроль доступа и нагрузки на сервер. Последнее наиболее актуально для систем, изначально не рассчитанных на работу с неограниченным числом потенциальных пользователей.

Заключение

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

Об авторе

Дмитрий А. Волков - сотрудник компании «Демос-Интернет». С ним можно связаться по электронной почте: vdv@vdv.ru

Литература

[1] С. Клименко, В. Уразметов. «Internet. Среда обитания информационного общества». ОНТИ ПНЦ РАН, 1995

[2] «The Common Object Request Broker: Architecture and Specification». Object Management Group Inc., 1999

[3] Vlada Matena, Mark Hapner. «Enterprise JavaBeans Specification, v1.1». Sun Microsystems, Inc., 1999

[4] Гарольд Э.Р. «Java Beans. Разработка компонентов программного обеспечения». ЛОРИ, 1999

[5] «RFC 1831. RPC: Remote Procedure Call Protocol Specification Version 2». R.Srinivasan. 1995.

[6] «RFC 2616. Hypertext Transfer Protocol — HTTP/1.1». R. Fielding, J. Gettys, J. Mogul, H.Frystyk, L. Masinter, P. Leach, T. Berners-Lee, 1999.