Д.О. Брюхов, В.И. Задорожный, Л.А. Калиниченко, М.Ю. Курошев, С.С. Шумилов

Москва, В-334, 117900 Вавилова 30/6, leonidk@ipian23.ipian.msk.su

1. Введение
2. Актуальные потребности применений
3. Концепция информационной архитектуры систем
4. Брокер Объектных Заявок
5. Проникновение идей OMG за пределы промежуточного слоя: система Spring
6. Развитие информационной архитектуры: Объектные Службы
7. Функции СУБД в информационной архитектуре
8. Проблемы согласованной службы запросов для информационной архитектуры
9. Развитие информационной архитектуры: Общие Средства
10. Объектные методологии роектирования
11. Семантическая интероперабельность
12. Заключение
Литература
Приложение. Словарь понятий

1. Введение

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

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

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

Деятельность по созданию технологии интероперабельных систем является беспрецедентной по масштабам. Наиболее существенный вклад в принимаемые идеологические, архитектурные и технологические решения интероперабельных систем вносит Object Management Group (OMG) - крупнейший в мире консорциум разработки программного обеспечения, включающий свыше 500 членов - компаний - производителей программного продукта, разработчиков прикладных систем и конечных пользователей. Так, например, в OMG входят: Air Force Institute of Technology, American Airlines, Apple Computers, AT&T, Bellcore, Boeing Computer Services, Borland International, Chase Manhattan Bank, Digital Equipment, Fujitsu, General Electric, Hewlett-Packard, IBM, ICL, Informix Software, Intel, Los Alamos National Lab., Microsoft, MIT, Oracle, Siemens AG, SunSoft, Sybase, Texas Instruments, US Defense Information Systems Agency. Целью OMG является создание согласованной информационной архитектуры, опирающейся на теорию и практику объектных технологий и общедоступные для интероперабельности спецификации интерфейсов информационных ресурсов. Эта архитектура должна обеспечивать повторное использование компонентов, их интероперабельность и мобильность, опираясь на коммерческие продукты.

Другие организации, которые работают в кооперации с OMG, например, с целью доведения результатов OMG до официальных стандартов в различных аспектах, включают: ANSI, ISO, CCITT, ANSA, X/Open Company. С OMG сотрудничает Object Database Management Group (ODMG), разрабатывающая промышленный стандарт объектных баз данных, согласованный с решениями OMG.

Развитие технологии за пятилетний период деятельности OMG столь значительно, что уместно говорить о создании новых общепринятых архитектур для распределенных вычислений вообще.

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

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

2. Актуальные потребности применений

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

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

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

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

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

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

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

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

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

3. Концепция информационной архитектуры систем

Основу информационной архитектуры систем составляет концепция промежуточного слоя (middleware) - сосредоточение родовых служб в специальном слое архитектуры, расположенном между операционной системой и средствами управления компьютерными сетями и прикладными системами, специфическими для конкретных областей применения (Рис.1.) [1].

Picture 1

Рисунок 1.

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

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

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

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

Объектная модель OMG определяется в виде объектной модели - ядра (Core Object Model - COM) и совокупности расширений. Объектная модель - ядро - специфицирует некоторый набор базовых понятий. Примерами понятий COM являются объекты, операции, типы, отношение тип/подтип, наследование, интерфейс типа. Каждое расширение вводит дополнительный набор понятий. Расширяться может либо COM, либо уже существующие и согласованные расширения. При этом вводится понятие профиля, как некоторой комбинации COM, и одного или нескольких расширений, вместе поддерживающих определенную целевую архитектуру.

Эталонная модель архитектуры OMG. Эталонная Модель [15] определяет концептуальную схему для поддержки технологии, удовлетворяющей техническим требованиям OMG. Она идентифицирует и характеризует компоненты, интерфейсы и протоколы, составляющие Архитектуру Управления Объектами OMG (Object Management Architecture - OMA), не определяя, впрочем, их детально. Обобщенная схема OMA представлена на Рис.2.

Picture 2

Рисунок 2.

Согласованная с OMA прикладная система состоит из совокупности классов и экземпляров, взаимодействующих при помощи Брокера Объектных Заявок (Object Request Broker - ORB)2)

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

Ниже основные компоненты OMA рассматриваются подробнее.

4. Брокер Объектных Заявок

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

