Архитектура распределенных систем программного обеспечения. Учебное пособие издано при поддержке образовательной программы Формирование
 Скачать 1 Mb.
|
Бизнес активностиЧтобы иметь возможность управлять длительными бизнес транзакциями, выполняемыми сетевыми службами, и при этом не блокировать ресурсы использованием протокола двухфазного подтверждения, стандарт WS-Transaction определяет другой координационный тип, называемый бизнес активностью. Этот координационный тип содержит два протокола: бизнес соглашение с завершением участника и бизнес соглашение с завершениемкоординатора. Протокол бизнес соглашения с завершением участника инициируется сетевой службой участника с целью проинформировать координатора о состоянии выполнения, которое может, например, иметь значения: прервано, завершено, ошибка. После достижения консенсуса, продолжать ли выполнение транзакции или прервать ее, координатор отвечает всем участникам сообщениями типа закрыть, завершить, компенсировать, отменить или ошибка. Протокол бизнес соглашения с завершением координатора похож на протокол бизнес соглашения с завершением участника, он отличается тем, что каждый участник в данном случае уверен, что координатор предварительно оповестит его, что получил все запросы на выполнение работ в рамках данной бизнес активности. Это дает возможность участнику подготовиться к следующим за этим операциям завершения или компенсации. На Рис. 4.23 и Рис. 4.24 приведены диаграммы состояний протоколов бизнес активностей. Координатор в соответствии со стандартом должен иметь две пары типов портов (одна пара – для соглашения с завершением участника, а вторая для соглашения с завершением координатора). Один из пары типов портов позволяет координатору выполнять протоколы в качестве координатора, а второй – в качестве участника (как и раньше, это необходимо для организации координационных цепочек, когда координаторы взаимодействуют друг с другом). Сетевые службы должны реализовывать только один или два типа портов, в зависимости от типа используемого протокола. Реализация компенсационных операций зависит от конкретной сетевой службы и не рассматривается как часть бизнес логики. Более того, для каждой бизнес активности и для каждой сетевой службы может определяться только одна компенсационная операция. Это означает, что если сетевая служба в рамках некоторой бизнес активности выполняет в некотором порядке серию заданий, все эти задания должны отменяться в совокупности.  Рис.4.23.Диаграммасостоянийпротоколабизнессоглашениясзавершением участника.  Рис.4.24.диаграммасостоянийпротоколабизнессоглашениясзавершением координатора. Композиция сетевых службЕсли координация служб позволяет нескольким службам участвовать в одном разговоре между собой, то их композиция обеспечивает службам возможность одновременно вести несколько разговоров с разными службами (Рис. 5.1). Композиция сетевых служб напоминает процессы, происходящие в системах управления рабочим потоком, где бизнес логика интегрированного приложения реализуется композицией других, автономных крупноблочных приложений. При этом, в общем случае, различные сетевые службы могут поддерживать разные протоколы, следовательно, клиент должен сам реализовывать все протоколы, необходимые для обращения к службам.  Рис.5.1.Клиентымогутучаствоватьвразличныхразговорахсразнымисетевыми службами. Одно из наиболее интересных свойств композиции сетевых служб состоит в том, что добавлением составных компонентов она позволяет создавать сколь угодно сложные приложения. Таким образом, композицию служб можно рассматривать в качестве средства управления сложностью, в котором службы строятся из других служб, находящихся на более низком уровне абстракции. В отличие от традиционных композиционных структур (как в программировании, так и производственной деятельности) композиция сетевых служб не предполагает физической интеграции компонентов. Сетевые службы это не библиотеки прикладных программ, которые надо    транслировать и объединять с другими частями приложений. Напротив, их надо рассматривать как интерфейсы, которыми надо пользоваться, обращаясь к ним. Как и в системах интеграции приложений на уровне предприятий, композиция сетевых служб эквивалентна указанию, к каким службам надо обратиться, в каком порядке это сделать, как надо управлять исключительными ситуациями. Базовые компоненты остаются отделенными от композитных служб.Компания А Компания Б  Компания В Компания Г  Внутреннее приложение реализует композиционную логику, обращаясь при необходимостиксетевымслужбам.Вданномслучаекакая-либоподдержкав промежуточном слое отсутствует. Рис.5.2.Вотсутствиесистемнойподдержкикомпозициисетевыхслужб,реализация композитной службы проводится традиционными средствами. Для композиции сетевых служб требуется системнаяподдержка. В настоящее время наиболее широко распространен подход, когда программирование композитных сетевых служб ведется средствами традиционных языков, например, языка Java. Сетевые службы более всего используются в качестве мостов между гетерогенными системными платформами, а в подобном окружении разработка служб и их композиция традиционно выполняется непосредственно программированием на некотором языке. Однако языки программирования разрабатывались, не имея в виду потребности композиции сетевых служб. В получающихся программах бизнес логика оказывалась перемешанной с низкоуровневыми деталями, что означало сложности не только в процессе разработке композиции, но и при сопровождении (Рис.5.2). Сложившаяся ситуация привела к осознанию необходимости моделей высокого уровня, и для композиции сетевых служб было предложено много разных языков (XL, WSFL, BPML, BPEL). |