Реферат: Предисловие редакторов русского издания

Содержание

Предисловие редакторов русского издания .............................................5

Часть 1. CORBA: "межгалактическая" основа..........................................8

Глава 1. Клиент/сервер в стиле CORBA.................................. 10

Глава 2. Объектный Web: CORBA встречает Java ...................41

Глава 3. Встречайте брокеров CORBA/Java.............................. 58

Часть 2 Принципы ORB. .........................................................................67

Глава 4. Статическая CORBA. ..................................................69

Глава 5. Динамическая CORBA................................................76

Глава 6. Экзистенциальная CORBA......................................... 89

Глава7. Метаданные: кто я? ................................................... 102

Часть 3. Сервисы CORBA ...................................................................... 121

^ Глава 8. Сервисы CORBA: Именования,

Жизненного Цикла и Событий ................................ 123

Глава 9. Сервисы CORBA: Объектный Трейдер ................... 144

Глава 10. Сервисы CORBA: Транзакции и

Совместный Доступ .................................................. 154

Глава 11. Сервисы CORBA: Безопасность............................... 171

^ Глава 12. Сервисы CORBA: Долговременное Хранение

и Внешнее Представление........................................ 201

Глава 13. Сервисы CORBA: Запросы и Контейнеры. ............ 229

Глава 14. Сервисы CORBA: Отношения и Время................... 243

Глава 15. Сервисы CORBA: Лицензирование и свойства....... 258

Часть 4. CORBA: Что Дальше?............................................................... 265

Глава 16. CORBA: ORB: Состояние Союза ............................ 267

Глава 17. CORBA: Следующее поколение............................... 278

Глава 18. Обзор Object Web II................................................... 304

Где искать информацию ........................................................................ 312

Основы CORBA

Роберт Орфали. Дан Харки, Джери Элвардс

Перевод: С.Кошель, а.цимбол Технический редактор: М.Аншина Титульный редактор; С.ОрАИК

Издательство ^МАЛИПо Москва, 1999

Предисловие редакторов русского издания 4

^ Часть 1. CORBA:"межгалактическая" основа 5

Введение в часть 1. 5

Глава 1. 5

Клиент/сервер в стиле CORBA 5

Распределенные объекты в стиле CORBA 6

Что такое распределенные объекты CORBA? 6

Компоненты CORBA: от системных овъектов к визнес-объектам 7

ОМА - Архитектура Управления Объектами от OMG (Object Management Architecture) 8

Брокер ОБъектиых запросов - Object Request Broker (ORB) 8

ОКБ против RPC 9

Анатомия CORBA 2.0 ORB 9

CORBA 2.0; межгалактический ORB 11

CORBA 2.0: Архитектура Взаимодействия ORB (Inter-ORB) 12

Сервисы CORBA 13

Объектные Сервисы: Middleware под заказ 15

Общие средства CORBA (CORBAfacilities) 15

^ CORBA BUSINESS OBJECTS: БИЗНЕС-ОБЪЕКТЫ 15

Взаимодействие Бизнес-объектов 16

Анатомия визнес-ОБъектов CORBA 17

Анатомия клиент/серверных Бизнес- объектов 18

Нирвана компонентов CORBA 18

Трехзвенная архитектура клиент/сервер в объектном стиле 19

Заключение 20

^ Глава2. Объектный Web:CORBA встречает Java 21

Эволюция Web 21

CGI - протокол, который не покинет нас 22

Трехзвенный Объектный Web 22

Клиент/серверные взаимодействия в Object Web 23

Что CORBA привносит в Java 23

Другие претенденты 24

Что Java привносит в CORBA 25

Клиент/серверный Object Web 26

Встречайте игроков 27

Заключение 29

Глава 3. 29

Встречайте Брокеров CORBA/Java 29

Sun Joe 29

NEO и Joe: краткая история 29

Что такое Joe? 30

Обратные вызовы 30

lona OrbixWeb 31

Что такое OrbixWeb? 31

Inprise (Visigenic) VisiBroker for Java 31

Что такое VisiBroker for Java? 32

Как медлительны Java ORB7 32

VisiBroker и Netscape ONE 32

Который из Java ORB7 33

Другие CORBA ORB 33

