Файл: Учебнопрактическое пособие Владимир 2021.pdf

253 имущество переносимости программного комплекса не только без его доработки, но даже и без его перекомпиляции.
Очень важным моментом является возможность использования других языков (например, C++) для некоторых модулей системы.
Например, это может понадобиться для разработки модулей работы с цифровым потоковым видео или для реализации поддержки оборудо- вания, драйвер которого поставляется только в виде COM- интерфейса.
В случае использования языка Java для разработки ПК разра- ботчику доступна стандартная технология взаимодействия с различ- ными серверами баз данных JDBC (Java DataBase Connectivity). Ос- новными частями технологии JDBC являются JDBC API (набор клас- сов и методов, к которым обращается прикладной программист) и
JDBC-драйверы, которые транслируют эти вызовы в команды API конкретной СУБД. Используя данную технологию можно получить систему, независимую от используемого сервера БД и, соответствен- но, иметь возможность выбора сервера непосредственно для каждого заказчика в соответствии с особенностями объекта.
Для хранения настроек объектов, конфигурации рабочих мест и прочей информации в БД можно применять стандартную реляцион- ную модель, при которой данные объектов каждого типа сохраняются в отдельной таблице, содержащей набор колонок, соответствующих списку свойств этих объектов. Такой вариант хранения обеспечивает быстрые сохранение, поиск и выборку данных из БД, и удобен в ин- формационных системах.
Системы безопасности же имеют свою специфику. С одной сто- роны, здесь нет острой необходимости в быстром поиске среди мил- лионов записей (количество обслуживаемых аппаратных объектов обычно все-таки существенно меньше). С другой стороны, при рас- ширении системы может возникнуть необходимость в добавлении новых типов объектов, что часто приводит к перестройке структуры
БД, что, в свою очередь, затрудняет процесс установки и поддержки системы. В качестве возможной альтернативы можно рассмотреть

254 хранение настроек объектов системы в полях типа BLOB формате
XML.
Используя для построения системы технологию CORBA для решения стандартных системных задач можно воспользоваться стан- дартными сервисами CORBA. Сервисы CORBA решают задачи поис- ка, установления отношений между объектами, сохранения их состо- яний, управления транзакциями и безопасностью, синхронного и асинхронного уведомления о тех или иных событиях и многое другое.
Одними из самых распространенных сервисов являются Сервис Со- бытий (Event Service) или идущий ему на смену и являющийся его развитием и обобщением Сервис Уведомлений (Notification Service).
Эти сервисы позволяют универсальным образом уведомлять объекты распределенной системы о происходящих событиях. Обеспечение безопасности.
При построении системы безопасности на базе стандартных технологий необходимо особое внимание уделить безопасности само- го комплекса. Для решения этой задачи создан специальный Сервис
Безопасности (Security Service). Это очень сложный сервис, специфи- кация его состоит почти из 300 страниц. Самое поразительное, что при всей его сложности и многочисленности решаемых им проблем, он практически не "виден" для прикладного программиста - все дей- ствия выполняются автоматически, в том числе и распространение контекста безопасности.
Интероперабельность брокеров поддерживается Универ- сальным Межброкерным Протоколом (General Inter-ORB Protocol, сокращенно GIOP). GIOP является универсальным, поскольку он не зависит от конкретной сетевой транспортной среды и может быть отображен в любой транспортный протокол, поддерживающий вир- туальные соединения. Одно из таких отображений - отображение
GIOP в протокол TCP/IP - определено CORBA 2.0 в качестве Меж- брокерного Протокола Internet (Internet Inter-ORB Protocol, сокра- щенно IIOP). Назначение протокола GIOP/IIOP заключается в том, чтобы поддержать сети брокеров в рамках Internet и за ее пределами.

