max404.NET

Развертывание распределенных бизнес-процессов с помощью Windows Workflow Foundation и веб-сервисов

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

Поскольку бизнес-процессы по своей природе распределенные - координируют информацию, которая поступает из многих источников, относящихся к различным подразделениям организации, - имеет смысл развертывать рабочий процесс как распределенное приложение. Чтобы поддерживать такую функциональность, группа разработки Windows Workflow Foundation выбрала веб-сервисы и IIS в качестве хост-платформы, на которой в предварительной версии .NET Framework 3.0 выполняются приложения распределенного рабочего процесса. В ближайшем будущем появится встроенная поддержка Windows Communication Foundation.

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

Сочетание этих двух технологий позволяет представлять бизнес-процессы как веб-сервисы. Благодаря этим технологиям можно создавать макро веб-сервисы, определяющие бизнес-взаимодействия, применять политики «гидратации» и «дегидратации» рабочего процесса (workflow hydration and dehydration policies) для поддержки веб-сервисов, хранящих информацию о состоянии, и обеспечивать мониторинг. Еще одно преимущество - возможность указать, что операцию требуется выполнить по завершении запроса к веб-сервису. Это позволяет продолжать выполнение запроса к веб-сервису без прямого запроса от клиента веб-сервиса в некое заранее определенное время. Эта функциональность позволяет реализовать эскалацию (escalation) и задание периодов ожидания. Кроме того, декларативная природа определения рабочего процесса позволяет реализовать полностью декларативную бизнес-логику.

Я покажу, как реализовать бизнес-процессы, выполняемые длительное время и хранящие информацию о состоянии, с помощью Windows Workflow Foundation и как сделать их доступными в виде веб-сервисов ASP.NET. Хостом для исполняющей среды рабочих процессов служит ASP.NET. Конструкции для планирования заданий, встроенные в Windows Workflow Foundation, позволяют продолжать выполнение длительного рабочего процесса после вызова веб-сервиса. Благодаря этому бизнес-процессы могут уведомлять пользователей о событиях эскалации (escalation events), влияющих на ход выполнения процесса.

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

Операции рабочего процесса

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

Табл. 1. Три операции веб-сервисов

Название операции	Дизайнер операции	Функциональность
WebServiceInputActivity		Предоставляет механизм приема входных данных при вызове метода веб-сервиса
WebServiceOutputActivity		Предоставляет механизм отправки выходных данных как значения, возвращаемого при вызове метода веб-сервиса
WebServiceFaultActivity		Предоставляет механизм отправки информации об ошибках как результата вызова метода веб-сервиса

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

WebServiceFaultActivity служит для возврата сведений об ошибке при вызове метода веб-сервиса. Когда WebServiceInputActivity обрабатывается операцией WebServiceOutputActivity или WebServiceFaultActivity, ее нельзя вызывать повторно, если экземпляр рабочего процесса не переключился обратно на эту операцию. Этого можно добиться с помощью различных циклических конструкций внутри Sequential Workflow или с помощью SetStateActivity внутри State Machine Workflow.

Планирование заданий в рабочем процессе можно осуществлять с помощью операций Delay. Операции Delay регистрируют событие таймера в Scheduler Service, а длительность задается в свойстве TimeSpan DelayActivity. Операция Delay выполняется внутри экземпляра рабочего процесса: выдается запрос к веб-сервису перед поступлением ответа на запрос. Однако ManualWorkflowSchedulerService обрабатывает события таймера в отдельном потоке. Благодаря этому рабочий процесс выполняется независимо от любых запросов к веб-сервисам. После того как DelayActivity обработает событие таймера, рабочий процесс продолжит выполнение с этой точки.


В табл. 2 показаны элементы образца рабочего процесса. Запрос с входными данными для веб-сервиса обрабатывается операцией WebServiceInputActivity. PolicyActivity1 манипулирует вводом веб-сервиса и формирует значение результата. Затем значение результата возвращается операцией WebServiceOutputActivity. Но экземпляр рабочего процесса, прежде чем освободить поток запроса, пытается выполнить как можно больше операций до тех пор, пока не перейдет в состояние простоя. После перехода в состояние простоя рабочий процесс освободит поток запроса к веб-сервису. В дальнейшем, когда будет сгенерировано событие таймера, DelayActivity обработает событие в отдельном потоке и продолжит выполнение PolicyActivity2. Отдельный поток - это поток общеязыковой исполняющей среды (CLR), который создается и управляется ManualWorkflowSchedulerService. Благодаря PolicyActivity рабочий процесс может выполнять код и в то же время поддерживать полностью декларативные решения. Это позволяет выразить всю бизнес-логику веб-сервисов, используя декларативный подход.

