Corba, назначение, терминология. OMA. Модель COBRA

CORBA – наиболее развитая объектная технология распределенного программирования. CORBA позволяет создавать распределенные в пространстве Сети компоненты, кот-е м.б. написаны на разл-х ЯП), работать на разл-х ОС, просто определяя интерфейсы друг друга и удаленно вызывая открытые методы объектов, из которых состоят компоненты.

CORBA состоит из следующих компонентов:

· Брокер объектных запросов (ObjectRequestBroker), который дает возможность объектам прозрачно создавать запросы и получать ответы в распределенной среде..

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

· Общие средства (CommonFacilities), коллекция сервисов, которую могут использовать многие приложения, но которые не являются такими фундаментальными, как сервисы объектов.

· Объекты приложения (ApplicationObject), которые являются продуктами одной группы разработчиков, которая контролирует свои интерфейсы.

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

Практически, для создания распределенных компонентов при программировании в CORBA выполняются обычно как минимум следующие шаги:

1. Проектируются распределенные компоненты

2. Описываются интерфейсы открытых объектов этих компонентов на языке IDL

3. Создаются реализации компонентов (объекты и их клиенты)

4. Тестирование компонентов в распределенной среде

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

 

Архитектура управления объектами.(OMA)

OMA состоит из четырех частей:

• фундаментальный компонент, называемый Брокер Объектных Запросов (ObjectRequestBroker),

• дополнительные сервисы, используемые разработчиками для управления распределенными объектами;

• общие сервисы, используемые многими различными приложениями, и

• распределенные приложения как таковые.

ORB - аббревиатура от “Брокер Объектных Запросов”, предусматривает фундаментальные и основные действия с распределенными объектами и с управлением ими. Стандартом, который был принят для реализации этих целей, явился CORBA (Единая архитектура программы-брокера объектных запросов).

Сервисы, используемые для разработки распределенных объектов, называются CORBA-сервисами. Поначалу они назывались общие объектные сервисы, поскольку не было уверенности, что всем распределенным объектам эти сервисы будут действительно необходимы.

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

Приложения, составленные из таких “строительных блоков” являются объектными приложениями.

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

 

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

module testApp {

interface test

{

long count(in string msg);

};

};

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

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

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

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

testServanttestRef = new testServant();

orb.connect(testRef);

org.omg.CORBA.ObjectobjRef =

orb.resolve_initial_references("NameService");

NamingContextncRef =

NamingContextHelper.narrow(objRef);

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

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

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

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

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

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

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

NameComponent path[] = {nc};

org.omg.CORBA.Objectobj= 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-суррогат, или динамическим (DynamicInvocationInterface). В случае статического вызова описания интерфейсов на IDL отображаются в программный код на языках С, С++, Smalltalk и др. При использовании динамического интерфейса запросы формируются специальным образом, без отображения интерфейса объекта в исходный код разрабатываемого приложения.

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

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

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

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

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

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

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

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

 

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

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