На основании совместных предложений ряда ведущих компаний (таких, как DEC, HP, HyperDesk, NCR, Object Design, SunSoft) OMG был разработан стандарт Общей Архитектуры Брокера Объектных Заявок (Common Object Request Broker Architecture - CORBA) [9]. CORBA определяет среду для различных реализаций ORB, поддерживающих общие сервисы и интерфейсы (Рис.3). Это обеспечивает переносимость клиентов и реализаций объектов между различными ORB.

Picture 3

Рисунок 3.

Интерфейсы объектов могут быть определены и помещены в Репозиторий Интерфейсов (Interface Repository) двумя способами: статически, т.е. описываются на Языке Определения Интерфейсов CORBA (Interface Definition Language - IDL), или динамически. Репозиторий представляет компоненты интерфейса как объекты и обеспечивает доступ к ним во время выполнения.

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

Клиент может также непосредственно взаимодействовать с ORB. ORB ищет соответствующий код, пересылает параметры заявки и передает управление Реализации Объекта (Object Implementation). Реализация Объекта принимает заявку через сгенерированный компилятором IDL скелетон (skeleton) и при этом может обращаться к Объектному Адаптеру (Object Adapter) и ORB. Когда обработка заявки завершена, управление и выходные значения возвращаются клиенту.

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

Мобильны также и реализации объектов для разных ORB при условии, что последние поддерживают заданное языковое отображение и имеют требуемые Объектные Адаптеры.

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

Объектный Адаптер является основным средством доступа к услугам ORB со стороны объектной реализации. Эти услуги обычно включают: генерацию и интерпретацию объектных ссылок, вызов методов, активизацию/деактивизацию реализации и объекта, регистрацию реализаций. Предполагается наличие нескольких широко доступных объектных адаптеров с интерфейсами, соответствующими определенным видам объектов.

В настоящее время существует ряд промышленных реализаций ORB, соответствующих стандарту CORBA [9]. CORBA непрерывно совершенствуется OMG. Текущий уровень стандарта - CORBA 2.0.

5. Проникновение идей OMG за пределы промежуточного слоя: система Spring

Идеи CORBA начинают проникать в архитектурные слои ниже промежуточного. Так, в проекте Spring [7], посвященном архитектуре операционной системы, рассчитанной на распределенные среды и на многопроцессорные платформы, основополагающими являются понятия строгих интерфейсов, открытости и расширяемости. Следуя этому, интерфейсы объектов Spring определены средствами IDL, не зависящими от языков программирования.

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

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

Реальным примером расширяемости системы может служить реализация эмуляции UNIX. Подсистема эмуляции будет целиком реализована на пользовательском уровне, не будет использовать "реальный" код UNIX и обеспечит совместимость на уровне исполняемого кода для большого набора программ Solaris. Подсистема использует сервисы, предоставляемые базовой системой Spring, и реализует только специфические для ОС UNIX средства, которые в Spring не имеют эквивалентов (например сигналы). Для того, чтобы реализовать эмуляцию Solaris, не требуется никакой модификации в самой системе Spring.

6. Развитие информационной архитектуры: Объектные Службы

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

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

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

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

