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

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 и отсутствие компонентной модели, которая могла бы значи- тельно упростить разработку.