1. Введение
2. Концепции и принципы объектного подхода
3. Объектные, распределенные технологии на основе спецификаций консорциума OMG
4. ODMG - разработка стандартов для объектных баз данных
5. Продукты компании Iona Technologies, поддерживающие спецификацию CORBA
6. Заключение
Литература

1. Введение

Разработка корпоративных информационных систем (ИС) является одной из крупнейших проблем в информационных технологиях.

Основной принцип управления любой сложной системой был известен давно: "devide et impera" - "разделяй и властвуй". Согласно этому принципу, сложная программная система на верхнем уровне должна состоять из небольшого числа относительно независимых компонентов с четко определенными интерфейсами. Затем декомпозиции подвергаются выделенные на первом этапе компоненты, и так далее до заданного уровня детализации. Таким образом система представляется иерархией с несколькими уровнями абстракции.

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

1.1. Основные принципы структурного подхода

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

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

1.2. Неоднородность ресурсов в распределенных системах

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

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

2. Концепции и принципы объектного подхода

2.1. Классы и объекты

Основные понятия объектно-ориентированного подхода - объект, класс и экземпляр.

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

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

Таким образом, объект - это типичный представитель класса, а термины "экземпляр объекта" и "элемент класса" равнозначны.

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

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

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

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

Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов.

2.2. Особенности применения объектного подхода

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

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

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

3. Объектные, распределенные технологии на основе спецификаций консорциума OMG

Две рассмотренные выше концепции - объектно-ориентированный способ разработки и распределенные вычисления - стали основными предметами рассмотрения для созданного в апреле 1989 года консорциума Object Management Group (OMG), членами которого сейчас являются более 500 ведущих компьютерных компаний, таких как Sun, DEC, IBM, HP, Motorola и др. Задачей консорциума является разработка спецификаций и стандартов, позволяющих строить распределенные объектные системы в разнородных средах. Основополагающими стали спецификации, получившие название Object Management Architecture (OMA) [1].

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

  • архитектура брокера запросов объектов (CORBA - Common Object Request Broker Architecture) определяет механизмы взаимодействия объектов в разнородной сети [2];
  • сервисы объектов (Object services) являются основными системными сервисами, используемыми разработчиками для создания приложений [3];
  • универсальные средства (Common Facilities) являются высокоуровневыми системными сервисами, ориентированными на поддержку пользовательских приложений, таких как электронная почта, средства печати и т. д.;
  • прикладные объекты (Application Objects) предназначены для решения конкретных прикладных задач.

3.1. OMG CORBA

Спецификация Common Object Request Broker Architecture (CORBA) лежит в основе всех стандартов, разработанных OMG. CORBA определяет механизм, обеспечивающий взаимодействие приложений в распределенной системе [2].

Главными компонентами стандарта CORBA являются:

  • объектный брокер запросов (Object Request Broker);
  • язык определения интерфейсов (Interface Definition Language).

В спецификацию CORBA включено также несколько дополнительных, но очень важных сервисов:

  • сервис динамического формирования запросов (DII);
  • сервис репозитория интерфейсов (IR);
  • сервис динамической обработки запросов (DSI);
  • сервис, обеспечивающий взаимодействие различных брокеров запросов (GIOP).

3.2. Роль CORBA в построении распределенных систем

Концептуально спецификация CORBA относится к двум верхним уровням семиуровневой модели взаимодействия открытых систем [4]. Характерные особенности проведения разработок в технологии CORBA заключаются в следующем.

  • Язык описания интерфейсов OMG IDL позволяет определить интерфейс, независимый от языка реализации.
  • Высокий уровень абстракции CORBA в семиуровневой модели OSI избавляет программиста от работы с низкоуровневыми сетевыми протоколами.
  • Программисту не требуется информация о месте сервера в сетевой ИС и способе его активации.
  • Разработка клиентской программы не зависит от серверной операционной системы и аппаратной платформы.

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

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

3.4. Объектный брокер запросов (ORB)

Спецификация CORBA разработана для обеспечения возможности интеграции разных объектных систем. На рис. 3 показано место главного компонента спецификации - брокера объектных запросов.

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

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

Клиент может запрашивать выполнение операций с помощью ORB несколькими способами. На рис. 4 показаны возможные варианты взаимодействия объектов.

