Проектирование компонентов рабочего процесса

14
Проектирование компонентов
рабочего процесса
Обзор
Во многих сценариях задачи пользователя должны осуществляться в определенном порядке
на основании выполнения определенных этапов или удовлетворять ряду базовых бизнесправил. Компоненты рабочего процесса используются для инкапсуляции задач и для
согласования шагов, необходимых для их выполнения. Компоненты рабочего процесса также
могут поддерживать задачи, зависящие от обрабатываемых данных, таких как данные,
вводимые пользователем или динамическими бизнес-правилами, которые определяют
бизнес-процесс.
Данная глава обсуждает разные сценарии и предлагает руководство по проектированию
компонентов рабочего процесса. Она начинается с рассмотрения того, как реальные сценарии
проецируются на ключевые сценарии организации рабочего процесса; это поможет сделать
правильный выбор стиля рабочего процесса для создаваемого приложения. Далее
демонстрируется, как требования и правила определяют доступные варианты реализации
компонентов рабочего процесса. И, в заключение, приводятся рекомендации по
проектированию компонентов рабочего процесса с учетом различных доступных вариантов.
Общие принципы проектирования и более подробное описание компонентов, обычно
используемых в слоях приложения, можно найти в главе 10, «Рекомендации по
проектированию компонентов».
Шаг 1 – Выбор стиля рабочего процесса на основании сценариев
Существует три основных типа стилей рабочего процесса: последовательный, конечный
автомат и управляемый данными. При последовательном рабочем процессе выполнение
задач состоит из определенного набора этапов. В конечном автомате действия определены
как набор состояний и событий, которые обусловливают переходы из одного состояния в
другое. В управляемом данными рабочем процессе действия выполняются на основании
информации, ассоциированной с данными. Таким образом, первым делом при
проектировании компонентов рабочего процесса необходимо понять, какой рабочий процесс
требуется поддерживать. Рассмотрим рекомендации по выбору одного из этих трех базовых
стилей рабочего процесса:

Последовательный рабочий процесс. Такой рабочий процесс управляет
последовательностью действий и принимает решение о том, какой из этапов будет
выполнен следующим. Несмотря на то, что последовательный рабочий процесс
может включать ветви и циклы, он предсказуем. Используйте последовательные
рабочие процессы, если для реализации определенной задачи требуется выполнять
серии заранее определенных шагов; или для таких сценариев как управление
системами, координирование операций между компаниями и обработка бизнесправил.

Конечный автомат. Такой рабочий процесс переходит в заданное состояние и
ожидает возникновения определенных событий для перехода в другое состояние.
Используйте конечный автомат для управляемых событиями сценариев, сценариев
пользовательских интерфейсов, таких как интерфейс мастера, или систем
обработки заказов, в которых предпринимаемые шаги и процессы зависят от
данных заказа.

Управляемый данными рабочий процесс1. В таком рабочем процессе данные
документа определяют действия, выполняемые рабочим процессом. Этот стиль
подходит для таких задач, как процесс утверждения документов.
Шаг 2 – Выбор способа разработки
Для создания рабочих процессов можно использовать код, языки разметки или их сочетание.
Используемый подход зависит от требований, предъявляемых к способу разработки в
создаваемом решении. Выбор способа разработки также зависит от того, как приложение
будет упаковываться и распространяться. Возможны такие варианты:

Только код. Выбирайте этот вариант, если рабочий процесс не будет сильно
меняться со временем; если имеются сложные бизнес-правила, которые тяжело
выразить средствами языков разметки; если группе разработки привычнее писать
управляемый код, а не создавать разметку в визуальных дизайнерах; или если
требуется разрабатывать новые типы рабочих процессов, что невозможно сделать с
помощью разметки. Также рабочие процессы, созданные с использованием только
кода, просто интегрировать в систему управления исходным кодом.