В настоящее время OMG приняты или находятся в процессе формирования спецификации следующих служб:

  • Служба Уведомления Объектов о Событии (Event Notification Service). Служба обеспечивает извещение заинтересованных объектов о происходящих в системе событиях. Объект может выступать в качестве "производителя" или "потребителя" некоторого события. Для обеспечения асинхронного взаимодействия множества производителей событий с множеством их потребителей используются специальные объекты - "каналы событий", которые являются стандартными объектами CORBA. Сами события объектами не являются.
  • Служба Жизненного Цикла Объектов (Object Lifecycle Service). Служба поддерживает создание, удаление, копирование и перемещение объектов. Для создания объектов используются специальные объекты - "фабрики объектов" (object factories). Для определения положения таких объектов используется понятие локатора фабрики (factory finder). Для локаторов определена операция поиска, которая возвращает последовательность соответствующих фабрик. Клиенты задают локатор фабрик как параметр в операциях создания, копирования и перемещения. Такой подход к копированию и перемещению объектов обеспечивает независимость от ORB и механизма хранения. Операция удаления определяется для любого объекта, поддерживающего базовый интерфейс службы жизненного цикла. Модель удаления обеспечивает различные механизмы поддержки целостности ссылок. Поддерживается "поверхностное" и "глубокое" копирование.
  • Служба Именования Объектов (Name Service). Служба обеспечивает отображение между именами и объектами (связывание имен). Связывание имени всегда определяется относительно некоторого контекста именования. Контекст именования - это объект, который содержит множество связываний имен, и каждое имя в нем уникально. Несколько имен могут связываться с объектом в одном или различных контекстах одновременно. Необязательно, однако, чтобы все объекты были именованными. Поскольку контекст подобен другим объектам, он также может быть связан с именем в некотором контексте именования. При этом формируется направленный граф именования с узлами, представляющими контексты. Такой граф допускает более сложные имена для обращения к объекту. Если задан контекст, последовательность имен определяет путь в графе именования. Служба поддерживает распределенные объединения пространств именования.
  • Служба Долговременного Хранения Объектов (Persistent Object Service). Служба обеспечивает сохранение объекта независимо от времени жизни клиентов, осуществляющих доступ к объекту, и от реализации, обеспечивающей выполнение методов объекта. Состояние объекта представляется динамической частью (определяет представление в оперативной памяти и может не поддерживаться в течении всего периода жизни объекта), и статической частью, которая используется для реконструкции динамической части. Служба предоставляет общие интерфейсы к механизмам, обеспечивающим сохранение статического состояния объекта и управление этим состоянием. Ключевой идеей объектных систем, критической для службы хранения, является возможность интеграции в данной архитектуре новых и уже существующих систем хранения.
  • Служба Управления Конкурентым Доступом (Concurrency Control Service). Поддерживает конкурентный доступ к одному или более объектам со стороны одного или более объектов. Интерфейс службы позволяет выполнять вычисления в рамках транзакции (автоматическое освобождение блокировок по завершении транзакции - commit или abort), либо нетранзакционно (ответственность за своевременное разблокирование ложится на пользователя ). Служба управления конкурентным доступом гарантирует сериализуемость транзакционных и нетранзакционных вызовов по отношению друг к другу. Служба управления конкурентным доступом используется совместно со Службой управления транзакциями для координации выполнения конкурентных транзакций.
  • Служба Внешнего Представления Объектов (Externalization Service). Спецификация службы определяет протоколы и соглашения по внешнему и внутреннему представлению объектов. Внешнее представление используется при записи объекта в поток передачи данных. Объекты, которые поддерживают соответствующие интерфейсы и чьи реализации удовлетворяют соответствующим соглашениям, могут быть направлены в поток (в память, в дисковый файл, через сеть и т.д.) и впоследствии преобразованы в новый объект в том же или в другом процессе. Допускается множество форм внешнего представления объекта, которые могут передаваться вне среды ORB и преобразовываться во внутреннее представление в среде другого ORB.
  • Служба Объектных Связей (Relationships Service). Служба обеспечивает средства для создания, удаления, навигации и управления связями между объектами. Служба определяет два новых вида объектов: связь и роль. Роль представляет CORBA-объект в некоторой связи. Объект-связь создается на основании множества ролей, передаваемого в фабрику связей. На связях можно задавать и проверять ограничения типа и кардинальности, при нарушении которых возникают исключительные ситуации. Служба не вводит новую систему типов. Для представления связей и ролей используется система типов IDL. Интерфейсы связей и ролей могут расширяться дополнительными атрибутами и операциями. Служба позволяет связывать так называемые немутабельные объекты.
  • Служба Транзакций (Transaction Service). Служба предоставляет гарантию того, что вычисления поддерживают некоторые, или все присущие транзакциям ACID свойства (атомарность, непротиворечивость, изолированность, постоянство). Транзакционная служба поддерживает два вида транзакций: плоские (flat) и гнездовые (nested)3). Клиент может посылать заявки к множеству объектов, размещенных в различных узлах сети в рамках области действия транзакции. Поддержка таких распределенных транзакций требует от ORB возможности передачи "контекста транзакции" с каждой заявкой.
  • Служба Изменения Объектов (Change Management Service). Поддерживает идентификацию и согласованную эволюцию объектов. Сюда входит управление версиями существующих объектов, связанными наборами или конфигурациями объектов, и преобразованиями между соответствующими представлениями объектов.
  • Служба Лицензирования (Licensing Service). Служба обеспечивает среду для спецификации и управления лицензионной политикой.
  • Служба Объектных Свойств (Properties Service). Позволяет связывать с объектом динамически создаваемые атрибуты. Посредством интерфейса, определенного службой, информация может быть связана с состоянием объекта (например, его заголовком или датой). Свойства являются динамическими эквивалентами атрибутов CORBA. Служба позволяет определять имена свойств, перечислять их, задавать им значения, получать значения по именам и удалять их.
  • Служба Объектных Запросов (Object Query Service). Осуществляет операции над наборами объектов. Операции имеют основанную на предикатах декларативную спецификацию и могут возвращать наборы объектов как результат. Служба запросов не должна нарушать инкапсуляцию объектов. Далее служба запросов рассматривается детальнее.
  • Служба Безопасности Объектов (Object Security Service). Контролирует доступ к объектам. Данная служба действует в пределах всей распределенной системы. Безопасность имеет дело с такими понятиями, как конфиденциальность и целостность информации, ответственность пользователей за свои действия, доступность информации. Дополнительные возможности в обеспечении безопасности могут предоставляться Общими Средствами, использующими ядро системы безопасности, реализуемое службой безопасности.
  • Служба Объектного Времени (Time Service). Поддерживает механизм синхронизации в распределенной системе.

