Файл: Технология CORBA (Компонентная модель CORBA (CCM)).pdf

CORBA (Common Object Request Broker Architecture) – это Общая Архитектура Брокера Объектных Запросов - это такой стандарт, набор спецификаций для промежуточного программного обеспечения (ППО, middleware) объектного типа. Ядро CORBA брокер (посредник) объектных запросов (ORB). Это подобие магистрали для объектов. Задача ППО, как нам известно, заключается в связывании программных приложений для обмена данными. Преобразования ППО - это путь от программ передачи информации между конкретными приложениями, через средства импорта- экспорта данных и организацию мостов между некоторыми приложениями, через SQL, RPC (Remote Procedure Call), TP мониторы (Transaction Proceesing) обработки транзакций, Groupware - управление различными неструктурированными данными (тексты, факсы, письма электронной почты, календари и т.д.) и, в конце концов, MOM - Message-Oriented Middleware (асинхронный обмен сообщениями между сервером и клиентом), к созданию распределенных компьютерных систем. Элементы этих систем могут как взаимодействовать друг с другом на одной локальной машине, так и по сети. CORBA разрешает организовать единую информационную среду, элементы которой могут общаться друг с другом, не завися от их конкретной реализации, "прописки" в распределенной системе, платформы и языка их реализации [3]. CORBA, как бы образует нижний слой архитектуры промежуточного слоя, обеспечивающий технологическую платформу интероперабельности. Отношения между знаками объектов на этом уровне не принимается во внимание [8]. Основная задача ORB выражать посреднические услуги при обмене запросами между объектами. Хотя ORB и "обитает" в среде клиент - сервер, объекты, с которыми он работает, выполняют функции либо клиентов, либо же серверов, это уже в зависимости от обстоятельств. Если объект принимает и обрабатывает запрос, то он выступает в роли сервера. Если он отправляет запрос, то играет роль клиента. Основной задачей ORB является прием и отправка запросов, а также передача результатов, и в том числе перехват каждого запроса одного объекта другому; определение местонахождения объекта, который, должен, обработать запрос; запустить соответствующий метод принимающего объекта; при необходимости входит и передача параметров, и передача результатов объекту, инициировавшему запрос. Поскольку ORB обрабатывает запросы "прозрачно", неважно, от какого объекта локального или удаленного поступил запрос. При обработке этих запросов для ORB не имеет значения ни язык программирования, ни операционная система или платформа. Механизм, который обеспечивает "прозрачность" обработки запросов, называется языком определения интерфейса (Interface Definition Language, IDL). Как правило, этот язык применяется для объявления границ и интерфейсов объекта. Во многом подобно независимому арбитру, IDL нейтрален и не зависит от объектов и ORB, при всем при том он связывает поставщиков служб распределенных объектов с их клиентами. Любому человеку, знакомому с DCOM, по всей вероятности, известно, что в модели DCOM используется IDL. Но IDL DCOM несовместим с CORBA и работает несколько иначе, чем IDL CORBA. В CORBA предусматривается множественное наследование, а ее IDL-средствам наследование необходимо для программирования объектов. Это существенно облегчает многократное использование блоков программ. В DCOM механизм множественного наследования не реализован. Вследствие этого и должны быть подготовлены и объединены все интерфейсы, прежде чем к ним обратится клиент. Язык IDL хорош еще и тем, что позволяет кратко описать API, сохранив при этом свободу определить методы на любом языке программирования, который обеспечивает связывание с CORBA. К таким языкам причисляются Ада, Кобол, Си, Си++, Smalltalk и Java. У некоторых поставщиков имеются свои собственные средства согласования с CORBA для Visual Basic и Фортрана. Как известно любому человеку, имевшему дело с объектно-ориентированным программированием, для составления запроса необходимы сведения об интерфейсе принимающего объекта, а объекты уже должны быть разработаны так, чтобы они могли получать информацию об интерфейсах тех объектов, с которыми они будут взаимодействовать. Но, пытаясь применить этот подход для распределенной между однотипными объектами обработки, сталкиваемся со множеством проблем. Для подлинной независимости IDL в CORBA используется репозиторий (хранилище) интерфейсов, который предназначен для хранения сигнатур методов, принадлежащих объектам, с тем чтобы эти сигнатуры можно было динамически извлекать и обновлять во время осуществления программы. Благодаря этому все объекты в корпоративной системе могут получить информацию об интерфейсах других объектов, методах, принадлежащих этим интерфейсам, и параметрах, необходимых для обращения к ним.

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

Для достижения поставленной цели, были выделены следующие задачи:

– рассмотреть теоретические аспекты технологии CORBA;

– изучить технология CORBA.

Объект исследования - CORBA.

Предмет исследования - технология CORBA.

Структура работы состоит из введения, основной части, заключения и списка литературы.

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ ТЕХНОЛОГИИ CORBA

1.1 Назначение CORBA

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

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

Спецификация CORBA использует язык описания интерфейсов (OMG IDL) для определения интерфейсов взаимодействия объектов с внешним миром, она описывает правила отображения из IDL в язык, используемый разработчиком CORBA-объекта.

Стандартизованы отображения для Ада, Си, C++, Lisp, Smalltalk, Java, Кобол, ObjectPascal, ПЛ/1 и Python.

Еще существуют нестандартные отображения на языки Perl, Visual Basic, Ruby и Tcl, реализованные средствами ORB, написанными для этих языков.

