Журнал о системах электронного документооборота (СЭД)
Workflow и управление бизнес-процессами

Создание приложений на платформе рабочих процессов

  0 комментариев Добавить в закладки

Дэвид Грин

Платформа рабочих процессов (workflow platform) облегчает решение многих бизнес-задач. В этой статье обсуждается создание приложений на платформе рабочих процессов. Такая платформа поддерживает ключевые концепции рабочих

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

 

Идея рабочего процесса не нова и лежит в основе эффективного способа решения бизнес-проблем. Задачи, к решению которых применяется подход на основе рабочих процессов, часто обладают тремя характеристиками:

●     главный фактор выгоды - координация (например, привлечение нескольких отделов организации к подготовке делового предложения или передача документа на рецензирование);

●     каждый экземпляр бизнес-процесса выполняется длительное время: дни, недели или месяцы, а не минуты;

●     в бизнес-процессе участвуют люди, которые обычно вносят наибольший вклад в результат работы.

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

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

Модель рабочих процессов

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

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

 

Преобразование рабочего процесса в стек. DIRECTUM-Journal.ru

Рис. 1. Преобразование монолитного рабочего процесса в стек

 

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

Модель рабочих процессов описывает организацию элементов работы (work units), или рабочих элементов (work items). Допустим, что в соответствии с процессом утверждения документов Джо пишет документ, после чего Фред его рецензирует. В данном случае элементы работы - написание и рецензирование документа, а организация выражается в том, что одна задача должна следовать за другой. В этой концепции нет ничего радикального.  Примером ее реализации может служить код, вызывающий два метода. Интерес представляют способы организации элементов работы.

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

В этом примере рабочими элементами являются рецензии документа, организованные в процесс утверждения.

Здесь интересны три характеристики:

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

Контракты рабочих процессов

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

Как правило, рабочие процессы связывают несколько сторон посредством

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

 

Рецензирование документа. DIRECTUM-Journal.ru

Рис. 2. Схема контракта приложения, служащего для рецензирования документов

 

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

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

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

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

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

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

Коллективное решение проблем

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

«Человек во многих отношениях подобен асинхронному сервису: никто не знает, когда он прореагирует на то или иное событие и прореагирует ли вообще»

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

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

В данном случае элементы работы - это операции, которые различные участники могут выполнить, пытаясь решить проблему недостачи. Однако организация здесь отличается от той, которая требовалась для утверждения документов. Участникам не навязываются те или иные действия; они сами выбирают, что и когда им делать. Тем не менее имеющийся у них выбор ограничивается организацией рабочего процесса; при этом следует учитывать два нюанса. Во-первых, операции сфокусированы на достижении цели (устранении недостачи). В начале решения проблемы создается связанное пространство коллективной работы (bounded collaboration space), которое не закрывается до достижения цели. Во-вторых, участники не могут выполнять произвольные операции. Вместо этого возможные операции определяются на основе роли участника и состояния коллективной работы. В свою очередь набор доступных операций определяется политиками, связанными с целью, и глобальными политиками, такими как недопущение задержки поставок продукции привилегированным клиентам.  По мере продвижения коллективной работы совокупность доступных операций меняется.

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

Операции, выраженные в сценариях

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

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

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

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

«Модель рабочих процессов, отражающая значение приложения для бизнеса и отделенная от нерелевантных технических аспектов - эффективный способ реализации взаимодействия между сотрудниками ИТ- и бизнес-отделов»

Теперь обсудим приложения, руководящие пользователями в выполнении каких-либо операций. Примерами таких приложений могут служить система интерактивного речевого ответа (interactive voice response, IVR) или система центра обработки вызовов, помогающая операторам следовать сценариям поддержки или продаж. Суть этих приложений - помочь пользователям выполнить последовательность операций, необходимых для достижения цели. UI системы - будь то генерируемая речь или набор активных и заблокированных кнопок на форме - обычно определяется организацией этих операций.

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

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

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

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

Правила и политики

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

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

Для связывания UI с нижележащей объектной моделью часто используется проектировочный шаблон Model-View-Controller (MVC), показанный на рис. 3. Модель представляет поведение системы, независимое от конкретного UI. Контроллер является элементом уровня UI, служащим для сопоставления событий UI с вызовами методов, нужными для управления моделью. Таким образом, сам UI не «загрязняется» никакими предположениями о нижележащей модели.

 