Заключение 33
^ Предисловие редакторов русского издания
Ура! Свершилось. Появилась первая книга по технологии CORBA на русском языке. Мы долго этого ждали. Почти 10 лет. Именно столько исполнилось в этом году международному консорциуму OMG (Object Management Group), который создал и развивает эту технологию. За это время он вырос с 8 компаний до более чем 800 и объединяет сейчас практически всех крупных поставщиков компьютерной продукции, а также крупнейших её потребителей в различных отраслях промышлен­ности. В основе создания OMG и CORBA лежит светлая идея объедине­ния промышленных приложений в единую информационную среду. Для этого была создана открытая архитектура и набор стандартов, которые и соединены в понятии ОМА (Object Management Arhitecture) CORBA (Common Object Request Broker Architecture). В неё входит также описа­тельный язык определения интерфейсов - IDL (Interface Definition Language). Обо всём этом, обо всех аспектах технологии подробно напи­сано в предлагаемой Вам книге.

Значение создания CORBA трудно переоценить. Разрозненные про­граммные системы с помощью интеллектуальных брокеров объектных запросов, дополнительных сервисов и общих средств, а также межбро-керного протокола, функционирующего поверх Интернет, образуют всеобъемлющую программную среду. Дух захватывает от перспектив, которые становятся доступны. Все последние достижения в области про­граммного обеспечения: клиент-серверные технологии, объектная иде­ология, современные средства моделирования объединились и привели к подъёму отрасли на качественно новую ступень развития.

Наверное, одно из самых популярных слов этой книги кроме спе­циальных терминов — амбициозный (ambitious). Амбициозные, гранди­озные цели и задачи ставит перед собой OMG, консорциум — родитель стандартов.

^ Часть 1. CORBA:"межгалактическая" основа Введение в часть 1.
Мы начинаем первую часть с "межгалактических" основ CORBA. Мы представим плавное введение в инфраструктуру ORB, HOP и CORBA 2.0. Затем рассмотрим Объектный Web (Object Web) - «убийцу прило­жений» от CORBA. Это не просто еще один рассказ о том, как суще­ствующая технология была адаптирована (через HTTP/CGI) для рабо­ты с World Wide Web. Вместо этого, CORBA приходит на смену HTTP/ CGI. Web возрождается на вершине инфраструктуры распределенных объектов CORBA. Мы называем этот союз распределенных объектов и Internet — Объектный Web (Object Web).

Ведущие компьютерные компании — такие, как Sun, JavaSoft, IBM/Lotus, Netscape, Apple, Oracle, BEA и HP, выбрали Объектный Web на основе CORBA в качестве своей "межгалактической" компо­нентной инфраструктуры. CORBA HOP обеспечивает универсальный способ для связи распределенных объектов через Internet и intranet. Сле­довательно, CORBA может стать настолько же повсеместной, как и TCP/ IP. Объектный Web создаст массовый рынок компонентов, которые фун­кционируют поверх промежуточного программного обеспечения (middleware) CORBA. Однако, мы только начинаем продвигаться впе­ред в нашем рассказе . Для того, чтобы получить больше реальных сведе­ний, прочитайте первую часть.

Вот те темы, которые мы осветим в первой части:

• Глава 1 дает взгляд "с высоты птичьего полета" на CORBA 2.0. Это самое быстрое в мире введение в CORBA для по-настоящему нетер­пеливых людей. Эта глава позволит стать вам гуру по основам CORBA за два часа или даже меньше. Разумеется, вы должны быть действи­тельно занятым человеком, если хотите остановиться только на этом кратком введении. Для остальных наших читателей данная глава дает только «вид сверху» на CORBA — можно сказать "панораму леса". Сами же "деревья" рассматриваются в главах 2 и 3. К концу чтения этой главы вы будете знать все об ORB, HOP, сервисах CORBA (CORBAservices), общих средствах CORBA (CORBAfacilities), а так­же о прикладных объектах CORBA (CORBA business objects). Кроме того, вы узнаете и о трехзвенных вычислениях клиент/сервер "в стиле CORBA".

• Глава 2 посвящена Объектному Web - "убийце приложений" от CORBA. Вначале мы расскажем о значении CORBA для Web. Затем мы расскажем о том, что нового CORBA привносит в Java и наобо­рот. Мы объясним то, как объектные модели Java и CORBA дополня­ют друг друга. После этого мы сравним CORBA с ее конкурентами — HTTP/CGI, DCOM/Java, Java RMI и сокетами (Sockets). Наконец, мы представим основных игроков Объектного Web на основе CORBA. А таких довольно много.