Помимо рассмотренных выше, имеется также, ряд служб, которые впоследствии были связаны с другими компонентами OMA (Общими Средствами и Брокером). Так к Общим Средствам отнесены организация архивов (archive service), резервное копирование (backup service) и восстановление (restore service), операционный контроль (operational control service). К функциям ORB отнесены поддержка репозитория реализаций (implementation repository), инсталляция и активизация объектов и реализаций (installation and activation service), поддержание репозитория интерфейсов (interface repository), обеспечение механизма дублирования информации (replication service), запуск объектных служб (startup services service).

Рассмотренные выше службы далеко не исчерпывают всех возможных кандидатов на эту роль. В ходе дальнейшей работы OMG, вероятно, будут выделены и приняты дополнительные Объектные Службы.

7. Функции СУБД в информационной архитектуре

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

Спецификация служб формируется на основе опыта промышленных корпораций, входящих в состав OMG. Существенное влияние на архитектурные решения оказывают также исследования и разработки, воплощенные в согласованном стандарте интерфейсов объектных СУБД [8], опубликованном в конце 1993 г. группой ODMG (Object Database Management Group). Эта группа включает представителей основных компаний - производителей объектных СУБД. Публикация стандарта ODMG-93 является важным событием: все фирмы-члены ODMG обязались сделать выпускаемые ими продукты соответствующими этому стандарту. Важно, что при разработке модели данных ODMG приняла решение базироваться на объектной модели данных OMG.

Предложенный ODMG язык определения объектов (Object Definition Language - ODL) является расширением языка IDL. Основными дополнительными типами языка являются типы коллекций (тип множества, мультимножества, массива, списка) и типы связей, напоминающие типы наборов КОДАСИЛ [6].

Стандарт ODMG-93 включает спецификацию объектного языка запросов (Object Query Language - OQL). Первоначальная версия языка определена независимо от языка SQL: объектный язык запросов обладает более богатой семантикой. Впоследствии принято решение принять в OQL синтаксис SQL"92, не уменьшая его (OQL) семантической мощности. OQL обладает существенно новыми чертами, включая манипулирование данными произвольной сложности, вызов методов, полиморфизм типов на основе позднего связывания, введение выражений путей в композиционной структуре объектов, работу с произвольными объектами (независимо от их времени жизни).

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

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

OMG сформулировала основые задачи Службы Объектных Запросов (Object Query Service - OQS) следующим образом:

  1. ORB должен превратиться в стандартный шлюз для доступа к массовым данным организаций, сохраняя в то же время традиционный сервис баз данных (в том числе реляционных) и обеспечивая совместимость с моделью данных CORBA IDL. Потенциально существует возможность слияния и унификации различных конкурирующих объектных инфраструктур (например, тех, что поддерживаются проектом стандарта ODMG-93 и планируемых SQL3).
  2. Необходимо повысить совместимость различных стандартов. В настоящее время стандарты OMG, ODMG и проект стандарта ISO/ANSI SQL3 не так далеки друг от друга. Вместе с тем может потребоваться значительное время для их согласования. Работа над Службой Объектных Запросов предоставляет уникальную возможность для трех указанных сообществ выработать унифицированную спецификацию.
  3. Использовать (в рамках общей инфраструктуры) существующие сложные реляционные и объектные механизмы запросов, файл-серверы, и механизмы поддержки вторичных индексов, на основании которых осуществляется доступ к массовым данным организаций. Такие данные являются результатом крупных капиталовложений. Поэтому Служба Объектных Запросов должна быть реализована так, чтобы имелась возможность повторного использования существующих механизмов на основе федерации неоднородных моделей данных и механизмов запросов.
  4. Интерфейсы Службы должны быть объектными, использовать объектную модель данных OMG и быть выражены на IDL.
  5. Должны быть предусмотрены меры по интеграции с новыми службами (например службой изменений и службой управления копированием) и сопряжению со службами коллекций, жизненного цикла объектов, объектных связей, объектных свойств и постоянного хранения объектов.