Кроме удаленных объектов в CORBA 3.0 определено понятие объект по значению. И код таких методов таких объектов по умолчанию выполняется локально. Если же объект по значению был получен с удаленной стороны, то нужный код должен либо быть заранее известен обеим сторонам, либо же быть динамически загружен. Чтобы это было возможно, запись, определяющая такой объект, содержит поле Code Base – это список URL, откуда может быть загружен код. У объекта по значению могут также быть и удаленные методы, поля, которые передаются вместе с самим объектом. Поля, в свою очередь тоже могут быть такими объектами, которые формируют таким образом списки, деревья или же произвольные графы. Объекты по значению могут иметь порядок от низшего к высшему классу, включая абстрактные и множественное наследование.

1.2 Компонентная модель CORBA (CCM)

Компонентная модель CORBA (CCM) - это совсем недавнее дополнение к семейству определений CORBA.

CCM была введена начиная с CORBA 3.0 и описывает типовой каркас приложения для компонент CORBA. CCM построено под сильным влиянием Enterprise Java Beans (EJB) и фактически является его независимым от языка расширением. CCM предоставляет абстракцию сущностей, которые могут предоставлять и получать сервисы через явственно определенные именованные интерфейсы и порты. Модель CCM предоставляет контейнер компонентов, в котором уже могут поставляться программные компоненты. Сам контейнер предоставляет набор служб, которые может использовать компонент. Эти службы включают (но не ограничивают) службу уведомления, авторизации, персистентности и управления транзакциями. Это более часто используемые распределенным приложением службы. Перетаскивая реализацию этих сервисов от необходимости реализации самим приложением в функциональность контейнера приложения, можно значимо снизить сложность реализации собственно компонентов.

1.3 Брокер Объектных Заявок

Брокер Объектных Заявок (Object Request Broker - ORB) - это промежуточное ПО, с помощью которого устанавливаются клиент-серверные отношения между объектами в распределенной компьютерной среде (см. рис. 1). ORB обеспечивает механизмы, которые позволяют объектам посылать или принимать заявки, отвечать на них и получать результаты, не заботясь при этом о положении других объектов в распределенной среде и способе их реализации. ORB также отвечает за поиск реализации объекта-сервера для выполнения заявки, подготовку реализации этого объекта к приему заявки и за передачу данных, являющихся результатом выполнения заявки. Брокер исполняет роль такого механизма, который позволяет объектам выдавать заявки и получать ответы прозрачным образом. И благодаря этому обеспечивается интероперабельность между приложениями на различных аппаратных платформах в неоднородных распределенных средах. Необходимо также подчеркнуть, что речь идет здесь о технической интероперабельности в том смысле, как это понятие интерпретируется в [3].

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

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

CORBA определяет среду для различных реализаций ORB, которые поддерживают общие сервисы и интерфейсы (см. рис.1). Это обеспечивает мобильность клиентов и реализаций объектов по отношению к различным реализациям ORB. Также ORB обеспечивает интероперабельность компонентов глобального объектного пространства. Определения интерфейсов объектов могут быть помещены в Репозитарий Интерфейсов (Interface Repository) двумя способами: - это статически - в результате спецификации на IDL, или это динамически. Репозитарий представляет компоненты интерфейса как объекты и обеспечивает доступ к ним в период выполнения.

При формировании заявки клиент может использовать интерфейс динамического вызова или генерируемый компилятором IDL стаб (stub) – это локальную процедуру вызова заданной операции при обращении к ней.

Клиент может прямо взаимодействовать с ORB. В таком случае ORB ищет соответствующий код реализации объекта, пересылает ему параметры заявки и передает управление. Реализация объекта принимает параметры заявки через сгенерированный компилятором IDL скелетон (Skeleton) и при этом может обращаться к Объектному Адаптеру (Object Adaptor) и ORB [8]. Основная функция объектного адаптера, используемого для реализации CORBA-объекта, - это обеспечение доступа к сервисам брокера объектных запросов. Объектный адаптер предоставляет все низкоуровневые средства для связи объекта с его клиентами. В число данных средств входят:

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

Спецификация OMG CORBA определяет базовый объектный адаптер, который должен быть выполнен во всех брокерах запросов. Basic Object Adapter (BOA) - это такой набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активизации приложений. Базовый объектный адаптер является решением первоочередной задачи обеспечения связи между реализацией объекта и брокером запросов. Для организации взаимодействия между ORB и, например, системой управления базами данных должен быть разработан свой объектный адаптер [10].

Скелетон - это серверная программа, при помощи которой связывает сервант с объектным адаптером, позволяя объектному адаптеру перенаправлять запросы к соответствующему серванту. При статических методах вызова скелетон формируется при компиляции IDL кода. При динамических же - не используется[12].

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

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

Для определенного языкового отражения обеспечивается программный интерфейс к стабу для каждого типа интерфейса. Стабы выполняют обращения к ORB, используя скрытые и, возможно, оптимизированные для определенного ядра ORB интерфейсы. Для определенного языкового отображения и, возможно, в зависимости от используемого Объектного Адаптера будет обеспечиваться доступ к методам, реализующим каждый объектный тип. Вызов этих методов осуществляется через скелетон. Присутствие скелетона не подразумевает существование соответствующего стаба клиента. Возможно, и обратное. Можно написать Объектный Адаптер, который не использует скелетоны для вызова методов реализации объектов [10].

Доступно широкое множество способов реализации конкретных ORB-ов. Далее будут приведены примеры таких реализаций. Должно иметь ввиду, что конкретный ORB может быть реализован сразу несколькими способами.

ORB, включаемый в клиентское и серверное приложение.

Если имеется подходящий механизм коммуникаций, то возможна реализация, ORB-а в виде набора подпрограмм как со стороны клиента, так же и со стороны реализации объекта. Вызовы методов могут транслироваться в работу со средствами взаимодействия процессов (Inter Process Communication - IPC).

ORB, выполненный в виде сервера.