• Глава 3 рассказывает о CORBA/Java ORB. Это новейшие и лучшие среди брокеров ORB. Он созданы целиком на Java. Следовательно, они еще и переносимые ORB - так называемые ОКВлеты (ORBlets). Действительно, теперь вы можете загружать CORBA ORB везде в пределах "межгалактической" сети как часть аплетов Java. ORB будут также встраиваться в браузеры, в этом случае вам не придется их загружать отдельно.

Мы надеемся, что вы получите удовольствие от обзорного путеше­ствия, даже если оно покажется вам слишком подробным. Первая часть представляет собой фундамент, необходимый для понимания осталь­ных частей книги. Если вы выбрали ускоренный вариант, то мы предпо­лагаем, что вы все же прочитаете первую часть полностью, прежде чем перейдете непосредственно к четвертой части. Возможно, это все, что вам необходимо знать о CORBA.
^ Глава 1. Клиент/сервер в стиле CORBA
Общая Архитектура Брокеров Объектных Запросов — Common Object Request Broker Architecture (CORBA) является наиболее важным (и амби­циозным) проектом в области промежуточного программного обеспе­чения (middleware), который когда-либо выдвигала компьютерная про­мышленность. CORBA — результат работы консорциума Object Management Group (OMG), который включает более 700 компаний, представляющих весь "цвет" компьютерной индустрии. Единственным значимым исклю­чением является Microsoft, у которой есть собственная (конкурирую­щая) технология объектного брокера, называемая Distributed Component Object Model (DOOM). (Примечание переводчика: Сейчас Microsoft явля­ется членом OMG). Для остальной части компьютерной промышленнос­ти следующим поколением middleware является CORBA. Объектная шина (object bus) CORBA определяет структуру "живущих на ней" компонен­тов, а также способы их взаимодействия. Следовательно, выбирая откры­тую объектную шину, индустрия тем самым выбирает действительно от­крытую, ничем не ограниченную область применения компонентов.

Что делает CORBA крайне важной, так это то, что она определяет промежуточное программное обеспечение, которое потенциально свя­зано со всеми другими формами существующих клиент/серверных middleware. Другими словами, CORBA использует объекты как унифи­цирующую метафору для объединения уже существующих приложений единой шиной взаимодействия. В то же время, она обеспечивает надеж­ный фундамент для построения будущего, основанного на компонентах. Ценность CORBA состоит в том, что вся ее система самоопределяема (самоописываема). Кроме того, спецификация сервиса всегда отделена от его реализации. Это позволяет вам соединять существующие системы с единой шиной.

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

CORBA позволяет вам создать простой объект, а затем сделать его транзакционным, защищенным, блокируемым, или сохраняемым, за счет применения множественного наследования от соответствующих сервисов. Это означает, что вы можете сначала спроектировать обыч­ный компонент с требуемой функциональностью, а затем дополнить его средствами промежуточного программного обеспечения, как на ста­дии его компиляции, так и на стадии выполнения. Так что, добро пожа­ловать в эпоху гибкого middleware, «сделанного на заказ». В любых других формах клиент/серверных технологий не существует ничего подобного.

Данная глава рассказывает об объектной шине CORBA и объектных системных сервисах, расширяющих эту шину. Мы начнем с обзора CORBA и с того, что она значит для интеллектуальных компонентов. Затем, мы рассмотрим объектную модель CORBA и архитектуру, кото­рая связывает это все в единое целое. Наконец, мы оценим перспекти­вы хорошо известных технологий клиент/сервер. Как вы увидите, неко­торых важных моментов для распределенных объектов все еще не хвата­ет. В части 4 мы и коснемся того, что готовит OMG в своих новых спецификациях.
^ Распределенные объекты в стиле CORBA
Возможно, секрет успеха OMG заключается в том, что эта группа создает спецификации интерфейсов, но не код как таковой. Интерфей­сы, определенные OMG, всегда основаны на реальных технологиях, раз­работанных компаниями — членами этой группы. Спецификации напи­саны на пассивном языке описания интерфейсов IDL (Interface Definition Language), который определяет функциональность компонентов, — т.е. внешние (часто называемые контрактными) интерфейсы с потенциаль­ными клиентами (в программном смысле). Компоненты, написанные на IDL, должны быть доступны независимо от программных языков, инст­рументальных средств, операционных систем и сетевой инфраструктуры программных компонент. А после принятия в декабре 1994 специфика­ции CORBA 2.0 эти компоненты будут способны взаимодействовать че­рез объектные брокеры CORBA, созданные разными производителями.
^ Что такое распределенные объекты CORBA?
Объекты CORBA представляют собой интеллектуальные единицы способные жить в любом месте сети. Они упакованы в виде двоичных компонентов, к которым удаленные клиенты могут обращаться, вызывая их методы. Как язык, так и компилятор, используемые для создания серверных объектов, являются полностью прозрачными для клиентов. Клиент не обязан знать, где располагается распределенный объект или под управлением какой операционной системы он выполняется. Он может находиться в том же процессе или на машине, расположенной где-то в "межгалактической" сети. Кроме того, клиенту не нужно знать, как ре­ализован серверный объект. Например, серверный объект может быть реализован как набор классов C++ или с помощью миллиона строк на КОБОЛе - клиент не почувствует разницу. В чем действительно нужда­ется клиент, так это в опубликованном интерфейсе своего серверного объекта. Такой интерфейс служит связующим контрактом между клиен­том и сервером. Весь смысл в IDL