К январю 1995 г. OMG были представлены следующие основные варианты спецификаций Службы Объектных Запросов:

  1. Объединенное предложение IBM, Itasca, Objectivity, Ontos, O2, Servio, SunSoft, Sybase, Taligent;
  2. Предложение Oracle;
  3. Предложение Texas Instruments (TI).

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

Объединенное предложение. Служба Объектных Запросов реализует функции запросов над коллекциями объектов. Запросы могут формулироваться посредством объектных производных языка SQL или других объектных языков запросов. В данном контексте в понятие "запрос" включаются также функции манипулирования коллекциями объектов.

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

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

Picture 4

Рисунок 4.

Предложение предполагает использовать один из двух языков запросов: SQL-9x (SQL-92 и будущий стандарт, основанный на разработке SQL3) и OQL-9x (очевидно, тот вариант OQL, в котором обеспечивается синтаксическая совместимость с SQL-9x).

Служба Объектных Запросов базируется на Объектной Модели OMG. Реляционная модель считается подмножеством объектной модели. Модель ODMG дополнительно вводит конструкции, которые отображаются в операции модели OMG. Определены коллекции и интерфейсы Службы Объектных Запросов.

Предложение Oracle. Служба Объектных Запросов основана на языке запросов SQL и на объектном расширении SQL. Абстрактные типы данных SQL3 вводят объектную модель данных, отличную от модели OMG. Семантика службы полностью определяется языком SQL. Все операторы языка SQL инкапсулированы посредством интерфейсов IDL. Определены отображения типов данных IDL, употребляемых в качестве параметров и результатов интерфейсных функций IDL, в типы данных SQL. В целом отображение объектной модели данных SQL3 в модель данных OMG проблематично. В этом заключается основная слабость этого предложения.

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

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

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

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

9. Развитие информационной архитектуры: Общие Средства

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

Рассматриваемая ниже архитектура Общих Средств также является предварительной и при уточнении должна согласовываться с общей архитектурой OMG.

Общие Средства подразделяются на две категории: "горизонтальные" и "вертикальные" наборы средств.

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

Ниже кратко рассматривается набор средств, вошедших в предварительные спецификации архитектуры Общих Средств OMG [11, 12, 13].

Средства поддержки пользовательского интерфейса (User Interface Common Facilities). Средства поддержки пользовательского интерфейса включают средства, облегчающие прикладному программисту разработку интерфейсов прикладных систем. Сюда входят:

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

Средства управления информацией (Information Management Common Facilities). Информация может храниться как в структурированном виде в базах данных, так и в виде текстов, изображений и т.п. Средства управления информацией включают:

  • средства информационного моделирования. Традиционно средства моделирования определяются как средства структурирования данных, средства манипулирования данными и средства поддержки целостности информации. В объектной парадигме данные и операции моделируются единообразно в рамках общей системы типов;
  • средства хранения и поиска информации. Речь идет об обеспечении высокоуровневых спецификаций хранения и поиска иформации для широкого класса прикладных систем. Главными проблемами здесь являются отсутствие стандартов для доступа к информационным системам (даже SQL существует в разных версиях), а также стандартных средств метаописания запрашиваемой информации;
  • средства кодирования и представления данных, формирующие самый нижний уровень моделирования информации. Эти средства должны обеспечивать, в частности, сжатие и декомпрессию данных, а также преобразование между внутренним и каноническим представлением;
  • средства поддержки коллекций объектов, предназначенные для обеспечения единообразного способа создания и манипулирования наиболее общими видами коллекций, используемых в компьютерных системах (множества, очереди, стеки, списки, бинарные деревья и т.п.), независимо от объектов, входящих в коллекции.

Средства управления системой (System Management Common Facilities). Средства управления системой включают:

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

