Свобода выбора альтернативных шагов коммуникации

В этом разделе мы определим, что значит в S-BPM использовать один шаг из нескольких возможных (так называемых альтернативных) коммуникационных шагов, и уточним в параграфе 12.5 абстрактное значение отдельных шагов, подробно описав их способность к многопроцессной коммуникации. В подпараграфе 12.4.1 мы уточним элементы характерного для коммуникации в S-BPM понятия Input Pool и сформулируем на этой основе в подпараграфе 12.4.2 первое уточнение по началу, выполнению и завершению для отправки и получения, в которых возможность многопроцессорной коммуникации остается по-прежнему абстрактной. Поскольку многие из встречающихся определений находятся симметрично в отправке и получении, мы сформулируем их с использованием параметра Comact для конкретного действия коммуникации.

Основа концепции Input Pool

Каждый субъект для поддержки асинхронной связи, типичной для распределенных систем, имеет в своем распоряжении Input Pool (Subj), в котором другие субъекты в роли передатчика могут оставлять сообщения на Subj и где Subj в роли приемника «ожидает» сообщения (т.е. ищет сообщения, если он готов принять их). Каждый Input Pool можно конфигурировать с помощью ограничений возможностей по максимальному количеству сохраненных в нем сообщений определенного или любого типа и (или) но передатчику. Предусмотрены все четыре возможные положения типа сообщения (читай — несколько параметров для любого или определенного типа и передатчика) (см. подпараграф 5.5.5.2).

Для единого описания синхронной связи ноль является значением параметра допустимости Input Pool и интерпретируется как требование того, что получатель ожидает сообщения указанного типа и (или) от указанного отправителя при встрече. Асинхронная коммуникация, однако, определяется положительными натуральными числами в параметрах допустимости Input Pool. В ситуации, когда отправитель пытается сохранить сообщение в Input Pool, а он уже достиг своей соответствующей границы допустимости, предоставляются две стратегии:

• — удаленная отправка, где-либо а) для добавления входящего сообщения удаляется сообщение из Input Pool или б) входящее сообщение выбрасывается (т.е. не добавляется в Input Pool);
• — блокированная отправка, где отправка сообщения блокируется и передатчик должен пытаться сохранить это сообщение до тех пор, пока а) в Input Pool не освободится место или б) тайм-аут прервет попытку передачи, или в) передатчик решит прервать попытку передачи.

В первом случае предоставляются две версии удаления, а именно: удаление из Input Pool сообщения, которое находится там очень долго или очень мало. Это то, что мы описываем с помощью двух определенных в приложении функций oldestMsg и youngestMsg. Будет ли попытка передачи из Input Pool Р приемника удалена или заблокирована, зависит от того, было ли данное состояние условий допустимости Р нарушено входящим сообщением или нет. Эти условия представлены в таблице constraintTable (Р), в которой строка i дает для комбинации senderi и msgTypei максимально допустимое количество сообщений этого типа вместе с действием action, в случае нарушения допустимости:

Если отправитель попытается сохранить сообщение MSG в Р, первая строка row = s t п а в constraintTable (Р) определяет (если она существует), какое ограничение количества имеет MSG и было ли оно нарушено через добавление MSG. (iff означает: if и only if, т. е. именно в том случае, если): Если такой строки нет, то сообщение может быть сохранено в Р. В противном случае оно закрепляется в идентифицируемой строке указанного действия, и эта попытка передачи блокируется, или сообщение признается (при определенных обстоятельствах сразу выбрасывается) через действие удаления.

Требуется, чтобы action_i = блокировка для каждой линии с sizej = О и в случае MAXSIZE (Р) <�°° constraintTable возникла следующая строка по умолчанию: any any maxSize Blocking.

Аналогично приемник пытается перевести «ожидаемое» сообщение, т. е. сообщение указанного типа (msgType, sender) из своего Input Pool в местное хранилище информации, как мы увидим при интерпретации шагов получения. В распределенном процессе в определенное время несколько субъектов могут пытаться сохранить сообщение в Input Pool Р одного и того же получателя, но только один субъект может получить доступ к ресурсу Р. Таким образом, необходим механизм отбора для определения этого субъекта. Мы используем функцию SelectР, при которой предикат доступа определяется как:

CanAccess {sender, Р) if sender =.