Как мы уже сказали, CORBA использует контракты IDL для указа­ния границ компонентов и их контрактных интерфейсов с потенциаль­ными клиентами. CORBA IDL является чисто декларативным языком. Это означает, что он не описывает детали реализации. Вы можете ис­пользовать IDL, чтобы лаконично определить API, а также некоторые важные моменты, например, обработку ошибок. Методы, определен­ные на языке IDL, могут быть реализованы и вызваны из любых язы­ков, которые обеспечивают поддержку CORBA. В настоящий момент это С, C++, Ada и Smalltalk (COBOL, Java и Objective С находятся в работе) (Примечание переводчика: в настоящее время эти компилято­ры уже созданы). Программисты имеют дело с объектами CORBA, ис­пользуя естественные и хорошо знакомые языковые конструкции. Для всех сервисов и компонентов, которые связаны с шиной CORBA, IDL предоставляет интерфейсы, не зависящие от операционной системы и языка программирования. IDL позволяет взаимодействовать клиентским и серверным объектам, написанным на различных языках (рис. 1-1).

Вы можете использовать OMG IDL для указания атрибутов компо­нентов, родительских классов, от которых они

унаследованы, исключительных ситуаций, порождаемых компонентами, генерируемых ими событий, а также методов, которые поддерживаются интерфейсом ком­понентов, включая входные и выходные параметры методов и их типы данных. Грамматика IDL является подмножеством C++ с дополнитель­ными ключевыми словами для поддержки концепции распределенности, кроме того, полностью поддерживаются особенности стандарта пре­процессора C++ и директивы pragma.

Амбициозность целей CORBA заключается в «IDL-изации» всего клиент/серверного middleware и всех компонентов, взаимодействующих через ORB. OMG надеется достичь этих целей с помощью следующих двух шагов: 1) она превратит все в гвозди и 2) даст каждому молоток.

• «Гвоздем» программы станет IDL. Он позволяет производителям ком­понентов описать на стандартном языке определений интерфейсы и структуры поставляемых объектов. Определенные с помощью IDL кон­тракты связывают производителей распределенных объектных серви­сов с их клиентами. Объект, который запрашивает что-либо у другого объекта, обязан знать интерфейс этого объекта. Репозитарий Интер­фейсов (Interface Repository) CORBA содержит определения всех таких интерфейсов. Он содержит метаданные, позволяющие компонентам находить друг друга динамически во время выполнения (run-time). Это делает CORBA самоопределяемой системой.

• «Молоток» состоит из набора распределенных сервисов, которые будут поставлять производители OMG. Такие сервисы определяют:

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

Звучит знакомо? Конечно. Мы описываем «объектную волну» кли­ент/серверных вычислений. Нынешнее время — время взаимодействую­щих объектов в противоположность взаимодействующим процессам (Целью этой новой волны является создание для индустрии программ­ного обеспечения некоего объектного подобия "Lego" (самый популяр­ный в мире игрушечный конструктор, прим. ред.) , не зависящего от конкретных производителей, не зависящего от операционных систем, и языков программирования.) Целью этой "новой волны" является создание мультипроизводителей, мультиоперационных систем, муль-тиязыков, функционирующих в "Лего" мире, используя объекты. (При­мечание переводчика: В данном случае "Лего" имеет смысл универсаль­ного идеального конструктора для создания программных компонен­тов). Такие производители, как Oracle, Sun, HP, IBM, Digital, Apple, Netscape, Tandem и NCR, используют CORBA как стандартный, IDL-ный интерфейс на объектной дороге. IDL является контрактом, кото­рый связывает их всех вместе.



