При посылке на вход произвольного объекта OID₂ сообщения OID₁ (которое тоже является объектом), сначала проверяется, содержится ли OID₁ в интерфейсе объекта OID₂ (проверка идентичности). Если да, то выполняется действие объекта OID₁, иначе сравниваются значения OID₁ и объектов интерфейса (проверка эквивалентности). Если соответствие найдено, выполняется действие, указанное в найденном в интерфейсе объекте.

2.8 Принципы взаимодействия объектов

Есть два основных способа управления объектами:

• Посылка сообщений

• Алгебра объектов

Определения операций Select и Pickup алгебры объектов можно найти в [17]. Здесь оно не рассматривается по той причине, что является надстройкой над управлением посылкой сообщений и описывается через механизм посылки сообщений. То есть операции алгебры объектов могут быть заданы через операции посылки сообщений, без исправления структуры СУБД. Полная алгебра объектов является замкнутой и состоит из следующих операций: Select , Pickup , Apply , Expression Apply , Project , Combine , Union , Interselect , Subtract , Collapse , Assimilate . Объектная алгебра более выразительна, чем реляционная, поскольку поддерживает полиморфность. Оператор Select, например, может работать с любыми видами операндов, а не только с множествами.

Согласно [17], любое сообщение в системе является объектом. Любой объект может иметь связанное с ним действие (knowhow), или не иметь его.

Алгоритм определения метода для выполнения

При посылке объекта проверяется, находится ли идентификатор объекта-сооб­ще­ния в интерфейсе объекта-получателя. Если да, то выполняется knowhow, связанное с этим идентификатором. Если нет – проверяется, совпадает ли значение объекта-сооб­щения со значением какого-либо метода из интерфейса объекта-получателя. Если да, то выполняется связанное с этим методом действие. Иначе возвращается объект fail.

Параметры методов

Набор_параметров (Blackboard) представляет собой множество меток, аргумент­ных пар { (L₁, arg₁), … , (L_n, arg_n) }. L_i ÎA, arg_i ÎO для 1 £ i £ n и "i, j Î 1,…,n : i ¹ j Þ L_i ¹ L_i.

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

Синтаксис посылки сообщения

Воздействие(Набор_параметров) Получатель. Объект, называемый Воздействие (Invoker), является сообщением (message) и посылается к другому объекту, названному Получателем (Reciver), используя Набор_параметров, предоставляющий необходимые аргументы. Если параметры в Наборе_параметров отсутствуют, то можно записать короче: Воздействие Получатель. Посланное сообщение всегда возвращает объект, называемый Результат (Result).

Посылка простого сообщения

Пусть B – Набор_параметров и m и r – два объекта в O.

Примитивные взаимодействия

(1) m(B) fail fail; fail(B) r fail;

(2) m(B) null null; null(B) r null;

(когда m fail)

(3) m(B) same same; same(B) r r;

(когда m fail и m null)

При совпадении идентификатора

(4) Если существует метод x из r такой, что x m и sig(x) = (A₁,c₁) … (A_n,c_n) c_r и {(A₁,a₁) … (A_n,a_n)} B и FID каждого поля с_i присутствует в a_i (в терминах ОО-програм­мирования: c_i является предком по значению для a_i), тогда

m(B) r r.kh(x)(A₁ : a₁, … , A_n : a_n )

иначе проверяется совпадение значения.

При совпадении значения

(5) Если существует метод x в r или его объектах-учителях (объектов, от которых наследуется поведение) такой, что x m и sig(x) = (A₁,c₁) … (A_n,c_n) c_r и {(A₁,a₁) …
(A_n,a_n)}B и FID каждого поля с_i присутствует в a_i, тогда

m(B) r r.kh(x)(A₁ : a₁, … , A_n : a_n )

иначе

(6) Если r является атомарным, то m(B) r fail.

Иначе m(B) r является комплексным сообщением (complex message sending), обладает сложной структурой.

Комплексные сообщения

Если Воздействие является объектом-агрегатом, то

s(B) o null, если s=[ ]