Разделение кода2. Выбирайте этот вариант, если имеются сложные бизнесправила, инкапсулированные компонентами бизнес-слоя; или если требуется
предоставить пользователям или администраторам возможность изменять
некоторые аспекты рабочего процесса с помощью дизайнеров рабочих процессов.
1
Также известны, как рабочие процессы на базе политик (прим. научного редактора).
2
То есть используется и язык разметки, и код (прим. научного редактора).

Разметка. Выбирайте этот вариант, если предполагается более частое изменение
рабочего процесса в будущем; если ассоциированные с рабочим процессом
бизнес-правила можно без труда выразить средствами языков разметки; если нет
необходимости создавать новые типы рабочих процессов; если необходимо
обеспечить гибкость для обновления модели рабочего процесса без повторной
сборки используемого моделью программного кода, реализующего рабочий
процесс.
Шаг 3 – Определение стратегии обработки правил
На данный момент уже сделан выбор относительно стиля рабочего процесса и способа
разработки рабочих процессов. Следующий шаг – принятие решение о том, как рабочий
процесс будет обрабатывать бизнес-правила. Доступные варианты определяются сложностью,
стабильностью бизнес-правил и требованиями к управлению, с ними связанными. При выборе
стратегии обработки бизнес-правил в компонентах рабочего процесса следует учитывать
следующие факторы:

Если правила сложные, для их разработки необходимо использовать только код
или разделение кода. Правила могут реализовываться и инкапсулироваться в
компонентах бизнес-слоя с возможностью координирования их выполнения
рабочим процессом.

Если правила подвержены изменениям, т.е. простые или управляемые данными,
для них следует применять разметку. Однако если правила управляются внешней
системой, такой как обработчик бизнес-правил, применяйте только код или
разработку с разделением кода.

Если правила будут контролироваться бизнес-пользователями,
администраторами или аналитиками, выбирайте решение с использованием
языков разметки, что обеспечит визуальный дизайнер или другое средство
редактирования правил, или решение, поддерживающее предметноориентированный язык программирования (Domain Specific Language, DSL). Однако
если правила управляются внешней системой, такой как подсистема управления
бизнес-правилами, применяйте разработку с разделением кода.
Шаг 4 – Выбор решения для рабочего процесса
Выбрав стиль рабочего процесса, способ разработки и требования по обработке правил,
можно переходить к выбору решения для рабочего процесса, который зависит от
возможностей, обеспечиваемых каждым решением. На платформе Microsoft доступны
следующие технологии:

Windows Workflow Foundation (WF). WF обеспечивает ориентированное на
разработчика решение для создания последовательного рабочего процесса,
конечного автомата или управляемого данными рабочего процесса. WF
поддерживает разработку с помощью только кода, с разделением кода и с
использованием языков разметки. Поддержка дизайнера доступна в Visual Studio
2005 через расширения и непосредственно в Visual Studio 2008 и последующих
версиях. WF включает дополнительные средства для безопасного, надежного,
транзакционного обмена данными, отслеживания действий, широкий выбор
средств передачи и кодирования передаваемых данных, а также обеспечивает
поддержку длительных рабочих процессов, которые могут сохраняться между
выключениями и повторными запусками системы.

Workflow Services. Workflow Services (Сервисы рабочего процесса) обеспечивают
интеграцию Windows Communication Foundation (WCF) и Windows Workflow
Foundation (WF) для обеспечения рабочих процессов WCF-возможностями. Начиная
с Microsoft .NET Framework 3.5, WCF расширена для обеспечения поддержки
рабочих процессов, предоставляемых как сервисы, и возможности вызова сервисов
из рабочих процессов. Кроме того, Microsoft Visual Studio 2008 включает новые
шаблоны и инструментальные средства, поддерживающие сервисы рабочего
процесса.