Вызов операций разделяемого объекта-сервера может быть статическим, через IDL-суррогат, или динамическим (Dynamic Invocation Interface). В случае статического вызова описания интерфейсов на IDL отображаются в программный код на языках С, С++, Smalltalk и др. При использовании динамического интерфейса запросы формируются специальным образом, без отображения интерфейса объекта в исходный код разрабатываемого приложения.

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

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

3.5. Базовый объектный адаптер BOA

Основная функция объектного адаптера, используемого для реализации CORBA-объекта, - обеспечение доступа к сервисам брокера объектных запросов. Объектный адаптер предоставляет все низкоуровневые средства для связи объекта с его клиентами [2][5]. В число этих средств входят:

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

Спецификация OMG CORBA определяет базовый объектный адаптер, который должен быть реализован во всех брокерах запросов. Basic Object Adapter (BOA) - это набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активизации приложений.

Роль базового объектного адаптера в архитектуре CORBA иллюстрирует рис. 5.

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

3.6. IDL - язык описания интерфейсов

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

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

Описание интерфейса на IDL состоит из заголовка и тела. Заголовок содержит название интерфейса и указывает наследуемые интерфейсы. Тело состоит из объявлений констант, типов, исключительных ситуаций, атрибутов и операций. IDL - не полный язык программирования. Он является языком, описывающим интерфейс. Для конкретной реализации объекта генерируется его отображение в один из полных языков, таких как С++, C, ADA, Smalltalk. Отображение также является предметом стандартизации OMG. В настоящее время описаны отображения в С++, С, Smalltalk. Ведется работа по спецификации отображения IDL в язык Java.

В качестве примера приведем фрагмент описания интерфейса на языке IDL.

interface Account {
// Определения типов, атрибутов и т.д.
attribute long Balance;
long deposit ( in long dollars); // операция
                               // языка IDL
        // будет отображена в метод объекта,
// доступного для удаленного вызова
};

interface CheckingAccount : Account {
// Дополнительные атрибуты и операции
attribute long cachBalance;
};

interface Person {
long addAccount ( in Account account);
long removeAccount (in Account account) raises (No_Account);
};

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

3.7. Динамический интерфейс вызова (DII)

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

3.8. Репозиторий интерфейсов (Interface Repository)

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

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

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

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

3.9. Протоколы взаимодействия различных объектных брокеров (GIOP, IIOP)

Основной задачей спецификации CORBA является обеспечение взаимодействия объектов, распределенных по разнородной сети и использующих в общем случае различные брокеры запросов. Для связи между брокерами был разработан протокол General Inter ORB Protocol (GIOP), стандартизующий низкоуровневое представление данных и множество форматов сообщений.

Internet Inter ORB Protocol (IIOP) определяет обмен сообщениями в формате GIOP через TCP/IP-соединения. В последнее время протоколу IIOP уделяется все больше внимания со стороны крупнейших производителей программного обеспечения. IIOP становится признанным стандартом для вызова удаленных объектов в Internet.

При необходимости протокол GIOP может быть реализован на основе других транспортных протоколов, например IPX/SPX. На рис. 6 показана иерархия спецификаций взаимодействия брокеров запросов по стандарту CORBA.

3.10. Основные объектные сервисы стандарта CORBA

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

Однако очевидно, что в большинстве ИС требуется некоторое множество системных объектных сервисов, которые не зависят от предметной области и обеспечивают базовую функциональность для управления распределенными объектами. С целью облегчения создания распределенных приложений консорциум OMG стандартизовал наиболее часто употребляемые сервисы (спецификация CORBAservices 1.0) [3]. Мы кратко рассмотрим характеристики основных сервисов архитектуры CORBA.

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

Event service обеспечивает поддержку асинхронного взаимодействия приложений.

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

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

Relationship service реализует логические связи между CORBA-объектами. Сервис определяет два дополнительных типа объектов: связь и роль. Роль представляет собой CORBA-объект, отражающий характер связи, а связь характеризует зависимости объектов прикладной области.

Concurrency control service позволяет клиентам координировать свои действия при использовании разделяемых ресурсов. Управление разделяемыми ресурсами осуществляется с помощью блокировок. Каждая блокировка ассоциируется с единственным ресурсом и единственным клиентом. Сервис определяет также несколько режимов блокировок, которые соответствуют различным способам доступа.

Externalization service формирует копию CORBA-объекта в виде некоторого внешнего представления - файла, элемента базы данных и т. д.

3.11. Универсальные средства (Common Facilities)

