4.6. Реализация взаимодействия по протоколуGiop.

В соответствии со спецификацией протокола GIOP в системе реализована система кодирования сообщений в три этапа:

1. Сначала кодируются данные, которые передаются вместе с запросом. Для сообщений типа Requestи эти данные представляют параметры операции, сообщений типаReply - результат операции и выходные значения операции или же информация об возникшем исключении. СообщениеLocateReply в качестве тела могут содержать информацию об местонахождении объекта, которая запрашивалась в сообщенииLocateRequest.

2. Кодируется заголовок конкретного сообщения, который дополнительно определен для каждого типа сообщений, за исключением сообщений CloseConnection иErrorMessage, которые не имеют дополнительного заголовка.

3. Кодируется само сообщение как заголовок, в котором указан размер остальной части сообщения, полученной на этапах 1-2.

Не все типы сообщений проходят указанные этапы. Следующая таблица показывает, какие виды сообщений какие стадии кодирования проходят:

Сообщение	1. Данные сообщения	2. Заголовок сообщения	3. Общий заголовок
Request	Кодируется	Кодируется	Кодируется
Reply	Кодируется	Кодируется	Кодируется
CancelRequest	-	Кодируется	Кодируется
LocateRequest	-	Кодируется	Кодируется
LocateReply	Кодируется	Кодируется	Кодируется
CloseConnection	-	-	Кодируется
MessageError	-	-	Кодируется

На листе 4 представлены алгоритмы (1-3) кодирования заголовков двух наиболее используемых типов сообщений - Request иReply, а также кодирование общего заголовка сообщения. Лист 5 показывает алгоритм (4) кодирования одного значения произвольного типа, что требуется во многих случаях. Далее следует привести краткие пояснения к схемам алгоритмов.

Схема 1. Кодирование общего заголовка.

Кодирование общего заголовка состоит из следующих шагов.

1. Кодирование заголовка (поле magic) заключается в заполнении этого поля значениям“GIOP”.

2. Кодирование номера текущей версии кодирует текущую версию 1.0.

3. Кодирование порядка байт просто заносит в поле значение 1, что соответствует лидирующему наименее значащему байту. Разбор сообщений, которые имеют другой порядок байт на данный момент не реализовано.

4. Кодирование типа сообщения заносит в соответствующее поле значение от 0 до 6, соответствующее типу передаваемого сообщения.

5. Кодирование размера сообщения предполагает, что оставшаяся часть (заголовок и тело сообщения, если они есть) уже закодирована и известен ее размер.

6. Кодирование сообщения заключается просто в копировании уже подготовленного буфера.

Схема 2. Кодирование запроса.

Пункты 1-6 обеспечивают кодирование заголовка запроса.

1. Кодирование контекста (списка строк) зарезервировано на будущее для реализации поддержки дополнительных сервисов, таких как сервис транзакций. Имеющаяся реализация кодирует контекст как пустой список.

2. Кодирование номера запроса просто помещает значение, соответствующие уникальному идентификатору запроса типа unsigned long.

3. Кодирование необходимости ответа кодирует величину типа boolean значением типа 0 (false) или1 (true), которая сигнализирует, должен ли сервер посылать ответное сообщение после выполнения запроса или нет. В подавляющем количестве случаев это поле имеет значениеtrue.

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

5. Кодирование имени операции кодирует операцию как строку. Если происходит запрос на чтение или запись одного из атрибутов, то имя операции получается из дополнения имени атрибута префиксами ‘_get_’или‘_set_’ соответственно.

6. Кодирование поля Principalкак потока байт зарезервировано для возможного обеспечения в будущем поддержки аутентификации запросов. Данная реализация кодирует поле как пустой поток (длина равняется нулю).

7. 8. Эти пункты в цикле кодируют все передаваемые (типовin иinout) операции параметры, то есть кодирование тела запроса.

Схема 3. Кодирование ответа.

Пункты 1-3 обеспечивают кодирование заголовка ответа.

1. Кодирование контекста (списка строк) зарезервировано на будущее для реализации поддержки дополнительных сервисов, таких как сервис транзакций. В ответе контекст должен совпадать с контекстом соответствующего запроса. Имеющаяся реализация кодирует контекст как пустой список.

2. Кодирование номера запроса просто помещает значение, которое копируется из запроса, ответ на который кодируется.

3. Кодирование типа ответа кодирует одно из четырех значений NO_EXCEPTION(0), которое показывает нормально выполнение запроса, SYSTEM_EXCEPTION (1) илиUSER_EXCEPTION (2), которые сигнализируют об возникновении исключения при отработке запроса илиLOCATION_FORWARD (3), что означает отсутствие запрашиваемого ответа у сервера и указывает на его (объекта) местонахождение. Данная реализация не поддерживает такое перенаправление запросов.

4. Далее в зависимости от успеха/неуспеха выполнения запроса происходит кодирование тела запроса.

5. В случае возникновения исключения оно кодируется строкой, которая однозначно его определяет.

6. 7. Если есть результат, возвращаемый операцией, то кодируется значение результата.

7. 9. Эти пункты в цикле кодируют все возвращаемые (типовout иinout) операцией параметры.

Схема 4. Кодирование значения произвольного типа.

На данной схеме приводится алгоритм кодирования значения любого, допустимого в OMG IDL типа. Кодирование происходит в соответствии с описанием в пункте 5.3. синтаксисом Общего Представления Данных (CDR). Следует заметить, что кодирование по этому алгоритму происходит только при использовании Интерфейса Динамических Вызовов(DII). Если же используется код, сгенерированный соответствующими утилитами, дляproxy-объекта, то с целью оптимизации в них происходит обращения напрямую к нужным подпрограммам кодирования соответствующих типов данных.