Технология Клиент-Сервер 1999'4

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

CORBA 3: первый взгляд

CORBA (Common Object Request Broker Architecture), стандарт, созданный Object Management Group, стал одним из самых влиятельных стандартов в объектно-ориентированном мире и одним из принципиальных шагов в движении индустрии к компонентной разработке.

Вскоре должно появиться первое – с 1996 года, когда и появился протокол IIOP – крупное обновление CORBA, CORBA 3.

В целом спецификация OMG работает на трех уровнях. Unified Modeling Language (UML) стандартизует представление модели в объектно-ориентированном анализе и разработке. CORBA определяет инфраструктуру взаимодействия. Object Management Architecture (OMA) представляет стандарт для сервисов и служб, используемых в распределеной архитектуре от уровня, близкого к системному (например, Naming и Event Services), до уровня приложения (например, Currency Object в финансах, Patient или Person Identifier в здравоохранении).

В этой статье есть место только для CORBA. Чтобы подробнее узнать о других уровнях, или чтобы получить любую из трех спецификаций OMG, посетите http://www.omg.org/.

Рис. 1

IDL – язык определения интерфейсов

В CORBA программисты определяют интерфейсы объектов на OMG IDL, ставшем международным стандартом (ISO/IEC 14750 и ITU-T Recommendation X.920). При создании определения интерфейса вы оговариваете операции, которые должен выполнять объект, входные и выходные параметры и любые исключения, которые можете предусмотреть. Этот интерфейс заключает контракт с клиентом объекта, использующим то же определение интерфейса для создания и управления вызовами, используемыми реализацией объекта. Такой дизайн обеспечивает большую гибкость и имеет множество выгод. Например, он предоставляет клинтам независимый от языка программирования, ОС, аппаратной платформы, представления данных, расположения в сети и протокола доступ к реализациям объектов.

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

Компиляторы IDL используют преобразования для создания вызовов функций или методов. Сейчас разработаны преобразования CORBA OMG IDL для C, C++, Java, Cobol, Smalltalk и Ada; a преобразование Lisp в процессе принятия. Пока нестандартизованные преобразования существуют для objective C, Visual Basic, Perl и других языков.

CORBA Object Invocations

Рис. 1 показывает запрос, передаваемый от клиента реализации объекта в архитектуре CORBA. Интересны два аспекта этой архитектуры.

Первое, и клиент, и реализация объекта изолированы от Object Request Broker (ORB) своим IDL-интерфейсом, который встроен в stub (на стороне клиента) и skeleton (на стороне реализации объекта). Поскольку клиенты видят только интерфейс объекта, а не детали реализации, архитектура гарантирует заменяемость реализации за интерфейсом – это наш программный распределенный объектный plug-and-play.

Второе, запрос не передается реализации объекта от клиента напрямую; вместо этого запросы всегда управляются ORB. Каждый вызов CORBA-объекта передается ORB; форма вызова для клиента всегда одинакова – неважно, локального или удаленного объекта (в случае удаленного реализация передается от ORB клиента ORB реализации объекта). Детали распределения касаются только ORB, где обрабатываются купленным, а не написанным вами ПО. Код приложения, освобожденный от этой административной ноши, сосредотачивается собственно на проблеме.

Простая архитектура

Паутина связей ORB-ORB дает возможность взаимодействия всех CORBA-объектов в сети. ORB используют для связи специфицированный OMG протокол IIOP, а также Interoperable Object Reference (IOR) – для передачи друг другу сведений о местонахождении реализаций объектов.

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

В объеме этой статьи невозможно передать утонченность серверной архитектуры СORBA и оставить место для описания чего-нибудь еще. OMG определила очень мощную, но стандартизованную инфраструктуру управления экземплярами объектов на стороне сервера. Она называется Portable Object Adapter (POA) и поддерживает количества объектов масштаба предприятия и обращений в масштабе Internet. В то же время она дает возможность простой реализации инкапсулированных объектов. Ключевая часть CORBA 3, CORBA Component Model , построена на POA.

Спецификации, включенные в CORBA 3, можно разделить на три основных категории: интеграция с Java и Internet, контроль качества сервиса и компонентная архитектура CORBA. 

Интеграция с Java и Internet 

Три новых спецификации усиливают интеграцию CORBA, Java и Internet: спецификация преобразования Java в IDL, спецификация брандмауэров и interoperable naming service.

Преобразование Java-IDL 

