Файл: Технология CORBA (Общий протокол межброкерного взаимодействия (GIOP)).pdf

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

2.2 Службы объектов CORBA

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

Имеется 16 объектных служб, в том числе:

Collection Properties

Сoncurrency Сontrol

Query Eventnoti fication

Nships Externalization Security

Licensing Startup

Lifecycle Time

Naming Trader

Persistence Transactions

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

Компонент это набор бизнес-объектов, которые осуществляют обработку, инкапсулируют данные и обеспечивают необходимые интерфейсы пользователя. Для взаимодействия объектов в рамках компонента используется ORB. Кроме того, с помощью ORB объекты обмениваются информацией о себе, в результате объекты "узнают" о существовании других объектов во время исполнения программы. Таким образом, в компоненте имеется все необходимое для вывода на экран представления объекта и взаимодействия с ним. Типичный бизнес-компонент мог бы применяться, скажем, для вывода на экран распределения мест на 11-часовом рейсе до Лос-Анджелеса, а другой для регистрации сведений о бронировании мест на этот рейс.Возможности компонентов можно расширить за счет добавления служебных функций системного уровня. Функция Persistence пригодится, чтобы поддерживать состояние объектов в рамках компонента.

Поскольку эти сервисные функции встроены в CORBA, их можно применять для создания "интеллектуальных" (smart) компонентов, при этом нет необходимости программировать их с нуля. Хотя и в DCOM имеется реестр компонентов и справочная служба, там нет способа поддерживать состояние объектов DCOM в перерыве между соединениями. Из-за этого недостатка DCOM уступает CORBA.На уровне прикладной программы, где устанавливаются границы инфраструктуры компонентов, базовые структуры программ определяют способы реализации совместной деятельности независимых компонентов. Благодаря четко определенным границам все компоненты вместе функционируют как единый комплекс, так что создается впечатление единства прикладной программы. Именно такое единство позволяет прикладным программам, использующим распределенные в гетерогенных средах объекты, "прозрачно" сопрягаться друг с другом. "Прозрачная" интеграция означает, что пользователи воспринимают прикладную программу как единое целое, а не как сложный набор разобщенных модулей.Инфраструктуру компонента одной прикладной программы можно расширить до инфраструктуры компонента нескольких программ. В этом случае CORBA несет ответственность за обмен информацией между множеством различных прикладных программ в рамках корпоративной системы. Для несовместимых с CORBA программ, например доставшихся в наследство приложений, можно создать оболочки (wrappers), которые придают им подобие объектов CORBA. Оболочка выполняет роль интерфейса, необходимого для доступа к конкретным функциям старой программы.Если вы с помощью CORBA интегрировали унаследованные программы с процессами клиента и сервера, у вас есть все составляющие многоуровневой модели клиентсервер. Один уровень это визуальные объекты, например интерфейсы, размещаемые на клиентских ПК. Другой уровень объекты сервера, предусматривающие бизнес-функции. Еще один уровень составляют унаследованные прикладные программы, например СУБД на большой ЭВМ.

Чтобы показать, почему CORBA ORB так хороши для ППО архитектуры клиент сервер, мы приводим следующий «краткий» список замечательных свойств, присущих всем ORB:

Статические и динамические вызовы методов. CORBA ORB позволяет статически определять вызовы ваших методов во время компиляции или находить их динамически во время выполнения. Таким образом, вам предоставляется выбор: строгий контроль типов на стадии компиляции или максимальная гибкость при отложенном (на этапе выполнения) связывании.

Связывание с языком высокого уровня. CORBA ORB позволяет вызывать методы серверного объекта с помощью выбранного Вами языка высокого уровня. При этом не имеет значения на каком языке написаны серверные объекты. CORBA отделяет интерфейс от его реализации и предоставляет независимые от языка типы данных, что дает возможность вызывать объекты из любого языка и для любой операционной системы. Наоборот, другие типы промежуточного программного обеспечения обычно предоставляют низко-уров-невые API-библиотеки для определенного языка . Кроме того, они не отделяют реализацию от спецификации и, как следствие, API тесно связан с реализацией, что делает интерфейс очень чувствительным к изменениям.

2.3 Объект CORBA и жизненный цикл серванта

POA обеспечивает сильное разделение между сроками службы объектов CORBA и сроками службы серванта. Следующие термины относятся к циклу жизни объекта CORBA:

• Активация (activation) - запуск существующего объекта CORBA, чтобы позволить ему принимать запросы.
• Дезактивация (deactivation) - завершение работы активного объекта CORBA.

Следующие термины относятся к циклу жизни серванта:

• Воплощение (incarnation) - соединение серванта с объектом CORBA
• Уничтожение (еtherealization) - разрушение ассоциации между сервантом и объектом CORBA

Во время своей жизни объект CORBA может быть воплощен более чем одним сервантом. В то же самое время, отдельный сервант, с другой стороны, может воплощать более одного объекта.Технология CORBA носит существенно более общий и универсальный характер, чем COM, что заложено в ее фундаменте. Опережение разработки спецификаций (по сравнению с реализациями) позволяет добиться более связной, целостной и гармоничной системы. С другой стороны, при разработке реального проекта нужно предварительно убедиться, что высококачественная реализация того или иного сервиса CORBA уже доступна (источниками проблем могут служить, например, PersistenceService и SecurityService).В настоящий момент CORBA не имеет своей собственной компонентной модели; работа над ней началась в 1998 г. и еще не завершена. Это главный серьезный недостаток. Правда, он несколько компенсируется наличием основанной на CORBA компонентной моделью Enterprise

