Обмен Сообщениями (Conversations)

Обмен Сообщениями (Conversation) является частным случаем использования диаграммы Взаимодействия и её неформальным описанием. Выражаясь общими терминами, Обмен Сообщениями представляет собой упрощенный вариант Взаимодействия, однако, диаграмма Обмена Сообщениями все же поддерживает все характеристики Взаимодействия. В частности, Участники (Пулы) диаграммы Обмена Сообщениями могут содержать Процессы для отображения связи между Обменом Сообщениями и Действиями (Activities).

Диаграмма Обмена Сообщениями содержит два дополнительных графических элемента, которые не отображаются на других диаграммах BPMN:

1. Узел Взаимодействия (Conversation Node). Сюда входят Обмен Сообщениями, Подчиненный Обмен Сообщениями (Sub-Conversation) и Обмен Сообщениями типа Вызов (Call Conversation).
2. Ссылка на Обмен Сообщениями (Conversation Link).

Обмен Сообщениями представляет собой логическое оформление (группировку) обмена Сообщениями (Потоков Сообщений), имеющих общую Корреляцию (Correlation). Посредством Обмена Сообщениями также отображается логическое отношение, характерное для обмена Сообщениями. В действительности логическое отношение часто связано с важными бизнес-объектами, например, «Заказом», «Транспортировкой и Доставкой», «Выставлением счета». Соответственно, Обмен Сообщениями ассоциирован с набором пар "имя-значение" или Ключом корреляции (Correlation Key, например, «Идентификатор Заказа» или «Идентификатор Доставки»), который записан в Сообщениях, подлежащих обмену. В данном случае Сообщение может быть направлено в конкретный экземпляр Процесса, ответственный за получение и обработку данного Сообщения.

На фигуре 9.16 представлен простой пример диаграммы Обмена Сообщениями.



Фигура 9.16 - Диаграмма Обмена Сообщениями

На фигуре 9.17 представлен один из вариантов расположенной выше диаграммы. В данном случае узел Обмена Сообщениями расширен с продолжением в собственные Потоки Сообщений. Обратите внимание, что диаграмма имеет такой же вид, что и диаграмма простого Взаимодействия (см. фигуру 9.3).



Фигура 9.17 - Диаграмма Обмена Сообщениями, расширенного в Потоки Сообщений

Случаи обмена Сообщениями связаны друг с другом и являются отражением удаленных бизнес-сценариев. Отношения иногда оказываются простыми, как, например, запрос, за которым следует ответ (такой пример может быть описан в качестве компонента структурного интерфейса какого-либо сервиса, например, определения операции WSDL). Однако в коммерческих операциях, управляемых Бизнес-процессами, отношения могут быть сложными, когда задействуется взаимный продолжительный обмен Сообщениями. В таких случаях отношения могут представлять собой не двусторонние, а комплексные, многосторонние Взаимодействия. Рассмотрим пример из логистики. Пополнение запасов товаров подразумевает следующие сценарии: формирование заказов, назначение проводника для доставки товаров по нескольким заказам, прохождение таможни/карантин, оплата и рассмотрение отводов.

Говоря об оркестровке Процесса, следует помнить, что Обмены Сообщениями являются значимыми для Хореографии (Choreography), однако, не отображаются в ней. Отличие состоит в том, что Хореография представляет собой проекцию комплексного (с несколькими Участниками) Обмена Сообщениями. Причиной этого является то, что обмен Сообщениями, моделируемый с использованием Действий Хореографии (Choreography Activities), подразумевает наличие нескольких Участников. Эта схема отличается от оркестровки Процесса, где элементы отправки и получения Сообщения принадлежат одному Участнику. Ещё одним отличием является то, что понятие Обмена Сообщениями сохраняется и в Хореографии, и в оркестровке. Таким образом, обмен Сообщениями будет, в итоге, выполняться и в оркестровке Процесса.

Поскольку Взаимодействие представляет собой проекцию обмена Сообщениями в режиме нисходящего моделирования (в период проектирования), то абстрактное представление всех Обменов Сообщениями, связанных с моделируемой областью, доступно во всех диаграммах Обменов Сообщениями. На диаграмме Обмена Сообщениями (такой, как на фигуре 9.18) в виде шестиугольников показаны Обмены Сообщениями между Участниками. Благодаря этому обеспечивается вид «с высоты птичьего полета» различных Обменов Сообщениями, связанных с определенной областью.



Фигура 9.18 – Диаграмма Обмена Сообщениями, изображающая несколько Обменов Сообщениями между Участниками одной области