s(B) o [A₁ : s₁(B) o₁, …, A_n : s_n(B) o_n], если s=[A₁ : s₁, …, A_n : s_n]

где o_j o, o_{j не} o) и orf(o_i) orf(o) = для j = 1,..,n и для любого i, j [1,..,n], если i j тогда o_{j не} o и orf(o_i) orf(o_j) = (т.е. o₁,…,o_n являются глубокими копиями объекта-получателя o).

Если Воздействие является объектом-условием, то

s(B) o s.then(B) o, если s.if(B) {False, fail}

s(B) o s.else(B) o, иначе.

Где s.if, s.then, s.else обозначение if-части, then-части и else-части s соответственно.

Если Воздействие является объектом-множеством, то

s(B) o null, если s={ }

s(B) o s₁(B) o, если s={s₁}

s(B) o s’(B) o, s’= s – {x} после x(B) o

где x – произвольно выбранный элемент из множества s.

Если Воздействие является объектом-списком, то

s(B) o null, если s=( )

s(B) o s_n(B) (… ( s₂(B) ( s₁(B) o))…) где s = (s₁, s₂, …, s_n)

Семантика дробящейся посылки

Пусть B – Набор_параметров и пусть s, oO. Тогда оператор дробящейся посылки, обозначаемый ~¹ определяется следующим образом:

Таблица 1: Семантика дробящейся посылки

Условие	S(B) ~1 o
s(B) o не fail	s(B) o
AGG(o) & o = [A1 : o1, …, An : on]	[A1 : s(B) o1, …, An : s(B) on]
BIO(o) & o.if не null	s(B) o.then
BIO(o) & o.if null	s(B) o.else
SET(o) & o = {o1,…,on}	{s(B) o1, …, s(B) on}
SEQ(o) & o = (o1,…,on)	(s(B) o1, …, s(B) on)
Иначе	Fail

2.9 Транзакции и механизм согласованного управления

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

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

Сериализуемость состоит в том, что результат совместного выполнения тран­закций эквивалентен результату их некоторого последовательного исполнения, назы­ва­емого планом выполнения транзакций. Это обеспечивает реальную незави­си­мость поль­зователей. Существует теорема Эсварана о двухфазной блокировке: если все транзакции подчиняются протоколу двухфазной блокировки, то для всех возможных существующих графиков запуска (порядков выполнения транзакций) существует возможность упоря­до­чения. Эта тема хорошо освещена в [9] и [22].

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

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

Протокол согласованного управления СУООБД обеспечивает:

• Управление совместно выполняющимися продолжительными транзакциями

• Усиливает корректность критерия другого, чем сериализуемость

• Учитывает объектную ориентированность данных

• Допускает обобщение операций (не только чтение и запись)

Подробное описание и теоретическое обоснование протокола согласованного управления для ООБД содержится в [19].

3. Разработка структуры СУ

3.1 Положение дел в области интероперабельности систем

Рост мощности программных приложений привел к выделению нового архитектурного слоя – информационной архитектуры систем, определяющей способность совместного исполь­зования, совместной деятельности (в дальнейшем будет использоваться термин "интероперабельность") компонентов (информационных ресурсов) для решения задач [21]. Этот слой расположен обычно над сетевой архитектурой, являющейся необходимой предпосылкой такой совместной деятельности компонентов, обеспечивающей их взаимосвязь.

Деятельность по созданию технологии интероперабельных систем охватывает весь мир. Наиболее существенный вклад в принимаемые идеологические, архитектурные и технологические решения интероперабельных систем вносит Object Management Group (OMG) (http://www.omg.org) - крупнейший в мире консорциум разработки программого обеспечения, включающий свыше 600 членов - компаний - производителей програм­мн­ого продукта, разработчиков прикладных систем и конечных пользователей. Целью OMG является создание согласованной информационной архитектуры, опирающейся на тео­рию и практику объектных технологий и общедоступные для интероперабельности спецификации интерфейсов информационных ресурсов. Эта архитектура должна обес­печивать повторное использование компонентов, их интероперабельность и мобиль­ность, опираясь на коммерческие продукты.

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