MVC-приложение. DIRECTUM-Journal.ru

Рис. 3. MVC-приложение

 

Все рассмотренные нами до сих пор с этой точки зрения рабочие процессы относятся к категории моделей в терминологии MVC. Но контроллер тоже можно рассматривать как рабочий процесс.  Организуемые им рабочие элементы - это методы объектов модели. Контроллер также взаимодействует с UI и моделью посредством четко определенных контрактов. Модель такого типа часто называют потоком страниц (page flow).  Как и операции, выражаемые в сценарии, поток страниц никто не стал бы реализовывать сегодня, используя типичную систему создания рабочих процессов. Есть два довода в пользу создания потока страниц на платформе рабочих процессов. Во-первых, при этом модель можно легко визуализировать, что помогает разработчикам и аналитикам описывать и анализировать необходимое поведение. Во-вторых, если поток страниц часто изменяется, его абстрагирование в виде модели повышает гибкость.

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

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

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

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

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

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

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

Ценность платформы рабочих процессов

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

 

Утверждение документа. DIRECTUM-Journal.ru

Рис. 4. Схема реализации рабочего процесса утверждения документа

 

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

 

public void HandleLoanRequest (
    string customerID,
    Application app)
{
    if (CheckCredit(
        customerId, app.Amount))
    {
        MakeOffer (customerId, app);
    }
}

 

В каком-то смысле это модель. Мы можем выполнить синтаксический анализ этого кода и создать представляющее его дерево CodeDOM.

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

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

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

Выразительность. Специализация модели рабочих процессов в соответствии с предметной областью рабочего процесса позволяет быстрее выразить характерные проблемы в более компактной форме. Для этого используется специфический для предметной области язык (domain-specific language, DSL), адаптированный к решению характерных проблем. Так, в случае процесса утверждения документа получение трех положительных отзывов из пяти означает, что документ хорош и что любые незавершенные рецензии можно отменить. Этот процесс довольно сложно закодировать, но модель рабочих процессов включает стандартные конструкции для решения подобных проблем.

Другие способы использования семантики

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

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

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

«Концепция рабочего процесса реализована в WF как организация рабочих элементов, абстрагированная от родственных концепций, с которыми она связана в традиционных системах с поддержкой рабочих процессов»

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

Композиция (composition). Если приложение разделено на рабочие элементы, благодаря понятным интерфейсам эти элементы можно повторно использовать в других рабочих процессах.  В самих рабочих процессах также можно определять рабочие элементы, которые могут быть задействованы другими рабочими процессами.

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

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

Характеристики платформы

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

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

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

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

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

Теперь выясним, как эти характеристики реализованы в Windows Workflow Foundation (WF). До сих пор мы обсуждали концепции, лежащие в основе разработки для WF, но только благодаря реализации в WF их потенциал можно конвертировать в реальные решения.  Концепция рабочего процесса реализована в WF как организация рабочих элементов, абстрагированная от родственных концепций, с которыми она связана в традиционных системах с поддержкой рабочих процессов. Действующие при этом абстракции делятся на три основных категории: проектирование и визуализация, хостинг и семантика.

Проектированиеи визуализация. В WF рабочий процесс представляет собой дерево элементов работы (называемых операциями). С этим деревом можно работать непосредственно как с объектной моделью. В состав WF входит и дизайнер, но его применение не обязательно. Вы можете создавать новые дизайнеры, адаптированные к потребностям конкретных сообществ пользователей или к конкретным организациям элементов работы. Кроме того, можно выполнить специализацию дизайнера, поставляемого с WF. Он применим не только в Visual Studio, но и в любых приложениях, способных к хостингу.

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

Хостинг. Исполняющая среда WF достаточно экономична в плане использования ресурсов, чтобы можно было осуществлять ее хостинг в клиентском контексте. Кроме того, она достаточно производительна, чтобы масштабироваться, будучи интегрированной в серверный хост, такой как SharePoint Server, входящий в Microsoft Office 12. Требования исполняющей среды WF к хосту абстрагируются в форме провайдерских интерфейсов сервисов, таких как сервисы многопоточности, транзакций, хранения состояния и коммуникаций.  Есть готовые реализации провайдеров, но в случае надобности их можно заменить.