Microsoft Office SharePoint Services (MOSS). MOSS1 – платформа для управления
информацией и координации совместной деятельности, обеспечивающая
поддержку рабочих процессов на основе технологий WF. MOSS обеспечивает
решение для рабочего процесса, управляемого оператором, и совместной
деятельности в контексте сервера Microsoft Office SharePoint® Server. Используя
Веб-интерфейс, можно определять рабочие процессы для визирования
документов, связанных с элементами списка SharePoint; использование дизайнера
SharePoint или Windows Workflow Designer (Дизайнер Windows рабочих процессов)
в Visual Studio позволяет определять условные и управляемые данными рабочие
процессы. Для настройки рабочих процессов может использоваться объектная
модель WF в Visual Studio. Однако MOSS подходит, только если бизнес-слой
взаимодействует лишь с одним сайтом SharePoint и не требует доступа к данным
других сайтов.

BizTalk Server. Сервер BizTalk поддерживает последовательные рабочие процессы,
конечные автоматы и управляемые данными рабочие процессы, а также
разработку с разделением кода и применением языков разметки. Он обеспечивает
возможность обмена электронными документами между компаниями с
использованием форматов Electronic Data Interchange (EDI)2 и/или XML и включает
мощные возможности оркестровки для проектирования и выполнения длительных,
тесно связанных бизнес-процессов и рабочих процессов с возможностями
надежного хранения и пересылки сообщений. BizTalk интегрируется с
гетерогенными приложениями и системами через адаптеры и обеспечивает
обработчик бизнес-правил и мониторинг деловой активности (Business Activity
Monitoring). Если требуется взаимодействовать с системами не-Microsoft,
1
Сервисы Microsoft Office SharePoint (прим. переводчика).
2
Электронный обмен данными (прим. переводчика).
выполнять EDI-операции или реализовывать шаблоны Enterprise Service Bus (ESB),
используйте комплект инструментов ESB Toolkit для BizTalk Server.
Шаг 5 – Проектирование компонентов бизнес-слоя для
поддержки рабочего процесса
Общей рекомендацией является создание рабочих процессов, состоящих из многошаговых
или длительных процессов, реализованных в отдельных компонентах, и обеспечить обработку
всех сбоев рабочих процессов через предоставление соответствующих исключений. При
проектировании бизнес-процессов необходимо учесть вызовы методов, не требующие ответа
или с длительным временем ответа. Если компонент должен выполнять заданный набор
этапов последовательно и синхронно, используйте конвейерный шаблон. Если этапы могут
выполняться асинхронно в любом порядке, используйте событийный шаблон.
Следующие разделы помогут разобраться с проектированием рабочих процессов с
применением технологий, предлагаемых платформой Microsoft.
Windows Workflow Foundation
Для Windows Workflow Foundation (WF) можно разрабатывать следующие бизнес-компоненты:
собственные рабочие процессы, действия и объекты состояний, а также собственные сервисы.
То, какие компоненты понадобятся, зависит от стиля рабочего процесса и способа разработки.
Далее описывается процесс создания трех основных типов рабочих процессов, собственных
сервисов и разметки рабочего процесса с использованием WF:

При проектировании последовательных рабочих процессов описываются или
используются существующие классы Activity (Действие) (только код или разделение
кода), определяются классы рабочего процесса (только код) и определяются
компоненты бизнес-процесса, взаимодействующие с компонентами рабочего
процесса (только код).

При проектировании конечных автоматов описываются классы состояний,
используемые для представления разных состояний процесса (только код или
разделение кода), описываются или используются существующие события,
запускающие изменения состояний (только код или разделение кода), описываются
или используются существующие классы Activity, управляющие переходами
состояний (только код или разделение кода), описываются классы рабочего
процесса (только код) и определяются компоненты бизнес-процесса,
взаимодействующие с компонентами рабочего процесса (только код).

При проектировании управляемых данными рабочих процессов описываются или
используются существующие классы Activity (только код или разделение кода),
описываются или используются существующие классы Condition (Условие) для
взаимодействия с поставщиками данных (только код или разделение кода),
описываются специальные классы рабочего процесса (только код) и определяются
компоненты бизнес-процесса, взаимодействующие с компонентами рабочего
процесса (только код).