JavaBeans, так что программисты на Java находятся в привилегированном положении. Все остальное, что присутствует в COM, имеется и в CORBA, и даже более того - за исключением универсальной технологии доступа к БД. Опять-таки, Java-программисты имеют преимущество и здесь - за счет наличия общей для Java технологии доступа к данным JDBC.Под “стандартом” применительно к CORBA понимается то, что официально утверждено консорциумом OMG. Надо сказать, что это очень высокий уровень “легитимности”, так как авторитет OMG в компьютерном мире чрезвычайно высок. В настоящий момент стандартизовано отображение языка IDL на 6 языков программирования - Ada, C, C++, Cobol, Java и Smalltalk. Существуют также отображения на Pascal (точнее, Delphi), Perl, Python и еще десяток языков.Наиболее используемыми языками в настоящий момент являются Java (вследствие прекрасного взаимодействия Java-технологий, особенно JDBC, RMI, JNDI и EJB, с CORBA), и C++ - как самый эффективный, мощный и распространенный язык компьютерной индустрии. CORBA обеспечивает даже несколько более высокий уровень за счет базировании технологии исключительно на языке описания IDL с последующим отображением таких спецификаций на конкретный язык программирования, а также некоторых возможностей, например, автоматического (т.е. прозрачного для программиста) распространения контекста транзакций.CORBA в настоящее время не имеет своей компонентной модели. Пусть это не имеет практического значения для Java-программистов, но в общем случае эта та область, где OMG (и фирмам-производителям программного обеспечения) еще предстоит серьезно поработать.CORBA имеет очень развитую сервисную часть; например, только для поиска серверных объектов по различным критериям можно использовать 4 различных сервиса CORBA. Кроме того, OMG стремится к максимальной стандартизации вспомогательных возможностей CORBA. CORBA предоставляет разработчикам существенно большие возможности, чем COM, в области сервисов и вспомогательных средств. С другой стороны, COM-программисты обычно не испытывают какого-либо дискомфорта из-за их недостатка. Вследствие ограниченности области применения COM объективно нет необходимости в создании таких же развитых и универсальных средств, как это совершенно необходимо для CORBA.Понятие “объекта” в CORBA принципиально отличается от своего COM-аналога. Объект CORBA не является переменной языка программирования и в общем случае время его существования не связано со временем работы серверных или клиентских приложений. СORBA-объект не занимает никаких ресурсов компьютера - оперативной памяти, сетевых ресурсов и т.п.

Эти ресурсы занимает только так называемый “сервант” (servant), который является “инкарнацией” одного или нескольких CORBA-объектов. Именно сервант является переменной языка программирования. Пока не существует сервант, сопоставленный с конкретным объектом CORBA, этот объект не может обслуживать вызовы клиентов, но, тем не менее, он существует. Результатом создания объекта (при этом совершенно не обязательно при этом создается и сопоставляется с этим объектом соответствующий сервант!) является так называемая “объектная ссылка” CORBA. Объектная ссылка сопоставлена с этим, и только с этим объектом, и это сопоставление остается корректным в течение всего срока существования CORBA-объекта (может быть, в течение нескольких лет). Объектная ссылка CORBA правильно интерпретируется ORB’ами от любого производителя программного обеспечения. После уничтожения CORBA-объекта все объектные ссылки на него навсегда теряют смысл. С помощью объектной ссылки клиент вызывает методы объекта, при этом инкарнациями этого объекта могут быть различные серванты (не более одного одновременно), которые физически могут находиться даже на различных компьютерах.CORBA является существенно более открытой, универсальной и гибкой системой, чем COM. И COM, и CORBA способны тесно и эффективно взаимодействовать со стандартными средствами обеспечения безопасности.

Несмотря на внешнюю похожесть, что вызвано общностью решаемых задач, между COM и CORBA, пожалуй, больше различий, чем сходства. В большинстве случаев либо нецелесообразно использовать CORBA (для небольших и простых проектов под Windows просто по причине относительно высоких затрат на приобретение программного обеспечения, лицензий и пр.), либо практически невозможно использовать COM (для сложных, масштабируемых, высоконадежных проектов или просто при работе в гетерогенных средах, а не только в Windows). Windows-приложения, ориентированные на взаимодействие с MicrosoftOffice, всегда будут использовать COM; проекты с использованием Java и любых Java-технологий (кроме Microsoft J++), как говорится, “сам бог велел” строить на основе CORBA. Во многих случаях выбор технологии диктует выбор той или иной части проекта: если вы планируете работать, например, с ORACLE 8i, то, безусловно, гораздо лучше ориентироваться на CORBA. Область, где эти технологии реально конкурируют, на мой взгляд, очень невелика. Как нетрудно заметить, автор настоящего обзора является сторонником CORBA, чего и желает всем своим читателям.

ЗАКЛЮЧЕНИЕ