Табл. 2. Пример модели рабочего потока веб-сервиса
Определение рабочего процесса

Контракт интерфейса

using System;
using System.Collections.Generic;
using System.Text;

namespace WorkflowLibrary1
{
    interface Interface1
    {
        string Salutation(string str);
    }
} 

Конфигурация
WebServiceInputActivity принимает параметр str, определенный в методе Salutation и связанный в рабочем процессе со свойством Hello

Возвращаемое значение метода Salutation моделируется операцией WebServiceOutputActivity и связано в рабочем процессе со свойством HelloReturn

Исполняющая среда сервисов

Последний этап, который идет после создания операций веб-сервисов для рабочего процесса, - публикация решения. При публикации создается виртуальный каталог, который используется IIS, чтобы развернуть решение как веб-сервис. На внутреннем уровне библиотека рабочего процесса обернута классом WorkflowWebService. Этот класс передает запросы к веб-сервисам, получаемые из SOAP-запроса, внутреннему механизму взаимодействия исполняющей среды рабочего процесса. Этот класс также создает WorkflowRuntime. Система создает WorkflowRuntime только при самом первом запросе к веб-сервису. Когда класс WorkflowWebService создает экземпляр исполняющей среды рабочего процесса, он кешируется и используется при будущих вызовах веб-сервиса. Публикация рабочего процесса как веб-сервиса позволяет серверу IIS играть роль внешнего приложения, которое служит хостом для рабочего процесса.

По умолчанию при публикации веб-сервиса исполняющая среда рабочего процесса настроена на использование ManualWorkflowSchedulerService, который выполняет экземпляр рабочего процесса в потоке запроса к веб-сервису. Чтобы планировщик мог создать поток, который обрабатывает события таймера, и таким образом обеспечить корректную работу операций Delay, необходимо изменить эту конфигурацию. Для этого добавляют флаг UseActiveTimers, которому присваивают значение true. Если этого не сделать, события таймера не будут обрабатываться, пока экземпляр рабочего процесса не получит следующий запрос к веб-сервису. Требуется внести изменение в файл web.config, создаваемый при публикации веб-сервиса:

<add type="System.Workflow.Runtime.Hosting.
               ManualWorkflowSchedulerService,
           System.Workflow.Runtime, Version=3.0.0.0,
           Culture=neutral, PublicKeyToken=31bf3856ad364e35"
     UseActiveTimers="true"/>

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

<add type="System.Workflow.Runtime.Hosting.
    SqlWorkflowPersistenceService, System.Workflow.Runtime,
    Version=3.0.0.0, Culture=neutral,
    PublicKeyToken=31bf3856ad364e35"
    ConnectionString="Initial Catalog=ASPPersistence;Data
        Source=localhost;Integrated Security=SSPI;"
    UnloadOnIdle="true" />

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

Более сложные бизнес-процессы требуют применения более одной WebServiceInputActivity - столько, сколько точек взаимодействия нужно для выполнения процесса. Чтобы клиентские приложения веб-сервиса имели возможность взаимодействовать с одним и тем же экземпляром рабочего процесса, предоставляется HTTP-модуль. Этот HTTP-модуль автоматически добавляется при выполнении стандартной операции по публикации веб-сервисов и помещается в файл web.config. Чтобы сделать возможным повторный вход в экземпляр рабочего процесса, HTTP-модуль записывает идентификатор экземпляра рабочего процесса в клиентский cookie - WF_WorkflowInstanceId (или считывает идентификатор из него). После получения экземпляра рабочего процесса из cookie HTTP-модуль помещает идентификатор в текущий HTTP Context с ключом __WorkflowInstanceId__. Если клиентскому приложению требуется выполнить несколько вызовов веб-сервисов одного и того же экземпляра рабочего процесса, а активизировать cookie невозможно, имеется еще один подход - использовать обработчики HTTP- или SOAP-заголовков, которые должен реализовать программист.

Кроме того, поддержка многопользовательского доступа требует, чтобы была возможность ограничивать взаимодействие с веб-сервисами для определенных ролей. Для этого исполняющая среда Windows Workflow Foundation использует модель провайдера ролей ASP.NET. Она позволяет установить для WebServiceInputActivity ограничения на прием информации от пользователей с определенной ролью. Чтобы настроить провайдер ролей ASP.NET, добавьте в файл web.config строки, показанные в листинге 1. Они указывают, что веб-сервис должен использовать SQL-провайдер ролей, работающий с базой данных aspnetdb.