Универсальные средства предоставляют поддержку интерфейсов высокого уровня и делятся на два типа: горизонтальные и вертикальные [5].

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

  • средств пользовательского интерфейса. Они покрывают аспекты, касающиеся представления информации, и включают инструменты для разработки интерфейса, средства для автоматизации этой работы, спецификации на рабочий стол (desktop) пользователя и т. д.
  • средств управления информацией. Они предоставляют операции, с помощью которых можно моделировать, описывать, сохранять, выбирать, перемещать информацию и обмениваться ею. Предполагается, что данный набор должен состоять из следующих спецификаций.
  1. Информационное моделирование (определяет правила, по которым осуществляется структуризация и доступ к информации).
  2. Хранение и выборка информации (определяет использование баз данных и систем каталогов).
  3. Информационный обмен.
  4. Стандарты перекодировки и представления, поддерживающие обмен информацией через разделяемые ресурсы, сетевые протоколы или программные интерфейсы;
  • средств управления системой. Они задают множество утилит, реализующих функции системного администрирования, то есть определяют интерфейсы основных операций, отвечающих за управление, мониторинг, безопасность, конфигурирование и т. д.
  • средств управления задачами. Предполагается, что данный набор будет представлен четырьмя спецификациями: службы управления потоками работ (workflow facility), службы программных агентов (agent facility), службы управления правилами (rule management facility), службы автоматизации (automation facility).

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

  • средств обработки изображений. Специфицируют доступ и обмен графическими данными. Роль этой службы заключается в поддержке приложений конечного пользователя по проверке, обработке, визуализации и сохранению графических данных.
  • средств поддержки информационной супермагистрали (superhighway facility). Специфицируется множество сетей, протоколов и правил их использования, а также множество репозиториев информации и набор средств, обеспечивающих пользователям и приложениям доступ к этой информации.
  • средств интегрированного автоматизированного производства. Обеспечивают интеграцию производственных функций предприятия с помощью компьютеров. В число объединяемых функций могут входить также управление процессами разработки, контроль качества, финансовые и маркетинговые операции.
  • средств эмуляции распределенных процессов. Службы этой спецификации должны обеспечить базис, на основе которого возможно быстрое построение и функционирование эмулируемой модели.
  • средств информатизации в газовой и нефтяной промышленности. Эта предметная область характеризуется большим количеством данных и высокой сложностью алгоритмов.
  • средств финансовых коммуникаций (accounting facility). Включают все формы коммерческих транзакций: обмен валюты, управление платежами, продажами и т. п.
  • средств поддержки разработки приложений. Обслуживают выбор, разработку, построение и эволюцию приложений, составляющих корпоративную информационную систему. Данные спецификации включают средства анализа, проектирования, реализации, тестирования и поддержки системы.

4. ODMG - разработка стандартов для объектных баз данных

Object Database Management Group (ODMG) была сформирована для выработки стандартов объектных баз данных. В отличие от OMG, фокусирующей свою деятельность на обеспечении интероперабельности приложений, ODMG стремится к обеспечению мобильности исходных текстов программ. Это подразумевает, что должны быть стандартизированы языки доступа к базам данных (но не внутренняя реализация программных продуктов). Разработанный стандарт ODMG 93 определяет общую объектную модель и общий язык для баз данных [6]. Эти меры призваны обеспечить необходимый уровень переносимости приложений.

4.1. Объектная модель данных ОDBMS

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

- Связи между объектами. ODMG/OM определяет представление этих связей, управление ими и их использование.

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

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

- Специальный тип "база данных", позволяющий БД быть представленной как объект в объектной модели данных.

4.2. Архитектура ODA

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

Все объекты БД тем не менее доступны для брокера запросов, поэтому возможен их удаленный вызов в распределенной разнородной среде.

Как упоминалось выше, каждый объектный адаптер, разработанный для архитектуры с брокером запросов, имеет специальное назначение. Например, в функции рассмотренного ранее базового объектного адаптера BOA входит отображение каждой операции над объектом в удаленный вызов процедуры (RPC). Объектный адаптер баз данных ODA имеет две специальные характеристики:

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

4.3. Стандартизация языков определения объектов и запросов к базам данных

