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

Рост мощности программных приложений привел к выделению нового архитектурного слоя – информационной архитектуры систем, определяющей способность совместного исполь­зования, совместной деятельности (в дальнейшем будет использоваться термин "интероперабельность") компонентов (информационных ресурсов) для решения задач [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).

Развитие возможностей информационных систем и Internet и желание обеспечить их взаимодействие между собой, привело к необходимости разработки единого прото­кола взаимодействия. Для этого была создана OMG, которая и занялась этим вопросом. В результате была разработана эталонная модель, которая определяет концептуальную схему для поддержки технологии, удовлетворяющей техническим требованиям OMG. Она идентифицирует и характеризует компоненты, интерфейсы и протоколы, состав­ляющие Архитектуру Управления Объектами OMG (Object Management Architecture (OMA)), не определяя, впрочем, их детально.

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

CORBA (Common Object Request Broker Architecture) определяет среду для различных реализаций ORB (Object Request Broker), поддерживающих общие сервисы и интерфейсы. Это обеспечивает переносимость клиентов и реализаций объектов между различными ORB.

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

Объектные Службы :

· Служба Уведомления Объектов о Событии (Event Notification Service).

· Служба Жизненного Цикла Объектов (Object Lifecycle Service).

· Служба Именования Объектов (Name Service).

· Служба Долговременного Хранения Объектов (Persistent Object Service).

· Служба Управления Конкурентым Доступом (Concurrency Control Service).

· Служба Внешнего Представления Объектов (Externalization Service).

· Служба Объектных Связей (Relationships Service).

· Служба Транзакций (Transaction Service).

· Служба Изменения Объектов (Change Management Service).

· Служба Лицензирования (Licensing Service)/

· Служба Объектных Свойств (Properties Service).

· Служба Объектных Запросов (Object Query Service).

· Служба Безопасности Объектов (Object Security Service).

· Служба Объектного Времени (Time Service).

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

· Средства поддержки пользовательского интерфейса (User Interface Common Facilities)

· Средства управления информацией (Information Management Common Facilities)

· Средства управления системой (System Management Common Facilities)

· Средства управления задачами (Task Management Common Facilities)

· Вертикальные общие средства (Vertical Common Facilities)

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

· Поддержка интероперабельности брокеров в стандарте CORBA 2.0

О роли СУООБД в архитектуре OMG можно прочесть в [13].

На основе анализа вышеизложенного, были выбраны в качестве основания следующие базовые службы СУООБД:

_· Служба Долговременного Хранения Объектов – управление хранением объектов

· Служба Управления Конкурентным Доступом и Служба Транзакция – объединены вместе протоколом согласованного управления.

· Служба Изменения Объектов – управление журнализацией изменений

Менеджер памяти

Менеджер памяти является ключевым модулем системы.

Его наличие позволяет

· Абстрагироваться от особенностей обращения к различным видам памяти.

· Создавать сколь угодно вложенные друг в друга структуры данных.

· Иметь единый интерфейс на каждом уровне вложенности.

· Организовать кэширование объектов

В состав менеджера памяти входит 3 системы управления:

1. Система управления виртуальной памятью

2. Система управления каналами

3. Система управления кэшированием объектов