Введение
Используя WWF, вы можете создавать рабочие процессы на основе Processor Flow и развертывать их в приложениях .NET любого типа. Кроме того, в этой статье обсуждаются некоторые уникальные проблемы, с которыми сталкиваются разработчики ASP.NET — проблемы, которые можно решить с помощью рабочих процессов, таких как поддержание состояния и навигация по страницам.
В сентябре 2005 года Microsoft представила Windows Workflow Foundation (WWF, Windows Workflow Foundation) на своей проводимой два раза в год конференции профессиональных разработчиков. Являясь одним из столпов WinFX API, WWF предоставляет разработчикам общую структуру для разработки приложений, ориентированных на процессы и рабочие процессы.
В настоящее время некоторые организации пытаются автоматизировать целые бизнес-процессы; их стандартный ответ — собрать команду разработчиков для разработки соответствующего кода. Хотя этот подход хорошо работает для этих организаций, существуют некоторые присущие ему проблемы. Чтобы глубже разобраться в этом вопросе, вам необходимо понять основные характеристики рабочего процесса.
Рабочий процесс — это, по сути, метод архивирования действий, связанных с выполнением единицы работы. Обычно во время обработки работа «протекает» через одно или несколько действий. Эти действия могут выполняться машинами или людьми и могут быть такими простыми, как определение порядка страниц в интернет-приложении, или такими сложными, как управление документом или продуктом, который должен быть просмотрен, изменен и одобрен любым количеством людей. сложный.
Поскольку многие рабочие процессы должны предусматривать участие человека, их выполнение может занять много времени: от нескольких часов до месяцев или дольше. Например, люди, участвующие в процессе, могут быть недоступны, не локальны или заняты другими задачами, поэтому рабочий процесс должен иметь возможность сохраняться в течение всех периодов бездействия; Более того, процессы, реализованные независимо посредством программирования, могут быть трудными для понимания нетехническими людьми и трудными для изменения разработчиками. Этот и другие факторы как раз и являются целью общих сред рабочих процессов, таких как Windows WF, цель которых — упростить создание, изменение и управление рабочими процессами — либо путем предоставления им визуального интерфейса, либо путем определения общего набора реализованных API.
Рабочие процессы WWF можно разместить в приложениях .NET любого типа, включая Windows Forms, консольные приложения, службы Windows и веб-приложения ASP.NET. Каждый тип требует специального рассмотрения. Хотя некоторых существующих примеров достаточно, чтобы проиллюстрировать, как размещать рабочие процессы в Windows Forms и консольных приложениях, в этой статье основное внимание будет уделено проблемам, с которыми сталкиваются разработчики ASP.NET, желающие интегрировать рабочие процессы в свои собственные приложения.
Примечание автора. Код, представленный в этой статье, был создан с использованием Windows WF Beta 1 и Visual Studio 2005 Beta 2. Информацию об установке Windows WF можно найти на сайте www.windowsworkflow.net . Хотя в этой статье обсуждаются некоторые основы Windows WF, в этой области доступны и другие ресурсы. Я предполагаю, что читатель хоть немного знает о Windows WF. Целью этой статьи является глубокий анализ Windows WF и ASP.NET, а не обсуждение Windows WF на высоком уровне.
1. Шаблоны WF и MVC для Windows.
При разработке приложения ASP.NET стандартным способом использования WWF является реализация подхода «модель-представление-контроллер» (MVC). По сути, цель MVC — разделить уровень представления, логику приложения и логику потока приложения.
Понимание этого будет очень полезно при разработке приложения ASP.NET. Пожалуйста, рассмотрите место для обработки заявок в службе поддержки. Предположим, что бизнес-пользователь инициирует этот рабочий процесс, заполнив веб-форму ASP.NET и нажав кнопку отправки. Затем сервер уведомляет сотрудника с помощью приложения Windows Forms и службы поддержки о том, что «доступен новый билет». Затем сотрудник службы поддержки обработает проблему и, наконец, закроет заявку. Если вы используете Windows WF для разработки этого сценария рабочего процесса, то вся логика и поток обработки могут содержаться в самом рабочем процессе, и приложению ASP.NET вообще не потребуется понимать эту логику.
Подобные площадки дают убедительные доказательства: отделение описания от логики — это хорошо. Поскольку этот процесс обработки запросов в службу поддержки настолько обыденен, если вы используете код C# или VB.NET для реализации этой логики в нескольких разных приложениях .NET, вы рискуете дублировать код или, что еще хуже, использовать совершенно разные коды. к различным реализациям одного и того же бизнес-процесса. Но если вы используете WWF для реализации этого процесса, разработчикам приложений, которым требуется этот процесс, нужно будет изменять шаги только в одном месте — самом рабочем процессе — без необходимости беспокоиться об изменении логики приложения. Дублирование кода и реализацию этого процесса можно упростить с помощью Windows WF.
При реализации архитектуры MVC в ASP.NET с использованием Windows WF разработчикам следует попытаться создать рабочие процессы, независимые от приложения, пока рабочий процесс все еще размещается внутри приложения. Это поможет сохранить независимость логики от описания и сохранить высокую степень независимости между последовательностью рабочих шагов и потоком страниц в веб-приложении.
Новый разработчик WWF может попытаться разработать рабочий процесс с фиксированным количеством действий в определенном порядке, а затем разработать набор веб-форм ASP.NET, которые перетекают из одной формы в другую в том же порядке. К сожалению, хотя это кажется логичным, на самом деле это очень непродуктивно, поскольку вам придется заново реализовывать логику рабочего процесса. Веб-странице X не нужно знать, нужно ли ей перейти на страницу Y или страницу Z, чтобы правильно реализовать этот шаг рабочего процесса. Вместо этого рабочий процесс (модель) должен сообщить ASP.NET (контроллеру), что делать дальше; затем ASP.NET должен решить, какую страницу отображать; Таким образом, каждой странице едва ли нужно понимать весь процесс; ей просто нужно знать, как выполнить другое действие, и позволить рабочему процессу позаботиться о том, как страница перемещается из одного места в другое. Такое разделение дает разработчикам большую гибкость при работе с потоком страниц. Например, если вы решите изменить порядок отображения страниц, вы можете легко сделать это изнутри рабочего процесса, не меняя ни единой строки кода в приложении ASP.NET.
2. Пример простого рабочего процесса MVC
Чтобы проиллюстрировать эту идею, я покажу вам простое приложение и рабочий процесс ASP.NET. Этот упрощенный рабочий процесс описывает процесс, который собирает некоторую личную информацию из внешнего приложения и затем отображает ее. Шаги следующие:
1. Вызов метода — это означает запрос имени человека. В этом рабочем процессе используется действие InvokeMethod (см. рисунок 1).
2. Подождите, пока не будет запущено событие — это означает получение имени на этом этапе, рабочий процесс использует действие EventSink;
3. Получите адрес электронной почты от хоста, используя аналогичный вызов.
4. Ожидание события означает получение адреса.
5. После получения имени и адреса электронной почты рабочий процесс запускает действие InvokeMethod для отправки личной информации вызывающему приложению. В реальной ситуации этот последний шаг не очень важен. Скорее всего, вы вызовете веб-службу для отправки данных в другую систему или поместите их в базу данных.
Рисунок 1. Пример рабочего процесса. Этот рабочий процесс описывает процесс, неявно присутствующий в примере приложения ASP.NET.
Чтобы реализовать этот рабочий процесс в ASP.NET, вам понадобится страница для сбора имен людей, страница для сбора адресов электронной почты и страница для отображения личных данных. Помните, что форма входа в систему не должна иметь представления о том, что произошло до или после нее. То же самое касается страниц отображения. Однако приложение ASP.NET должно знать, какую страницу отображать пользователю. Это цель введения контроллеров; В этом примере для реализации решения используется обработчик HTTP. Этот пользовательский обработчик, называемый WorkflowController, отвечает за следующие задачи:
· Получение ссылки на время выполнения рабочего процесса.
· Получите ссылку на существующий экземпляр рабочего процесса или запустите новый экземпляр рабочего процесса (это зависит от того, был ли запущен экземпляр рабочего процесса).
·Установить связь между диспетчером и рабочим процессом.
· Обрабатывать события из этого рабочего процесса.
· Сообщите ASP.NET, какую страницу необходимо отобразить, в зависимости от того, какой уровень рабочего процесса выполняется в данный момент.
Как вы видели, этот пользовательский обработчик по существу выполняет всю работу, связанную с WWF и управлением страницами, сохраняя отдельные страницы ASP.NET «тихими» о действиях, происходящих в фоновом режиме. Единственное, о чем должна беспокоиться веб-форма, — это выполнение конкретной задачи и передача необходимых данных контроллеру.
По умолчанию WWF работает в асинхронной модели. Это означает, что когда хост приложения запускает экземпляр рабочего процесса, управление немедленно возвращается хосту, в то время как рабочий процесс продолжает выполняться в другом потоке. Это может быть полезно в приложении Windows Forms, где крайне желательно постоянное реагирование пользовательского интерфейса. Используя эту асинхронную модель, рабочий процесс может выполняться в фоновом режиме, в то время как пользователь может продолжать работать с приложением. Однако в веб-приложении такого поведения ожидать нельзя, поскольку управление обычно возвращается пользователю только после того, как сервер завершил единицу работы. Это как раз воплощение масштабируемости Windows WF. В Windows WF разработчики могут использовать или создавать «службы времени выполнения» для мониторинга и даже изменения среды выполнения рабочего процесса. Примеры:
· Служба сохранения состояния — сохраняет состояние рабочего процесса между выполнением и временем простоя.
· Служба трассировки — выводит информацию о выполнении рабочего процесса на некоторые носители.
· Служба транзакций — помогает поддерживать целостность данных во время выполнения рабочего процесса.
Кроме того, службы потоковой обработки позволяют разработчикам контролировать работу экземпляров рабочего процесса. выполняются. Как обсуждалось ранее, среда выполнения рабочего процесса по умолчанию запускает экземпляр асинхронно в потоке, независимом от хоста. Но поскольку это, скорее всего, не то, что ожидает ASP.NET, вам придется поменять службу потоков рабочего процесса по умолчанию. К счастью, Microsoft предоставила решение для этой проблемы — ASPNetThreadingService. Чтобы реализовать это изменение, вы можете либо добавить ASPNetThreadingService в службу среды выполнения рабочего процесса, написав код вручную, либо выполнить эту задачу в файле web.config. Пример приложения в этой статье использует режим конфигурации. В разделе runtime/services рабочего процесса файла web.config (см. листинг 1) добавьте строку, подобную следующей:
<add type=
"System.Workflow.Runtime.Hosting.ASPNetThreadingService,
System.Workflow.Runtime, Версия=3.0.00000.0,
Культура=нейтрально, PublicKeyToken=31bf3856ad364e35"/>
3. Реализация логики контроллера
Далее вам необходимо реализовать логику контроллера с помощью HTTP-процессора. Чтобы создать этот контроллер, все, что вам нужно сделать, это создать класс под названием обработчик WorkflowController, который реализует интерфейс обработчика IHttp. До сих пор вы не видели ничего особенного в Windows WF — это особенность, специфичная для ASP.NET (читайте дальше).
В этом классе процессора WorkflowController метод интерфейса процессора IHttp с именем ProcessRequest обрабатывает веб-запрос от приложения ASP.NET. Здесь вам необходимо получить ссылку на статический экземпляр среды выполнения рабочего процесса, создать обработчики событий для рабочего процесса и инициировать выполнение рабочего процесса. Перед запуском экземпляра рабочего процесса необходимо проверить, содержит ли значение строки запроса GUID, который представляет идентификатор экземпляра рабочего процесса. Если этот идентификатор присутствует, вы знаете, что экземпляр уже запущен, поэтому вы можете получить ссылку на этот экземпляр и продолжить выполнение. Если этот идентификатор не существует, вам необходимо создать новый экземпляр и запустить процесс выполнения, вызвав метод Start Workflow во время выполнения рабочего процесса.
После запуска экземпляра обработчики событий управляют взаимодействием внутри и снаружи рабочего процесса. Поскольку целью данной статьи не является обсуждение локальных коммуникационных сервисов, я не буду подробно обсуждать здесь эту тему, а проанализирую методы ее высокоуровневой реализации и еще раз обсужу, как это работает в приложении ASP.NET. Чтобы облегчить обработку связи, вам понадобится несколько интерфейсов .NET, используемых для описания информации в рабочем процессе и хосте и за его пределами. Вы найдете их в исходном коде проекта WorkflowClassLibrary, прикрепленном к этой статье. Вы также найдете классы, реализующие эти интерфейсы и соответствующие функциональные возможности, необходимые для реализации механизма рабочего процесса.
Давайте еще раз кратко рассмотрим файл web.config. Обратите внимание, что рядом с элементом ASPNetThreadingService, обсуждавшимся ранее, мы использовали три элемента для описания класса службы связи:
<add type="Workflow.RuntimeServices.GetNameService,
Workflow.Library, Версия=1.0.0.0, Культура=нейтральная,
PublicKeyToken=c4620ae819b5257e"/>
＜add type="Workflow.RuntimeServices.GetEmailService,
Workflow.Library, Версия=1.0.0.0, Культура=нейтральная,
PublicKeyToken=c4620ae819b5257e"/>
＜add type="Workflow.RuntimeServices.SendDataService,
Workflow.Library, Версия=1.0.0.0, Культура=нейтральная,
PublicKeyToken=c4620ae819b5257e"/>
Здесь также есть элемент, который указывает библиотеке времени выполнения рабочих процессов использовать SqlStatePersistenceService. Эта дополнительная служба сохраняет постоянство состояния рабочего процесса в базе данных SQL-сервера между запросами страниц. Эту базу данных необходимо создать вручную в заранее, но Microsoft предоставляет для этого сценарий SQL. Вы найдете его в папке C:WINDOWSMicrosoft.NETFrameworkv2.0.50215Windows Workflow FoundationSQL. Как и службы моделей, эти службы можно добавлять программно. , но вы также можете реализовать его в конфигурации, что значительно сократит объем кода для написания и обеспечит гибкость — даже после того, как код создан. В конфигурации есть строка, которая добавляет HttpModule, который поддерживает среду выполнения Windows WF. библиотека в ASP.NET также есть строка, которая устанавливает контроллер-обработчик Http, о котором говорилось ранее. Как вы можете видеть в этой конфигурации, в ней есть много вещей.
В заключение, Windows WF предоставляет чрезвычайно простой в использовании и. расширяемая среда, позволяющая разработчикам разрабатывать приложения, основанные на рабочих процессах. Оно стало и будет оставаться важной технологией. Если вы не являетесь компанией, предоставляющей технологические услуги, или независимым поставщиком программного обеспечения, программное обеспечение должно обеспечивать бизнес-процессы и операционные процессы, такие как Windows WF. , разработчики могут сделать процесс разработки простым и гибким.
