Москва, В-334, 117900 Вавилова 30/6, leonidk@ipian23.ipian.msk.su
Рассматриваемая технология применима к произвольным компьютеризованным системам. Говоря об информационных системах, мы лишь подчеркиваем, что особенно нас будут интересовать автоматизированные системы с базами данных. Рассматриваемая технология привела к выделению нового архитектурного слоя - информационной архитектуры систем, определяющей способность совместного использования, совместной деятельности (в дальнейшем будет использоваться термин "интероперабельность") компонентов систем для решения задач.
Компонентами системы являются произвольные информационные ресурсы - программные компоненты, базы данных, базы знаний, файлы данных (включая мультимедийную информацию), компоненты существующих информационных систем, и др. независимо от аппаратно-программных платформ их реализации и размещения в пространстве. Этот слой расположен обычно над сетевой архитектурой, являющейся необходимой предпосылкой такой совместной деятельности компонентов, обеспечивающей их взаимосвязь.
Деятельность по созданию технологии интероперабельных систем является беспрецедентной по масштабам. Наиболее существенный вклад в принимаемые идеологические, архитектурные и технологические решения интероперабельных систем вносит Object Management Group (OMG) - крупнейший в мире консорциум разработки программного обеспечения, включающий свыше 500 членов - компаний - производителей программного продукта, разработчиков прикладных систем и конечных пользователей. Так, например, в OMG входят: Air Force Institute of Technology, American Airlines, Apple Computers, ATAMPT, 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, а также аспекты, представляющие интерес для читателей журнала "СУБД" и находящиеся в состоянии исследований и развития.
В настоящей статье мы предлагаем краткий обзор структуры и компонентов архитектуры интероперабельных информационных систем в соответствии с их текущим состоянием.
Функционирование систем в условиях информационной и реализационной неоднородности, распределенности и автономности информационных ресурсов системы. Информационная неоднородность ресурсов заключается в разнообразии их прикладных контекстов (используемых онтологических средств - понятий, словарей; отображаемых реальных объектов, составляющих "поверхность соприкосновения" различных реальных миров и их (объектов) абстракций в информационных системах; семантических правил, определяющих адекватность совокупностей моделируемых объектов реальности; моделируемых деятельностей; видов данных, способов их сбора и обработки; интерфейсов пользователей и т.д.).
Реализационная неоднородность источников проявляется в использовании разнообразных компьютерных платформ, средств управления базами данных, моделей данных и знаний, средств программирования, операционных систем и т.п.
Интеграция систем. Системы эволюционируют от простых, автономных подсистем к более сложным, интегрированным системам, основанным на интероперабельном взаимодействии компонентов.
Реинженерия систем. Эволюция деловых процессов - это непрерывный процесс, который является неотъемлемой составляющей деятельности организаций. Соответсвенно, создание системы и ее реконструкция (реинженерия) - непрерывный процесс формирования, уточнения требований и конструирования. Реконструкция систем осуществляется постепенно. Система должна быть сконструирована так, чтобы произвольные ее составляющие могли быть реконструированы при сохранении целостности системы.
Миграция унаследованных систем. Любая система после создания противодействует изменениям и имеет тенденцию быстрого превращения в бремя организации (т.н. legacy systems - унаследованные системы, использующие "уставшие" технологии, архитектуры, платформы, а также собственно программное и информационное обеспечение, при проектировании которых не были предусмотрены нужные меры для их пошаговой миграции в новые системы, соответствующие новым требованиям деловых процессов и технологии). Существенно, что в процессе миграции необходимо, чтобы мигрировавшие составляющие системы и оставшиеся компоненты унаследованных систем сохраняли интероперабельность.
Повторное использование неоднородных информационных ресурсов. Технология разработки информационных систем должна позволять крупномасштабно применять технологию повторного использования информационных ресурсов, переходя от технологии программирования, основанной на интенсивном индивидуальном труде по созданию вручную изделий, удовлетворяющих специфическим требованиям одного конкретного применения, к технологии, основанной на планируемых капиталовложениях в разработку повторно-используемых компонентов, которые могут быть "соединены" (т.е., образованы их интероперабельные сообщества) для производства серий стандартизованных продуктов в определенной прикладной области.
Продление жизненного цикла систем. В условиях исключительно быстрого технологического развития требуются специальные меры, обеспечивающие необходимую продолжительность жизненного цикла.
Существенно, что свойство интероперабельности информационных ресурсов является необходимой предпосылкой удовлетворения перечисленных требований.
Традиционно к такому промежуточному слою относились средства управления и доступа к данным, средства разработки программ, средства управления распределенными вычислениями (включая поддержку необходимых протоколов взаимодействия), средства поддержки пользовательского интерфейса и др. Такие инфраструктуры использовались как отдельными компаниями (IBM), так и в международных проектах (UNIX - ориентированная интеграционная среда) [1]. Применяемые идеи и технологии не позволяли до сих пор решить радикально архитектуру промежуточного слоя.
OMG на основе объектной технологии и идеи интероперабельности вводит концепцию промежуточного слоя последовательно, радикально и до конца. Технически интероперабельность компонентов (представляемых объектами) решена введением базовой объектной модели, унифицированного языка спецификации интерфейсов объектов, отделением реализации компонентов от спецификации их интерфейсов, введением общего механизма поддержки интероперабельности объектов (брокера объектных заявок, играющего роль "общей шины", поддерживающей взаимодействие объектов). Тем самым достигается однородность представления компонентов и их взаимодействия. Далее, для формирования информационной архитектуры вводится слой унифицированных (ортогональных) служб, которые используются как при конструировании прикладных систем, так и для формирования функционально законченных средств промежуточного слоя, предлагающих конкретные виды услуг. Существенно, что и службы, и средства представляются однородно своими объектными интерфейсами, что позволяет обеспечить их интероперабельность посредством брокера объектных заявок.
Одним из интересных следствий этого подхода, иллюстрирующим его радикальность, является реализация в информационной архитектуре функций СУБД совокупностью объектных служб.
Объектная модель OMG. Объектная модель OMG определяет общую объектную семантику для спецификации базовых характеристик объектов стандартным, независимым от реализации образом.
Объектная модель OMG определяется в виде объектной модели - ядра (Core Object Model - COM) и совокупности расширений. Объектная модель - ядро - специфицирует некоторый набор базовых понятий. Примерами понятий COM являются объекты, операции, типы, отношение тип/подтип, наследование, интерфейс типа. Каждое расширение вводит дополнительный набор понятий. Расширяться может либо COM, либо уже существующие и согласованные расширения. При этом вводится понятие профиля, как некоторой комбинации COM, и одного или нескольких расширений, вместе поддерживающих определенную целевую архитектуру.
Эталонная модель архитектуры OMG. Эталонная Модель [15] определяет концептуальную схему для поддержки технологии, удовлетворяющей техническим требованиям OMG. Она идентифицирует и характеризует компоненты, интерфейсы и протоколы, составляющие Архитектуру Управления Объектами OMG (Object Management Architecture - OMA), не определяя, впрочем, их детально. Обобщенная схема OMA представлена на Рис.2.
Согласованная с OMA прикладная система состоит из совокупности классов и экземпляров, взаимодействующих при помощи Брокера Объектных Заявок (Object Request Broker - ORB)2)
Объектные Службы (Object Services) представляют собой коллекцию служб, снабженных объектными интерфейсами и обеспечивающих поддержку базовых функций объектов. Общие Средства (Common Facilities) образуют набор классов и объектов, поддерживающих полезные во многих прикладных системах функции. Прикладные объекты представляют прикладные системы конечных пользователей и обеспечивают функции, уникальные для данной прикладной системы.
Ниже основные компоненты OMA рассматриваются подробнее.
На основании совместных предложений ряда ведущих компаний (таких, как DEC, HP, HyperDesk, NCR, Object Design, SunSoft) OMG был разработан стандарт Общей Архитектуры Брокера Объектных Заявок (Common Object Request Broker Architecture - CORBA) [9]. CORBA определяет среду для различных реализаций ORB, поддерживающих общие сервисы и интерфейсы (Рис.3). Это обеспечивает переносимость клиентов и реализаций объектов между различными ORB.
Интерфейсы объектов могут быть определены и помещены в Репозиторий Интерфейсов (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.
Такой подход позволяет достичь распределенности системы, соответствия типов, безопасности (при необходимости от самой слабой до самой сильной) и унифицируемости при вызове операций, независимо от того, размещаются ли объект и обратившийся к нему клиент в одном адресном пространстве, на одной машине, или удалены друг от друга.
Spring организована как микроядерная система. Она почти полностью реализована в виде набора менеджеров объектов (например, файловая система, поддерживающая объекты-файлы), выполняющихся в непривилегированном режиме и часто в различных адресных пространствах. Как следствие, добавить новую функцию к системе столь же легко, как и написать прикладную программу в Spring, причем каждая такая функция становится неотъемлемой частью распределенной системы. Все сервисы и объекты, доступные в одном узле, также доступны и в других узлах данной распределенной среды.
Реальным примером расширяемости системы может служить реализация эмуляции UNIX. Подсистема эмуляции будет целиком реализована на пользовательском уровне, не будет использовать "реальный" код UNIX и обеспечит совместимость на уровне исполняемого кода для большого набора программ Solaris. Подсистема использует сервисы, предоставляемые базовой системой Spring, и реализует только специфические для ОС UNIX средства, которые в Spring не имеют эквивалентов (например сигналы). Для того, чтобы реализовать эмуляцию Solaris, не требуется никакой модификации в самой системе Spring.
Общая характеристика. Объектные Службы представляют собой набор услуг (интерфейсов и объектов), которые обеспечивают базовые функции, необходимые для реализации и использования другими объектами. Операции, предоставляемые Объектными Службами, выступают в качестве базовых "строительных" блоков для Общих Средств и прикладных объектов.
Объектная служба может включать отдельный объект (например, объект службы времени), множество объектов с одним и тем же типом интерфейса (например, объекты очередей) или множество объектов с различными типами интерфейсов, наследуемыми из одного типа интерфейса службы (например, все объекты, обеспечивающие службу жизненного цикла).
Интерфейсы Объектных Служб являются модульными (отдельный объект может использовать некоторые, или все Объектные Службы), легко расширяются и настраиваются. Предоставляемые Объектными Службами операции доступны посредством интерфейсов, определенных на IDL или его расширении, совместимом с объектной моделью OMG. Наличие объектного интерфейса не требует объектно-ориентированной реализации службы. Объекты клиентов могут не использовать реализации базовых операций, предоставляемые Объектными Службами (например, объект может предоставлять свой собственный способ хранения данных; объект, моделирующий процесс, может не поддерживать транзакции).
В настоящее время OMG приняты или находятся в процессе формирования спецификации следующих служб:
Рассмотренные выше службы далеко не исчерпывают всех возможных кандидатов на эту роль. В ходе дальнейшей работы 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 обладает существенно новыми чертами, включая манипулирование данными произвольной сложности, вызов методов, полиморфизм типов на основе позднего связывания, введение выражений путей в композиционной структуре объектов, работу с произвольными объектами (независимо от их времени жизни).
OMG сформулировала основые задачи Службы Объектных Запросов (Object Query Service - OQS) следующим образом:
Объединенное предложение. Служба Объектных Запросов реализует функции запросов над коллекциями объектов. Запросы могут формулироваться посредством объектных производных языка SQL или других объектных языков запросов. В данном контексте в понятие "запрос" включаются также функции манипулирования коллекциями объектов.
Служба Объектных Запросов должна предоставлять возможность объектам и пользователям выполнять запросы над произвольными коллекциями других объектов. Запросы являются декларативными утвержденими, содержащими предикаты над атрибутами и операциями объектов, а также позволяющими вызывать произвольные сервисы в среде OMG. Запросы могут быть адресованы любым объектам, временно или постоянно хранимым. Должно быть предусмотрено использование механизмов вторичной индексации.
В средах с базами данных (реляционными, объектно-ориентированными и другими) Служба Объектных Запросов должна иметь правильные отображения в собственные механизмы этих систем. Иерарахическая и федеративная структура, позволяющая интегрировать разнообразные вычислители запросов и автономные системы запросов, показана на Рис.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), выборе федеративной архитектуры, включающий решение проблемы отображения моделей данных, выбор спецификации Службы Коллекций Объектов.
Не следует ожидать, что все проблемы будут легко решены: многие из них являются фундаментальными.
Рассматриваемая ниже архитектура Общих Средств также является предварительной и при уточнении должна согласовываться с общей архитектурой OMG.
Общие Средства подразделяются на две категории: "горизонтальные" и "вертикальные" наборы средств.
"Горизонтальный" набор средств определяет операции, используемые во многих системах и не зависящие от конкретных прикладных систем. "Вертикальный" набор средств представляет технологию поддержки конкретной прикладной системы (вертикального сегмента рынка, включающего здравоохранение, производство, управление финансовой деятельностью, САПР и т.д.). При этом возможна эволюция Общих Средств, связанная с миграцией вертикальных средств, которые оказываются общими для ряда прикладных систем, в набор горизонтальных средств. Следует отметить, что грань между Объектными Службами и Общими Средствами, также как и между Общими Средствами и прикладными объектами, не является жестко фиксированной. Она может изменяться вместе с развитием объектной технологии. Архитектурные требования определения Общих Средств аналогичны требованиям, которые должны выполняться при определении Объектных Служб.
Ниже кратко рассматривается набор средств, вошедших в предварительные спецификации архитектуры Общих Средств OMG [11, 12, 13].
Средства поддержки пользовательского интерфейса (User Interface Common Facilities). Средства поддержки пользовательского интерфейса включают средства, облегчающие прикладному программисту разработку интерфейсов прикладных систем. Сюда входят:
Хотя перечисленные методы основаны на объектной модели, они зачастую используют различные понятия и терминологию.
Согласно Object Analysis and Design Special Interest Group [2] в составе OMG, разработка систем включает в себя этапы стратегического планирования, анализа, проектирования и реализации.
Стратегическое планирование. Целью этапа стратегического планирования является определение основных функций системы, методов взаимодействия системы с внешним миром (человеком, другими системами), стратегии разработки системы с учетом организационных, финансовых и технических ограничений.
Анализ. Целью этапа анализа является получение полного и детального описания проблемной области, не зависящего от среды реализации.
Проектирование. Целью этапа проектирования является уточнение модели системы, полученной на этапе анализа для адаптации к реальной среде реализации и определение возможности использования существующих систем.
Реализация. Целью этапа является конкретная реализация системы.
При разработке сложных систем часто бывает недостаточно ее одностороннего рассмотрения. Методы OAD предоставляют разработчику различные модели для описания системы: объектную, динамическую и функциональную.
Объектная (структурная) модель используется для описания структуры системы: классов (типов объектов), их атрибутов и операций и связей между типами (классами). Примеры объектных моделей: диаграмма отношений объектов, иерархия типов, диаграммы часть-целое.
Динамическая модель используется для описания поведения объектов внутри системы. Примеры динамических моделей: список событий, диаграммы переходов состояний, диаграммы запросов объектов.
Функциональная модель используется для описания процессов предметной области. Примеры функциональных моделей: диаграммы функциональной декомпозиции, диаграммы потока данных.
В настоящее время OMG изучает необходимое развитие объектных моделей OMG для применения в целях объектного анализа и проектирования систем и для моделирования разнообразных прикладных объектов при использовании стандартов OMG.
В [3] введено понятие полной семантически интероперабельной инфраструктуры, обеспечивающей необходимые моделирующие, методологические и архитектурные средства анализа, принятия решений, доказательных рассуждений и реализации, ориентированные на повторное использование ресурсов в семантически интероперабельных композициях. Эта инфраструктура считается дополнительной по отношению к архитектуре OMG [4]. Этот подход предполагает наличие полных спецификаций существующих ресурсов и прикладных областей, включая их структуру и функции, ограничения целостности (инварианты), спецификации деятельностей (потоков работ). Спецификации ресурсов и прикладных областей должны включать также их контекстные описания. Контекстная спецификация предоставляет информацию, необходимую для правильной интерпретации экстенсиональных и интенсиональных предложений, составляющих спецификацию ресурса (предметной области). Базовыми компонентами контекстной спецификации являются онтологические спецификации, представляющие собой описания понятий контекста как контекстно-зависимых знаний, включающих необходимые правила.
Предполагается, что существующие информационные ресурсы являются технически интероперабельными. Их полные спецификации образуются в результате трансформации, унификации, обобщенного представления первоначальных спецификаций ресурсов. Информационные ресурсы содержат факты, правила и демонстрируют поведение, которые имеют определенную интерпретацию в прикладном контексте ресурса. Каждый ресурс сопровождается онтологическими спецификациями, позволяющими склеивать ресурсы в непротиворечивую композицию в контексте прикладной области. Такая композиция должна быть конкретизацией прикладной задачи. Для спецификации и проектирования семантически интероперабельных информационных систем используются специальные языки и методологии проектирования [3,5].
Нетрудно видеть, что разрабатываемая архитектура специально ориентирована на достижение целей - насущных потребностей разработки прикладных систем, сформулированных в начале статьи:
Информационные ресурсы (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). Объект, который может жить дольше, чем процесс, который его породил. Долговременные объекты существуют до момента их явного удаления.
Институт проблем информатики Российской академии наук
2) Термин "заявка", поставленный в соответствие термину request, представляется более уместным, чем, например, термин "запрос" ввиду того, что последний соответствует термину "query" который также используется в информационной архитектуре.
3) Термин "гнездовые", поставленный в соответствие термину nested, представляется более точным, чем используемый термин "вложенные".
