23. Основные сервисы Corba, модель организация приложений corba, примеры.

CORBA-cервисы, представляют собой набор служб системного уровня, упакованных вместе с интерфейсами IDL. Их можно рассматривать как расширение функциональности ORB. Они используются для создания компонент, их именования и внедрения в среду.

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

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

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

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

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

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

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

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

Скелет (skeleton) — объект, работающий в адресном пространстве сервера. Получив запрос от клиента, он распаковывает его и передает серверу. Также скелет преобразует ответы сервера и передает их клиенту (заглушке).

Создание CORBA приложения на Java начинается с написания интерфейса для удаленного объекта, используя язык описания интерфейсов (Interface Definition Language, IDL).

Создадим файл test.idl

module testApp {

interface test

{

long count(in string msg);

};

};

Серверная часть приложения.

Первое что мы делаем, создаем ORB. Затем создаем экземпляр класса удаленного объекта (testServant) и регистрируем его в ORB. Дальше вызываем специальную службу имен (NameService) и регистрируем в ней имя удаленного объекта, чтобы клиент смог его найти

После того как сервер обработает запрос от клиента и выполнит метод count он снова перейдет в состояние ожидания.

ORB orb = ORB.init(args, null);

testServant testRef = new testServant();

orb.connect(testRef);

org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService");

NamingContext ncRef =

NamingContextHelper.narrow(objRef);

Код клиента. Основные шаги написания клиентского приложения

• Создание и инициализация ORB

• Получение контекста службы имен (NamingContext)

• Нахождение удаленного объекта

• Вызов метода count.

Третий пункт. Создается объект NameComponent. Вызывается метод resolve(NameComponent[] path), который отыскивает по имени удаленный объект (стандартный CORBA-объект). При помощи метода narrow(org.omg.CORBA.Object obj) класса testHelper (сгенерированного idltojava компилятором) получаем объектную ссылку на интерфейс test.

NameComponent nc = new NameComponent("test", "");

NameComponent path[] = {nc};

org.omg.CORBA.Object obj= ncRef.resolve(path);

test testRef = testHelper.narrow(obj);

Теперь можно вызывать метод count

String msg = "try to count";

int count = testRef.count(msg);

24. ORB, понятие, назначение, основные функции

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

Вызов ORB

1. Клиент вызывает метод посредством “заглушки”.

2. ORB передает вызов ВОА, который активизирует реализацию.

3. Реализация запрашивает у ВОА, является ли последний по-прежнему активным и доступным.

4. ВОА передает запрос через “заготовку” реализации метода.

5.Реализация через ORB возвр-ет результат (или исключение).

Клиент может запрашивать выполнение операций с помощью ORB несколькими способами. Вызов операций разделяемого объекта-сервера может быть статическим, через IDL-суррогат, или динамическим (Dynamic Invocation Interface). В случае статического вызова описания интерфейсов на IDL отображаются в программный код на языках С, С++, Smalltalk и др. При использовании динамического интерфейса запросы формируются специальным образом, без отображения интерфейса объекта в исходный код разрабатываемого приложения.

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

Объектный брокер запросов (ORB)

Спецификация CORBA разработана для обеспечения возможности интеграции разных объектных систем

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

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

Клиент может запрашивать выполнение операций с помощью ORB несколькими способами. Вызов операций разделяемого объекта-сервера может быть статическим, через IDL-суррогат, или динамическим (Dynamic Invocation Interface). В случае статического вызова описания интерфейсов на IDL отображаются в программный код на языках С, С++, Smalltalk и др. При использовании динамического интерфейса запросы формируются специальным образом, без отображения интерфейса объекта в исходный код разрабатываемого приложения.

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

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

Для связи между брокерами был разработан протокол General Inter ORB Protocol (GIOP), стандартизующий низкоуровневое представление данных и множество форматов сообщений.

Internet Inter ORB Protocol (IIOP) определяет обмен сообщениями в формате GIOP через TCP/IP-соединения. IIOP становится признанным стандартом для вызова удаленных объектов в Интернет. Такая комбинация GIOP и IIOP необходима для поддержки внешнего взаимодействия. Все поставщики ORB обеспечивают внешнюю совместимость этого протокола.