На фигуре 9.18 изображены 13 обособленных Обменов Сообщениями между взаимодействующими Участниками (рассматривается область логистики). Участники «Retailer» (продавец) и «Supplier» (поставщик) участвуют в Обмене Сообщениями «Delivery Negotiations» (переговоры о доставке), а Участник «Consignee» (грузополучатель) ведет переговоры с Участниками «Retailer» и «Supplier» посредством Обменов Сообщениями «Delivery/Dispatch Plan» (план отправки и доставки) и «Shipment Schedule» (схема доставки) соответственно. В Обмен Сообщениями МОГУТ БЫТЬ вовлечены более двух участников (например, в Обмене Сообщениями «Detailed Shipment Schedule» (детальная схема доставки) могут участвовать «Consignee», «Consolidator» (консолидатор) и «Shipper»). Для того, чтобы указать количество вовлеченных в Обмен Сообщениями Участников, необходимо указать ассоциации между этими Участниками и Обменом Сообщениями. К примеру, в Обмене Сообщениями «Deliver Negotiations» один экземпляр Участника «Retailer» ведет переговоры с другим (одним) экземпляром Участника «Supplier». Однако один экземпляр Участника «Shipper» ведет обсуждение с несколькими экземплярами Участника «Carrier» (на диаграмме такой Участник обозначен многоэкземплярным маркером Пула) в Обмене Сообщениями «Carrier Planning» (планирование перевозки). Обратите внимание, что в рамках Обмена Сообщениями множественность (многоэкземплярность) подразумевает наличие одного и более экземпляров (а не от нуля и более).

Поведение различных Обменов Сообщениями моделируется в отдельных Хореографиях (Choreographies), где детализируется последовательность обмена Сообщениями. В действительности тесно связанные Обмены Сообщениями могут использоваться совместно в одной и той же модели Хореографии, к примеру, обмен Сообщениями в «Delivery Negotiation» ведет к Обменам Сообщениями «Shipment Schedule», «Delivery Planning» и «Delivery/Dispatch», которые, в свою очередь, могут использоваться вместе в одной Хореографии. При этом они также по отдельности могут входить в состав разных Хореографий.

На фигуре 9.19 изображено подмножество более крупного Обмена Сообщениями, представленного на фигуре 9.18. На фигурах 9.20 и 9.21 более детально показан Подчиненный Обмен Сообщениями «Delivery Negotiations». Он растягивает Обмен Сообщениями за счет Потоков Сообщений, благодаря которым обеспечивается структура Обмена Сообщениями и не нарушается последовательность в нем. На фигуре 9.19 также изображен Ключ Корреляции (CorrelationKey), входящий в состав Потоков Сообщений данного Обмена Сообщениями. К примеру, «Order Id» (ID заказа) необходим для всех Сообщений, составляющих Потоки Сообщений в «Delivery Negotiation». Некоторые из этих Потоков Сообщений требуют наличия Variation Id (это необходимо для работы с видами поставок на основании продукции).



Фигура 9.19 – Пример Подчиненного Обмена Сообщениями

На фигуре 9.20 отображен Подчиненный Обмен Сообщениями, представленный на фигуре 9.19, который расширен с помощью Потоков Сообщений и Обмена Сообщениями более высокого уровня.



Фигура 9.20 – Пример Подчиненного Обмена Сообщениями, расширенного Обменом Сообщениями и Потоками Сообщений

На фигуре 9.21 отображен Обмен Сообщениями, представленный на фигуре 9.20, который также расширен с помощью набора Потоков Сообщений в сочетании с предыдущими Потоками Сообщений. Обратите внимание, что вновь открытые Потоки Сообщений, принадлежащие Обмену Сообщениями более низкого уровня, взаимосвязаны посредством Ключа Корреляции (CorrelationKey) как Обмена Сообщениями более низкого уровня (Variation Id), так и Подчиненного Обмена Сообщениями более высокого уровня (Order Id).



На фигуре 9.19 изображен Обмен Сообщениями с иерархической структурой, которая просматривается в одном наборе Потоков Сообщений, находящемся в родительско-дочерних отношениях с другим. В частности, после «Planned Order Variations» на родительском уровне (использовался Order Id) Потоки Сообщений дочернего уровня следуют до «Retailer Order and Delivery Variations Ack» (использовались Variation Id и Order Id). Оставшиеся Потоки Сообщений (использовался Order Id) находятся на родительском уровне. Дочерний Обмен Сообщениями является частью родительского Обмена Сообщениями. Вложенный Обмен Сообщениями графически отмечен знаком «+», указывающим на то, что Подчиненный Обмен Сообщениями или Обмен Сообщениями типа Вызов вызывает Взаимодействие. Вложенный Обмен Сообщениями может охватить любое количество уровней.