Поскольку любая развитая БД поддерживает языки определения данных, манипулирования данными и выполнения запросов, стандарт для БД должен определять их семантику и синтаксис. В необъектных базах данных общеупотребимыми названиями для этих языков являются язык определения данных (data definition language), язык манипулирования данными (data manipulation language) и язык запросов (query language). Стандарт ODMG определяет работу с объектами, поэтому названия языков претерпели соответствующие трансформации: в стандарте ODMG 93 специфицируются языки определения объектов (ODL) и объектных запросов (OQL). ODMG не стандартизует язык манипулирования объектами. Вместо этого ODMG определяет, как отобразить необходимые манипуляции со структурами и объектами на обычные объектно-ориентированные языки программирования, такие как C++ и Smalltalk.

4.3.1. Язык определения объектов (ODL)

Язык определения объектов (ODL) расширяет язык определения интерфейсов IDL. Он позволяет определить атрибуты, связи, операции и типы данных.

Главная цель этого языка - обеспечить переносимость приложений, созданных для разных объектных баз данных. Язык ODL отображается в различные языки программирования, что позволяет определенной с его помощью схеме базы данных быть независимой от программной среды и продуктов СУБД. За счет инвариантности по отношению к среде реализации приложений и баз данных ODL дает программисту возможность задавать семантику поведения объектов, абстрагируясь от деталей реализации.

4.3.2. Язык объектных запросов (OQL)

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

4.4. Реляционные СУБД в объектных системах

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

Объектная оболочка может служить не только средством преобразования моделей данных. Она способна обеспечивать доступ к РБД разных производителей, то есть включать в себя логику по распределению данных и управлению ими [9].

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

5. Продукты компании Iona Technologies, поддерживающие спецификацию CORBA

5.1. Orbix 2.0 - реализация стандарта CORBA 2.0

Orbix - это мощное средство компании IONA Technologies, предназначенное для построения и интеграции распределенных приложений. Orbix позволяет определять программные интерфейсы объектов, используя стандартный язык. Доступ к этим объектам разрешен из любого узла распределенной системы, что является одной из главных особенностей данного продукта [12] [13].

Orbix 2.0 - полная реализация стандарта OMG Common Object Request Broker Architecture 2.0, поддерживающая отображение языка IDL в С++, а также несколько дополнительных средств разработки, не описанных в специфкации.

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

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

5.1.1. Определение интерфейсов

В распределенной системе возможна реализация объектов с применением различных языков программирования. Orbix позволяет использовать язык C++, анонсированы реализации продукта для языков ADA и Smalltalk. В случае применения С++ каждый IDL-интерфейс реализуется в виде класса на C++. Этот класс должен содержать все методы и параметры, которые соответствуют IDL-операциям и атрибутам. Для каждого IDL-интерфейса возможно реализовать более чем один С++ класс. Это позволяет иметь различные реализации объектов-серверов для одного интерфейса, что может потребоваться в многоплатформенных системах.

5.1.2. Клиенты и серверы

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

5.1.3. Механизмы реализации IDL-интерфейса

Orbix поддерживает два механизма соотнесения IDL-интерфейса с реализующим его С++ классом:

  • BOA-механизм. Класс реализации интерфейса является наследником класса BOAImpl, с помощью которого предоставляется доступ к методам базового объектного адаптера BOA;
  • TIE-механизм. Программист должен явно указать, что класс относится к данному IDL-интерфейсу.

5.1.4. Средства разработки распределенных приложений, реализованные в Orbix

Основные средства

Репозиторий интерфейсов (Interface Repository)

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

Dynamic Invocation Interface

Orbix поддерживает сервис Dynamic Invocation Interface, который позволяет приложению формировать запросы к интерфейсу, неизвестному на стадии компиляции. Такие динамические запросы формируются путем указания во время выполнения имени объекта, реализующего интерфейс, имени операции и параметров вызова.

IIOP - протокол

Orbix поддерживает описанный в спецификации CORBA протокол IIOP для взаимодействия с другими брокерами запросов. С помощью этого же протокола могут быть разработаны связки с другими продуктами, поддерживающими объектный механизм коммуникаций.

Дополнительные средства

Фильтры (Filters)

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

Загрузчики (Loaders)

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

Локаторы (Locators)

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

Smart Proxy

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

5.2. OrbixOTS - сервис управления распределенными транзакциями

Продукт OrbixOTS - это реализация сервиса распределенных транзакций в соответствии со спецификацией OMG CORBAservices 1.0. Продукт разработан совместно компаниями Iona Technologies и Transarc. В его основу положена архитектура известного монитора транзакций Encina, что гарантирует высокие показатели надежности и производительности.

