Файл: Технология построения распределенных информационных систем(Основные понятия технологии CORBA).pdf

’ Сервис внешнего представления является стандартным сервисом CORBA. Его реализация в машине удалённых запросов базируется на стандартизированных IDL декларациях его интерфейсов и принципах его функционирования, представленных на официальном сайте разработчиков www.omg.org. Ниже приведено краткое описа­ние интерфейсов сервиса внешнего представления.

По стандартной спецификации сервис внешнего представления предоставляет внешний интерфейс, позволяющий переводить объекты типа Streamable во внеш­нее представление и обратно. Для успешного выполнения этих операций, для об­рабатываемых объектов должны быть корректно реализованы методы интерфейса Streamable^[12].

Приложение, которое желает перевести объекты во внешнее представление (экс- тернализовать), должно выполнить следующие действия при инициализации:

Получить ссылку на объект типа Stream (объект данного типа может быть со­здан приложением методом createQ объекта StreamFactory, функциональность которого должна поддерживаться сервисом внешнего представления).

Вызвать метод externalize() объекта Stream, передав ему в качестве параметра ссылку на экстернализуемый объект типа Streamable. '

Приложение имеет возможность экстернализовать несколько объектов в один поток, для этого у объекта Stream существуют методы begin_context(), которые необходимо вызывать перед экстернализацией первого объекта и end.context(), вызываемый после экстернализации последнего объекта^[13].

Далее сам объект Stream отвечает за перевод переданных ему по ссылке объектов во внешнее представление. В частности, его функциональность должена включать в себя реализацию интерфейса StreamIO, предоставляющего базовые методы записи и чтения из потока. Именно ссылка на объект типа StreamIO передаётся в качестве ар­гумента в метод externalize_tojstream() каждого из экстернализуемых объектов типа Streamable, и они пользуются методами объекта SytreamIO для записи необходимой информации в поток.

Приложение, которое желает перевести объекты из внешнего представления (ин- тернализовать), должно выполнить следующие действия при инициализации:

Получить ссылку на объект типа Stream - поток, в котором сохранены объек­ты.

Вызвать метод internalize() объекта Stream, передав ему в качестве параметра ссылку на объект типа FactoryFinder - объект с интерфейсом CosLifeCycle::Fac- toryFinder (IDL декларация интерфейса включена в описание стандартного CORBA сервиса Object Lifecycle Service), содержит метод find-factories(), ис­пользуемый для поиска фабрики Streamable объекта по её описанию.

---

Фабрики Streamable объектов должны поддерживать интерфейс StreamableFactoгу и используются для создания неинициализированных объектов при их чтении из потока. Реализация объекта типа FactoryFinder должна включать в себя механизм поиска нужной фабрики Streamable объектов по некоторому уникальному идентифи­катору key. Значение идентификатора Streamable объекта запаковывается в поток при его экстернализации, извлекается из потока перед его интернализацией, по из­влечённому идентификатору ищется нужная фабрика, с помощью которой и созда­ётся неинициализированный Streamable объект (метод create.uninitialized() объекта типа StreamableFactory). В качестве идентификатора используется значение атри­бута key самого Streamable объекта, получаемое при его экстернализации^[14].

В текущей реализации машины удалённых запросов интерфейс сервиса внешнего представления расширен модулями CosStorage и ExternalizationStorage с интерфей­сами:

• CosStorage::Storage - представляет собой низкоуровневое хранилище байт, с базовыми операциями по работе с ним.
• CosStorage::StorageInput - итератор для доступа к данным, хранимым в объ­екте Storage.
• CosStorage: :StorageFactory - фабрика, используемая для создания объектов ти­па Storage.
• ExternalizationStorage::StorageStream - CosExternalization::Stream с хранением данных в виде CosStorage::Storage.
• ExternalizationStorage::StorageStreamFactory - фабрика, используемая для со­здания объектов типа StorageStream.

Транспортный сервис может быть исполь­зован для передачи объектов адресату или множеству адресатов через различные среды: через прямое соединение, через почтовую систему или даже посредством пе­реноса файлов между не связанными между собой системами.

Транспортный сервис предоставляет внешний интерфейс согласно стандарту CORBA и использует другие сервисы CORBA для выполнения внутренних функций: сервис внешнего представления (Externalization Service) используется для получения внешнего представления передаваемого объекта. Поэтому при запуске транспортно­го сервиса одним из его обязательных входных параметров является IOR объекта ти­па StreamFactory,созданного сервисом внешнего представления.

При инициализации транспортный сервис создаёт объект типа TransportService и вспомогательные объекты, в соответствии со спецификацией сервиса и реализую­щие его функциональность^[15].

Транспортный сервис представляет собой приложение, которое получает объект, передает его через различные транспортные среды адресату или адресатам и отдает объект приложению, которому объект предназначался. Сервис действует совместно с приложением-отправителем объекта и совместно с приложением-получателем объ­екта.

---

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

Сервис удаленных запросов предоставляет внешний интерфейс согласно стан­дарту CORBA и использует другие сервисы CORBA для выполнения внутрен­них функций: транспортный сервис (Transport Service) используется для транс­портировки внешнего представления запроса, а сервис внешнего представления (Externalization Service) используется для получения внешнего представления за­проса и результата* с целью дальнейшей передачи через транспортный сервис.

