Архитектура распределенных систем программного обеспечения. Учебное пособие издано при поддержке образовательной программы Формирование

• Название: Учебное пособие издано при поддержке образовательной программы Формирование
• Анкор: Архитектура распределенных систем программного обеспечения
• Дата: 13.01.2023
• Размер: 1 Mb.
• Имя файла: mdwrbook.docx
• Тип: Учебное пособие; #885216
• страница: 35 из 36

Транзакции

Транзакционное поведение композитных служб определяется внедрением в оркестровую схему атомарных областей. На графических диаграммах такие области окружают наборы активностей, обладающие свойством все-или-никто. Атомарность достигается выполнением с вызванными службами протоколов двухфазного подтверждения, возможно основанных на спецификации WS-Transaction. Это поведение полностью реализуется в системном слое, не требуя от разработчика никакого программирования.

Иногда требуется менее строгая транзакционная семантика, не требующая досконального выполнения транзакционных свойств, что связано с длительностью блокировки ресурсов при выполнении композитных служб. Алгоритм 2РС для подтверждения атомарности наборов операций атомарных областей применять нельзя. Решение этой проблемы находится при применении компенсаций, когда результаты подтвержденных операций отменяются выполнением других операций. Применение такого подхода означает, что при возникновении ошибки для осуществления частичного отката операций атомарной области системный слой сетевых служб должен инициировать и выполнить протокол компенсации подтвержденных активностей. Компенсация может управляться мотором, который в совокупности с системными программами сетевых служб, реализующими спецификации WS- Transaction (в частности, протокол бизнес активностей), выполняет компенсационный протокол и информирует службы о необходимости компенсаций.

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

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

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

6. Управление исключениями

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

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

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

Подходы "попытка-перехват-возбуждение". Эта методика похожа на то, как делается в программах на языках Си++ и Java операторами try, catch и throw, но адаптирована для сетевых служб. Для исключения вводится логическое условие, связанное с композиционными данными, обычно с результатом сообщения о выполнении операции. Если условие выполнено, выполняется и часть программы, управляющая исключением. После этого процесс может повторить активность, повторить обработку исключения или просто остановиться. Иерархия позволяет определять обработчики исключений на разных уровнях абстракции. Первыми вызываются обработчики исключений, определенные внутри группы активностей, в которой возникло исключение. После окончания их работы

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

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

Подходы, основанные на правилах. Эти подходы описывают логику управления исключениями на основе правил event-condition-action, с помощью которых исключительное событие (например, отказ заказчика), должно быть облечено в форму сообщений, посылаемых клиентом композитной службе, или в форму таймаутов. Условие – это логическое выражение над сообщением, которое проверяет, действительно ли событие относится к исключительной ситуации, которую надо обработать (например, оно может проверять, разрешено ли данному заказчику иметь отрицательный баланс). Затем на исключение реагирует действие, вызывая операцию или прерывая транзакцию. Правила обычно определяются в некотором текстовом виде, дополняя графическую нотацию, определяемую в обычной оркестровке.

Подходы, основанные на правилах, четко разделяют нормальное и исключительное поведение процесса. Эти подходы хороши, если число правил невелико, иначе трудно анализировать и понимать совместное поведение набора правил и взаимодействие внутри набора между правилами и потоками.