Рис из номера. Наелись; "Дож* зампно. ао чего все похож» на позли "
^ Компоненты CORBA: от системных овъектов к визнес-объектам
Обратите внимание, что мы использовали термины «компоненты» и «распределенные объекты» как взаимозаменяемые. Распределенные объекты CORBA по определению являются компонентами из-за спосо­ба их упаковки. В распределенных объектных системах единицей работы и распределенности является компонент. Инфраструктура распределен­ных объектов CORBA предоставляет простые механизмы, чтобы ком­поненты стали более автономными, самоуправляемыми и взаимодей­ствующими. Такая заявка намного смелее, любых попыток конкуриру­ющих форм промежуточного программного обеспечения Технология распределенных объектов CORBA позволяет нам собирать в единое це­лое сложные информационные клиент/серверные системы, просто свя­зывая и расширяя их компоненты. Вы можете модифицировать объек­ты, не влияя на другие компоненты или на то, как они взаимодейству­ют. Клиент-серверные приложения превращаются в наборы взаимодей­ствующих компонентов

Последняя «нирвана» в области индустрии компонентов клиент/сер­вер - суперинтеллектуальные компоненты, которые не просто взаимо­действуют, — они сотрудничают на семантическом (смысловом) уров­не, чтобы выполнить необходимую работу. Программисты могут легко добиться необходимого взаимодействия компонентов, , создавая про­граммный код независимо для каждого компонента . Хитрость, однако, состоит в том, чтобы создать компоненты, которые a priori ничего не знают друг о друге, но сделают именно то, что нужно. Чтобы этого до­биться, необходимы стандарты, устанавливающие правила стыковки на разных уровнях взаимодействия компонентов.
^ ОМА - Архитектура Управления Объектами от OMG (Object Management Architecture)
Осенью 1990 года OMG впервые опубликовала Руководство по Ар­хитектуре Управления Объектами (Object Management Architecture Guide -ОМА Guide). Его обновление было сделано в 1992 году. Подробности, касающиеся Общих Средств (Common Facilities) были добавлены в янва­ре 1995. На рис.12 показаны четыре основных элемента данной архитек­туры: 1) Брокер Объектных Запросов (Object Request Broker - ORB) опре­деляет объектную шину CORBA; 2) Сервисы CORBA (CORBAservices) определяют системный уровень объектной структуры, которая расши­ряет шину; 3) Общие Средства CORBA (CORBAfacilities) определяют го­ризонтальные и вертикальные структуры, которые непосредственно используются бизнес-объектами; 4) Application Objects представляют прикладные объекты и приложения, то есть конечных потребителей инфраструктуры CORBA. Данный раздел описывает общий взгляд на четыре приведенных элемента инфраструктуры CORBA.
^ Брокер ОБъектиых запросов - Object Request Broker (ORB)
Брокер объектных запросов - это объектная шина. Она позволяет объектам прозрачно генерировать запросы и получать ответные отклики от других объектов - локальных или удаленных. Клиент ничего не знает о механизмах, используемых для коммуникации, активизации или хране­ния серверных объектов. Спецификации CORBA 1.1 (выпущенные в 1991) определяют только IDL, языковое связывание и API для обращения к ORB. Таким образом, вы могли бы написать переносимые программы, способные работать на дюжине CORBA-совместимых ORB, представ­ленных на рынке (особенно со стороны клиента). CORBA 2.0 определяет взаимодействие (interoperability) ORB разных производителей.



Рис 1.2 Архитектура Управления Объектами ОМС

CORBA ORB обеспечивает широкий спектр сервисов распределен­ного промежуточного программного обеспечения. ORB позволяет объек­там обнаруживать друг друга во время выполнения (run-time) и вызы­вать сервисы друг друга.

ORB намного более сложен, чем альтернативные формы клиент/ серверного middleware, включая традиционные вызовы удаленных про­цедур (Remote Procedure Calls - RPC), обмен сообщениями (Message-Oriented Middleware — MOM), хранимые процедуры баз данных или се­тевые службы взаимодействия "точка-точка" (peer-to-peer). Теоретичес­ки, CORBA является лучшим клиент/серверным middleware из когда-либо определенных. На практике же CORBA хороша настолько, насколько хорош реализующий эту архитектуру продукт.

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

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

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