Сервис удалённых запросов при запуске получает в качестве одного из входных параметров IOR объекта типа TransportService, созданного транспортным серви­сом. Далее, используя полученную ссылку,' создаёт и регистрирует в транспортном сервисе объект типа Consumer, тем самым приобретая возможность получать объ­екты через транспортный сервис, и объекты типа StreamableFactory, необходимые для выполнения операций перевода из внешнего во внутреннее представление пе­редаваемых и получаемых объектов. После чего создаёт объект типа RemoteQueryMachine и вспомогательные объекты, в соответствии со спецификаци­ей сервиса и реализующие его функциональность^[16].

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

Приложение, которое взаимодействует с сервисом удаленных запросов, должно выполнить следующие действия при инициализации:

Получить ссылку на объект типа RemoteQueryMachine (ссылка может быть получена через IOR объекта, который сохраняется в файле при запуске серви­са удалённых запросов либо через Сервис Именования Объектов, если сервис удалённых запросов был запущен с опцией регистрации в Сервисе Именова­ния).

Зарегистрировать объекты типа QueryListener, предназначенные для уда­ленного исполнения запросов, посредством метода RemoteQueryMachine::register_listener().

Зарегистрировать объекты типа StreamableFactory, необходимые для выпол­нения операций перевода из внешнего во внутреннее представление, в объекте типа TransportService, ссылка на который может быть получена при помощи метода RemoteQueryMachine::get_transport().

---

Эти действия требуются для приложения, которое будет получать запросы от сер­виса, выполнять эти запросы, а также получать результаты запросов^[17].

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

2.2. Общая схема системы

Технология CORBA описывается в спецификациях, но статус, степень детализации и принципы написания этих документов сильно различаются.

CORBA определяется с помощью формализованной спецификации, написанной на языке IDL. Появлению очередной версии предшествуют четко организованный процесс адаптации нового стандарта, который обычно завершается быстрее, чем аналогичные процедуры в ISO. В результате CORBA может похвастаться значительным числом реализаций. Первоначальный вариант спецификации появился в 1991 году, и уже в 1992-м был выпущен коммерческий продукт — брокер объектных запросов DEC ObjectBroker^[18].

Спецификация CORBA — это строго организованное описание, не обремененное деталями реализации, которые оставляются на долю разработчиков конкретных продуктов. Обилие реализаций от разных поставщиков с одной стороны стимулирует конкуренцию и, как следствие, совершенствование технологии, но с другой — порождает проблемы несовместимости разнородных продуктов. Так, спецификация CORBA включает определение Basic Object Adapter, который обеспечивает доступ к сервисам брокера объектных запросов со стороны сервера объекта. Эта часть спецификации оказалась слишком общей, так что разработчики получили слишком большую степень свободы в реализации собственных объектных адаптеров. В итоге, часто оказывалось невозможно перенести серверные компоненты архитектуры с одного ORB на другой. В новой спецификации переносимого объектного адаптера (Portable Object Adapter, POA) делается исправить этот недостаток.

Различные брокеры запросов взаимодействуют между собой по протоколу General Inter ORB Protocol (GIOP). В связи с активным переносом в среду Web критически важных корпоративных приложений наибольший интерес представляет реализация протокола GIOP на базе TCP/IP — протокол Internet Inter ORB Protocol (IIOP).

---

Ниже представлена схема взаимодействия сервисов машины удалённых запросов внутри одного сервера системы и между не­сколькими серверами, разнесёнными в сети (Рис.1).

Ядро CORBA, включающее Брокер Объектных Запросов и Объектные Адапте­ры, обеспечивает механизмы, позволяющие объектам взаимодействовать меж­ду собой, не заботясь о положении в распределенной среде и способе их реали­зации, обеспечивает механизмы управления циклом жизни CORBA-объектов и их реализаций^[19].

Рис. 1. Схема взаимодействия сервисов машины удалённых запросов

Реализация машины удалённых запросов на основе технологии -CORBA в виде набора взаимодействующих сервисов CORBA позволила достигнуть среди прочего:

• Платформенной и языковой независимости. Реализация описанных выше сер­висов на языке C++ легко переносима между операционными системами семей­ства Windows и Unix. Использование для описания интерфейсов сервисов языка IDL позволяет легко отображать их на большинство современных объектно - ориентированных языков программирования, переносимость клиентов и реализаций объектов между ORB различных про­изводителей.
• Возможности создания серверных объектов по запросам клиента с обеспечени­ем оптимального управления ресурсами серверов (оперативная память, сете­вые соединения), возможность построения динамических связей между объек­тами в системе и динамического сопоставления с ними произвольных свойств^[20].

Заключение

Итак, CORBA является ведущей технологией построения распределенных объектных сред. Она имеет базовые принципы и множество различий в деталях реализации. На основе технологии CORBA создан солидный багаж проектов, что наглядно демонстрирует многочисленные «истории успеха» на Web-узле консорциума OMG и домашней страничке CORBA.

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

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

---