Учебнопрактическое пособие Владимир 2021
 Скачать 7.94 Mb.
|
|
5.2. Технология CORBA Технология CORBA, разрабатываемая с 1989 года консорциу- мом OMG (Object Management Group), является результатом работы ведущих специалистов из более чем 800 компаний и организаций. Четкий процесс стандартизации, включая аспекты взаимодействия реализаций CORBA от разных поставщиков (интероперабельность), независимость от языков программирования и операционных сред, фундаментальная поддержка ООП и многие другие уникальные ха- рактеристики, сделали CORBA ведущим стандартом в области ин- фраструктурного middleware. Основой технологии CORBA являются: • IDL (Interface Definition Language) - язык, позволяющий опи- сать все аспекты удаленного взаимодействия; схемы отображения IDL-объявлений на конкретные языки программирования; • ORB (Object Request Broker) - объектная магистраль, позволя- ющая передавать запросы от клиентов к серверам и обратно; • Сервисы (Common Object Services) CORBA; Распределенная система, использующая CORBA, не ориентиро- вана на применение конкретных операционных систем, двоичных 252 стандартов, сетевых протоколов и языков программирования. Факти- чески, это единственная технология, которая обеспечивает возмож- ность использования практически любых языков программирования и функционирование программного обеспечения практически на лю- бых аппаратно-программных платформах Архитектура комплекса При использовании технологии CORBA вся система представ- ляет собой набор работающих в сети приложений, предоставляющих друг другу какие-либо ресурсы или обеспечивающие выполнение ка- ких-либо задач. При этом отдельными независимыми приложениями могут являться компоненты доступа к базе данных, служебные серви- сы системы (типа сервиса хранения настроек объектов или сервиса безопасности), драйверы работы с оборудованием, функциональные модули (работы с планами помещений, генерации отчетов, работы с БД пользователей и др.), а также пользовательские приложения, обеспечивающие отображение состояния объектов системы и воз- можность управления ими. Данная технология обеспечивает четкое разделение модулей си- стемы на клиентские (пользовательские приложения) и серверные (драйверы оборудования). Технология обеспечивает удаленную сты- ковку модулей. Благодаря использованию стандартной технологии стыковки между собой всех модулей системы сторонним разработчикам предо- ставляется возможность расширения системы за счет разработки сво- их собственных модулей, реализующих дополнительные возможно- сти системы или поддержку нового специализированного оборудова- ния. Технология CORBA позволяет вести разработку практически на любом языке программирования (C++, Java, Delphi и др.) и под лю- бую аппаратно-программную платформу (Microsoft Windows – Intel, Linux, Sun Microsystems Solaris – SPARC). Однако использование язы- ка программирования Java позволяет получить дополнительное пре- 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-ами. 263 Помимо прочих требований, протокол GIOP сделан максималь- но простым. Его простота допускает возможность реализации взаи- модействия по этому протоколу практически в любой системе. Протокол GIOP/IIOP должен поддерживаться как отдельными ORB-ами, так и ORB-ами, объединенными в сеть на уровне Internet и, возможно, шире. Реализация поддержки протоколов GIOP/IIOP должна потребо- вать минимальных затрат как в плане инженерного проектирования, так в плане распространения готовых ORB-ов. В то время как IIOP изначально определен поверх протокола TCP/IP, сообщения, которыми происходит обмен в рамках протокола GIOP специально разработаны для реализации поверх любого прото- кола, который базируется на установленном между сервером и клиен- том соединении. Спецификация GIOP делает минимальные предположения об архитектуре агентов, которые поддерживают обмен данными по это- му протоколу. Спецификация GIOP считает ORB некой системой с неизвестной архитектурой. Подход конкретного ORB-а к обеспечению поддержки прото- кола GIOP/IIOP не определен. Например, ORB может принять IIOP в качестве внутреннего протокола, использовать его только для внеш- него обмена, используя для обмена в рамках самого ORB-а какие-то дополнительные средства коммуникации или выбрать нечто среднее между этими двумя крайностями. Все что требуется от ORB-а - это чтобы существовало нечто способное принимать и отправлять сооб- щения по протоколу IIOP. Протокол GIOP предназначается для реализации поверх боль- шого количества транспортных протоколов. При этом делаются сле- дующие предположения об особенности протокола: Транспорт ориентируется на установление соединения с после- дующим обменом информации в рамках соединения. Соединение ис- пользуется для определения правил нумерации запросов. Транспорт протокол должен гарантировать прохождение пере- данных байт в том порядке, в котором они были посланы. 264 Транспорт может рассматриваться как поток байт без дополни- тельных ограничений на размеры, фрагментацию или выравнивание размеров посылок. Транспорт должен обеспечивать сигнализацию об разрыве со- единения. Если один из участников обмена неожиданно прервал свою работу, произошел сбой в операционной системе или сети, то другой должен быть уведомлен об этом. Сервер не инициирует установление соединения, но он выпол- няет некоторые действия по подготовке к принятию запросов от кли- ентов. Клиент знает местоположение (адрес) сервера и устанавливает соединение по указанному адресу. Сервер может принять соединение, уникальное для каждого клиента (при этом продолжив ожидание но- вых запросов), а может и не принять, например вследствие недостатка ресурсов. Если соединение установлено, то по данному каналу может происходить двусторонний обмен информацией, причем каждая сто- роны имеет возможность в произвольный момент времени разорвать соединение. Вовсе не обязательно конкретный транспорт должен прямо реа- лизовывать все перечисленные требования, но должна иметься воз- можность для эмулирования описанной транспортной модели. Соединение двунаправленное в смысле потока данных, но оно не является симметричным в плане обмена сообщениями GIOP. Со- общения Request, LocateRequest и CancelRequest могут посылаться только клиентом. Сообщения Reply, LocateReply и CloseConnection - только сервером. Сообщение ErrorMessage может быть послано обеи- ми сторонами. Через соединение для обмена в соответствии с прото- колом GIOP могут посылаться только сообщения GIOP. Каждое сообщение типа Request должно иметь уникальный но- мер, который идентифицирует запрос в рамках установленного со- единения. Этот номер никоим образом не интерпретируется серве- ром, но он позволяет клиенту установить соответствие между запро- сом и пришедшим ответным сообщением в случае инициации сразу нескольких запросов. Генерация этих уникальных номеров возлагает- ся на клиента. 265 Соединение может быть либо закрыто в рамках протокола, ли- бо разорваться. Закрытие соединения может инициироваться со сто- роны сервера посредством посылки сообщения CloseConnection или клиентом посредством обычного закрытия соединения в произволь- ный момент времени. Если на момент закрытия соединения имеются неотработанные запросы, то сервер должен рассматривать такие за- просы как отмененные. Сервер не может послать сообщение CloseConnection, если он начал обработку запроса, для которого не поступило сообщения CancelRequest, или он (сервер) не послал от- ветного сообщения. При получении сообщения CloseConnection клиент должен рас- сматривать все сообщения, для которых не было получено ответа как необработанные. Такие сообщения клиент может без дополнительных мер предосторожности послать еще раз при установлении нового со- единения. В случае если сервер предоставляет такую возможность, то кли- ент может посылать в рамках одного соединения запросы к разным объектам, оптимизируя таким образом использование ресурсов. С другой стороны, клиент может предпочесть установление нового со- единения для каждого нового объекта, обслуживаемого сервером, хо- тя рекомендуется избегать таких случаев. Язык описания интерфейсов Язык описания интерфейсов (IDL), используемый OMG опреде- ляет типы объектов посредством спецификации их интерфейсов. Ин- терфейс состоит из множества именованных операций и их парамет- ров. Хотя и описание на IDL обеспечивает ORB всей необходимой информацией о типе объекта, для работы вовсе необязательно, чтобы ORB-у был доступен исходный текст этих описаний. Эта же инфор- мация может быть заложена также в виде заглушек со стороны клиен- та и скелета со стороны сервера, а также в динамически изменяемом хранилище описаний, что позволит ORB-у нормально функциониро- вать. 266 Язык описания интерфейсов рассматривается как средство, с помощью которого реализация объекта сообщает своим потенциаль- ным клиентам о том, какие операции доступны и каким образом их следует вызывать. Можно оттранслировать описание на языке IDL в исходный код на конкретном языке программирования. Различные объектно-ориентированные или объектно- неориентированные языки программирования могут получать доступ к объектам различным образом. Для объектно-ориентированных язы- ков допускается отображение объектов, доступных ORB-у в объекты в смысле этих языков программирования. Даже для объектно- неориентированных языков декорирование настоящего представле- ния ссылок на объекты будет полезным. Конкретное отображение IDL для языка программирования должно быть идентичным для всех реализаций ORB-ов. Отображение для языка программирования включает в себя определение специфичных для языка программиро- вания типов данных и описания процедур доступа к объектам посред- ством ORB-а. Оно также включает в себя интерфейс для доступа кли- ента к заглушке, что может не требоваться для объектно- ориентированных языков, интерфейс динамических вызовов, скелет реализации, описание адаптеров объектов и прямой интерфейс к ORB-у. Отображение для языка также определяет порядок взаимодей- ствия между вызовом метода и потоками (тредами - threads) как со стороны клиента, так и со стороны реализации. Обычно обеспечива- ется синхронный вызов, в котором подпрограмма вызова возвращает управление при завершении выполнения запроса. Допускается опре- деление дополнительных средств, для определения порядка передачи управления и синхронизации клиентского кода с вызовом метода объекта. Типом называется некий предикат (математическая функция с одним аргументом возвращающее значение логического типа исти- на/ложь), который определен на множестве всевозможных значений. Значения удовлетворяют этому типу, если результат предиката - ис- тина. Такие значения называются членами типа. 267 Объектным типом называется тип, членами которого являются объекты, удовлетворяющие данному типу. Определены следующие основные (базовые) типы данных: 16 и 32 разрядные знаковые и беззнаковые целые типы; 32 и 64 разрядные типы с плавающей точкой в соответ- ствии с IEEE; символьный тип в соответствии с ISO Latin-1 (8859.1); логический тип с множеством значений истина и ложь; 8 разрядный тип, который гарантированно не подвергается никаким изменениям при передаче между различными системами; перечислимые типы, состоящие из последовательности идентификаторов; строковый тип, состоящий из последовательности симво- лов переменной длины, длина строки доступна во время выполнения программы; тип "any", который может принимать значения всех базо- вых и составных типов. Также могут быть определены составные типы: структура, состоящая из упорядоченных пар (имя, значе- ние); объединение, состоящее из дискриминатора и значения типа, связанного с дискриминатором; последовательность, которая является массивом перемен- ной длины значений одного типа, длина последовательности доступ- на во время выполнения; массив фиксированной длины, элементами которого явля- ются значения одного типа; тип интерфейс, который определяет множество операций, которое должен поддерживать экземпляр этого типа. CDR - это способ представления всех типов данных, определен- ных в OMG IDL в виде последовательности восьмиразрядных вели- чин, далее называемых байтами. Поток байт представляет из себя некоторую абстракцию обыч- но соответствующую буферу данных, который передается между 268 процессами или машинами с помощью средств IPC или сетевого транспорта. Далее считается, что поток байт или просто поток - это последовательность переменной (но конечной) длины величин, со- стоящих из 8 бит (байт) с четко определенным заголовком. Байты в потоке нумеруются от 0 до n-1 , где n - это длина потока. Индекс каж- дого байта используется для вычисления границ выравнивания, как это описано далее. Протокол GIOP определяет два вида потоков - сообщение и ин- капсуляция. Сообщение - это основная единица обмена информацией в протоколе GIOP. Инкапсуляция - это поток, внутри которого любая структура данных, имеющаяся в OMG IDL может быть декодирована независимо от остального контекста сообщения. Инкапсуляция поз- воляет осуществлять предварительное кодирование сложных типов данных (таких как TypeCode) или обрабатывать части сообщений без требования полного его декодирования. Все базовые типы могут быть закодированы как набор байт. При этом допускается использование как представления, в котором первым в поток помещается наиболее значимый или наименее значи- мый байт. Заголовок сообщения включает в себя флаг, который опре- деляет порядок при кодировании базовых типов в сообщении. Поря- док байт внутри любой инкапсуляции может отличаться от порядка байт в сообщении или другой инкапсуляции, внутри которой эта ин- капсуляция находится. Изменение порядка байт в случае необходи- мости возлагается на получателя сообщения. Для того, чтобы сделать возможным помещение и извлечение значений базовых типов в поток и из потока с помощью подпро- грамм, предназначенных для работы именно с этими типами данных, все базовые типы данных при помещении в поток должны быть вы- ровнены на свою естественную границу, то есть на число байт, кото- рое нацело делится на число байт, необходимых для представления этого типа. Таким образом значение, имеющее размер n должно ко- дироваться с позиции m*n , где m - это целое число. В CDR n может принимать значения 1, 2, 4 или 8. Если необходимо, то выровненному значению предшествует область минимально возможного размера, 269 необходимого для выравнивания. Значение байтов внутри этой обла- сти не определено. Выравнивание определяется относительно начала потока. Пер- вый байт в сообщении или инкапсуляции имеет индекс 0. Выравнивание составных типов не налагает никаких дополни- тельных требований, кроме тех, которые применяются при кодирова- нии их элементов. Элементы структуры кодируются в том порядке, в котором они определены в описании на IDL. Каждый элемент кодируется образом, соответствующим его типу. Объединение кодируется значением дискриминатора и членом объединения, соответствующим данному значению. Массив кодируется как последовательность его элементов. Так как длина массива фиксирована, она не кодируется. Если массив име- ет несколько измерений, то первый индекс изменяется наиболее мед- ленно, а последний - наиболее быстро. Последовательность элементов кодируется как величина типа unsigned long, за которым следуют элементы последовательности. Это значение определяет количество элементов. Каждый элемент кодиру- ется в соответствии со своим типом. Строка кодируется как величина типа unsigned long, содержа- щее длину строки, и отдельными символами - элементами строки. Длина строки и ее представление в виде списка символов включают завершающий нулевой символ, что дает возможность использования стандартных функций библиотеки языка C (например, strcpy) для де- кодирования сообщения. Значение перечислимого типа кодируется в виде величины типа unsigned long, соответствующей данному значению. Первому в по- рядке перечисления в определении на IDL значению соответствует 0, второму - 1 и так далее. Первый байт инкапсуляции кодирует порядок байт внутри нее - значение типа 0 означает кодирования по принципу первым - стар- ший байт, 1 - младший. Далее идут данные. Флаг порядка байт не включается в данные, но он включается в инкапсуляцию. Все значе- 270 ния внутри инкапсуляции выравниваются относительно ее начала, первый байт (с индексом 0) соответственно занимает флаг порядка байт. Если инкапсуляция кодируется как последовательность величин типа octet (байтов), то ей предшествует значение типа unsigned long, содержащее общий размер инкапсуляции. Никакого выравнивания для инкапсуляции не предполагается, но такой способ кодирования всегда гарантирует 4-байтное выравнивание для первого байта инкап- суляции. Спецификация CORBA определяет несколько псевдообъектов, которые не являются ни базовыми ни составными типами и кодиру- ются специальным образом. Ввиду особой специфичности данного кодирования и оно здесь не рассматривается. Операция представляет сервис, выполнение которого может быть запрошено. Операция определяется идентификатором операции. Операция описывается некоторой сигнатурой, которая задает пара- метры запроса и возвращаемое значение. В частности сигнатура со- стоит из: спецификации параметров, требуемых для выполнения операции спецификации возвращаемого значения спецификации исключения, которые могут возникнуть во время выполнения операции и типов данных, которые соответствуют этим исключениям спецификации дополнительной контекстной информации, которая может повлиять на выполнение запроса индикации семантики, которую клиент должен учитывать при выполнении операции. Хранилище описаний представляет из себя сервис, который обеспечивается постоянным объектом, доступном из программы. Во время выполнения программы он дает доступ к информации, анало- гичной той, что сохраняется в IDL описании объекта. Эта информа- ция может быть использована для выполнения запроса - таким обра- зом, программа, которая не предусматривала использование объекта 271 какого-либо типа, определить доступные у этого типа методы, типы его параметров и осуществить вызов. Разработка на основе CORBA Процесс разработки приложения с использованием технологии CORBA состоит из следующих4-х этапов: 1. Определение интерфейса на IDL. 2. Обработка IDL для создания кода заглушки и скелетона. 3. Создание кода реализации объекта (сервер). 4. Создание кода использования данного объекта (клиент). Язык определения IDL позволяет независимо от используемого языка программирования создать универсальное описание интерфей- са будущей системы. Созданный на IDL код должен специальным компилятором пре- образовываться в код интерфейса объекта на требуемом языке про- граммирования. После чего, на клиенте автоматически генерируется заглушка, преобразующая вызовы методы данного интерфейса в об- ращения к ORB. На сервере программист на основе сгенерированно- го интерфейса создает собственную реализацию данного класса. Скелетон автоматизирует получение и обработку удаленного вызова методов, поступающих через ORB. По сравнению с классическим клиент-серверным подходом, ис- пользование технологии CORBA для разработки распределенных приложений имеет следующие преимущества: Использование IDL для описания интерфейсов позволяет разрабатывать программные компоненты независимо от языка про- граммирования и базовой операционной системы; Поддержка богатой инфраструктуры распределенных объ- ектов; Прозрачность вызова удаленных объектов. Однако программные решения на базе технологии CORBA ред- ко выходят за рамки отдельных предприятий. Разработка крупно- 272 масштабных межорганизационных систем на базе технологии CORBA сопряжена со следующими трудностями: Плохая совместимость различных реализаций технологии CORBA от различных поставщиков; Проблемы взаимодействия узлов CORBA через Интернет; Несогласованность многих архитектурных решений CORBA и отсутствие компонентной модели, которая могла бы значи- тельно упростить разработку. |