255
Согласно GIOP, внутренняя архитектура брокеров предпола- гается неизвестной. Подход, который может быть выбран конкретным брокером для поддержки GIOP/IIOP, не определяется. Все, что требу- ется для согласованного включения брокера в компьютерную сеть, - это существование связанных с ним компонентов, способных посы- лать и принимать сообщения IIOP.
Спецификация GIOP включает:
1) определение Общего представления данных (Common
Data Representation - CDR), являющегося, по существу, комму- никационным синтаксисом, отображающим значения типов данных OMG IDL в формат передачи данных между броке- рами и межброкерными мостами (агентами);
2) форматы передаваемых между агентами сообщений GIOP, которые введены для поддержки объектных заявок, уста- новления местоположения реализаций объектов и управления транспортными соединениями;
3) определение ограничений на допустимый сетевой транспорт
GIOP.
Протокол IIOP, который можно считать специализацией GIOP, определяет дополнительно, как агенты открывают соединения TCP/IP и используют их для передачи сообщений GIOP. GIOP трактует транспортное соединение как асимметричное. Определяются две различных роли использования соединения: роль клиента и роль сер- вера. Клиент образует соединение и посылает объектные заявки, сервер принимает заявки и посылает ответы. Сервер не может посы- лать объектных заявок. Соединение может использоваться совместно многочисленными клиентами в одном брокере для посылки незави- симых заявок различным объектам в определенном брокере или сервере. Допускается асинхронная посылка заявок при их произ- вольном чередовании в соединении.
В передаваемых сообщениях допускается произвольный поря- док байтов (зависящий от архитектуры процессора), устанавливае- мый отправителем сообщения. Получатель сообщения должен изме- нить этот порядок нужным для себя образом. Установлены выравни-

256 вания значений базовых типов IDL (char, octet, short, unsigned short,
long, unsigned long, float, double, boolean, enum) по границе естествен- ных для них полей. Установлено кодирование конструируемых типов
IDL (struct, union, array, sequence, string), ненакладывающее до- полнительных требований выравнивания по отношению к тем, ко- торые установлены для базовых типов.
Обзор архитектуры CORBA
Обобщенная архитектура построения Брокеров Объектных за- просов (Object Request Broker - ORB) разработана для поддержки ин- теграции самых разнообразных объектных систем. Спецификация
CORBA устанавливает принципы создания Брокеров Объектных за- просов, которые и допускают такую интеграцию. Запрос посылается от клиента к серверу. Клиент это приложение, или нечто другое, вы- полняющее операцию над объектом, а реализация объекта - это код и данные, которые на самом деле выполняют эту операцию. ORB спо- собен выполнить все действия, необходимые для нахождения реали- зация указанного объекта, подготовке этой реализации к обработке запроса и передаче данных, относящихся к запросу. Интерфейс, предоставляемый клиенту, абсолютно не зависит от местоположения реализации объекта, языка программирования, на котором он написан или каких-либо других аспектов, не влияющих на определение ин- терфейса для данного объекта.
При определении конкретной архитектуры Брокер Объектных запросов вовсе необязательно должен быть реализован как один ком- понент, но каждая реализация должна реализовывать три категории операций:

Операции, которые одинаковы для всех реализаций ORB- а.

Операции, специфичные для конкретного объектного типа.

Операции, специфичные для отдельных видов реализаций объектов.

257
Различные реализации ORB-а могут поддерживать различные виды реализаций, а различные адаптеры объектов могут обеспечивать различные наборы сервисов для клиента и реализаций. Ядро Брокера
Объектных запросов обеспечивает основные механизмы для манипу- ляций объектами и выполнения запросов. Спецификация CORBA предназначается для поддержки различных механизмов реализации объектов, поэтому структура ядра не определяется. Вместо этого за- дается набор интерфейсных функций, которые должны присутство- вать в каждой реализации ORB-а и тем самым маскируют отличия между различными реализациями Брокеров Объектных запросов.
Система объектов обеспечивает клиента набором сервисов.
Клиент способен запросить некоторый сервис. Объект - это нечто, что обеспечивает один или более сервисов, которые клиент может запро- сить.
Доступно широкое множество способов реализации конкретных
ORB-ов. Далее будут приведены примеры таких реализаций. Следует иметь ввиду, что конкретный ORB может быть реализован сразу не- сколькими способами.

ORB, включаемый в клиентское и серверное приложение.
Если имеется подходящий механизм коммуникаций, то возможна ре- ализация ORB-а в виде набора подпрограмм как со стороны клиента, так и со стороны реализации объекта. Вызовы методов могут транс- лироваться в работу со средствами взаимодействия процессов (Inter
Process Communication - IPC).

ORB, выполненный в виде сервера. С целью обеспечения централизованного сбора и управления всевозможной информацией,
ORB может быть реализован в виде отдельного приложения. Взаимо- действующие приложения устанавливают контакт с ORB-ом посред- ством нормальных механизмов IPC.

ORB как часть системы. Для повышения надежности, за- щиты данных и достижения лучшей производительности ORB может быть реализован как часть операционной системы. При этом ссылки на объект могут быть сделаны постоянными, таким образом, умень- шая время, необходимое для обработки каждого запроса. При реали-

