Часть 7. Глобально распределенные информационные системы

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

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

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

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

7.1. Проблема "унаследованных систем" (Legacy Systems)

Во введении к этой части проблема интеграции неоднородных автономно разработанных информационно-вычислительных ресурсов рассматривалась в двух контекстах. Первый контекст - повторное использование (reusability) существующих и доступных по сети ресурсов. Второй контекст - облегчение разработки корпоративных информационных систем, отдельные компоненты которых создаются разными, территориально распределенными группами, каждая из которых в силу исторических причин использует наиболее привычную для нее технологию. Например, канадская компания BNR для разработки новых программных продуктов использует коллективы программистов из разных стран мира. Некоторые группы предпочитают использовать Си++, другие - объектный Лисп, третьи - Smalltalk и т.д. Но в результате должна появиться единая, реально работающая, программная система.

Но имеется и третий контекст, контекст унаследованных систем (legacy systems). В любой крупной, долгое время существующей корпорации накапливаются информационные подсистемы, разработанные в соответствии с морально устаревшими технологиями. Например, трудно найти корпорацию с возрастом больше 25 лет, в которой не использовались бы информационные подсистемы, созданные на основе ранних аппаратно-программных платформ компании IBM. Базы данных таких подсистем содержат громадные объемы ценной информации, и корпорация просто не может обойтись без их использования. С другой стороны, унаследованные системы очень трудно сопровождать и поддерживать. Очень часто программная часть системы написана на языке ассемблера, а люди, которые писали эти программы, больше не работают в корпорации. Возникают проблемы и с аппаратной частью.

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

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

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

7.2. Объектный подход

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

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

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

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

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

7.3. Предложения OMG и ODMG

В этом и следующем разделах, кроме документов OMG и ODMG, использованы материалы статей Л.А.Калиниченко, опубликованных в журнале "СУБД" (N 4 за 1995 г. и NN 1 и 2 за 1996 г.).

OMG (Object Management Group) - это международный консорциум, включающий более 500 компаний, связанных с производством компьютерной аппаратуры и программного обеспечения (в частности, членами OMG являются компании IBM, Digital Equipment, Hewlett Packard, Intel, Microsoft, Borland International, Oracle, Informix Software, Sybase и т.д.). Основной задачей OMG является разработка архитектуры и методов реализации программного обеспечения, которое в объектно-ориентированном стиле позволило бы выполнить интеграцию существующих и заново разрабатываемых (не обязательно объектно-ориентированных) информационно-вычислительных ресурсов. OMG регулярно выпускает спецификационные документы, которые становятся фактическими промышленными стандартами. Основными составляющими подхода OMG являются базовая объектная модель (Core Object Model), эталонная модель архитектуры (OMA - Object Management Architecture) и более приближенная к реализации общая архитектура брокера объектных заявок (CORBA - Common Object Request Broker Architecture).

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

Во-вторых, для реального взаимодействия должным образом настроенных объектов предполагается наличие специального программного обеспечения, называемого в документах OMG брокером объектных заявок (ORB - Object Request Broker). Брокер объектных заявок должен существовать и на стороне вызывающего объекта, и на стороне вызываемого объекта. Основная задача ORB состоит в том, чтобы доставить заявку на вызов метода вызываемого объекта и возвратить результаты выполнения метода вызываемому объекту.

ODMD (Object Database Management Group) - это консорциум, близкий к OMG не только по названию, но и по сути, хотя и преследующий другие цели. В состав ODMG входят компании, производящие объектно-ориентированные СУБД (в частности, Object Design, Objectivity, Ontos, O2 Technology и т.д.). Главной задачей ODMG является попытка выработки стандарта объектно-ориентированных баз данных. В конце 1993 г. ODMG выпустила документ ODMG-93, являющийся первой версией такого стандарта.

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

Объектная модель ODMG-93 основана на базовой объектной модели OMG с рядом расширений, специфичных для объектно-ориентированных баз данных. В частности, в объектной модели ODMG-93 присутствует понятие экстента (extent) объектного типа как множества объектов этого типа (понятно, что без введения такого понятия трудно говорить об объектно-ориентированных базах данных).

Вторым важным компонентом архитектуры ODMG-93 является язык определения объектов ODL (Object Definition Language), который является расширением языка IDL. Следующий компонент архитектуры - язык объектных запросов OQL (Object Query Language). Этот язык синтаксически близок к языку SQL-92, но, естественно, обладает более мощной семантикой. (Интересно, что при этом ODMG находится в весьма сложных отношениях с комитетом, разрабатывающим язык SQL-3, который по замыслу является не объектно-ориентированным, а объектно-реляционным.) Наконец, в документе ODMG-93 определены правила связывания языка OQL с языком Си++ (в качестве первого выбран именно этот язык, поскольку он наиболее распространен в существующих объектно-ориентированных СУБД). Определены общие правила связывания с языком Smalltalk. В дальнейшем предполагается ввести правила связывания и для других языков программирования.

Мы коротко упомянули о работах ODMG только потому, что они близки к направлению OMG. Более того, в ODMG-93 предполагается, что объекты стандартных объектно-ориентированных баз данных должны быть в состоянии взаимодействовать через ORB. Тем не менее, более подробно деятельность ODMG мы рассматривать не будем.

7.4. Промышленный стандарт CORBA

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

Имеется два способа определения интерфейса объекта и помещения его в репозиторий интерфейсов - статический и динамический. Статический способ основан на описании интерфейса объекта на языке IDL. Репозиторий представляет компоненты интерфейса как объекты и обеспечивает доступ к ним.

Для вызова метода объекта-сервера объект-клиент может использовать интерфейс динамического вызова или полагаться на генерируемый компилятором IDL стаб - локальный представитель вызываемого метода.

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

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

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

Объектный адаптер является средством доступа к услугам ORB со стороны объектной реализации. Эти услуги включают генерацию и интерпретацию объектных ссылок, вызов методов, активизацию/деактивизацию реализации, регистрацию реализации. Архитектура OMA предполагает также наличие объектных служб (object services) и общих средств (common facilities). Объектные службы представляют собой набор услуг (интерфейсов и объектов), обеспечивающих базовые функции, которые требуются для реализации других объектов и общих средств. Объектная служба может включать отдельный объект, набор объектов с одним типом интерфейсов или набор объектов с разными типами интерфейсов, наследуемых от одного типа интерфейса объектной службы.

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

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

Назад | Содержание | Вперед