Файл: Лекция 1 (Определения и терминология, форматы сообщений).doc

Общая схема организации взаимодействия логических блоков подсистемы транзакционных возможностей ОКС 7 представлен на нижеследующей диаграмме «Подсистема транзакционных возможностей ОКС 7 и ее взаимодействие с верхними и нижними уровнями модели взаимодействия открытых систем (ВОС)».

Подсистема транзакционных возможностей ОКС 7 и ее взаимодействие с верхними и нижними уровнями модели взаимодействия открытых систем (ВОС)

Адресация обеспечивается SCCP

Примитивы управления SCCP используются для передачи информации пользователей SCCP о доступности (недоступности SCCP-местный или удаленный), которые прозрачно передаются к ТС пользователей.

Компонентный подуровень

Компонента является средством проведения подсистемой транзакций ОКС 7 (ТС-Transaction Capability) запроса на выполнение операции или отклик.

Операция – действие, которое должно выполняться на удаленном окончании, идентифицируемое примитивом INVOKE-Id. Это позволяет произвести несколько вызовов аналогичной или различных операций. На операцию может передаваться только один отклик (указание об успехе или ошибке).

Диалог (структурированный и неструктурированный)

Услуги управления диалогом

Когда два TC пользователя взаимодействуют в рамках какого-либо приложения, то в основном, требуется более чем один вызов операции. Результирующий поток компонент должен идентифицироваться следующим образом:

Компоненты аналогичного потока соотносятся;
Потоки, относящиеся к нескольким экземплярам одного и того же приложения, могут быть идентифицированы и для них допускается параллельное выполнение.

Для TC пользователя каждый такой поток (компонент) идентифицируется диалогом и соответствующим параметром идентификатора диалога. Услуга управления диалогом, обеспечиваемая для этой цели, является структурированным диалогом.

Если для завершения распределенного прикладного процесса требуется одиночное сообщение, то может быть использовано однонаправленное сообщение неструктурированного диалога. Инициатор операции TCAP не ожидает сообщения о результате операции (такая операция является операцией класса 4), но может принять сообщение об ошибке протокола, если она случается.

Неструктурированный диалог – ассоциация между компонентами. Неструктурированный диалог обеспечивается в протоколе посредством однонаправленного сообщения (unidirectional). В случае, если происходит ошибка, то возвращается также однонаправленное сообщение.

Структурированный диалог

ТС пользователи указывают на начало диалога или его структуру, включая продолжение и окончание диалога. Использование структурированного диалога позволяет ТС пользователю выполнять одновременно несколько диалогов, каждый из которых определяется отдельным идентификатором.

Когда используется структурированный диалог, ТС пользователь должен указать на один из следующих четырех возможностей:

Начало диалога;
Подтверждение диалога;
Диалог продолжается: полностью дуплексный обмен компонентами является возможным;
Диалог завершается: на передающей стороне более не передается компонент;

Параметр идентификатора диалога используется, как в примитивах управления операциями (компонентами), так и в примитивах управления передачей (диалогом) и необходимы для определения, какие компоненты относятся к какому диалогу. Параметр идентификатора диалога отражается (по соглашению) первым параметром в этих примитивах, начиная с буквы «D». Каждый пользователь TC имеет для данного диалога собственную ссылку. Местные ссылочные номера (используемые на интерфейсе с SCCP) представлены в данных рекомендациях. Сопоставление этих местных ссылочных номеров с ссылочными номерами протокола осуществляется подсистемой транзакционных возможностей ОКС 7.

Для управления диалогом при нормальных обстоятельствах были определены три примитива – они указывают на начало диалога (TC-BEGIN), продолжение (TC-CONTINUE) и завершение (TC-END). Каждый из этих примитивов может быть использован для запроса передачи 0, 1, или нескольких компонент, которые могут содержать информацию, относящуюся к одной или нескольким операциям.

Гипотетический пример инициирования диалога, его продолжения и последующего дуплексного обмена компонентами между пользователями и завершение диалога по инициативе пользователя B, представлен на нижеследующей стрелочной диаграмме.

Пример инициирования диалога, его последующего продолжения и завершения по инициативе пользователя B

Если «отклик» на вызов операции является вызовом другой операции с приемной стороны, первоначальный идентификатор вызова («Invoke Id») возвращается как идентификатор связанной операции («Linked Id»), указывая, что этот вызов операции с приемной стороны «связан» с первоначальной операцией. Пример организации связанной операции приведен на нижеследующей диаграмме.

Пример вызова связанной операции

Связанные операции.

Услуга структурированного диалога позволяет ТС пользователю начать диалог, произвести в рамках его обмен компонентами, закончить или прервать диалог.

Это обеспечивается посредством идентификатора транзакций среди соответствующих транзакционных сообщений.

Начало диалога