Средства управления задачами (Task Management Common Facilities). В набор средств управления задачами входят:

  • средства поддержки потоков работ (workflow), обеспечивающие управление и координацию объектов, представляющих некоторый рабочий процесс;
  • средства управления агентами. Система агентов является одним из верхних уровней представления семантики взаимодействия компонентов, основанного на архитектуре OMG. Средства управления агентами призваны, в частности, облегчить процесс интеграции унаследованных систем;
  • средства управления сообщениями, поддерживающие коммуникации высокого уровня для разработчиков прикладных интероперабельных систем.

Вертикальные общие средства (Vertical Common Facilities). Вертикальные общие средства предназначены для использования в качестве стандартных для обеспечения интероперабельности в специфических прикладных областях. Сюда входят:

  • средства работы с изображениями, включающие IDL-спецификации для доступа и обработки изображений;
  • средства поддержки международной информационной супермагистрали, реализующие коммерческие операции, поиск информационных ресурсов, проведение телеконференций и т.п. в среде супермагистрали;
  • средства поддержки прикладных систем для бизнеса и производства (контроль качества продукции, САПР, маркетинг, финансы, операции с банковскими счетами и т.д.);
  • распределенные моделирующие средства, включающие управление авиаперевозками, ситуационное моделирование для военных и игровых целей и т.д.;
  • средства поддержки разведывательных работ и производства в газовой и нефтяной промышленности. Следует отметить, что по инициативе ряда ведущих компаний данной отрасли, в 1991 году была начата работа по созданию стандартов, которые позволили бы повысить эффективность информационного обеспечения предприятий. Эти работы учитываются OMG при выработке стандартов соответствующих общих средств;
  • средства поддержки разработки прикладных систем, включающие средства анализа, разработки, построения и развития информационных систем предприятий.

10. Объектные методологии роектирования

Разработка информационных систем является трудоемким процессом. Упрощению и ускорению их создания способствуют методы Объектно-Ориентированного Анализа и Проектирования систем (Object Analysis and Design - OAD). OAD - это способ разработки систем при использовании объектной технологии на протяжении всего процесса разработки. Основными преимуществами методов OAD по сравнению с традиционными методами (в частности структурным анализом) являются:

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

К настоящему времени разработано большое число различных методов OAD, например: OOD [17], OMT [20], OOA&OOD&OOP [18,19], Objectory [21] и др.

Хотя перечисленные методы основаны на объектной модели, они зачастую используют различные понятия и терминологию.

Согласно Object Analysis and Design Special Interest Group [2] в составе OMG, разработка систем включает в себя этапы стратегического планирования, анализа, проектирования и реализации.

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

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

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

Реализация. Целью этапа является конкретная реализация системы.

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

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

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

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

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

11. Семантическая интероперабельность

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

В [3] введено понятие полной семантически интероперабельной инфраструктуры, обеспечивающей необходимые моделирующие, методологические и архитектурные средства анализа, принятия решений, доказательных рассуждений и реализации, ориентированные на повторное использование ресурсов в семантически интероперабельных композициях. Эта инфраструктура считается дополнительной по отношению к архитектуре OMG [4]. Этот подход предполагает наличие полных спецификаций существующих ресурсов и прикладных областей, включая их структуру и функции, ограничения целостности (инварианты), спецификации деятельностей (потоков работ). Спецификации ресурсов и прикладных областей должны включать также их контекстные описания. Контекстная спецификация предоставляет информацию, необходимую для правильной интерпретации экстенсиональных и интенсиональных предложений, составляющих спецификацию ресурса (предметной области). Базовыми компонентами контекстной спецификации являются онтологические спецификации, представляющие собой описания понятий контекста как контекстно-зависимых знаний, включающих необходимые правила.

Предполагается, что существующие информационные ресурсы являются технически интероперабельными. Их полные спецификации образуются в результате трансформации, унификации, обобщенного представления первоначальных спецификаций ресурсов. Информационные ресурсы содержат факты, правила и демонстрируют поведение, которые имеют определенную интерпретацию в прикладном контексте ресурса. Каждый ресурс сопровождается онтологическими спецификациями, позволяющими склеивать ресурсы в непротиворечивую композицию в контексте прикладной области. Такая композиция должна быть конкретизацией прикладной задачи. Для спецификации и проектирования семантически интероперабельных информационных систем используются специальные языки и методологии проектирования [3,5].

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

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

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

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

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

