Файл: "Технология CORBA".pdf

ВВЕДЕНИЕ

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

Задачи исследования: ознакомление с теоретическим основами предметной области и методологическими основами для проектирования создания распределенных приложений на примере технологии CORBA.

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

Предмет исследования: распределенные системы обработки информации.

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

Глава 1. Распределенные системы

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

Распределенная система – это набор независимых компьютеров, представляющийся их пользователям единой объединенной системой.

Распределенные системы обладают рядом характеристик. Первая: от пользователей скрыты различия между компьютерами и способы связи между ними. Вторая: пользователи и приложения работают в распределенных системах единообразно, не зависимо от того, где и когда происходит их взаимодействие.

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

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

Глава 2. Распределенные системы объектов

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

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

Видимая часть объекта называется его интерфейсом. Интерфейс объекта представляет собой протокол сообщений, используемых для запроса функциональности. Совокупность интерфейсов определяет поведение объекта. Интерфейс объекта состоит из имени объекта и набора методов. Методы состоят из двух частей: описание (signature) и реализация (implementation). описание состоит из имени метода, имен и типов параметров (в том числе возвращаемое значение) и исключений (exceptions). Реализация метода – это код, выполняемый для осуществления нужной операции.

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

Поведение объекта – это контракт, который предлагается потребителю. Именно контракт объекта гарантирует то, что вызов одного из его методов в соответствии с описанием приводит к определенному результату или исключению. Контракт состоит из описания и необходимых предусловий (pre-conditions), инвариантов (invariants) и постусловий (post-conditions). Инварианты – это условия, которые всегда остаются истинными. предусловия – условия, правильность которых должна быть обеспечена перед вызовом метода. Постусловия – условия, правильность которых проверяется после вызова метода, и подтверждают правильность выполнения контракта.

Провайдером (поставщиком) контракта является сервер. Потребителем контракта является клиент. Клиент запрашивает сервис у сервера. Клиент вызывает метод у провайдера. Иногда это называют посылкой сообщения от клиента к серверу. [4]

Чаще всего распределенные объекты работают в конфигурации Клиент-сервер. Сами объекты являются серверами – они реагируют на запросы, предоставляют клиенту сервисы или ресурсы. Чтобы отличать такие серверы от процессов, работающих в системе клиент-сервер, будем говорить об объектах, которые работают со стороны сервера или клиента. Объекты со стороны сервера предлагают сервисы и ресурсы. Объекты же со стороны клиента их запрашивают. Они находятся во взаимодействии, так же, как и во всех объектно-ориентированных системах, где клиент и провайдер находятся на различных машинах внутри одной сети.

Комбинация объектно-ориентированного подхода и идеологии клиент-сервер вбирает в себя лучшее из двух областей:

• абстрактность, которая уменьшает сложность системы и упрощает ее разработку;
• распределеннность в соответствии с параметрами аппаратного обеспечения и концентрация совместно используемых данных (и общего кода) в одном месте (удобном для их обработки).

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

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

Глава 3. CORBA

Первые спецификации CORBA появились в начале 90-х годов. Основной целью OMG (некоммерческая организация, Object Management Group) при разработке CORBA было создание распределенной системы, способной преодолеть большинство проблем межоперационной совместимости при интеграции сетевых приложений.

Базовая спецификация состоит из более чем семисот страниц, и более тысячи страниц описывают службы, построенные на этой основе. Различные реализации CORBA имеют собственные расширения, всё складывается из предпочтений конкретного производителя.

3.1 Глобальная архитектура

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

Рисунок 3.1.1 Глобальная архитектура CORBA

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

Кроме объектов, являющихся частями конкретных приложений, так же в модель входят средства CORBA (CORBA facilities) – это сочетания внутренних служб CORBA. CORBA facilities делятся на две группы: горизонтальные средства (horizontal facilities) и вертикальные средства (vertical facilities). Более подробная информация о группах представлена в таблице 3.1

Таблица 3.1 Группы средств CORBA

3.2 Объектная модель

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

Объекты и службы описываются при помощи языка определения интерфейсов (Interface Definition Language, IDL) CORBA. Этот язык имеет традиционный для языков определения интерфейса синтаксис описания методов и их параметров. Семантику IDL для CORBA описать невозможно, объект сам определяет какие наборы методов (интерфейсы) он реализует. Спецификации интерфейса можно задать только при помощи IDL.

Общая организация системы CORBA отображена на рисунке 3.2.1. Будем считать, что система CORBA организована в виде набора клиентов и серверов объектов.

Рисунок 3.2.1 Организация системы CORBA

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

С точки зрения процесса, брокер ORB сам по себе предоставляет лишь некоторые услуги:

• обработка ссылок на объекты. Вид этих ссылок обычно зависит от конкретного брокера ORB. Поэтому любой брокер ORB предоставляет операции для маршалинга (упаковку) и демаршалинга (распаковку) ссылок на объекты в ходе обмена между процессами, а также операции для сравнения ссылок.
• начальный поиск доступных для процесса служб. Обычно он предоставляет данные для получения начальной ссылки на объект, реализующий конкретную службу CORBA. Так, например, для использования службы именования необходимо, чтобы процесс знал, как на нее сослаться. Подобную задачу инициализации равно необходимо решать и для других служб.

Клиенты и серверы различают только интерфейс ORB. Обычно видятся только заглушки, которые обрабатывают обращения к соответствующим объектам. Заместитель – это клиентская заглушка, единственное назначение которой – выполнить маршалинг обращения в запрос и переслать этот запрос серверу. После получения ответа с сервера выполняется его демаршалинг и передача клиенту.

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

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

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