258 зации ORB-а как части операционной системы возможны всевозмож- ные виды оптимизации, такие как избежание кодирования и декоди- рования данных, если клиент и сервер находятся на одной и той же машине.

ORB, основанный на библиотеках. Если код объекта зани- мает небольшой объем и не требует никаких дополнительных средств, то он может быть выполнен в виде библиотеки. При этом все заглушки на самом деле будут являться настоящими методами. При этом предполагается, что имея доступ к данным реализации, клиент не разрушит эти данные.
Реализация объекта обеспечивает само понятие объекта, обычно задавая данные для конкретного экземпляра объекта и код для вы- полнения методов объекта. Часто реализация будет использовать дру- гие объекты или вспомогательные программы для обеспечения функ- ционирования объектов. В некоторых случаях выполнение операции над объектом влечет некие побочные действия не над объектами.
Конкретный ORB может поддерживать широкий набор объектных ре- ализаций: отдельные серверы, библиотеки, объектно- ориентированные системы управления базами данных и др. С помо- щью использования дополнительных Адаптеров объектов теоретиче- ски можно поддерживать любую реализацию объекта.
Адаптер объектов - это первичный путь для обеспечения серви- са конкретной реализацией объекта. Предполагается, что имеется не- сколько адаптеров объектов, каждый из которых обеспечивает доступ к объектам определенного вида. Сервисы, которые обеспечиваются
ORB-ом посредством адаптеров объектов часто включают: генерацию и интерпретацию ссылок на объекты, вызов методов, активацию и де- активацию реализаций объектов, а также регистрацию конкретных реализаций и отображение объектных ссылок и реализаций. Инфор- мация, которая находится в каждом из хранилищ может быть произ- вольно изменена в любой момент времени с помощью методов, обес- печиваемых реализацией ORB-а. Однако, неосторожное изменение, сделанное во время работы может привести нарушить целостность

259 информации, находящейся в каждом из хранилищ и сделать невоз- можным дальнейшее функционирование ORB-а.
Для конкретного отображения и, возможно, используемого адаптера объектов определяется свой порядок вызова методов каждо- го объекта. Этот интерфейс в общем случае является интерфейсов об- ратных вызовов. При необходимости ORB вызывает требуемые про- цедуры.
Также доступен интерфейс для динамической обработки посту- пающих запросов. В этом случае реализация объекта взаимодействует с заданным интерфейсом по аналогии с интерфейсом динамических вызовов.
Подпрограммы динамической отработки запросов могут вызы- ваться как с помощью интерфейса динамических вызовов, так и с по- мощью процедур-заглушек, каждый метод дает одинаковый резуль- тат.
Клиент запрашивает сервисы инициированием запросов. Запрос
- это событие, то есть действие, происходящее в конкретный момент.
С запросом связана информация, состоящая из операции, объекта, у которого запрашивается сервис, нуля или более действительных па- раметров вызова и необязательный контекст запроса. Форма запроса - это описание или шаблон, который может быть выполнен произволь- ное количество раз. Форма запроса определяется отображением для конкретного языка программирования. Альтернативной формой за- проса является использования Интерфейса Динамических вызовов, который позволяет создать запрос, добавить аргументы и выполнить запрос. Под значением понимается допустимый параметр запроса.
Значение которое определяет объект, называется ссылкой на объект, связанной с конкретным экземпляром объекта. Выполнение запроса вызывает выполнение соответствующего сервиса. После завершения запроса клиенту возвращается результат запроса (если он есть). В случае ненормального завершения запроса клиенту возвращается ис- ключение. Исключение может содержать специфические параметры, специфические для данного типа исключений.