Листинг 1. Провайдер ролей, добавленный в файл Web.config

<connectionStrings>
  <add name="SqlServerConnection"
    connectionString="Integrated Security =
      SSPI;server=.;database=aspnetdb" />
</connectionStrings>
<system.web>
  <roleManager enabled="true" defaultProvider="SqlProvider">
    <providers>
      <add name="SqlProvider"
          connectionStringName="SqlServerConnection"
        applicationName="ConsoleAppSample"
        type="System.Web.Security.SqlRoleProvider, System.Web,
        Version=2.0.3600.0, Culture=neutral,
        PublicKeyToken=b03f5f7f11d50a3a" />
    </providers>
  </roleManager>
</system.web>

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

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

Первый этап - определить бизнес-процесс, в рамках которого будут передаваться отчеты о расходах. В этой модели будут использоваться операции ввода и вывода веб-сервиса, чтобы определить точки взаимодействия между клиентским приложением и бизнес-процессом. В результате моделирования процесса утверждения расходов получается рабочий процесс Windows Workflow Foundation, показанный на рис. 1.

Рис. 1. Модель рабочего процесса проверки отчетов о расходах

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

Табл. 3. Контракт метода CreateExpenseReportId

String CreateExpenseReportld();

Заметьте: в определении метода CreateExpenseReportId нет никаких входных параметров, зато имеется возвращаемое значение. Значит, у WebServiceInputActivity CreateExRInput нет никаких параметров, а у WebServiceOutputActivity CreateExROutput есть свойство ReturnValue, сопоставленное возвращаемому строковому значению. PolicyActivity1 должна создавать идентификатор отчета о расходах и присваивать ему значение, которое возвращается как часть WebServiceOutputActivity CreateExROutput.

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

Табл. 4. Контракт метода SubmitExpenseReport

void SubmitExpenseReport(ExpenseReport expenseReport)

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

После передачи отчета о расходах рабочий процесс входит в цикл утверждения. При реализации цикла используется WhileActivity с условием DeclarativeCondition, которое проверяет, установлен ли флаг, указывающий, что отчет проанализирован. Этот флаг устанавливается, когда менеджер утвердил или отверг отчет о расходах. ListenActivity находится внутри WhileActivity; ListenActivity содержит точку взаимодействия, в которой запрашивается информация из отчета о расходах, путь эскалации и точки взаимодействия для утверждения или отклонения. Путь эскалации задает с помощью DelayActivity максимальное время, в течение которого менеджер должен проанализировать отчет. Если он не успевает это сделать, менеджеру направляется электронное сообщение через PolicyActivity2. Событие Timer - внутреннее сообщение, поэтому его не нужно определять в контракте веб-сервиса.

Точка взаимодействия для запроса реализована парой операций ввода и вывода веб-сервисов. WebServiceInputActivity ReviewExRInput принимает запрос к веб-сервису, а WebServiceOutputActivity возвращает переданный отчет о расходах клиентскому приложению. Поскольку это простой запрос состояния рабочего процесса, нет необходимости выполнять какую-либо обработку между этими двумя операциями (табл. 5).

Табл. 5. Контракт метода RetrieveExpenseReport

ExpenseReport RetrieveExpenseReport();

Последние две точки взаимодействия, содержащиеся внутри ListenActivity, - операции утверждения и отклонения. Эти два события не требуют какого-либо уведомления клиента. При их вызове не ожидается возврата какого-либо значения. Назначение этих операций - установить статус отчета о расходах и установить флаг «проанализирован», который сравнивается с false операцией WhileActivity. Присваивание значений этим переменным осуществляется в PolicyActivity3 и PolicyActivity4 (табл. 6).

Табл. 6. Контракты методов RejectExpenseReport и ApproveExpenseReport

void RejectExpenseReport();

void ApproveExpenseReport();

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

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

Windows Communication Foundation

Я рассказал о реализации веб-сервисов с применением ASMX-технологий, поддерживаемых операциями Windows Workflow Foundation. Первая версия Windows Workflow Foundation напрямую не предоставляла никакие операции или хосты для развертывания более новых сервисов Windows Communication Foundation; эта функциональность будет поддерживаться более новыми версиями инфраструктуры. Однако есть несколько способов, позволяющих уже сейчас использовать Windows Communication Foundation при работе с Windows Workflow Foundation:

• разработать сервис Windows Communication Foundation, который служит хостом для исполняющей среды рабочего процесса и выполняет экземпляр рабочего процесса;
• обратиться к сервису Windows Communication Foundation из определения рабочего процесса через InvokeWebServicesActivity;
• обратиться к сервису Windows Communication Foundation через собственную Activity.

