В публикациях этого раздела в предыдущих номерах журнала обсуждались архитектурные концепции и технологии интероперабельных информационных систем, анализировалось текущее состояние развития этого важного направления в проектировании и разработке распределенных информационных систем [1], был представлен обзор основных компонентов стандарта систем управления объектными базами данных ODMG-93 [5]. Наконец, в контексте обсуждения основных принципов архитектуры CORBA и концепций объектной модели OMG были рассмотрены важные компоненты стандарта CORBA - спецификации языка определения интерфейсов объектов OMG IDL и его отображений в объектно-ориентированные языки программирования [6].
Предлагаемая работа1) посвящена обсуждению и анализу тех новых возможностей, которые привнесены OMG в версию стандарта CORBA 2.0 с целью существенного развития средств поддержки концепции интероперабельности. Речь пойдет здесь об обеспечении интероперабельности брокеров объектных заявок.
1. Введение
Object Management Group (OMG), крупнейший в мире консорциум по разработке программного обеспечения, в соответствии со своей основной задачей разработки технологии, допускающей повторное использование, переносимость и интероперабельность программных и информационных компонентов в распределенных неоднородных средах, совершил в 1995 году радикальный шаг, обеспечивающий распространение архитектуры CORBA (Common Object Request Broker Architecture) на компьютерные сети произвольного масштаба.
Летом 1995 года OMG была опубликована новая версия стандарта - CORBA 2.0 [11]. Из нововведений, имеющих отношение к обсуждаемой в данной работе проблеме, нужно прежде всего отметить некоторые архитектурные усовершенствования. Так, для брокера объектных заявок введены интерфейсы динамических скелетонов - серверных интерфейсов, позволяющих передавать запросы от брокера реализациям объектов, о типе которых разработчик не располагает информацией на стадии компиляции. Такой интерфейс представляет собой серверный аналог клиентского интерфейса динамического вызова.
Наиболее существенные нововведения в CORBA 2.0 связаны, однако, с допущением более высокой степени неоднородности распределенной объектной среды, являющейся "областью действия" стандарта, а именно допускается сосуществование в этой среде нескольких (возможно, разнотипных) брокеров и описываются механизмы их взаимодействия. В частности, специфицированы протоколы обмена сообщениями между брокерами, в числе которых, что весьма важно, предусмотрен специальный протокол обмена в среде Internet. Это последнее обстоятельство способствует существенному расширению сферы применения стандартов CORBA. Таким образом, в CORBA 2.0 в достаточно общем виде решается проблема интероперабельности брокеров - "interORBability", как называют ее авторы стандарта.
Обсуждению именно этих элементов стандарта CORBA 2.0 посвящается данная работа. Рассматриваются архитектурные аспекты взаимодействия брокеров, использование мостов для преобразования сообщений, которыми обмениваются брокеры, а также предложенные OMG протоколы взаимодействия брокеров (межброкерные протоколы). Представлены, наконец, возможные подходы к интеграции технологий CORBA и World Wide Web, благодаря которой обеспечиваются чрезвычайно важные новые возможности оперирования информационными ресурсами в Internet и осуществление которой стало возможным благодаря введению CORBA 2.0.
2. Концепция интероперабельности брокеров в CORBA 2.0
В предшествующих версиях стандарта CORBA [9, 10] обеспечивалась интероперабельность объектов, управляемых некоторым брокером. Задача интероперабельности брокеров ставилась, однако ее конструктивного решения эти версии стандарта не предлагали.
Интероперабельность объектов достигалась благодаря архитектуре, ключевым компонентом которой является брокер объектных заявок, играющий роль посредника во взаимодействии объектов-клиентов и объектов-серверов, а также спецификациям интерфейсов на языке OMG IDL (IDL-спецификациям), независимом от конкретных брокеров. Эти возможности обсуждались более подробно в [1, 6].
Брокер представляет собой механизм, позволяющий объектам выдавать заявки и получать ответы прозрачным образом. Благодаря этому обеспечивается интероперабельность между приложениями на различных аппаратных платформах в неоднородных распределенных средах. Необходимо подчеркнуть, что речь идет здесь о технической интероперабельности в том смысле, как это понятие интерпретируется в [1].
Интероперабельность брокеров распространяет эту возможность на случаи, когда объекты-клиенты и объекты-серверы ассоциированы с несколькими однотипными или разнотипными брокерами. Под однотипными брокерами понимаются здесь различные установки одной и той же реализации брокера какого-либо производителя, а установки различных реализаций брокера мы называем разнотипными брокерами.
Интероперабельность брокеров трактуется OMG как способность объекта-клиента, управляемого брокером-1, вызывать определенные IDL-спецификациями операции объекта-сервера, управляемого брокером-2, при условии, что брокер-1 и брокер-2 были разработаны независимо друг от друга. Иначе говоря, такие вызовы должны быть независимы от того, одним и тем же или разными (возможно, разнотипными) брокерами поддерживаются взаимодействующие объекты.
CORBA 2.0 предлагает конструктивное решение проблемы обеспечения интероперабельности брокеров. При этом авторы стандарта полагают, что предложенный ими подход достаточно универсален, поскольку для каждого конкретного случая можно выбрать подходящую комбинацию предусмотренных элементов поддержки интероперабельности (протоколов передачи сообщений между брокерами, видов мостов для трансформаций передаваемой информации).
Представляется уместным заметить здесь, что в рамках стандарта CORBA 2.0 OMG по-прежнему ограничивается лишь поддержкой технического уровня интероперабельности [1], основанного на полной инкапсуляции ресурсов посредством IDL-спецификаций интерфейсов. Достижение семантической интероперабельности ресурсов в контексте задачи является весьма сложной проблемой. Для этого требуется решение вопросов о релевантности имеющихся ресурсов задаче, о соответствии их прикладного контекста контексту задачи, а также о непротиворечивости интероперабельной композиции ресурсов в прикладном контексте задачи при обеспечении ее решения.
В [4] было введено понятие полной семантически интероперабельной инфраструктуры, обеспечивающей необходимые моделирующие, методологические и архитектурные средства анализа, принятия решений, доказательных рассуждений и реализации, ориентированные на повторное использование ресурсов в семантически интероперабельных композициях. Эта инфраструктура считается дополнительной по отношению к архитектуре OMG [3].
Разработка подходов, обеспечивающих семантическую интероперабельность разнородных ресурсов, уже в течение ряда лет ведется в Институте проблем информатики РАН в рамках проектов СИНТЕЗ и INTAS INFOSEM (грант INTAS 94-1817). Эти проекты опираются на архитектуры, обеспечивающие техническую интероперабельность ресурсов. Полные спецификации ресурсов в рамках канонической объектной модели высокого уровня образуются в результате трансформации, унификации, обобщенного представления их первоначальных спецификаций. Информационные ресурсы содержат факты, правила и демонстрируют поведение, которое имеет определенную интерпретацию в прикладном контексте ресурса. Каждый ресурс сопровождается онтологическими спецификациями, позволяющими "склеивать" ресурсы в непротиворечивую композицию в контексте прикладной области. Такая композиция должна быть конкретизацией прикладной задачи.
Для спецификации и проектирования семантически интероперабельных информационных систем используются специальные языки и методологии проектирования [2, 4]. Эти подходы развиваются в указанных проектах с учетом последних достижений CORBA и ее интеграции с WWW.
Возвращаясь теперь к стандарту CORBA 2.0, рассмотрим подробнее предложенный OMG подход и те элементы стандарта, которые обеспечивают поддержку интероперабельности брокеров объектных заявок.
3. Поддержка интероперабельности брокеров в CORBA 2.0
Как уже отмечалось, стандарт CORBA 2.0 не ограничивается декларациями о необходимости обеспечения интероперабельности брокеров объектных заявок. В нем предлагается конструктивная техника для решения этой проблемы, которая обсуждается в данном разделе.
Прежде всего рассматриваются принципы организации брокеров, вводится понятие домена как составной части "области действия" брокера, обсуждаются архитектурные аспекты взаимодействия брокеров, ассоциированных с разными доменами, а также механизмы преобразования представления межброкерных сообщений в терминах одного домена в представление их в терминах другого домена, называемые мостами.
Основные идеи предложенных в CORBA 2.0 протоколов обмена сообщениями между брокерами, в том числе протокола, обеспечивающего взаимодействие брокеров в среде Internet, будут обсуждаться в следующих разделах.
3.1. Брокеры объектных заявок
В распределенной объектной системе объекты взаимодействуют между собой. Объекты-серверы оказывают различные услуги (выполняют операции) по заявкам объектов-клиентов. В CORBA 2.0 предусматривается, что услуги могут оказываться не только объектами приложений. Некоторые часто используемые услуги стандартизованы, и системы объектов, их реализующие, называются Объектными службами [1].
Основу спецификаций интероперабельности брокеров в CORBA 2.0 составляет предложенный OMG архитектурный подход, предусматривающий использование в качестве стержневого элемента или "общей шины" в распределенной системе объектов специального компонента-посредника между объектами-клиентами и объектами-серверами, названного брокером объектных заявок [6]. Главная часть брокера называется ядром. Ядро брокера реализует некоторый минимальный набор функций, которые дают возможность объекту-клиенту вызывать операции объекта-сервера.
Помимо ядра брокер включает дополнительные компоненты, называемые брокерными сервисами и призванные решать довольно широкий круг задач при обработке заявок - от разрешения ссылок и кодирования/декодирования сообщений до поддержки секретности, управления транзакциями, восстановления или дублирования (replication) данных. В конкретных реализациях брокерные сервисы могут быть встроены в само ядро либо являются надстройками над ним.
Брокерные сервисы вызываются чаще всего неявным образом при обработке заявок, связанных с взаимодействиями на уровне приложений. Однако, с архитектурной точки зрения, брокерные сервисы как компоненты брокера принадлежат уровню промежуточного слоя (middleware) распределенной системы.
При функционировании брокерных сервисов обеспечиваются различные виды прозрачности. Прежде всего, сами вызовы их осуществляются, как правило, прозрачным для приложения образом. Далее, при помещении сообщений в буфер и извлечении сообщений из буфера Сервис кодирования/декодирования сообщений поддерживает прозрачность представления заявок. Сервис разрешения ссылок поддерживает прозрачность местоположения объектов и т.д. Сфера проявления различных видов прозрачности расширяется в случае интероперабельности брокеров.
Для обеспечения интероперабельности конкретной пары брокеров должны быть определены сервисы каждого из них и установлено соответствие между ними, поскольку брокерные сервисы, управляющие объектами-клиентами, с одной стороны, и объектами-серверами, с другой, взаимодействуют между собой при обработке заявок объектов-клиентов на выполнение различных операций. Соответствие между брокерными сервисами на стороне клиента и на стороне сервера вовсе не обязательно должно быть взаимно-однозначным. Выбор нужного целевого брокерного сервиса может осуществляться на основе анализа статических свойств объекта-клиента и объекта-сервера, динамических атрибутов заявки, путем использования оптимизационных методов, в соответствии с ограничениями секретности или каким-либо иным путем.
3.2. Домены
Компоненты распределенной неоднородной системы могут различаться их местоположением, характеристиками оборудования, сетевыми механизмами и т.д. Эти различия между сферами действия различных брокеров существенны с точки зрения обеспечения интероперабельности. Для возможности их описания вводится понятие домена.
Под доменом понимается множество объектов, обладающих какими-либо общими характеристиками и подчиняющихся некоторым общим правилам. Домены позволяют разделить систему на части, каждая из которых состоит из совокупности компонентов с общими свойствами, называемых членами соответствующего домена.
Домены могут выделяться по административному или по технологическому принципу. К числу административных можно отнести домены именования, домены управления ресурсами, домены характеристик системы, относящихся к периоду выполнения. Технологические домены выделяются по общности протоколов или, например, синтаксических либо иных характеристик периода разработки.
Сами домены могут рассматриваться как объекты, и, следовательно, домены могут быть членами других доменов. Один и тот же объект может быть членом нескольких доменов. Множества членов различных доменов могут пересекаться. По этим причинам доменная структура всей системы может быть весьма сложной.
С доменом связано понятие границы домена, интерпретируемое как граница той сферы, в рамках которой имеют силу присущие членам домена характеристики. Если некоторая характеристика, ассоциированная с одним доменом, транслируется в соответствующую ей характеристику, ассоциированную с другим доменом, то этот процесс трактуется как пересечение границы между этими доменами.
3.3. Соотношение между брокерами и доменами
В CORBA 2.0 допускаются различные соотношения между брокерами и доменами. Область действия одного брокера может включать один или несколько доменов, и, наоборот, один домен может охватывать области действия одного или нескольких брокеров.
Предполагается, что различные брокеры являются независимыми и могут ассоциироваться с различными доменами. Стандарт не предписывает никакого конкретного варианта декомпозиции функций брокеров, определяющей состав брокерных сервисов, а также структурирования доменов.
3.4. Домены и интероперабельность брокеров
В терминах доменов можно дать более точную трактовку понятия интероперабельности брокеров. Интероперабельность брокеров заключается, по существу, в возможности прозрачным образом пересекать границы доменов, составляющих их области действия.
Для того чтобы обеспечить прозрачность пересечения границ доменов, необходимо поддерживать точно определенное отображение понятий одного домена в понятия другого. Механизмы такого отображения называются мостами и будут рассматриваться далее.
Характер проблем, возникающих в связи с необходимостью обеспечения интероперабельности двух брокеров, существенным образом зависит от соотношения между этими брокерами и доменами, которые входят в их области действия. Простейший случай интероперабельности имеет место, когда все объекты, поддерживаемые одним брокером, принадлежат одному домену.
Проблемы интероперабельности могут возникнуть при взаимодействии не только разнотипных, но и однотипных брокеров. Примерами могут служить ситуации, когда взаимодействуют объекты, принадлежащие разным доменам, которые выделены по критерию секретности, или в связи с назначением различных идентификаторов эквивалентным типам объектов на разных брокерах.
Вместе с тем некоторые проблемы могут отсутствовать даже при взаимодействии двух разнотипных брокеров. Так, может использоваться один и тот же домен именования, и в таком случае нет необходимости в использовании какого-либо специального механизма отображения между доменами именования.
3.5. Мосты
Если при взаимодействии объектов пересекается граница доменов, то, как уже говорилось, должен использоваться механизм отображения, преобразующий заявки, представленные в терминах домена-источника заявки, в заявки, выраженные в терминах целевого домена, которому заявка адресуется. Такие механизмы называются мостами.
В CORBA 2.0 мосты часто именуются межброкерными, поскольку речь идет об отображениях между доменами, содержащими объекты, которые являются носителями специфической информации брокеров (домены ссылок, домены типов, домены секретности, домены транзакций и т.д.). По существу, мосты обеспечивают преобразование представления информации в форме, естественной для исходного брокера, в форму, свойственную целевому брокеру. Предполагается, что при этом сохраняется семантика передаваемой информации2.
Межброкерные мосты предлагается также использовать для обеспечения интероперабельности с системами, не удовлетворяющими стандартам CORBA. По этому принципу может быть, например, реализована известная объектная модель COM (Component Object Model) компании Microsoft [12]. Уровень сложности подобного рода разработок будет, естественно, зависеть от степени близости модели, используемой в такой системе, к объектной модели CORBA.
Мосты могут обеспечивать два вида отображений - опосредованное и непосредственное. При опосредованном отображении (mediate bridging) передаваемые через границу домена элементы трансформируются из их формы, внутренней для этого домена, в согласованную промежуточную общую форму.
Сфера действия этой общей формы может быть различной - от согласованного решения для конкретного случая (брокер/домен) до универсального стандарта. Может существовать несколько таких общих форм, каждая из которых ориентирована на конкретные частные случаи или оптимизирована для различных специальных целей. При существовании нескольких общих форм выбор подходящей формы для конкретного случая может быть как статическим, так и динамическим.
В случае непосредственного отображения (immediate bridging) передаваемые через границу домена элементы трансформируются из их внутренней для одного домена формы во внутреннюю форму другого домена. Непосредственное отображение потенциально является более эффективным, однако его использование приводит к потере гибкости и общности. Оно применяется чаще всего для связывания административных доменов (построенных на одинаковой технологии).
Возможны различные подходы к программной реализации мостов, обеспечивающих как опосредованное, так и непосредственное отображение. Один из важных критериев выбора подхода называется уровнем моста (bridging level). Мост может реализоваться полностью внутри брокера, и тогда он называется встроенным (in-line). В другом варианте мост реализуется как надстройка над брокером. Такой мост называется внешним (request-level).
Внешние мосты могут строиться без необходимости какой-либо информации о внутренней организации используемых брокеров. В то же время, при разработке встроенных мостов такая информация необходима.
Встроенные мосты (рис. 1) реализуют самый прямой метод отображения между брокерами. Со структурной точки зрения, этот метод подобен схемам взаимодействия, используемым в одном брокере.
Встроенный мост.
Встроенный мост реализуется внутренними средствами брокера, которые выполняют необходимые отображения. Здесь могут использоваться дополнительные или альтернативные брокерные сервисы, входящие в состав применяемых брокеров, дополнительные или альтернативные стабы и скелетоны. Обращение к внутренним средствам брокера осуществляется при этом через внутренние интерфейсы прикладного программирования брокера.
Внешние мосты (рис. 2) используют для получения и выдачи заявок обычные (пользовательские) API-интерфейсы брокеров, в том числе и интерфейсы динамических скелетонов. Реализуются мосты этого вида программным кодом, внешним по отношению к брокеру и имеющим статус приложения.
Внешний мост.
Различается два вида внешних мостов - мосты со специфическими интерфейсами (interface-specific bridges) и родовые мосты (generic bridges). Мосты со специфическими интерфейсами поддерживают только предопределенные IDL-интерфейсы и строятся с использованием интерфейсов стабов и скелетонов, генерируемых IDL-компилятором. Напротив, родовые мосты способны обрабатывать заявки к объектам-серверам с произвольными IDL-интерфейсами, используя Репозитарий интерфейсов, интерфейсы динамического вызова, интерфейсы динамических скелетонов, а также базисные объектные адаптеры. Мосты первого вида могут быть в некоторых случаях более эффективными, но здесь должна применяться предварительная компиляция, и это снижает гибкость, по сравнению с родовыми мостами.
Завершая обсуждение вопроса о мостах, необходимо сделать следующее замечание. Как уже отмечалось выше, основная задача мостов состоит в том, чтобы сделать границы между доменами прозрачными при передаче заявок. Однако на практике иногда необходимо принимать во внимание "административные" границы доменов, отражающие различия в поведении, связанные с организационной политикой или иными причинами. Необходимо, чтобы используемые мосты между доменами в таких случаях учитывали требования подобного рода, и им было известно нечто о трафике. Потребуются, вероятно, ограничения на трафик между доменами и мониторинг над ним, и здесь может оказаться в большой мере нежелателен полностью прозрачный мост. Принимаемая во внимание политика, видимо, должна быть специфической для рассматриваемого приложения, и в таких случаях мосты этого рода могут быть составными частями приложений.
3.6. Интероперабельные Объектные Ссылки
Выполняя свои главные функции по трансляции заявок одного брокера в заявки для другого, мосты, по необходимости, должны иметь дело с объектными ссылками.
Объектные ссылки рассматриваются как имена объектов и используются для обозначения конкретных объектов. Объектная ссылка всегда идентифицирует один и тот же объект, когда эта ссылка применяется в заявке. Вместе с тем каждый объект может обозначаться несколькими различными ссылками.
Важнейшее требование CORBA заключается в том, чтобы клиенту были доступны такого рода имена объектов для вызова операций объектов-серверов на других брокерах. При этом клиент не должен различать ссылки на объекты на локальном или удаленном брокере.
В конкретных реализациях брокеров могут использоваться различные форматы объектных ссылок. CORBA 2.0 не предписывает какого-либо определенного формата их представления. Однако для разработчиков мостов и для понимания протокола IIOP обмена информацией между брокерами в среде Internet (см. разд. 5) авторы стандарта предложили "информационную модель" объектной ссылки, названную ими Интероперабельной Объектной Ссылкой (Interoperable Object Reference, сокращенно - IOR).
Интероперабельная Объектная Ссылка формируется из объектной ссылки, когда требуется пересечь какого-либо вида границу ссылающегося домена. Брокеры представляют объектную ссылку в подходящей для них форме, в том числе, возможно, и в форме IOR-структуры. Поскольку в независимо разрабатываемых брокерах объектные ссылки могут иметь совершенно различные представления, мосты будут использовать IOR для промежуточных передач и должны обеспечивать требуемые преобразования объектных ссылок при переходе из одного домена в другой.
Содержание IOR определено в стандарте и описано в форме IDL-спецификации. Оно представляет собой совокупность идентификатора типа объекта и последовательности специфических для данного объекта профилей. Каждый профиль описывается уникальной числовой меткой (тэгом), которая учреждается и регистрируется OMG, а также данными, представленными в виде последовательности октетов.
Включаемая в Интероперабельную Объектную Ссылку информация о типе объекта-сервера необходима для таких брокеров, которые обеспечивают контроль целостности типов. Содержащиеся в описаниях профилей сведения о поддерживаемых протоколах позволяют выбирать наиболее эффективные из доступных средств коммуникации. Наконец, сведения о доступных брокерных сервисах дают возможность осуществлять выбор подходящего сервиса для обработки заявки и во многих случаях сокращать или исключать накладные расходы на выполнение процедуры выбора. Подробные данные, содержащиеся в профилях, могут потребоваться мосту между двумя доменами для реализации отображения.
В процессе обработки заявки объекта-клиента на выполнение операции осуществляются, как указывалось выше, некоторые действия и над объектными ссылками. Действительно, когда мост направляет объектную ссылку брокеру, она должна быть преобразована в формат, естественный для этого целевого брокера. Кроме того, если идентифицируемый ссылкой объект принадлежит домену из области действия какого-либо другого брокера, мост должен ассоциировать каждую вновь создаваемую ссылку на объект-"представитель" (proxi) со ссылкой на первоначальный объект. В стандарте CORBA 2.0 предложено несколько возможных схем решения этих задач.
4. Универсальный межброкерный протокол GIOP
Как уже отмечалось, протокол GIOP является одним из необходимых элементов поддержки интероперабельности брокеров в стандарте CORBA 2.0, обеспечивающим независимость взаимодействий брокеров от используемой коммуникационной среды. Рассмотрим основные идеи этого протокола.
4.1. Компоненты GIOP
Интероперабельность брокеров поддерживается Универсальным Межброкерным Протоколом (General Inter-ORB Protocol, сокращенно GIOP). GIOP является универсальным, поскольку он не зависит от конкретной сетевой транспортной среды и может быть отображен в любой транспортный протокол, поддерживающий виртуальные соединения. Одно из таких отображений - отображение GIOP в протокол TCP/IP - определено CORBA 2.0 в качестве Межброкерного Протокола Internet (Internet Inter-ORB Protocol, сокращенно IIOP). Назначение протокола GIOP/IIOP заключается в том, чтобы поддержать сети брокеров в рамках Internet и за ее пределами.
Согласно GIOP, внутренняя архитектура брокеров предполагается неизвестной. Подход, который может быть выбран конкретным брокером для поддержки GIOP/IIOP, не определяется. Все, что требуется для согласованного включения брокера в компьютерную сеть, - это существование связанных с ним компонентов, способных посылать и принимать сообщения IIOP.
Спецификация GIOP включает:
· определение Общего представления данных (Common Data Representation - CDR), являющегося, по существу, коммуникационным синтаксисом, отображающим значения типов данных OMG IDL в формат передачи данных между брокерами и межброкерными мостами (агентами);
· форматы передаваемых между агентами сообщений GIOP, которые введены для поддержки объектных заявок, установления местоположения реализаций объектов и управления транспортными соединениями;
· определение ограничений на допустимый сетевой транспорт GIOP.
Протокол IIOP, который можно считать специализацией GIOP, определяет дополнительно, как агенты открывают соединения TCP/IP и используют их для передачи сообщений GIOP.
Компоненты GIOP имеют следующие характерные черты. GIOP трактует транспортное соединение как асимметричное. Определяются две различных роли использования соединения: роль клиента и роль сервера. Клиент образует соединение и посылает объектные заявки, сервер принимает заявки и посылает ответы. Сервер не может посылать объектных заявок. Соединение может использоваться совместно многочисленными клиентами в одном брокере для посылки независимых заявок различным объектам в определенном брокере или сервере. Допускается асинхронная посылка заявок при их произвольном чередовании в соединении.
CDR определяет отображение полного OMG IDL. В передаваемых сообщениях допускается произвольный порядок байтов (зависящий от архитектуры процессора), устанавливаемый отправителем сообщения. Получатель сообщения должен изменить этот порядок нужным для себя образом. Установлены выравнивания значений базовых типов IDL (char, octet, short, unsigned short, long, unsigned long, float, double, boolean, enum) по границе естественных для них полей. Установлено кодирование конструируемых типов IDL (struct, union, array, sequence, string), не накладывающее дополнительных требований выравнивания по отношению к тем, которые установлены для базовых типов3.
В GIOP используется общий формат кодирования Интероперабельных Объектных Ссылок, необходимый в случаях, когда объектные ссылки пересекают границы доменов. Содержание IOR рассмотрено выше в разд. 3.6.
Согласно CDR, значения типов данных IDL передаются как потоки октетов. Различаются два вида потоков октетов: сообщения и инкапсуляции. Инкапсуляции представляют собой потоки октетов, в которых значения IDL могут компоноваться независимо от конкретного контекста сообщений. Инкапсуляции позволяют компоновать сложные константы и используются для представления определенных в Репозитарии интерфейсов кодов типов (TypeCodes), Интероперабельных Объектных Ссылок, специфических контекстов для вызова конкретных услуг и др.
4.2. Сообщения GIOP
GIOP обходится семью типами сообщений, поддерживающими все необходимые функции CORBA, включая сообщения об исключительных ситуациях, передачу контекста операций, вызов операций по объектным ссылкам и т.п. Три типа сообщений предназначены для клиентов (Request, CancelRequest, LocateRequest), и три типа сообщений предназначены для серверов (Reply, LocateReply, CloseConnection), а сообщения типа MessageError могут использоваться как клиентами, так и серверами.
Сообщение Request (Заявка) включает заголовок и тело. Основные компоненты заголовка перечислены ниже.
· Идентификатор заявки, служащий для соотнесения ответных сообщений (Reply) c заявками. Клиент должен генерировать значения идентификаторов заявок так, чтобы избежать неоднозначности.
· Признак ожидания ответа, имеющий истинное значение для заявок, требующих ответа.
· Объектный ключ, идентифицирующий целевой объект вызова. Это значение является осмысленным в сервере и не интерпретируется клиентом.
· Имя операции, подлежащей вызову.
В теле заявки перечисляются параметры операции в порядке, соответствующем их заданию в определении операции на языке IDL.
В заголовке сообщения Reply (Ответ) указывается идентификатор соответствующей заявки и статус ответа (имеется ли исключительное состояние и кем оно выработано - пользователем или системой, либо следует ли переадресовать заявку - статус LOCATION_FORWARD). В теле ответа, если в заголовке указано NO_EXCEPTION, содержится возвращаемое значение и значения выходных параметров в порядке, соответствующем их заданию в спецификации операции на IDL. Если было выработано исключительное состояние, его код содержится в теле ответного сообщения.
Случай переадресации заявки требует более подробного рассмотрения. GIOP поддерживает миграцию объектов и динамическое определение фактического их местоположения. Используемый транспортный адрес не обязательно соответствует какому-либо компоненту брокера, объектному адаптеру, объектному серверу, межброкерному мосту и др. Этот адрес означает существование некоторого агента, с которым может быть открыто соединение и которому можно направлять заявки.
Агенты, соответствующие серверной стороне соединения, могут играть одну из следующих ролей по отношению к конкретной объектной ссылке.
· Агент может принимать объектные заявки для конкретных объектов и возвращать ответы. Агент при этом либо обладает фактической реализацией объекта, либо является межброкерным мостом, трансформирующим заявки и пересылающим их другому брокеру.
· Агент не может принимать объектные заявки для каких-либо объектов, он служит для определения местоположения объекта. В этом случае любое сообщение, направляемое агенту, приводит к выработке исключительных состояний или к появлению в ответном сообщении статуса переадресации заявки LOCATION_FORWARD, указывающего новый адрес, по которому следует направить заявку. Такие агенты могут также отвечать на сообщения LocateRequest сообщениями LocateReply.
· Агент может непосредственно отвечать на некоторые заявки (к определенным объектам) и обеспечивать переадресацию для других объектов.
· Агент может непосредственно реагировать на запросы определенного объекта в определенные моменты времени и осуществлять переадресацию в другое время (возможно, даже при использовании одного и того же соединения).
Сообщение CancelRequest (Отменить Заявку) служит для извещения сервера о том, что клиент не ожидает более ответа на сообщения Request или LocateRequest.
Сообщение LocateRequest (Определить местоположение заявки) может быть послано клиенту для определения ситуации: является ли объектная ссылка верной, способен ли текущий сервер непосредственно принимать заявки по указанной объектной ссылке, или по какому адресу следует переадресовать заявку.
Сообщение сервера LocateReply (Ответ о местоположении заявки) определяет фактическую ситуацию для клиента.
Сообщение сервера CloseConnection (Закрыть Соединение) информирует клиентов, что сервер намерен закрыть соединение и что он прекращает обслуживание и дальнейший прием заявок в этом соединении.
Сообщение MessageError (Ошибка в сообщении) отправляется в ответ на любое сообщение GIOP, содержащее неправильные компоненты заголовка.
5. Межброкерный протокол Internet
Агенты, способные принимать объектные заявки или обеспечивающие их переадресацию, публикуют свои TCP/IP-адреса в составе Интероперабельных Объектных Ссылок (IOR). TCP/IP-адрес состоит, как обычно, из IP-адреса машины и номера порта в TCP. Клиент, нуждающийся в услугах объекта-сервера, должен инициировать TCP/IP-соединение с адресом, указанным в IOR. Сервер может принять или отклонить соединение. Брокеры могут придерживаться любой политики установления соединений. После установления соединения, клиент и сервер обмениваются сообщениями GIOP в установленном GIOP порядке. После посылки (приема) сообщения CloseConnection клиент или сервер должны закрыть соединение TCP/IP.
Профили в IOR, идентифицирующие отдельные объекты, доступные посредством межброкерного протокола Internet, включают IP-адрес машины, адрес порта TCP/IP, объектный ключ, сообщенный агентом, содержащим объект. Агент, генерирующий значение объектного ключа, должен быть способен однозначно сопоставить этому значению требуемый объект.
6. Межброкерные протоколы, учитывающие специфику среды
Завершая рассмотрение межброкерных протоколов CORBA 2.0, нужно заметить, что стандарт допускает применение помимо Универсального Межброкерного Протокола (GIOP) также и других протоколов, учитывающих особенности той среды, в которой они используются (Environment-Specific Inter-ORB Protocol, сокращенно - ESIOP). Такие протоколы естественно использовать для уже существующей сетевой или распределенной среды, и они могут быть для нее оптимизированы. ESIOP-протоколы должны вместе с тем удовлетворять архитектурным соглашениям, положенным в основу интероперабельности брокеров, для того чтобы не осложнять создание межброкерных мостов.
В качестве практически важного примера протоколов такого рода в стандарт включены спецификации ESIOP-протокола для среды OSF DCE (Open Software Foundation"s Distributed Computing Environment). Однако в данной работе они не обсуждаются.
7. Интеграция CORBA и WWW-технологий на основе протоколов CORBA 2.0
Всемирная паутина (WWW) составляет новую парадигму распределенного информационного обслуживания в Internet. Популярные программы просмотра, такие как, например, Mosaic или Netscape, используются для доступа к коллекциям текстовых документов с гиперссылками, представленных на языке гипертекстовой разметки (HTML). HTML-документы поддерживаются WWW-серверами, использующими Протокол Передачи Гипертекста (HTTP), который был разработан для эффективной поддержки множества независимых запросов к документам.
Быстрое распространение WWW происходило в тот период, когда распределенные объектные системы, в особенности архитектура CORBA, проходили стадию стабилизации и созревания. Принятие стандарта CORBA 2.0 позволяет обеспечить поддержку глобального объектного пространства в масштабе Internet.
Существенное различие назначений WWW и CORBA заключается в том, что WWW облегчает жизнь поставщиков и потребителей информации, а CORBA облегчает задачу разработчиков систем и фирм-поставщиков инструментальных средств. Поэтому роли WWW и CORBA являются взаимно дополняющими, и в этой связи требуются специальные технологии, обеспечивающие их сопряжение. Такое сопряжение сулит очевидные преимущества. Разработчики программных продуктов, использующие CORBA, получают доступ к быстро растущему рынку на основе WWW, а мир WWW получает доступ к услугам, обеспечиваемым на основе возможностей CORBA, значительно более мощным, чем реализуемая WWW простая модель обмена HTML-страницами. Интеграция двух миров приведет к наилучшему использованию этих двух стандартов.
Известны два основных подхода к интеграции CORBA и WWW [7]. Первый из них основан на построении шлюзов между мирами WWW и CORBA, служащих для трансформации HTTP в IIOP. Другой подход заключается во встраивании функций CORBA в состав клиентов WWW (программ просмотра) и серверов. Реализация второго подхода возможна либо на основе новых WWW-клиентов и серверов со встроенным IIOP, либо при помощи подгрузки (downloading) из сети модуля поддержки IIOP в клиенте или сервере.
На рис. 3 для примера показана общая схема реализации последнего варианта. Этот подход сохраняет возможность использования HTTP для общения с клиентами и серверами WWW, отводя IIOP роль основного транспортного протокола и протокола вызова услуг. Основным преимуществом этого подхода является сохранение существующих серверов и программ просмотра WWW без каких-либо изменений.
Интеграция функций CORBA и средств WWW.
В новом поколении WWW клиентов и серверов, поддерживающих Java, модуль поддержки IIOP реализуется на Java. Достоинства этого подхода заключаются в обеспечении динамической "раскрутки" функций по отношению к CORBA. Так, для любого ресурса, доступного посредством CORBA, может быть разработан пользовательский интерфейс как апплет Java. Этот апплет использует модуль IIOP для взаимодействия с сервером CORBA. При первом доступе пользователя к какой-либо услуге программа просмотра автоматически загружает и инсталлирует апплет пользовательского интерфейса. После этого пользователь имеет доступ к этой услуге посредством собственного апплета.
Таким образом, услуги объектов-серверов оказываются доступными широчайшей аудитории, независимо от применяемых пользователями платформ и при сохранении для разработчика возможности усовершенствования реализации услуг и их интерфейсов.
8. Заключение
С появлением архитектуры CORBA 2.0 отпали последние препятствия к широкому распространению CORBA в Internet/Intranet. CORBA 2.0 воплощена рядом фирм (например Digital, IBM, IONA Technologies, SunSoft) в реализациях их брокеров для разнообразных платформ. Эти обстоятельства существенным образом способствуют повышению заинтересованности разработчиков информационных ресурсов в предоставлении их стремительно расширяющемуся рынку ресурсов в Internet посредством CORBA.
Важнейшим результатом появления CORBA 2.0 является незамедлительно начавшаяся интеграция технологий CORBA и WWW. Фирмы, поддерживающие на рынке технологию CORBA, могут извлечь выгоду, используя любой из подходов к такой интеграции, рассмотренных в статье. Так, производители брокеров могут поставлять соответствующие мосты и шлюзы, наряду с модулями IIOP на языке Java.
Ответом OMG на этот быстрый процесс является происходящая сейчас стандартизация отображения IDL в язык Java. Введение такого стандарта позволит различным разработчикам гарантировать интероперабельность клиентов, написанных на Java, с другими объектами CORBA. Можно ожидать также дальнейшего усовершенствования протокола IIOP для более эффективной поддержки мультимедиа-данных.
Литература
- Брюхов Д.О., Задорожный В.И., Калиниченко Л.А., Курошев М.Ю., Шумилов С.С. Интероперабельные информационные системы: архитектуры и технологии. СУБД, # 4, 1995 г.
- Kalinichenko L.A. SYNTHESIS: a language for specification, design and programming of the heterogeneous interoperable information resource environments. IPI RAS, September 1995, p. 105.
- Kalinichenko L.A. A Complementary Architecture Integrating Industrial and Semantic Interoperation Environments. Proceedings of the International Conference on Object-Oriented Programming and Technology EastEurOOPe"93, Bratislava, November 1993.
- Kalinichenko L.A. Emerging semantic-based interoperable information system technology. Computers as our better partners. Proceedings of the International IISF/ACM Symposium, Tokyo, World Scientific, 1994.
- Калиниченко Л.А. Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния. СУБД, # 1, 1996 г.
- Калиниченко Л.А., Когаловский М.Р. Стандарты OMG: Язык определения интерфейсов IDL в архитектуре CORBA. СУБД, # 2, 1996 г.
- Madsen M. ANSAweb: a service architecture to enhance the World Wide Web. First Class, January/February, 1996.
- Object Management Group, Object Management Architecture Guide, OMG Document Number 92.11.1, September 1, 1992.
- Object Management Group, The Common Object Request Broker: Architecture and Specification, OMG Document Number 91.12.1. Revision 1.1. December 1991.
- Object Management Group, The Common Object Request Broker: Architecture and Specification, OMG Document Number 93.xx.yy, Revision 1.2. Draft 29 December 1993.
- Object Management Group, The Common Object Request Broker: Architecture and Specification. Revision 2.0. July 1995.
- Woods S., Parodi J. Overview of the Component Object Model. Digital Equipment Corp., August 1994.
Калиниченко Леонид Андреевич
Институт проблем информатики РАН
E-mail: leonidk@ipian23.ipian.msk.su Когаловский Михаил Рувимович
Институт проблем рынка РАН
E-mail: kogalov@cemi.msk.su
1) Эта статья подготовлена в рамках проекта Российского Фонда Фундаментальных Исследований, грант 94-07-20453.
2) См. замечания о семантической интероперабельности в разд. 2.
3) Заметим, что используемая в этой части стандарта структура типов языка IDL не согласована со спецификациями синтаксиса языка OMG IDL, представленными в документации [11]. См. также [6].