2) форматы передаваемых между агентами сообщений GIOP, которые введены для поддержки объектных заявок, установления местоположения реализаций объектов и управления транспортными соединениями;

3) определение ограничений на допустимый сетевой транспорт GIOP.

Протокол IIOP, который можно считать специализацией GIOP, определяет дополнительно, как агенты открывают соединения TCP/IP и используют их для передачи сообщений GIOP. GIOP трактует транспортное соединение как асимметричное. Определяются две различных роли использования соединения: роль клиента и роль сервера. Клиент образует соединение и посылает объектные заявки, сервер принимает заявки и посылает ответы. Сервер не может посылать объектных заявок. Соединение может использоваться совместно многочисленными клиентами в одном брокере для посылки независимых заявок различным объектам в определенном брокере или сервере. Допускается асинхронная посылка заявок при их произвольном чередовании в соединении.

В передаваемых сообщениях допускается произвольный порядок байтов (зависящий от архитектуры процессора), устанавливаемый отправителем сообщения. Получатель сообщения должен изменить этот порядок нужным для себя образом. Установлены выравнивания значений базовых типов IDL (char, octet, short, unsigned short, long, unsigned long, float, double, boolean, enum) по границе естественных для них полей. Установлено кодирование конструируемых типов IDL (struct, union, array, sequence, string), не накладывающее дополнительных требований выравнивания по отношению к тем, которые установлены для базовых типов [9].

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

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

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

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

5. Клиенты и серверы CORBA

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

В трехуровневой архитектуре понятие клиента и сервера весьма условно. Компонент распределенной системы может выступать одновременно в роли клиента для другого компонента и быть сервером для других компонентов системы (рис. 2).

6. Стабы и скелетоны

Клиентские стабы (заглушки) и серверные скелетоны выступают в роли «клея», который связывает языково-независимую спецификацию интерфейса на IDL с языково-зависимым кодом реализации. Клиентские стабы каждого интерфейса включаются клиентами, которые используют эти интерфейсы. Клиентский стаб для конкретного интерфейса обеспечивает пустые реализации для каждого метода этого интерфейса. Перед тем, как выполнить сервер функциональности, стаб клиента соединяется с Брокером Объектных Заявок, чтобы передать и получить параметры. Стаб клиента, который генерируется IDL-компилятором, это часть кода, которая делает доступным клиенту интерфейс конкретного CORBA сервера. Скелетон сервера, также генерируемый IDL-компилятором, это часть кода, которая обеспечивает «каркас», на котором построен код реализации сервера для конкретного интерфейса.

7. Основные объектные службы CORBA

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

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

Сервис Жизненнго Цикла (Life Cycle Service) определяет операции создания, копирования, перемещения и удаления компонентов на шине [7].

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

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

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

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

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

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

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