Первый подход позволяет разработчикам использовать Windows Communication Foundation как хост-процесс для исполняющей среды рабочего процесса. Этот сервис должен инициировать выполнение рабочего процесса, когда вызывается заранее определенный OperationContract. Такой подход обеспечивает, что рабочий процесс будет принимать ввод из OperationContract как параметры. В листинге 2 приведен пример того, как мог бы выглядеть этот OperationContract.

Листинг 2. Создание экземпляра рабочего процесса

[ServiceContract]
class WorkflowApplication
{
  WorkflowCommunicationHandler internalWFCommunications;
  Guid workflowInstanceId;
  WorkflowRuntime workflowRuntime;

  [OperationContract]
  public void BeginWorkflowApplication(string inputVariable)
  {
    workflowRuntime = new WorkflowRuntime();
    internalWFCommunications = new WorkflowCommunicationHandler();
    string connectionString = "Initial Catalog=WorkflowPersistence;" +
      "Data Source=localhost;Integrated Security=SSPI;";
    workflowRuntime.AddService(
      new SqlWorkflowPersistenceService(connectionString, true,
      new TimeSpan(0, 10, 0), new TimeSpan(0, 0, 5)));

    ExternalDataExchangeService externalDataService =
      new ExternalDataExchangeService();
    workflowRuntime.AddService(externalDataService);
    externalDataService.AddService(internalWFCommunications);

    workflowRuntime.StartRuntime();

    Dictionary<string, object> inputParams =
      new Dictionary<string, object>();
    Type type = typeof(Workflow1);
    workflowInstanceId = Guid.NewGuid();

    inputParams["inputVariable"] = inputVariable;
    WorkflowInstance workflowInstance =
      Program.workflowRuntime.CreateWorkflow(type, inputParams,
      workflowInstanceId);

    workflowInstance.Start();
  }
}

Чтобы Windows Communication Foundation позволяла осуществлять непрерывное взаимодействие с экземпляром рабочего процесса, можно предоставить другие точки взаимодействия как дополнительные экземпляры OperationContract. Параметры OperationContract передаются рабочему процессу в событии взаимодействия с рабочим процессом. Вот дополнительный OperationContract для ServiceContract, показанного в листинге 2:

[OperationContract]
public void SendDataToWorkflowApplication(
  Guid workflowInstanceId, string inputVariable)
{
  WorkflowInstance workflowInstance =
    workflowRuntime.GetWorkflow(workflowInstanceId);
  internalWFCommunications.SendRequest(workflowInstance, inputVariable);
}

Второй подход - вызывать сервис Windows Communication Foundation, используя InvokeWebServicesActivity, - возможен благодаря тому, что Windows Communication Foundation поддерживает SOAP. К сожалению, этот подход неприменим к сервисам WS-*, поддерживаемым Windows Communication Foundation. Лучше выбрать третий подход - создать операцию Windows Workflow Foundation, внутренний метод выполнения которой вызывает сервис Windows Communication Foundation (WCF) через ServiceProxy для WCF:

protected override ActivityExecutionStatus Execute(
  ActivityExecutionContext executionContext)
{
  RentalReservationsProxy p = new RentalReservationsProxy();
  this.ResultValue = p.MakeReservation(this.InputValue);
  p.Close();
  return base.Execute(executionContext);
}

При выполнении этой операции свойство InputValue передается классу RentalReservationsProxy. Используя этот прокси, операция вызывает OperationContract MakeReservation, содержащийся в сервисе RentalReservationProxy, и возвращает прокси-класс, который является абстрактным представлением WCF-сервиса WorkflowApplication. При вызове MakeReservation свойство InputValue операции передается в качестве входного параметра, а возвращаемое значение присваивается свойству ResultValue.

Совместное использование Windows Communication Foundation и Windows Workflow Foundation позволяет обеспечить, чтобы удаленные клиенты могли обращаться к рабочему процессу как к WCF-сервису и вызывать WCF-сервисы через операции.

Заключение

Вы можете применять мощную декларативную модель Windows Workflow Foundation для обеспечения доступа к бизнес-процессам и в то же время использовать веб-сервисы при выполнении бизнес-процессов как технологию развертывания. Кроме того, Windows Communication Foundation и Windows Workflow Foundation можно применять для публикации надежных бизнес-приложений, совместимых с WS-*. Чтобы глубже ознакомиться с Windows Workflow Foundation и разработкой рабочих процессов для .NET Framework 3.0, см. сайт Windows Workflow Foundation (EN). Информацию по разработке для Windows Communication Foundation см. по ссылке (EN).