Отношения подчинения между Обменами Сообщениями могут частично перекрываться. Это происходит тогда, когда в двух или более Обменах Сообщениями происходят общие для них двоих отправка и получение Сообщений. Как изображено на фигуре 9.18, Сообщение отсылается как часть «Detailed Shipment Schedule» (используется Carrier Schedule Id) с целью активации «Delivery Monitoring» (используется Shipment Id). В ходе операции «Delivery Monitoring» Сообщение может быть отправлено в «Detailed Shipment Schedule» с целью запросить информацию об изменениях в случае, если возникнут какие-то проблемы при транспортировке.

Разделение и слияние относятся к сценариям перекрытия. Разделение Обмена Сообщениями возникает тогда, когда обмен Сообщением, являющимся частью данного Обмена Сообщениями, происходит между двумя или более Участниками, которые одновременно активируют новый удаленный Обмен Сообщениями (между этими же или другими Участниками). При разделении Обмена Сообщениями ни последующего обмена Сообщениями, ни последующего слияния Обменов Сообщениями не происходит. Примером может служить Обмен Сообщениями «Delivery Planning», ведущий к «Carrier Planning» и «Special Cover». Слияние Обмена Сообщениями происходит тогда, когда несколько этих элементов объединяются в один Обмен Сообщениями. При этом в исходных Обменах Сообщениями отправка и принятие Сообщений прекращается, что означает завершение Обменов Сообщениями. Итак, разделение и слияние представляют собой рефакторинг Обменов Сообщениями и подразумевают разделение одного Обмена Сообщениями на параллельные и последующее их объединение.

Процессы могут входить в состав диаграммы Взаимодействия. Участник/Пул, содержащийся во Взаимодействии, может заключать в себе Процесс (хотя это НЕ ОБЯЗАТЕЛЬНО). В качестве примера см. фигуру 9.4.

Если Дорожка (Lane) Процесса представляет собой Обмен Сообщениями, то Элементы Потока (Flow Elements), содержащиеся в ней и отправляющие или отсылающие Сообщения, ДОЛЖНЫ выполнять вышеперечисленные действия в качестве Обмена Сообщениями, для отображения которого служит данная Дорожка.

Хореографии (Choreographies) могут входить в состав диаграммы Взаимодействия. Во Взаимодействии указывается то, каким образом устанавливается соответствие между Участниками (Participants) и Потоками Сообщений (Message Flows) Хореографии и Участниками и Потоками Сообщений Взаимодействия. Для этой цели во Взаимодействии используются элементы ParticipantAssociations и MessageFlowAssociations.

Для установки соответствий между Участниками элементы innerParticipant и ParticipantAssociation ссылаются на Участника Хореографии, в то время как элемент outerParticipant ссылается на Участника Взаимодействия, содержащего данную Хореографию. Такое соответствие устанавливается и между Секциями Участников (Participant Bands) Задач Хореографии (Choreography Activities) данной Хореографии и Пулами (Pools) Взаимодействия. Таким образом, использование имен в Секциях Участников становится НЕОБЯЗАТЕЛЬНЫМ (см. фигуру 9.32).



Фигура 9.32 – Пример Хореографии в составе Взаимодействия

Для установки соответствий между Потоками Сообщений элементы innerMessageFlow и MessageFlowAssociation ссылаются на Потоки Сообщений Хореографии, в то время как элемент outerMessageFlow ссылается на Поток Сообщений Взаимодействия, содержащего данную Хореографию. Такое соответствие устанавливается между Потоками Сообщений Хореографии (которые не отображаются) и Потоками Сообщений Взаимодействия (которые отображаются). Это позволяет Потокам Сообщений Взаимодействия «подключаться» с помощью соответствующего Действия Хореографии (см. фигуру 9.32).

Ассоциации Участников (ParticipantAssociations) могут образовываться исходя из Партнерских Сущностей (partnerEntities) и Партнерских Ролей (partnerRoles) Участников. К примеру, если на Действие Хореографии назначен Участник с той же Партнерской Сущностью, что и Участник Взаимодействия, содержащего это Хореографию, то оба этих Участника могут стать внутренними (inner) и внешними Участниками (outerParticipants) Ассоциации Участников (ParticipantAssociation). Подобным образом, Потоки Сообщений, ссылающиеся на одно и то же Сообщение Действия Хореографии типа Вызов и Взаимодействия, могут быть автоматически синхронизированы с помощью Ассоциации Потока Сообщений (MessageFlowAssociation), но только при условии, что данное Сообщение входит в состав только одного Потока Сообщений.



Фигура 9.33 – Хореография в составе диаграммы классов Взаимодействия