260
Параметр характеризуется режимом передачи и своим типом.
Режим определяет, должно ли передаваться значение параметра от клиента к серверу (in), от сервера к клиенту (out) или в обоих направ- лениях (inout).
Если есть возвращаемое значение, то оно рассматривается как параметр типа out.
Исключение свидетельствует о том, что операция не была успешно выполнена. Исключение может содержать дополнительную информацию, специфичную для конкретного исключения.
Контекст запроса обеспечивает передачу дополнительной, спе- цифичной для операции информации, которая может повлиять на вы- полнение запроса.
Параметры запросов определяются их позицией. Параметры мо- гут быть входные, выходные и входные и выходные одновременно.
Как результат запрос может возвратить одно значение, как, впрочем, и любые выходные параметры. В случае возникновения исключения значение всех выходных параметров не определено.
Интерфейс - это описание множества возможных операций, ко- торые клиент может выполнять над объектом. Объект удовлетворяет интерфейсу, если он может быть указан как конечным объектом для каждого потенциального запроса, описанного в интерфейсе. Типу ин- терфейса удовлетворяют только объектные типы.
Интерфейс ORB-а является функциям, вызываемым непосред- ственно у Брокера Объектных запросов и идентичным для всех ORB- ов, не зависящим от конкретного объекта либо адаптера объектов. Но так как большинство действий с объектами выполняется посредством адаптеров объектов, существует всего несколько общих операций, ко- торые могут быть выполнены над каждым объектом. Эти операции могут вызываться как клиентом, так и реализацией объекта.
Этот интерфейс допускает динамическое создание запросов к объекту вместо вызова процедуры, декорирующей такое создание.
При динамическом создании запроса клиент должен указать всю ин- формацию. Необходимую выполнения операции. Например, инфор-

261 мация о типах параметров может быть получена с помощью храни- лища описаний объектов.
Для объектно-неориентированных языков программирования задается программный интерфейс для доступа к методам объекта- заглушки, имеющегося у клиента. Эта заглушка осуществляет пере- дачу запроса и обычно оптимизирована для выполнения под управле- нием конкретного ORB-а. Если доступно более одного ORB-а, то у них может быть различное внутреннее представление заглушек. Объ- ектно-ориентированные языки программирования, такие как C++ и
Smalltalk такого интерфейса не требуют.
Обзор протокола GIOP
Спецификация протокола GIOP состоит из следующих элемен- тов:

Определение Общего Представления данных (Common
Data Representation - CDR ). CDR - это способ кодирования типов данных, определенных в IDL в низкоуровневое представление, при- годное для передачи их по имеющимся каналам связи между ORB- ами.

Формат сообщения протокола GIOP. Сообщения протоко- ла GIOP обеспечивают нахождение объекта, отработку запросов, а также простейшее управление каналом коммуникации.

Предположения о транспорте. Спецификация GIOP опи- сывает общие предположения, которые делаются при рассмотрении любого сетевого транспортного слоя, который может быть использо- ван для обмена сообщениями протокола GIOP. Также описываются общие принципы управления соединением.
Спецификация IIOP добавляет к спецификации протокола GIOP следующий пункт:

Транспорт для сообщений протокола IIOP.
Спецификация IIOP описывает, каким образом агенты могут установить соединение по протоколу TCP/IP и использовать его для передачи сообщений протокола GIOP.

262
Протокол IIOP не является самостоятельной спецификацией - это специализированное отображение протокола GIOP поверх транс- портного слоя TCP/IP. Спецификация GIOP (без элементов, специ- фичных для IIOP) может рассматриваться как самостоятельный доку- мент, являющийся базовым для обеспечения в будущем отображения на новые транспортные протоколы.
За исключением редкого случая прямых вызовов методов между классами одного и того же языка программирования необходим ме- ханизм кодирования вызова метода в некоторую последовательность байт (byte stream) у клиента и декодирования этой последовательно- сти у сервера. Для этой цели спецификация определяет Общий Про- токол обмена между Брокерами Объектных запросов (General Inter-
Orb Protocol - GIOP). Кроме того, определен протокол передачи со- общений протокола GIOP поверх транспортного протокола TCP/IP, являющегося основным видом взаимодействия в Internet, ввиду чего этот протокол получил название Протокола обмена между Брокерами
Объектных запросов в Internet (Internet Inter-Orb Protocol - IIOP).
Протокол IIOP должен поддерживаться всеми Брокерами Объектных запросов, независимо от особенностей их реализации, что является главным требованием для обеспечения взаимодействия между произ- вольными ORB-ами двух разных и совершенно независимых произ- водителей.
Протоколы GIOP и IIOP допускают взаимодействие между раз- личными ORB-ами независимо от платформ, на которых они выпол- няются, операционных систем, под управлением которых происходит взаимодействие и прочих аппаратно- и программно-зависимых аспек- тов. При разработке этих протоколов преследовались следующие це- ли:
Протоколы GIOP и IIOP разрабатывались с учетом доступного широко распространенного и гибкого транспортного механизма
(TCP/IP) и задает минимум дополнительных протоколов, необходи- мых для передачи запросов между отдельными ORB-ами.