Добавлен: 16.05.2023
Просмотров: 280
Скачиваний: 2
Различные объектно-ориентированные и не объектно-ориентированные языки программирования могут получать доступ к CORBA-объектам по-разному. Для объектно-ориентированных языков, скорее всего, предпочтительно видеть CORBA-объекты как объекты языка программирования. И даже для не объектно-ориентированных языков скрытие фактического представления объектных ссылок и методов внутри брокера представляется удобным. Связывание того или иного языка программирования с IDL должно быть одинаковым для всех реализаций ORB. Связывание языка включает определение специфичных для языка типов данных и интерфейсов процедур для доступа к объекту через ORB. Оно включает структуру интерфейса клиентской заглушки (для объектно-ориентированных языков не обязательно), интерфейс динамического вызова, скелетон реализации, объектные адаптеры и интерфейс для обращения напрямую к брокеру.
Связывание также определяет взаимодействие между вызовами объекта и потоками выполнения в клиенте и реализации. Самые распространенные связывания предоставляют синхронные вызовы, когда управление возвращается клиенту после завершения операции. Дополнительные связывания могут возвращать управления программе сразу после инициации вызова. В этом случае должны предоставляться дополнительные подпрограммы, зависящие от языка, осуществляющие синхронизацию потоков программы и вызова объекта.
1.2.7 Клиентские заглушки (client stubs)
Обычно клиентские заглушки предоставляют доступ к операциям объекта, описанным на IDL способом, ожидаемым для программиста, знакомого с IDL и связыванием конкретного языка программирования. Заглушки вызывают функции остальной части ORB, используя закрытые интерфейсы, которые могут быть оптимизированы для использования с конкретной реализацией ядра брокера.
1.2.8 Динамический интерфейс вызова (Dynamic invocation)
Также доступен интерфейс, позволяющий создавать вызовы объекта динамически, то есть вместо того, чтобы вызывать подпрограмму заглушки, специфичную для конкретного объекта, клиент может определить объект, который требуется вызвать, операцию, которую требуется выполнить, и набор параметров путем вызова (или последовательности вызовов) универсальной функции. Клиентский код должен предоставить информацию об операции, которую требуется выполнить, включая типы передаваемых параметров (их можно получить из репозитория интерфейсов или другого источника времени выполнения). Природа динамического интерфейса вызова может значительно различаться в зависимости от связывания.
1.2.9 Скелетон реализации (Server skeleton)
Для каждого конкретного связывания языка программирования и, возможно, в зависимости от конкретного объектного адаптера, будет создан определенный интерфейс к методам, реализующим некоторый тип объектов. При этом реализация объекта предоставляет подпрограммы, удовлетворяющие интерфейсу, а ORB вызывает эти подпрограммы через скелетон.
Из существования скелетона не следует существование соответствующей клиентской заглушки: клиент может делать запросы и через динамический интерфейс вызова. Для некоторых объектных адаптеров скелетоны могут быть не нужны: например, в таких языках как Smalltalk есть возможность создавать реализации динамически.
1.2.10 Динамический интерфейс скелетона
Также доступен интерфейс, позволяющий управлять вызовами объектов динамически. Вместо того чтобы обращаться к реализации объекта через скелетон, специфичный для определенной операции, можно обратиться к реализации через интерфейс, предоставляющий доступ к имени операции и ее параметрам так же, как клиентский динамический интерфейс вызова. Для определения параметров может быть использована как чисто статическая, так и динамическая (например, предоставленная репозиторием интерфейсов) информация. Реализация должна предоставить брокеру информацию обо всех параметрах операции, брокер, в свою очередь, предоставляет значения входных параметров операции. По завершении операции, код реализации предоставляет брокеру значения всех выходных параметров или исключения.
Динамические скелетоны могут быть вызваны как клиентскими заглушками, так и динамическим интерфейсом вызова на стороне клиента, причем результат должен быть одинаковым.
1.2.11 Объектные адаптеры
Объектный адаптер предоставляет основной способ доступа к сервисам брокера со стороны реализации объекта. Предполагается, что будут существовать несколько общедоступных объектных адаптеров, интерфейсы которых подходят для определенных видов объектов. Сервисы, предоставляемые брокером через объектный адаптер, включают генерацию и интерпретацию объектных ссылок, вызов методов, безопасность взаимодействий, активацию и деактивацию объектов и их реализаций, сопоставление объектных ссылок реализациям и регистрацию реализаций.
Широкий диапазон уровней модульности, времен жизни, политик, стилей реализации и других свойств объектов делает невозможным предоставление ядром брокера единого интерфейса, удобного и эффективного для всех объектов. С помощью объектных адаптеров брокер может выделять группы реализаций объектов, имеющие схожие требования, и предоставлять интерфейсы, предназначенные для этих групп.
1.2.12 Интерфейс ORB
Это интерфейс, позволяющий обращаться напрямую к брокеру объектных запросов, он одинаков для всех брокеров и не зависит ни от интерфейса объекта, ни от объектного адаптера. Поскольку основная функциональность брокера предоставляются через объектный адаптер, заглушки, скелетоны или динамический вызов, только несколько операций могут запрашиваться напрямую. Эти операции полезны как клиентам, так и реализациям объектов.
1.2.13 Репозиторий интерфейсов
Репозиторий интерфейсов — это сервис, предоставляющий устойчивые объекты, отражающие IDL-информацию в форме, доступной во время выполнения. Информация из репозитория интерфейсов может быть использована брокером для осуществления запросов. Более того, используя информацию из репозитория, программа может найти объект, интерфейс которого был неизвестен во время компиляции программы, и, тем не менее, определить, какие операции могут выполняться объектом, и вызвать эти операции.
В дополнение к этой роли, репозиторий интерфейсов используется также для хранения дополнительной информации, связанной с интерфейсами объектов брокера. Например, отладочной информации, библиотек заглушек и скелетонов, и т.д.
1.2.14 Репозиторий реализаций
Репозиторий реализаций содержит информацию, которая позволяет брокеру находить и активировать реализации объектов. Большая часть информации в репозитории специфична для конкретного ORB и рабочей среды. Обычно, инсталляция реализаций и управление политиками, связанными с активацией и исполнением реализаций выполняется через операции с репозиторием реализаций.
Репозиторий реализаций используется также для хранения дополнительной информации, связанной с реализациями объектов (отладочная информация, административный контроль, выделение ресурсов, безопасность и т.д.).
Выводы по 1 главе.
В начале 1990-х гг. были проблемы обеспечения возможности общения программ, выполняемых на разных машинах. Для решения данной проблемы в 1989 г. был создан консорциум OMG, основной задачей которого стала разработка и продвижение объектно-ориентированных технологий и стандартов.
Главной особенностью CORBA является использование компонента ORB (Object Resource Broker – брокер ресурсов объектов) для создания экземпляров объектов и вызова их методов.
В главе рассмотрена архитектура CORBA, было представлено описание взаимодействия элементов между собой, а также описание и назначение каждого отдельного элемента.
2 Особенности создания CORBA-системы
2.1 Основы языка IDL
Для описания синтаксиса языка в спецификациях стандарта CORBA используется нотация, аналогичная EBNF (Extended Backus-Naur Format – Расширенный формат Бэкуса-Наура).
::= – является по определению
| – или
< > – нетерминальный символ, представляемый заключенным в скобки понятием
«текст» – литерал
* – возможность повторения предшествующей синтаксической конструкции нуль или более раз
+ – возможность повторения предшествующей синтаксической конструкции один или более раз
{ } – заключенные в скобки синтаксические конструкции рассматриваются как единая конструкция
[ ] – заключенная в скобки синтаксическая конструкция является необязательной.
При отображении IDL в различные языки программирования CORBA требует, чтобы конструкции IDL были адекватно отображены:
– все базовые и конструируемые типы;
– ссылки на объекты и константы, определяемые в IDL;
– вызовы операций;
– исключительные ситуации;
– доступ к атрибутам;
– сигнатуры операций в виде, определенном ORB (интерфейс динамического вызова).
Реализация отображения дает возможность программисту иметь доступ ко всем функциям ORB в виде, удобном для соответствующего языка программирования. Все реализации ORB должны следовать стандарту OMG отображения для конкретного языка программирования.
Язык определения IDL позволяет независимо от используемого языка программирования создать универсальное описание интерфейса будущей системы (рисунок 7).
Рисунок 7 - Пример описания интерфейса на языке IDL
Созданный на IDL код должен специальным компилятором преобразовываться в код интерфейса объекта на требуемом языке программирования. После чего на клиенте автоматически генерируется заглушка, преобразующая вызовы методы данного интерфейса в обращения к ORB. На сервере программист на основе сгенерированного интерфейса создает собственную реализацию данного класса. Скелетон автоматизирует получение и обработку удаленного вызова методов, поступающих через ORB.
2.2 Порядок действий при создании CORBA-системы
Создавая CORBA-приложения, нужно помнить, что их модель отличается от модели традиционных монолитных программ и даже клиент-серверных систем, хотя с последними есть и нечто общее. Связку объектов CORBA и клиентов трудно назвать приложением как таковым. Подобные системы похожи на паутину, где все переплетено: клиент может в любую минуту стать сервером, и пользователь вряд ли узнает, с каким сервером объектов он работает в данный отрезок времени, а если проект выполнен грамотно, может даже и не заметить сбоя.
Типичная тактика действий программы, использующей технологию CORBA, такова: соединиться с нужным объектом, использовать его функции и отсоединиться от него. И таких атомарных циклов могут быть сотни.
Добиться хороших результатов в создании программ на основе CORBA можно, придерживаясь определенного порядка действий:
– объектно-ориентированный анализ и моделирование;
– описание и трансляция объектов;
– создание сервера;
– создание клиента;
– отладка объектов.
1) Объектно-ориентированный анализ и моделирование.
CORBA – объектно-ориентированная технология, потому в первую очередь необходимо осуществить объектную декомпозицию и представить систему в виде взаимодействующих между собой классов. Чтобы модель была понятна и разработчикам, нужно задокументировать ее. Построить IDL-описания по UML-модели поможет пакет Rational Rose.
2) Описание и трансляция интерфейсов.
Готовая модель системы содержит классы, которые должны быть описаны с помощью языка IDL. Далее это описание можно транслировать с помощью IDL-компилятора в базовые исходные тексты на конкретном языке программирования (заглушки и скелетоны) или добавить IDL-описания в репозиторий интерфейсов.
3) Создание сервера.
Сервер – это программа, предоставляющая некий сервис, удаленные объекты в случае с CORBA. Серверы CORBA могут активизироваться самостоятельно, будучи запущенными системным администратором либо при загрузке операционной системы. Также программист может зарегистрировать серверы CORBA с помощью утилит, после чего специальный демон будет отслеживать входящие запросы программ-клиентов и активизировать нужные серверы автоматически. Для этой цели в VisiBroker for C++ имеется OAD (Object Activation Daemon), в VisiBroker for Java – OADJ.
Собственно, написать сервер не так сложно, как это может показаться. Схематично процесс работы типичного CORBA-сервера представлен на рисунке 1.
Рисунок 1 - Процесс работы типичного CORBA-сервера
Инициализация ORB нужна для создания коммуникационного канала между клиентом и объектами.
Объектный адаптер в CORBA играет особую роль. Это, по сути, координатор действий. Если ORB не отличается интеллектом и просто выполняет транспортные функции, то объектный адаптер занимается сложной работой по запуску и экспорту объектов, а также заведует информацией, хранящейся в репозитарии реализаций (implementation repository) – специальном хранилище данных, которым пользуется демон активизации объектов. Если сравнивать ORB с системной шиной компьютера, то объектный адаптер нечто вроде драйвера платы расширения.