Файл: Технология CORBA (Использование технологии CORBA).pdf

Сегодня ADT используются во многих языках, называемых объектно-ориентированными. Эти языки представляют ADT в виде объектов. Чтобы представить ADT как объект, необходимо нечто, динамически создающее новые копии, имеющие атрибуты (статусы) и поведение (действия). Объекты должны группироваться и делиться на категории по общим атрибутам и признакам поведения. Такая группировка необходима для администрирования всей совокупности членов в целом. Более того, необходимы критерии, по которым они могли бы обобщаться или подразделяться на категории. Такая потребность в обобщении или делении на категории возникает в группе, члены которой являются разнотипными.

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

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

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

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

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

1.3 Использование технологии CORBA

Технология CORBA – стандарт написания распределенных приложений, принадлежащий консорциуму Open Management Group (OMG). Благодаря этой технологии решается задача связывания различных объектов (программных приложений) для обмена данными. Объекты могут взаимодействовать друг с другом не зависимо от реализации и размещения. Клиент при помощи брокера запросов направляет свой запрос на определенный сервер, зная только интерфейс этого сервера. Сервер получает запрос, обрабатывает и направляет ответ клиенту с помощью того же брокера. Преимущества технологии CORBA заключаются кроме того в том, что она делает возможным повторное использование кода без необходимости его переписывать, например, на другой язык программирования. Наследование интерфейсов делает возможным расширение существующего функционала.

Object Request Broker или ORB – брокер объектных запросов, некое промежуточное ПО между объектами. Брокер отвечает за отправку запроса и получения ответа, поиск определенной реализации сервера для выполнения того или иного запроса и подготовку найденного сервера для выполнения запроса. [5]

Таким образом не предполагается осведомленность объектов о положении друг друга в системе. Object Services в CORBA – набор системных сервисов. Они обеспечивают дополнительную функциональность брокера. Например, сервис именования хранит ссылки на объекты системы CORBA (по имени объекта можно получить этот объект). Сервис жизненного цикла определяет управление жизненным циклом компонентов на шине. Сервисы условно можно поделить на две категории: те, которые уже функционируют поверх ORB без дополнительного встраивания, и те, которые необходимо встраивать в брокер отдельно.

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

1. Сервис жизненного цикла. Основополагающий сервис, определяющий жизненный цикл компонентов на шине (создание, удаление, копирование и т.д.).

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

3. Сервис долговременного хранения. Выполняет функцию сохранения объектов в долговременной памяти.

4. Сервис событий. Основная функция – поддержка асинхронного взаимодействия.

5. Сервис отношений. Предоставляет логические связи между компонентами.

6. Сервис контроля совместного доступа. Занимается управлением разделяемыми ресурсами, доступом к ним.

7. Сервис транзакций. Определяет множество моделей транзакций. 8. Сервис внешнего представления. Копирует объект и представляет его в виде файла, элемента базы данных, т.е. в виде какого-либо внешнего представления.

9. Сервис запросов. Обеспечивает выполнения запросов к объектам.

10. Сервис свойств. Служба, позволяющая ассоциировать свойства с компонентом.

Таким образом, сам брокер объектных запросов иногда не предоставляет полной функциональности без сервисов. Есть некие стандартные сервисы, которые употребляются очень часто и расширяют функциональность брокера. Консорциум OMG стандартизовал такие сервисы. Перейдем к следующему элементу. Основная задача Common Facilities (общих средств) – поддержка интерфейсов сервисов высокого уровня. Общие средства можно поделить на две категории: горизонтальные и вертикальные.

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

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

Но, это разделение весьма условно, так как клиент может являться сервером, а сервер клиентом. Например, при выполнении запроса, сервер может отправить запрос другому компоненту, и в этом случае сервер фактически является клиентом по отношению к другому серверу. Для коммуникации, приложения должны понимать друг друга. Они должны знать, какие действия совершает то или иное приложение, и дать понят другим, какие действия могут совершать они сами. Именно для этой цели был создан язык IDL (Interface Definition Language). IDL-определенные методы могут быть выполнены на любом языке, поддерживающем отображение из языка IDL. Соответственно язык IDL используется в среде компонентов для связи. Соответственно каждому компоненту необходимо отображать этот язык в свою реализацию.