При проектировании собственных сервисов описываются или используются
существующие классы Activity для взаимодействия с сервисом, определяется
интерфейс сервиса, поддерживающий необходимые операции, на базе
проверенных практик проектируется сервис и выбирается соответствующий хост
для сервиса (IIS, Workflow Appliance Software (WAS)1 или WorkflowServiceHost (Хост
сервиса рабочего процесса)).

При проектировании разметки рабочего процесса может использоваться дизайнер
Visual Studio (доступный как расширение Visual Studio 2005 и входящий в состав
Visual Studio 2008 и последующих версий) или дизайнер SharePoint Designer для
построения рабочих процессов на базе списков SharePoint. В качестве альтернативы
разметка, связанная с продуктом стороннего производителя, может создаваться в
дизайнере стороннего производителя, или можно вручную написать код разметки,
используя соответствующий синтаксис XAML.
Сервер BizTalk
BizTalk может поддерживать разработку и с разделением кода, и с применением языков
разметки. При использовании BizTalk может понадобиться спроектировать компоненты
рабочего процесса, используемые в оркестровке BizTalk. Примерами таких компонентов
рабочего процесса являются адаптеры и коннекторы. Также может понадобиться создать
сервисы, обеспечивающие операции, необходимые рабочему процессу, или спроектировать
бизнес-компоненты, обрабатывающие запросы для рабочих процессов BizTalk.
BizTalk может использоваться и без написания специальных компонентов, т.е. позволяет
применить разработку с использованием разметки. Иначе говоря, если необходимо выполнять
только простые операции, возможности сервера BizTalk прекрасно подойдут для
преобразования сообщений и описания функций. Далее описывается процесс создания
рабочих процессов с использованием BizTalk:
1

При проектировании компонентов рабочего процесса для BizTalk определяется
класс, реализующий соответствующий интерфейс, и затем этот класс регистрируется
в COM.

При проектировании компонентов бизнес-слоя для BizTalk определяются классы,
поддерживающие необходимые операции. В случае необходимости, в компонентах
бизнес-слоя можно запускать атомарные транзакции, вызываемые оркестровкой.
Бизнес-слой должен проектироваться с использованием проверенных практик для
обеспечения поддержки необходимых операций.

При проектировании специальных сервисов описываются или используются
существующие классы BizTalk для взаимодействия с сервисом, определяется
интерфейс сервиса, поддерживающий необходимые операции; при
проектировании сервиса используются проверенные практики и выбирается
соответствующий хост для его размещения (IIS или WAS).
ПО, содержащее рабочий процесс (прим. переводчика).
На рис. 1 представлена совместная работа всех этих компонентов для обеспечения поддержки
рабочего процесса BizTalk.
Рис. 1
Совместная работа компонентов для поддержки рабочего процесса BizTalk.
BizTalk с ESB
Комплект инструментов Microsoft Enterprise Service Bus (ESB) Toolkit расширяет BizTalk
возможностями для создания подключенных сервисно-ориентированных корпоративных
приложений. Комплект инструментов ESB Toolkit включает компоненты, поддерживающие и
реализующие среду обмена сообщениями, упрощая тем самым построение основанных на
сообщениях корпоративных приложений. Комплект инструментов предоставляет следующие
компоненты:

Веб-сервисы ESB. Обеспечивают основные возможности Microsoft ESB Toolkit.
Предоставляются следующие сервисы:
◦
Маршрутизирующие Веб-сервисы (Itinerary on-ramp Web services),
принимающие внешние сообщения и отсылающие их для дальнейшей
обработки обработки.
◦
Веб-сервис преобразования адресов (Resolver Web service), позволяющий
внешним приложениям вызывать инфраструктуру преобразования адресов
(Resolver Framework) для поиска конечных точек ESB на основании
механизмов разрешения, поддерживаемых инфраструктурой
преобразования адресов, таких как политики бизнес-правил, регистрации
UDDI, статический вызов, интерфейс WS-MetadataExchange (Обмен
метаданными) и на основании содержимого сообщения.
◦
Веб-сервис преобразования (Transformation Web service) обеспечивает
функции для преобразования содержимого сообщения и выполнения
бизнес-требований. Преобразованиям может подвергаться
непосредственно входящее сообщение или сообщения, извлекаемые из
базы данных MessageBox (Хранилище сообщений) BizTalk.
◦
Веб-сервис обработки исключений (Exception Handling Web service)
принимает сообщения об исключениях из внешних источников и публикует
их в Инфраструктуре управления исключениями ESB (ESB Exception
Management Framework). Оттуда конвейер обработки сбоев будет
нормализовать, отслеживать и публиковать сообщение об исключении в
Портале управления ESB (ESB Management Portal).
◦
Веб-сервис UDDI позволяет приложениям и пользователям выполнять поиск
конечных точек по имени сервиса, поставщику услуг или категории деловой
активности; также с его помощью приложения и пользователи могут
управлять поставщиками услуг, сервисами и категориями, хранящимися в
хранилище UDDI.
◦
Веб-сервис обслуживания BizTalk предоставляет сведения о хостах BizTalk,
оркестровке, приложениях и состоянии.

Портал управления ESB. Обеспечивает такие возможности как отслеживание
исключений и сбоев, повторная передача сообщений, предупреждения и
уведомления, интеграция с UDDI, составление отчетов и аналитика, возможности
настройки.

Компоненты конвейера взаимодействий ESB. К ним относятся Сервис обмена
сообщениями Java (Java Messaging Service, JMS) и компоненты пространств имен
для использования в конвейерах BizTalk.

Инфраструктура управления исключениями. Может перехватывать исключения от
подсистем обмена сообщениями и оркестровки BizTalk и формировать сообщения о
сбоях.

Инфраструктура поставщика преобразования адресов и адаптера ESB. Реализует
подключаемую и настраиваемую архитектуру для динамически разрешаемых
конечных точек и трансформаций, а также для маршрутизации сообщений.

Обработка маршрутов. Этот механизм обеспечивает возможность упрощенного
динамического описания, передачи и выполнения множества вызовов сервисов
или маршрутизации/преобразования запросов.

Примеры приложений ESB. Демонстрируют применение комплекта инструментов
Microsoft ESB Toolkit, показывая пути использования предоставляемых им
возможностей в собственных приложениях SOA и ESB.
Совместное использование Windows Workflow Foundation и BizTalk
Во многих ситуациях Windows Workflow Foundation (WF) или BizTalk по отдельности не могут
обеспечить полную поддержку необходимых рабочих процессов. В этом случае в одном
приложении можно использовать необходимые функции обоих решений для рабочих
процессов. Сочетайте WF и BizTalk:

если хотите реализовать с помощью только кода рабочий процесс бизнес-правил с
использованием компонентов WF, взаимодействующий с подсистемой управления
бизнес-правилами BizTalk;

если имеются существующие рабочие процессы WF, которые должны вызываться
из системы оркестровки BizTalk;

при создании рабочего процесса SharePoint, который должен выполнять
оркестровку BizTalk;

если рабочий процесс WF должен интегрироваться с гетерогенными или
устаревшими системами.
Дополнительные источники
Электронная версия списка используемых источников по технологиям проектирования
рабочих процессов доступна по адресу http://www.microsoft.com/architectureguide.

«Introduction to Programming Windows Workflow Foundation» (Введение в
программирование Windows Workflow Foundation) по адресу
http://msdn.microsoft.com/en-us/library/ms734696.aspx

«Microsoft BizTalk ESB Toolkit» (Комплект инструментов Microsoft BizTalk ESB) по
адресу http://msdn.microsoft.com/en-us/library/dd897973.aspx