^ Самоописываемая система. CORBA предоставляет метаданные на этапе выполнения для описания каждого серверного интерфейса, известного системе. Каждый CORBA ORB должен поддерживать Ре-позитарий Интерфейсов (Interface Repository), который содержит те­кущую (real-time) информацию, описывающую предоставляемые сервером функции и их параметры. Клиенты используют метадан­ные, чтобы определить, каким образом вызывать сервисы во время выполнения. Метаданные также помогают инструментальным сред­ствам создавать код «на- лету». Такие метаданные генерируются ав­томатически либо прекомпиляторами языка IDL, либо такими ком­пиляторами, которые знают, как генерировать IDL непосредствен­но из объектно-ориентированного языка. Например, компилятор MetaWare C++ генерирует IDL непосредственно из определения класса C++; Inprise VisiBroker/Netscape Caffeine генерирует IDL не­посредственно из байт-кода Java. Насколько нам известно, не суще­ствует других видов middleware клиент/сервер, которые бы обеспечи­вали такой тип метаданных и независимые от языка определения для всех своих сервисов. Как станет ясно из дальнейшего изложения, все бизнес-объекты и компоненты требуют позднего связывания, чтобы обеспечить наибольшую гибкость, на которую они способны. Прозрачность локальная/удаленная. ORB может выполняться в авто­номном режиме на лаптопе, или же может взаимодействовать со всеми другими ORB во вселенной, используя сервисы протокола ПОР (Internet Inter-ORB Protocol — Internet-протокола взаимодействия ORB) стандарта CORBA 2.0. ORB может выступать в качестве посред­ника для межобъектных вызовов внутри единственного процесса, нескольких процессов, выполняющихся на одном компьютере, или множества процессов, выполняющихся в разных сетях под управле­нием разных операционных систем. Такой механизм полностью про­зрачен для ваших объектов. Обратите внимание, что ORB может выступать посредником как между "мелко-зернистыми" объектами — подобными классам C++, так и для более масштабных — "круп­но-зернистых" объектов. В общем случае, CORBA-программисту нет дела до транспортных протоколов, местоположения серверов, ак­тивации объектов, порядка следования байтов через различные плат­формы или целевых операционных систем — CORBA все это сделает прозрачным.

• ^ Встроенная безопасность ч транзакции. ORB включает в свои сообще­ния контекстную информацию для управления безопасностью и тран­закциями при переходе с машины на машину и через границы ORB.

• ^ Полиморфные сообщения. В отличие от других форм middleware, ORB не просто вызывает удаленную функцию — он вызывает функцию целевого объекта. Это означает, что вызов одной и той же функции может дать разный эффект, в зависимости от объекта, принимаю­щего вызов. Например, вызов метода con'figure_yoiirself приведет к разным результатам в случае вызова для объекта базы данных и для объекта-принтера (см. также следующую врезку).

• ^ Сосуществование с существующими системами. Отделение опреде­ления объекта от его реализации в архитектуре CORBA обеспечива­ет возможность инкапсуляции существующих приложений. Исполь­зуя CORBA IDL, вы можете сделать ваш существующий код, по­добным объекту на шине ORB, даже если он реализован в хранимых процедурах, CICS, IMS или КОБОЛе. Это делает CORBA эволюци­онным решением. Вы можете написать ваши новые приложения как "чистые" объекты и инкапсулировать существующие приложения в IDL-обертку.
^ ОКБ против RPC
Итак, чем вызовы методов ORB отличаются от вызовов RPC? Эти механизмы очень похожи, но есть некоторые важные отличия. С помо­щью RPC вы вызываете указанную функцию (данные отделены). С по­мощью ORB, наоборот, вы вызываете метод определенного объекта. Различные объектные классы могут отвечать на вызов одного и того же метода по-разному благодаря полиморфизму. Поскольку каждый объект управляет своим собственным экземпляром данных, вызываемый ме­тод работает с этим определенным экземпляром данных (рис. 1-3).

Вызов методов ORB обладает точностью скальпеля. Вызов направ­ляется определенному объекту, который управляет конкретными дан­ными, затем выполняется функция определенным для данного класса способом. Вызовы RPC, наоборот, не отличаются специализацией - все функции с одним и тем же именем реализованы одинаково. Здесь нет дифференцированных сервисов.