= SelectP ({subjectfj TiyingToAccess {subject, P)}) 12.4.2. Структура взаимодействия альтернативных шагов связи В альтернативном состоянии связи субъект осуществляет коммуникацию Comact, в которой проводятся следующие три шага элементов множества Altematiive {subj, node) всех Cowacf-альтернатив, при которых subject находится в данном состоянии node до тех пор, пока коммуникация не будет успешной (см. подпараграф 5.5.4.3 и 5.5.4.4):

• — выбор: из Altematiive {subj, node) выбрать старый тип сообщения;
• — подготовка: подготовить старое соответствующее msgToBeHandled, т. е. в случае Comact = Send конкретное сообщение msgToBeSent и в противном случае конкретный тип сообщения expectedMsg,
• — попытка ComAct: Try Alternative _ComAct, т. е. отправить подготовленное msgToBeSent или подходящее к виду expectedMsg сообщение (подходящее в смысле Match) перенять из Input Pool или получить синхронно.

Оба первых этапа (выбор и подготовка альтернатив) уточняется через компонент ChooseAndPrepareAltemative_{С (тАф} который представляет собой первый шаг TryAlternative_ComAct и определяется в подпараграфе 12.5.1. Если третий шаг для alt не удается (т.е. msgToBeHandled не может быть послано или принято ни асинхронно, ни синхронно), субъект повторяет три шага для следующей альтернативы, до тех пор пока:

• — comact для альтернативы успешно завершен, и можно установить Completed субъекта для Comact (сервис) в данном состоянии node;
• — или действует TryRoundFinished, т. е. все альтернативы были безуспешными.

Во втором случае после первого так называемого раунда попыток Nonblocking начинается ряд дальнейших comact-попыток blocking в том смысле, что они могут быть завершены не только с помощью нормального Completed, но и через Timeout или User Abruption. Timeout имеет более высокий приоритет, чем User Abruption.

Все Round Alternative должны быть инициализированными Alternative {subj, node) после каждой группы попыток. Это происходит:

• — для nonblocking-группы в начале, для первой blocking-группы в InitializeBlockingTryRounds, где также установлены Timeout-часы,
• — для каждой последующей группы в Initialize Round Alternatives.

Непрерывность блокирующей группы попыток начинается в SVD

по меньшей мере из трех исходящих из node-краев, которые могут быть взяты в соответствии с нормальной или принудительной ComActTerminierung для продолжения расчетов с помощью Proceed. Три предиката — NormalExitCond, TimeoutExitCond, AbruptionExitCond — определяют исходящий край, который должен быть взят для следующего 57?>-состояния, если comact нормально Completed или завершено через Timeout или UserAbruption. Эти три предиката также инициализируются при запуске (а именно значением false). Следующее определение выполнения (subj, ComAct, state) обобщает приведенные выше объяснения в символической форме. Мы передаем его в виде традиционной блок-схемы на рис. 12.2. Такие диаграммы представляют собой ASM и, таким образом, имеют точную семантику [1, с. 44] и эквивалентное текстовое определение в приложении, где также определены не приведенные здесь более или менее очевидные машины компонентов.

Рис. 12.2. Perform (subj, ComAct, state)

Макросы и компоненты выполнения (subj, ComAct, state). Мы определяем здесь старт (subj, ComAct, state), Interrupt и ABRUPT и указываем на приложение для других компонентов.

Start (subj, ComAct, state) =

InitializeRoundAlternatives (subj, state) InitializeExit&CompletionPredicatesComAct (subj, state) EnterNonBlockingTryRound (subj, state) where.

InitializeRoundAlternatives (subj, state) =

RoundAlternative (subj, state) := Alternative (subj, state) InitializeExit&CompletionPredicatesComAct (subj, state) = InitializeExitPredicatesComAct (subj, state) InitializcExit&CompletionPrcdicatesComAct (subj, state) InitializeExitPredicatesComAct (subj, state) =

NormalExitCond (subj, ComAct, state) := false TimeoutExitCond (subj, ComAct, state) := false AbruptionExitCond (subj, ComAct state) := false InitializeExit&CompletionPredicatesComAct (subj, state) =.

Completed (subj, ComAct, state) := false Enter [Non] BlockingTryRound (subj, state) = tryMode (subj, state) := [non] blocking Interrupt ComAct (subj, state) =

SetCompletePredicateComAct (subj, state) SETTIMEOUTEXIT ComAct (subj, state) SetComoletionPredicateComAct (subj, state) = Completed (subj, ComAct, state) := true SetTimeout Exit ComAct (subj, state) = TimeoutExitCond (subj, ComAct, state) := true AbruptComAct (subj, state) = SetCompletPredicateComAct (subj, state) SetAbruptionExitComAct (subj, state)