Сценарий работы сервиса распределенных транзакций можно проиллюстрировать следующим примером.

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

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

Затем приложение А выполняет модификацию БД, но не завершает эту транзакцию, поскольку за этот шаг ответственен сервис транзакций.

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

Приложение В модифицирует БД, снова оставляя задачу завершения транзакции сервису транзакций. Управление возвращается приложению А.

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

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

5.3. OrbixWeb - CORBA-совместимый брокер объектных запросов с поддержкой языка Java

В отличие от продукта Orbix, поддерживающего отображение IDL-интерфейсов в язык С++, компилятор языка IDL из OrbixWeb генерирует Java-классы для клиентского и серверного приложений. По всем же функциональным характеристикам OrbixWeb является точной копией Orbix, то есть поддерживает все элементы спецификации CORBA 2.0 и расширения, описанные в разделе 5.1, включая фильтры, локаторы, загрузчики и т. д.

OrbixWeb позволяет разрабатывать как клиентские, так и серверные приложения на языке Java. В то же время оба продукта - Orbix и OrbixWeb - устроены таким образом, что поддерживают прозрачное взаимодействие приложений, созданных с помощью каждого из них. Это означает, например, что клиентское приложение, построенное на языке Java, может обращаться к серверам приложений, разработанных с помощью Orbix на С++, и наоборот.

Совокупность этих двух продуктов позволяет использовать CORBA-технологию в Inernet-ориентированных приложениях. Клиентское приложение может быть разработано в виде загружаемых с Web-сервера Java-аплетов, интерпретируемых стандартным навигатором, а серверное приложение должно обеспечить сервисы, требуемые для функционирования интерфейсных программ.

5.4. Реализация сервиса именования объектов - OrbixNames

Этот продукт полностью реализует стандарт сервиса именования объектов по спецификации CORBAservices 1.0. Именование объектов в распределенной системе производится следующим образом. Разрабатывается иерархическая структура - дерево, которое можно сравнить с обычной файловой системой. Узлами дерева являются так называемые контексты (аналог каталогов) и листья, в которых содержатся ссылки на распределенные объекты. Полное имя объекта есть путь от корня дерева контекстов к листу, содержащему нужную объектную ссылку. На рис. 13 приведен простой пример дерева контекстов.

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

5.5. Сервис событий - OrbixTalk

Еще одним объектным сервисом, реализованным по спецификациям OMG, является система управления событиями в распределенной среде. В соответствии со стандартом, модель сервиса событий предусматривает два типа взаимодействующих объектов - поставщики (suppliers) и потребители (consumers), передающих сообщения через специальный объект - "событийный канал" (Event Channel).

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

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

5.6. Объектный адаптер Orbix+Versant Adapter

Orbix+Versant Adapter (OVA) интегрирует Orbix с объектно-ориентированной базой данных компании Versant Object Technology. С помощью интеграции этих двух продуктов достигаются следующие цели:

  • для Orbix-приложений обеспечивается хранение объектов в долговременной памяти;
  • объекты, хранимые в объектной БД Versant, становятся доступными для удаленного вызова из других CORBA-приложений.

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

5.7. Orbix+Isis - отказоустойчивый брокер объектных запросов

Продукт Orbix+Isis интегрирует объектную среду разработки приложений Orbix и технологию надежной обработки данных компании Isis. Он предназначается для построения высоконадежных распределенных приложений.

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

Программный интерфейс Orbix+Isis представляет собой множество C++ классов, реализующих распределенные вычисления, отказоустойчивость и балансировку загрузки. Приложения разрабатываются с использованием языка IDL, описания которого компилируются в С++. В Orbix+Isis сохранены все возможности стандартного продукта Orbix, в том числе такие, как фильтры и интеллектуальные клиенты (smart proxy). Приложения-клиенты Orbix-серверов остаются неизменными в случае их использования с серверами Orbix+Isis. Серверные приложения требуют минимальных модификаций, добавляющих свойства надежной обработки данных.

5.8.Процесс разработки распределенных приложений с помощью продуктов Iona Technologies

В данном разделе кратко описан процесс разработки распределенных приложений на основе продуктов Orbix.

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

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

Предположим, что IDL-интерфейс имеет приведенный ниже вид и помещается в файл account.idl.

interface Account {
attribute long cash;
void AddCash (in long cashAmount);
void SpendCash (in long cashAmount);
};