^ Анатомия CORBA 2.0 ORB
CORBA 2.0 Object Request Broker представляет собой промежуточ­ное программное обеспечение, которое устанавливает клиент/сервер­ные отношения между объектами. Используя ORB, объект-клиент мо­жет прозрачно (не задумываясь ни о чем) вызывать метод объекта-сер­вера, который может находиться на той же машине или где-то в сети. ORB перехватывает вызов и отвечает за поиск объекта, способного от­ветить на запрос, передает ему параметры, вызывает метод и возвраща­ет результат. Клиент не должен беспокоиться о том, где расположен объект, на каком языке программирования он создан, под управлением какой операционной системы выполняется и т.п. Клиента никогда не интересуют системные аспекты объектов, не являющиеся частью их интерфейсов. Очень важно отметить то, что роли клиент/сервер исполь­зуются только для координации взаимодействия между двумя объекта­ми. Объекты на шине ORB могут выступать и в качестве клиентов, и в качестве серверов, в зависимости от ситуации.

На рис. 1-4 показаны клиентская и серверная части CORBA ORB. Светлые части являются новыми для CORBA 2.0. Несмотря на большое количество прямоугольников, ситуация не так запутана, как кажется. Главное - необходимо понять, что CORBA, подобно SQL, предостав­ляет как статические, так и динамические интерфейсы для своих серви­сов. Это произошло потому, что OMG получила два запроса на разра­ботку ORB: один от HyperDesk и Digital, основанный на динамическом API, а другой от Sun и HP, основанный на статическом API. OMG дала задание двум группам объединить эти две особенности. Результатом яви­лась CORBA. «Общая» («Common») в аббревиатуре CORBA означает слияние предложений для такого двойного API, что имеет колоссаль­ный смысл, поскольку дает нам и статический и динамический API.



Для начала давайте рассмотрим, что делает CORBA с клиентской стороны:

• ^ IDL-стабы клиента (Client IDL Stubs) обеспечивают статические интерфейсы к объектным сервисам. Такие прекомпилированные ста-бы определяют, как клиенты вызывают соответствующие сервисы на сервере. С точки зрения клиента стабы подобны локальному вы­зову — это локальный заместитель (proxy) для удаленного серверно­го объекта. Эти сервисы определяются посредством IDL., Стабы и клиента и сервера генерируются компилятором IDL. Клиент должен иметь IDL-стаб для каждого интерфейса, который он использует на сервере. Стаб содержит код маршалинга — marshaling). Это означает, что стаб кодирует и декодирует операцию и ее параметры в едино­образный формат сообщения, которое может быть отослано серверу. Он также содержит заголовочные файлы, которые дают возмож­ность вызывать метод сервера из языка высокого уровня (С, C++, Java или Smalltalk), не заботясь о базовом протоколе или таких пре­образованиях, как упорядочение данных. Для обращения к удален­ному сервису вы просто вызываете метод из вашей программы.

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

• API Репозитария Интерфейсов (Interface Repository API) позволяет вам получать и модифицировать описания интерфейсов всех зареги­стрированных компонентов, поддерживаемых ими методов и их па­раметров. CORBA называет такие описания — сигнатурой метода (method signature). Репозитарий интерфейсов представляет собой рас­пределенную базу данных реального времени которая содержит в машинном формате версии определенных на IDL интерфейсов. Ду­майте о нем, как о динамическом репозитарии метаданных ORB. Данный API разрешает компонентам динамический доступ, хране­ние и модификацию метаданных. Такое всеобъемлющее использо­вание метаданных позволяет каждому компоненту, живущему на ORB, иметь самоописываемый интерфейс. Сам ORB является само­описываемой шиной (см. следующую врезку).

• Интерфейс ORB состоит из нескольких API к локальным сервисам, которые могут быть полезны приложениям. Например, CORBA пре­доставляет API для преобразования ссылки на объект в строку и наоборот. Эти вызовы могут быть очень полезны, если необходимо хранить ссылки на объекты и использовать их для связи с объектами. CORBA 2.0: Глобальные репозитарные идентификаторы В стандарте CORBA 2.0 ORB предоставляют глобальные идентифи­каторы - Репозитарные ID (Repository ID) — для уникальной и глобаль­ной идентификации компонентов и их интерфейсов среди ORB разных производителей и множества репозитариев. Репозитарный ID генериру­ется системой и представляет собой уникальную строку, которая ис­пользуется для поддержания целостности в соглашениях по наименова­нию. Соглашения по наименованию используются для всех репозитари­ев, при этом конфликты имен недопустимы. Репозитарный ID генери­руется директивой pragma языка IDL. Эта директива специфицирует, генерировать ли идентификатор с использованием системы универсаль­ных уникальных идентификаторов (Universal Unique Identifiers — UUID) DCE или он будет определяться пользователем — добавлением уникаль­ного префикса к составным именам IDL. Сам по себе репозитарный ID представляет строку, состоящую из трехуровневой иерархии имен.

