Бизнес-процессы, Оркестровка и хореография, Стандарты процессного управления

Оркестровка и хореография: подходы к описанию композитных бизнес-процессов

Выделяют два основных подхода к организации взаимодействующих бизнес-процессов: оркестровка и хореография. Оркестровка описывает поток взаимодействия между процессами организации, а хореография – последовательность условий такого взаимодействия. Статья приводит краткую характеристику этих подходов, анализирует их схожие и различные стороны и описывает их роль в сервис-ориентированной архитектуре. Оркестровка и хореография: подходы к описанию композитных бизнес-процессов
Иван Артамоновhttps://artamonoviv.ru/images/icon/logo.png
Внимание! Эта статья была опубликована в 2016 году в книге "Моделирование бизнес-транзакций". Использование материалов из нее разрешено только при правильной библиографической ссылке (для докладов, курсовых работы, рефератов, дипломных и пр. научных работ) или url-ссылки (для сайтов). Библиографическое описание дано в конце статьи.
PDF-версия статьи: скачать
Выделяют два основных подхода к организации взаимодействующих бизнес-процессов: оркестровка и хореография. Оркестровка описывает поток взаимодействия между процессами организации, а хореография – последовательность условий такого взаимодействия. Статья приводит краткую характеристику этих подходов, анализирует их схожие и различные стороны и описывает их роль в сервис-ориентированной архитектуре.

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

Ну что, стало что-то понятно из этих определений? Очевидно, что если и можно извлечь какие-то знания из этого, то с трудом. Я постараюсь сейчас подробно и внимательно рассказать о том, что такое оркестровка и хореография, чем они отличаются и где они применяются. Кстати, более подробно о них я написал в одноименной книги "Моделирование бизнес-транзакций". Если у вас будет возможность, сделайте на нее ссылку из своей работы, электронную, на сайте Elibrary или научную (библиографическую).

Итак.

Оркестровка

Оркестровка - описание внутреннего бизнес-процесса (сервиса) предприятия в виде последовательности и условий взаимодействия между внутренними и внешними для организации веб-сервисами (процессами).

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

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

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

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

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

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

Языки моделирования, предназначенные для описания оркестровки с целью автоматизации процесса посредством системы управления бизнес-процессами или специализированного «движка» оркестровки, называются языками оркестровки. С этой точки зрения к языкам оркестровки бизнес-процессов можно отнести, например, BPEL, XPDL и, по большей части, BPMN.

С точки зрения программирования, языками оркестровки могут являться любые, поддерживающие парадигму императивного программирования, то есть все те языки, где можно сделать классический алгоритм, решающий определенную задачу за конечное число шагов. Например, C, C++, Python, PHP, Perl, Ruby, C#, Java и пр.

Хореогафия

Признаюсь, это более непонятная штука.

Официально-научное определение гласит, что:

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

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

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

В хореографии раскрывается только видимое извне поведение каждого из участников, но не описываются никакие внутренние операции, которые происходят внутри участников (служб) и которые напрямую не производят видимый эффект. Зачастую хореографию связывают с B2B взаимодействием, выводя независимость участников взаимодействия за пределы одной организации (некоторого домена ответственности). К языкам описания хореографии относят WS-CDL (Web Services Choreography Description Language, хотя, к сожалению, его черновик так и не был завершен), ebXML Business Process Specification Schema (BPSS) и др.

Сравнение оркестровки и хореографии

Тонкую границу между оркестровкой и хореографией не всегда удается сразу определить. Вообще, хореографию даже иногда путают с оркестровкой и даже называют ею процессы оркестровки (к примеру, хореография бизнес-взаимодействия стандарта ebXML BPSS не является таковой, а идеально вписывается в определение оркестровки) или целые программные системы (например, IBM WebSphere Process Server включает компонент, который называется «Business Process Choreographer» («Хореограф бизнес-процессов»). Этот компонент поддерживает моделирование бизнес-процессов с помощью языка BPEL, тогда как BPEL является признанным примером языка описания оркестровки).

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

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

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

Хореография же, наоборот, описывает не порядок взаимодействия, а условия этого взаимодействия для возможности передачи сообщений между участниками. Существует два принципиальных подхода к организации хореографии: подход, основанный на передаче контекста и соглашениях между участниками (агентный подход).

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

В случае подхода с контекстом поведение глобального процесса определяется контролем над передаваемыми между участниками данными. Этот механизм поддерживается языком WS-CDL и часто используется для B2B взаимодействия.

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

В хореографии взаимодействие определяется поведением входящих компонентов, что соответствует движению «снизу вверх» – «от частного к общему».
У оркестровки и хореографии разнится точка зрения наблюдателя ко всему процессу целиком. Оркестровка рассматривает процесс-координатор в качестве владельца, ответственного за результаты своей работы. Именно он отвечает за обработку ошибок, преобразование данных, проверку условий, разделение потока вычислений, его объединение и т.д. В хореографии же не требуется централизованного взгляда на весь процесс. Достаточно определить параметры поведения входящих в нее участников или характеристики обмена данными между ними.