CORBA 3 добавляет к “нормальному” преобразованию IDL в Java, описанному в начале статьи, преобразование Java в IDL. Преобразование определяет интерфейс IDL для Java-объекта, что дает двойной эффект: Java-программист может использовать стандартный протокол OMG – IIOP – в удаленных вызовах, а Java-серверы – получать вызовы от CORBA-клиентов, написанных на любых поддерживаемых CORBA языках программирования.

Спецификация брандмауэров

Спецификация брандмауэров (CORBA 3 Firewall Specification) определяет брандмауэры уровня транспорта, уровня приложения и (может быть, самое интересное) двунаправленный протокол (General Inter-Orb Protocol (GIOP)) соединения, применимый в обратных вызовах и оповещениях о событиях. Брандмауэры уровня транспорта работают на уровне TCP. Определяя хорошо известные порты 683 для IIOP и 684 для IIOP через SSL, спецификация позволяет администраторам сконфигурировать брандмауэры для регулирования трафика CORBA через протокол IIOP. Есть и спецификация для CORBA через Socks.

В CORBA объектам зачастую нужно сделать обратный вызов или оповестить клиента, вызывавшего их; то есть, работать в качестве клиентов, а клиентские модули создают объекты, вызываемые в процессе обратных вызовов. Поскольку стандартные подключения CORBA передают вызовы только в одном направлении, обратный вызов, как правило, требует установки второго TCP-соединения. Это не допускается практически ни одним брандмауэром. Новая спецификация позволяет IIOP-подключениям делать обратные вызовы. Эта возможность ограничена требованиями безопасности обеих сторон.

Interoperable naming service

Объектные ссылки CORBA – краеугольный камень архитектуры. До появления CORBA 3 IOR имелся только один путь добраться до экземпляра объекта и вызвать его. Способа вызвать удаленный экземпляр не существовало – даже если его наличие, работоспособность и местоположение были известны – если только не существовало доступа к его объектной ссылке. Простейшим путем для этого было получить ссылку на его Naming Service. Но если такой ссылки нет?

Interoperable Naming Service определяет один URL-формат ссылок на объеты, iioploc, который может быть использован в программе для удаленного доступа к определенному сервису, включая Naming Service. Второй URL-формат, iiopname, на самом деле вызывает удаленный Naming Service, используя имя, которое пользователь присоединяет к URL, и получает IOR именованного объекта. Например, идентификатор iioploc iioploc:// www.omg.org/NameService будет разрешен как CORBA Naming Service, работающий на машине с IP-адресом, соответствующим доменному имени www.omg.org.

Контроль качества сервиса (QoS)

Новая спецификация Asynchronous and Messaging Invocation (AMI) определяет ряд асинхронных и независимых от времени режимов вызова для CORBA и позволяет в каждом режиме как статичные, так и динамические вызовы. Результаты асинхронных вызовов могут быть получены с помощью опроса или обратного вызова, это выбирается формой производимого клиентом вызова.

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

Минимальная CORBA в первую очередь предназначена для встраиваемых систем. После завершения и записи в микросхемы встраиваемые системы невозможно изменить, и их взаимодействие с внешней сетью вполне предсказуемо. Им не нужны динамические аспекты CORBA, такие, как Dynamic Invocation Interface или поддерживающий его Interface Repository, и по этой причине они исключены из минимальной CORBA.

Real-time CORBA стандартизует управление ресурсами – потоками, протоколами, подключениями и т.д. – используя модель приоритетов для достижения предсказуемого поведения как в статистической, так и в жесткой среде реального времени. Динамическое планирование, не являющееся частью данной спецификации, сейчас находится в стадии разработки. Готовится также стандарт, базирующийся на избыточности сущностей и пути обработки ошибочных ситуаций, предназначенный для повышения устойчивости приложений CORBA к сбоям. 

CORBA Components Package

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

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

Одна из наиболее впечатляющих разработок OMG со времен CORBA 2, CORBAcomponents представляют собой шаг вперед, сулящий выгоды программистам, пользователям и заказчикам компонентного ПО. Три главные части компонентов CORBA:

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

Заключение

После 10 лет совместной работы членов OMG основы инфраструктуры CORBA завершены и постоянно используются в тысячах мест. Расширения, собранные под названием CORBA 3 вносят в эту устоявшуюся архитектуру простоту использования и точный контроль.

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

Copyright © 1994-2016 ООО "К-Пресс"