Поддержка как статических, так и динамических вызовов клиент/ сервер, а также репозитарии интерфейсов, дает CORBA неоспоримые преимущества по сравнению с конкурирующими middleware. Статичес­кие вызовы легче программировать, они быстрее и самодокументируе­мы. Динамические вызовы предоставляют максимальную гибкость, но они сложнее в программировании; они очень полезны для инструмен­тальных средств, которые исследуют сервисы во время выполнения.

Серверная часть не может определить разницу между статическим и динамическим вызовом; оба они имеют одинаковую семантику сообщения. В обоих случаях ORB находит объектный адаптер сервера, пере­дает ему параметры, а затем передает управление коду объекта с помо­щью IDL-стаба (или скелетона - skeleton) сервера. На рис. 1-4 показа­но, что делают элементы CORBA на стороне сервера:

• ^ IDL-стабы сервера (Server IDL Stubs) (OMG называет их скелетона­ми - skeletons) предоставляют статические интерфейсы каждому сервису, экспортируемому сервером. Эти стабы, как и стабы клиен­тов, создаются компилятором IDL.

• ^ Интерфейс Динамических Скелетонов (Dynamic Skeleton Interface -DSI), введенный в CORBA 2.0, предоставляет механизм связывания реального времени для тех серверов, которым необходимо управ­лять входящими вызовами методов компонентов не имеющих IDL-скомпилированных скелетонов (или стабов). Динамический скеле­тон ищет значения параметров во входном сообщении, чтобы по­нять, для кого они предназначены, т.е. для какого объекта и метода. В противоположность этому, нормально скомпилированные скелето­ны определены для конкретного класса объектов и располагают реа­лизацией для каждого метода, описанного на IDL. Динамические ске­летоны чрезвычайно полезны для реализации универсальных мостов между ORB. Они могут также использоваться интерпретаторами и языками сценариев, чтобы динамически сгенерировать реализацию объекта. DSI является серверным эквивалентом DII. Он может вос­принимать как статические, так и динамические вызовы клиентов.

• ^ Объектный Адаптер (Object Adapter) располагается на вершине ядра коммуникационных сервисов ORB и принимает запросы к сервису со стороны серверных объектов. Он обеспечивает среду реального времени для создания экземпляров серверных объектов, передачи запросов объектам и назначения объектам идентификаторов (ID) — CORBA вызывает идентифицированные объектные ссылки (object references). Объектный адаптер также регистрирует поддерживаемые им классы и их экземпляры этапа выполнения (т.е. объекты) в Репо-зитарии Реализации (Implementation Repository). CORBA указывает, что каждый ORB должен поддерживать хотя бы стандартный адап­тер - Базовый Объектный Адаптер (Basic Object Adapter - BOA). Сер­веры могут поддерживать более одного адаптера.

• Репозитарий Реализации (Implementation Repository) является репози-тарием времени выполнения с информацией о классах, поддержи­ваемых сервером, об объектах, экземпляры которых созданы, а так­же их ID. Он также служит общим хранилищем дополнительной ин­формации, связанной с реализацией ORB. В качестве примера мож­но привести информацию о трассировке, безопасности и другие административные данные.

Интерфейс ORB состоит из нескольких API к локальным сервисам, которые идентичны таковым на клиентской стороне. На этом закончим панорамный обзор компонентов ORB и их интер­фейсов.
^ CORBA 2.0; межгалактический ORB
Стандарт CORBA 1.1 касался только создания переносимых объект­ных приложений; реализация ядра ORB была оставлена в качестве уп­ражнения для производителей. Результатом явился некоторый уровень переносимости компонентов, но не их взаимодействия. Стандарт CORBA 2.0 добавил возможность взаимодействия, введя обязательный Internet-Протокол Взаимодействия ORB (Internet Inter-ORB Protocol - HOP). ПОР представляет собой в основном протокол TCP/IP с некоторыми эле­ментами обмена сообщениями, определенными CORBA, который фун­кционирует как общий опорный (backbone) протокол. Каждый ORB, который выполняет вызов в CORBA-совместимой среде, обязан полно­стью реализовать НОР или, как минимум, обес