В современных технологиях и концепциях EAI оркестровка играет одну из ведущих ролей. Именно об оркестровке идет речь, когда происходит интеграция слабо-связных сервисов низкого уровня в тот или иной бизнес-процесс (или очередной сервис) более высокого уровня. Здесь ведущий бизнес-процесс – это всего лишь оркестровка вспомогательных процессов более низкого уровня. В качестве индивидуальных «шагов» такой последовательности потока взаимодействия могут использоваться отдельные операции, реализуемые службами.

Кроме того, основной индустриальный стандарт оркестровки BPEL, использующий модели XML, использует то же WSDL-описание служб на двух уровнях: во-первых, описанные в терминах WSDL службы используются для взаимодействия в рамках процесса, а во-вторых, каждый BPEL-процесс – это такой же сервис, описанный на WSDL, соответствует стандартам сервисной архитектуры.
Свойство процессов и служб объединяться в крупные процессы и системы для реализации более сложной функциональности с точки зрения оркестровки и хореографии называют рекурсивной композицией. Рекурсивная композиция предполагает, что сценарии оркестровки или хореографии могут комбинироваться с другими описаниями в новые сценарии оркестровки и хореографии, которые могут использоваться в отличном от изначального контексте. Оркестровка, представляющая с определенной точки зрения целостную службу или процесс, по природе своей поддерживает подобную композицию.

Представление крупного процесса с точки зрения скомибинированных оркестровок – это представление его в виде «белого» ящика, где каждый включенный во взаимодействие процесс – это в первую очередь определенный сценарий. Хореография, наоборот, часто представляется исследователям в виде описания взаимодействия между частями целостной системы, и вопрос о рекурсивной композиции в таких случаях, конечно, не рассматривается. Сложность возникает при определении точки зрения на композитную хореографию для каждого из сценариев. С точки зрения вовлекаемого во взаимодействие сценария, то для него композитный процесс – более высокого уровня, тогда как другие процессы, вовлекаемые в композитный – равны ему. Такой же вопрос можно задать по отношению к процессам, вовлекаемым в исходный сценарий и т.д.

Этот вопрос можно решить, например, приняв решение о взаимодействии исключительно между сценариями хореографии, находящимися на одном уровне детализации. Каждый сценарий, как независимый участник, получает определенную роль в процессе композиции и выполняет свои задачи в рамках этой роли также, как выполняют свои задачи уже вовлеченные в него процессы (подобный пример можно отметить, например, для WS-CDL). Таким образом, невозможно одновременно создать побочную линию композиции хореографии в одном комбинированном сценарии с интеграцией хореографий с изначально разных уровней абстракций.

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

Процесс оркестровки часто связан с наличием некоторой «информационной среды». Информационная среда представляет собой совокупность получаемой, хранимой и обрабатываемой координатором процесса информации вместе с процедурами ее обработки и проверки. Среда может быть выделена как для группы действий оркестровки, так и для всего процесса. Поэтому в процессе оркестровки можно определить свои переменные, проводить с ними несложные процедуры, проверять их при циклах и ветвлениях и т.д. В хореографии нет исполнителя центрального процесса, нет отдельного потока управления, поэтому создавать и поддерживать информационную среду для процесса хореографии можно только силами всех ее участников. Работа с информационными объектами ведется исключительно в границах процессов-участников, а проверка условий перехода к следующему шагу хореографии может проводить инициатор этого шага. Именно поэтому в средствах описания хореографии особая роль уделяется поддержке процессов информационного обмена и управления состоянием информационной составляющей каждого участника.

Исполняемый BPEL-код оркестровки действительно является «исполняемым» и схож со скриптовыми языками программирования: загружается в BPEL/BPM систему и исполняется как любой программный код через последовательный доступ к операциям веб-служб, манипуляцию с данными или ветвление/повторение потока управления и др. При этом «оркестрированный» поток отображается как самостоятельный сервис, взаимодействие с которым возможно через специфическое API. Сценарий хореографии не может быть исполнен напрямую, он «принимается к сведению» участниками хореографии и позволяет на своей основе конфигурировать службы для взаимодействия и строить локальные сценарии оркестровки для каждой из них.
В оркестровке нашла отражение классическая методология программирования и описания потока работ: последовательное изменение состояния системы и включенных в нее компонентов для достижения определенного результата. Оркестровка регламентирует передачу управления под контролем центрального координатора, который является владельцем и ответственным за весь процесс.

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


Библиографическое описание

Артамонов, И. В. Оркестровка и хореография / И. В. Артамонов // Моделирование бизнес-транзакций. – Иркутск: Издательство БГУ, 2016. – С. 39 - 45.

URL-ссылка

https://artamonoviv.ru/articles/business_process_orchestration_and_choreography/