Спроектированный IDL-интерфейс объекта необходимо отобразить в используемый язык программирования. Будем считать, что это С++. Компилятором IDL генерируются несколько файлов:

  • заголовочный файл account.hh, в котором описываются все необходимые С++ объекты;
  • файл для серверного приложения accountS.cc;
  • файл для клиентского приложения accountC.cc.

Все внутренние функции Orbix, ответственные за коммуникации, реализованы в генерируемых файлах, а также в библиотеках, подключаемых на стадии компоновки. Теперь необходимо разработать сами клиентские и серверные приложения, то есть реализовать интерфейс Account и вызовы его операций. Интерфейс, описанный на языке IDL, отображается в С++ следующим образом. Строится класс, имеющий доступ к методам базового объектного адаптера BOA.

Class Account_i : public AccountBOAImpl {
// атрибут cash описан в сгенерированном файле // account.hh
// и доступен в результате наследования
public:
        Account_i();
        ~Account_I();
        virtual void AddCash (CORBA::Long cashAmount, CORBA::Environment 
        &IT_env=
                CORBA::default_environment) {
        cash = cash + cashAmount;
        }

        virtual void SpendCash (CORBA::Long cashAmount, CORBA::Environment 
        &IT_env=
                CORBA::default_environment) {
        cash = cash - cashAmount;
        }
};

Реализация методов, описанных в заголовочном файле, и является реализацией операций IDL-интерфейса, доступных для удаленного вызова.

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

Этапы разработки распределенного приложения приведены на рис. 15.

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

Приведем фрагмент кода для вызова серверного объекта.

.... 
Account_i * accRef = Account::_bind (":Account", ""); 
// получена ссылка на удаленный объект Account 
accRef -> AddCash(100); 
// Вызов метода удаленного объекта 
...

После инициализации объектной ссылки (accRef) все операции с ее использованием осуществляются абсолютно аналогично операциям с обычной переменной, являющейся указателем на локальный С++ объект.

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

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

Мы описали процесс разработки распределенных приложений на примере продукта Orbix, где языком реализации является С++. Разработка приложений с помощью продукта OrbixWeb полностью аналогична, за исключением того, что в роли языка реализации выступает Java. Использование продуктов OrbixNames, OrbixOTS, OrbixTalk состоит в разработке клиентских приложений, применяющих предоставляемые сервисы. Все упомянутые продукты и другие объектные сервисы реализованы в виде CORBA-серверов, имеющих строго определенные IDL-интерфейсы.

6. Заключение

Наиболее бурно развивающимся направлением в области информационных технологий в последние годы стала разработка программного обеспечения, связанного с сетью Internet и системами Intranet, опирающегося на Web-технологию и язык Java. Объектные, распределенные технологии консорциумов OMG и ODMG интегрируются в общие тенденции, расширяя и обобщая их. Примечательно, что все ведущие производители систем Internet/Intranet, включая Sun, IBM, Netscape, Microsoft, встраивают в свои продукты поддержку CORBA-совместимых протоколов.

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

Литература

  1. Object Management Group. Object Management Architecture Guide. - 1992.
  2. Object Management Group. The Common Object Request Broker: Architecture and Specification. - 1995.
  3. Object Management Group. CORBAservices: Common Object Services Specification. - 1995.
  4. T.J. Mowbray, R. Zahavi. The Essential CORBA: Systems Integration Using Distributed Objects.
  5. R. Ben-Natan. CORBA - A guide to the Common Object Request Broker Architecture.
  6. Object Database Management Group. The Object Database Standard: ODMG-93. - 1994.
  7. A. Carmichael, Object Development Methods. - SIGS BOOKS, 1994.
  8. N. Ganti. The Transition of Legacy Systems to a Distributed Architecture. - John Wiley & Sons, 1995.
  9. Б. Страуструп. Язык программирования С++.
  10. Д. Брюхов, В. Задорожный, Л. Калиниченко и др. Интероперабельные информационные системы: архитектуры и технологии. - СУБД, 4, 1995.
  11. Л. Калиниченко. Стандарт систем управления объектными базами данных ODMG 93: краткий обзор и оценка состояния. - СУБД, 1, 1996.
  12. Iona Technologies. Orbix 2, Reference guide. 1996.
  13. Iona Technologies. Orbix 2, Programmers guide. 1996.
Юрий Пуха, Jet InfoSystems, (+7 095) 972-1182