Семантика. Разные варианты семантики модели ориентированы на решение разных проблем. WF изначально поддерживает три основных стиля рабочих процессов: поток, конечный автомат и рабочий процесс, управляемый данными. Поток оптимален в случае приложений, в которых рабочий процесс находится под контролем, таких как в примере с операциями, выражаемыми в сценариях. Конечный автомат - лучший вариант, если рабочий процесс управляется внешними событиями, что имеет место, например, в случае MVC-приложения и приложений, руководящих пользователем при выполнении каких-либо операций. Подход на основе управлениями данными адаптированным приложениям, в которых операции зависят от состояния, таких как система коллективной работы над решением проблем.

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

Универсальная исполняющая среда рабочих процессов

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

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

«Транзакции ACID особенно полезны, когда нужно обеспечить согласованность состояния рабочего процесса и состояния внешней сущности, такой как приложение или сообщение»

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

Исключения и компенсация. Исполняющая среда WF поддерживает всем известную концепцию исключений «throw-try-catch», которая представлена в стандартной модели рабочих процессов. Но исполняющая среда WF поддерживает и более общий подход к обработке ошибок, включающий компенсацию успешно завершенных частей транзакций.

Коммуникации. Как мы убедились, рабочие процессы должны поддерживать разные способы взаимодействия, что отражено в исполняющей среде WF и стандартной модели рабочих процессов и дополнено поддержкой взаимодействия, основанного на использовании .NET-методов, интерфейсов событий и Web-сервисов. В будущем должна быть реализована и поддержка системы Windows Communication Framework. Таким образом, в WF на самом деле реализован предлагаемый в этой статье подход, основанный на платформе рабочих процессов.

Высокоуровневая схема реализации приложения утверждения документов показана на рис. 4. В качестве хоста рабочих процессов в приложении применяется сервер SharePoint. Исполняющая среда WF использует сервис планирования по умолчанию, доступный в WF. Но сервисы хранения состояний и коммуникаций, используемые по умолчанию, заменены в этом приложении специальными версиями, адаптированными к особенностям хоста SharePoint. Первый из этих сервисов сохраняет состояние длительно выполняемого рабочего процесса в базе данных SharePoint, а сервис коммуникаций позволяет использовать в рабочем процессе средства взаимодействия с пользователями, реализованные в SharePoint. Оба этих сервиса входят в состав Microsoft Office 12.

Для определения самого рабочего процесса утверждения документов используются три вида операций. Во-первых, это стандартные операции WF, позволяющие применять структурирующие элементы вроде If-Else и While.  Во‑вторых, это операции, реализованные в Office 12, которые служат для доступа к сервисам взаимодействия с пользователями в SharePoint. К третьей категории относятся специальные операции, на основе которых стандартным способом реализуется специфическая для организации семантика пересылки и делегирования. Дизайнер WF применяется для определения рабочего процесса и позволяет владельцу рабочего процесса утверждения документа получить схематическое представление состояния экземпляра этого процесса.

Подход к решению проблем

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

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

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

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

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

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

Чтобы платформа рабочих процессов была полезна во многих контекстах, она должна определять стандартную расширяемую модель рабочих процессов, полностью программируемую в периоды разработки и выполнения, поддерживать разные способы взаимодействия, потреблять мало ресурсов, обеспечивать интеграцию в системы и без проблем масштабироваться в крупномасштабных средах, демонстрируя при этом высокую производительность. WF обладает всеми этими характеристиками. Кроме того, будучи компонентом WinFx и частью платформы Windows, она отличается низкой стоимостью и может быстро стать популярной.

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

Об авторе

Дэвид Грин (David Green) начал работать в лабораториях Hursley корпорации IBM в 1977 году. За прошедшее с тех пор время занимал различные связанные с разработкой ПО должности в издательской компании, компаниях American Express и Siemens Nixdorf, а также в одном из крупнейших банков Великобритании. В основе всей его карьеры лежат стремление создавать эффективные приложения для реального бизнеса и разработка подходов и инструментов, помогающих упростить создание бизнес-решений мирового уровня. На протяжении последних двух лет работал в Microsoft над платформой Windows Workflow Foundation, которую считает важным расширением доступного разработчикам инструментария.

Оригиналстатьи: The Archtecture Journal

Источник: The Achitecture Journal / Русская редакция, март 2006

Похожие записи
Комментарии (0)
Сейчас обсуждают
Больше комментариев