Для этой цели существуют стабы и скелетоны (серверные и клиентские заглушки). Стаб (заглушка) действует в адресном пространстве клиентского приложения. Фактически, это пустые реализации для каждого метода интерфейса. Он является неким посредником. Его основная функция – упаковать параметры запроса в специальный формат и передать запрос скелетону сервера (через ORB).

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

Отложенный синхронный тип запроса предполагает некую совокупность двух предыдущих типов запроса. Здесь отправивший запрос компонент также продолжает работу, как при одностороннем типе запроса, но позднее он может заблокироваться до получения ответа, как при синхронном типе запроса. Универсальный межброкерный протокол (GIOP – General InterORB Protocol) поддерживает интероперабельность брокеров. Этот протокол не зависит от внутренней архитектуры брокера. Для 209 согласованного включения брокера в сеть, необходимо лишь наличие связанных с брокером объектов, которые способны принимать и посылать сообщения IIOP. Данный протокол является своеобразным каркасом.

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

ГЛАВА 2. ОСОБЕННОСТИ АРХИТЕКТУРЫ И ПОСТРОЕНИЯ CORBA

2.1 Применения технологии CORBA

Технология создавалась фирмой Microsoft как средство взаимодействия приложений (в том числе составных частей операционной системы) Windows, функционирующих на одном компьютере, с последующим развитием для использования в пределах локальной сети. Главная задача на момент создания обеспечение технологии Object Linking and Embedding (OLE 1.0). Характерно, что обмен данными между приложениями (Dynamic Data Exchange, DDE) первоначально строился не по COM-технологии, а с использованием механизма сообщений (messages). Развитие технологии идет по мере добавления новых возможностей. Как универсальная технология взаимодействия приложений COM начал использоваться с OLE 2.0 (1991). Концепция технологии неразрывно связана с ее реализацией. Появление новых возможностей это просто появление новых библиотек, функций API и утилит Windows. "Общий знаменатель технологии" двоичная структура объекта, хотя в настоящий момент существует язык описания структуры объекта Interface definition Language (IDL). [6]

Технология создавалась консорциумом OMG как универсальная технология создания распределенных систем в гетерогенных средах. OMG представляет собой некоммерческую организацию, являющуюся содружеством разработчиков программного обеспечения и его потребителей, объединивших свои усилия для создания спецификаций этой технологии. В настоящий момент в OMG состоит более 800 членов, включая всех сколько-нибудь серьезных производителей программного обеспечения (и даже c недавнего времени Microsoft). Первая спецификация CORBA появилась в 1991 г. Новые возможности официально считаются добавленными в CORBA в момент утверждения соответствующей спецификации. Как правило, в разработке спецификации участвуют крупнейшие специалисты в данной области.

Технология CORBA носит существенно более общий и универсальный характер, чем COM, что заложено в ее фундаменте. Опережение разработки спецификаций (по сравнению с реализациями) позволяет добиться более связной, целостной и гармоничной системы. С другой стороны, при разработке реального проекта нужно предварительно убедиться, что высококачественная реализация того или иного сервиса CORBA уже доступна (источниками проблем могут служить, например, Persistence Service и Security Service).

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

Данные вызова преобразуются в сетевой формат, сериализируются с помощью сгенерированных для объектов заглушек (stubs) и передаются от клиентских к серверным ORB. На сервере данные вызова десериализируются с помощью Фреймворка. В этом случае для объекта, где вы­полняется вызов, генерируются специальные скелетоны для правильного отображения данных. Данные, полученные при обработке вызова, пере­даются по цепочке обратно к клиентскому коду.