Литература

  1. Майкл Л. Броди. "Интероперабельные информационные системы в науке" - Сборник материалов семинара, Москва, апрель 6-7, 1995.
  2. Hutt A. (editor). Object Analysis and Design. Description of methods. Object management group. John Wiley and Sons. 1994. p. 202
  3. Калиниченко Л.А. СИНТЕЗ: язык определения, проектирования и программирования интероперабельных сред неоднородных информационнных ресурсов (вторая редакция) Сентябрь 1993.
  4. Kalinichenko L.A. A Complementary Architecture Integrating Industrial and Semantic Interoperation Environments. Institute for Problems of Informatics, Russian Academy of Sciences, Technical Report, 1993.
  5. Kalinichenko L.A. Emerging semantic-based interoperable information system technology. Computers as our better partners. Proceedings of the International IISF/ACM Symposium, Tokyo, World Scientific, 1994.
  6. Язык описания данных КОДАСИЛ, Москва, Статистика, 1981
  7. Митчел Д., Гиббонс Д., Гамильтон Г., Кесслер П., Халиди Ю. и др. Система Spring: общий обзор. Открытые системы. N 1, 1995.
  8. The Object Database Standard: ODMG-93. Ed. by R.G.G. Cattell, Morgan Kaufmann Publ., 1994.
  9. Object Management Group, "The Common Object Request Broker: Architecture and Specification", OMG Document Number 91.12.1, December 1991.
  10. Object Management Group, "Object Services Architecture", Revision 8.0, 09 December 1994.
  11. Object Management Group, "Common Facilities Architecture", Revision 2.0, September 1994.
  12. Object Management Group, "Common Facilities Architecture", Revision 3.0, November 1994.
  13. Object Management Group, "Common Facilities Roadmap", Revision 3.1, January 1995.
  14. OMG, "Common Object Services Specification Volume1 (COSS1), March 1994.
  15. Object Management Group, "Object Management Architecture Guide", OMG Document Number 92.11.1, September 1, 1992.
  16. Wiederhold G., Wegner P., Ceri S. Toward megaprogramming. CACM, v. 35, N 11, November 1992.
  17. G.Booch, Object-Oriented Analysis and Design with Applications, Benjamin/Cummings Series in OO Software Eng., 1994.
  18. P. Coad and E. Yourdon, Object-Oriented Analysis (Second Edition), Prentice Hall, 1991.
  19. P. Coad and E. Yourdon, Object-Oriented Design, Prentice Hall, 1991.
  20. J. Rumbaugh et al., Object-Oriented Modeling and Design, Prentice Hall, 1991.
  21. I. Jacobson, M. Christerson, P. Jonsson,G. Overgaard, Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley, 1992.

Приложение. Словарь понятий

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

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

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

Реинженерия (Re-engineering). Реконструкция системы, непрерывный процесс формирования, уточнения требований и конструирования систем.

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

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

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

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

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

Общие средства (Common Facilities). Родовые средства, полезные в предопределенных прикладных областях, доступные посредством унифицированных спецификаций интерфейсов и просто специализируемые в конкретных применениях.

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

Объект (Object). Комбинация состояния и множества методов, которая воплощает абстракцию, характеризующуюся определенным поведением для допустимых заявок. Объект имеет тип (типы) и является экземпляром класса (классов). Объект моделирует некоторую сущность реального мира, инкапсулирует реализацию (состояние и операции, внутренне реализуемые как данные и методы) и отвечает на заявки, требующие обслуживания. Методы могут быть собственностью одного или нескольких объектов. Заявки могут направляться одному или нескольким объектам. Данные состояния могут быть собственностью одного или нескольких объектов. Данные состояния и методы могут располагаться в одном или разных местах.

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

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

Брокер объектных заявок (Object Request Broker). Обеспечивает средства, с помощью которых объекты выдают и принимают заявки и ответы.

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

Институт проблем информатики Российской академии наук

1) Эта работа выполнена в рамках проекта Российского Фонда Фундаментальных Исследований, грант 94-07-20453

2) Термин "заявка", поставленный в соответствие термину request, представляется более уместным, чем, например, термин "запрос" ввиду того, что последний соответствует термину "query" который также используется в информационной архитектуре.

3) Термин "гнездовые", поставленный в соответствие термину nested, представляется более точным, чем используемый термин "вложенные".