ТС пользователь начинает новый диалог посредством ввода примитива запроса «TC-Begin». Назначение этого примитива является следующим:

- указать компонентному подуровню на начало диалога, идентифицированного параметром идентификатора диалога, присутствующим в этом примитиве;

- запросить передачу какой-либо компоненты (компонент), переданных к подуровню компонент посредством примитивов управления компонентами типа “запрос” и имеющие аналогичный идентификатор диалога.

Примитив запроса «TC-Begin» может быть введен перед передачей каких-либо компонент к подуровню компонент. На приемной стороне ТС пользователь пункта назначения информируется о том, что новый диалог инициирован посредством примитива индикации «TC-Begin». На присутствие компонент указывается в поле “компоненты присутствуют”.

Продолжение диалога

Пользователь ТС указывает на продолжение диалога посредством ввода примитива запроса «ТC-Continue». Эти запросы, инициируемые соответствующим примитивом, необходимы для передачи какой-либо компоненты (компонент), переданных к компонентному подуровню для этого диалога, с момента приема сообщения «TC-Begin» или передачи примитива запроса «ТC-Continue».

На приемной стороне указанный примитив «ТC-Continue ind.» информирует пользователя о следующем:

- что диалог может быть продолжен;

- что компоненты доставлены (если параметр “компоненты присутствуют” не указывают “пусто”)

Завершение диалога

Для ТС пользователя обеспечивается три сценария, позволяющие ему завершить диалог:

- специально организованное завершение диалога;

- основное завершение диалога;

- прерывание диалога ТС пользователем.

Окончание диалога использует запрос TC-END и соответствующий указательный примитив. Примитив запроса TC-END указывает, какой сценарий будет использован для завершения диалога.

а) Предварительно организованное завершение диалога.

В этом сценарии ТС пользователь, по предварительному соглашению решил, когда завершить диалог: влияние примитива TC-END является исключительно локальным. К ТС пользователю на приемной стороне пункта назначения никакая индикация TC-END не предусматривается.

Никаких компонент не может быть передано или принято для диалога, как только пользователем был передан примитив управления диалогом TC-END. Пример предварительно организованного завершения диалога представлен на нижеследующей диаграмме.

Пример предварительно организованного завершения диалога

Типичным применением предварительно организованного завершения диалога является доступ к распределенной базе данных, при запросе TC пользователя A и его незнании, где расположена искомая им информация. TC пользователь A транслирует запрос к возможным местонахождениям информации и будет принимать отклики от пользователя, владеющего искомой информацией.

Предварительно организованное завершение диалога обеспечивает отсутствие сообщений от других пунктов назначения, условно информирующих пользователя: «Я не имею этой информации». Только пользователь, владеющий соответствующей информацией, может продолжить диалог, в то время как все остальные SP назначения будут завершать диалог локально. Инициатор запросов будет также завершать диалог с неподтвержденными пунктами назначения местно. В приведенном выше примере рассматривается ситуация, где имеются два пункта назначения – B1 и B2 и инициированы два диалога (D1, D2) и (D3, D4). B1 владеет запрашиваемой информацией и решает продолжить диалог (передается транзакция управления диалогом «TC-Continue req. (D2)».

Предварительно организованное завершение диалога может еще использоваться пользователем TC в случае, если ему требуется передать информацию, на которую не ожидается какого-либо отклика.

в) основной сценарий

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

Базовый сценарий использует примитивы TC-END со следующей целью:

- доставка какой-либо компоненты (компонент), которые были переданы к подуровню транзакций и для которых передача была задержана (на подуровне транзакций допускается образование очереди)

- индикация к ТС пользователю, что обмен компонентами в любом направлении будет для инициированного диалога прекращен.

Пример основного завершения диалога

В общем, когда пользователь вводит примитив запроса завершения диалога, то это вызывает передачу каких-либо задержанных компонент к удаленному окончанию.

На стороне приема, диалог предполагается завершенным, когда все компоненты, принятые в сообщении, указывающие на завершение, были доставлены к TC пользователю.

с) прекращение диалога ТС пользователем

ТС пользователь имеет возможность запросить немедленное прекращение диалога, не принимая во внимание какие-либо задержанные вызовы операций. При этом, пользователь ТС может обеспечить “сквозную” (End-to-End) передачу информации, указывающую на причину прерывания диалога, а так же определенную диагностическую информацию. Эта информация ТСАР не анализируется.

Запрос TC-U-Abort и соответствующая индикация примитива предназначены для выполнения соответствующих функций.

Управление компонентами.

Определение параметров.

Этот раздел определяет параметры, использующиеся с примитивами управления компонентами.

“класс”, “идентификатор диалога” – соотносит компоненты с определенным диалогом;

“идентификатор вызова” – идентифицирует вызов операции;