Файл: Технология построения распределенных информационных систем(Основные понятия технологии CORBA).pdf
Добавлен: 14.03.2024
Просмотров: 25
Скачиваний: 0
’ Сервис внешнего представления является стандартным сервисом 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 для всех определений элементов архитектуры делает модель согласованной, четко организованной и легко расширяемой. Концепция отображения в языки программирования обеспечивает взаимодействие объектов, создаваемых в разных языковых средах. Понятие объектной ссылки обеспечивает строгую идентификацию объекта и упрощает работу по размещению объекта.