Огляд робочого потоку Windows Workflow. Частина 6, Різне, Програмування, статті

Читати частина 5


Користувальницькі служби


На додаток до вбудованим службам, таким як служба сталості та служба відстеження, ви також можете додавати свої власні об’єкти в колекцію служб, підтримувану WorkflowRuntime. Ці служби зазвичай визначаються із застосуванням інтерфейсу і реалізації, так що ви можете легко замінити одну службу іншої, не перекодіруя робочий потік.


Раніше представлений в цьому розділі кінцевий автомат використовує наступний інтерфейс:





[ExternalDataExchange]
public interface IDoorService
{
void LockDoor();
void UnlockDoor();
event EventHandler<ExternalDataEventArgs> RequestEntry;
event EventHandler<ExternalDataEventArgs> OpenDoor;
event EventHandler<ExternalDataEventArgs> CloseDoor;
event EventHandler<ExternalDataEventArgs> FireAlarm;
void OnRequestEntry(Guid id);
void OnOpenDoor(Guid id);
void OnCloseDoor(Guid id);
void OnFireAlarm();
}

Інтерфейс складається з методів, що використовуються робочим потоком для виклику служби, та подій, ініційованих службою, яка використовується робочим потоком. Застосування атрибуту ExternalDataExchange вказує на те, що виконуюча середу робочого потоку використовується для комунікацій між працюючим потоком і реалізацією служби.


Усередині кінцевого автомата присутній ряд примірників CallExternalMethodActivity, що використовуються для виклику методів цього зовнішнього інтерфейсу. Один приклад – коли двері закривається і відмикається. Робочий потік при цьому повинен викликати метод UnlockDoor або LockDoor, і служба реагує на це посилкою відповідної команди дверному замку.


Коли служба потребує у взаємодії з робочим потоком, то робить це через події; виконуюча середу робочих потоків також включає службу на ім’я ExternalDataExchangeService, яка служить проксі для таких подій. Цей проксі використовується при порушенні події, але оскільки робочий потік може і не бути завантаженим в пам’ять на момент доставки події, ця подія спочатку маршрутізіруєтся зовнішньої службі обміну, яка перевіряє, завантажений чи робочий потік, і якщо ні, то відновлює його з постійного сховища і потім передає подія в цей робочий потік.


Код, який застосовується для конструювання ExternalDataExchangeService і проксі для подій, визначених в службі, показаний нижче:





WorkflowRuntime runtime = new WorkflowRuntime();
ExternalDataExchangeService edes = new ExternalDataExchangeService();
runtime.AddService(edes);
DoorService service = new DoorService();
edes.AddService(service);

Це конструює примірник зовнішньої служби обміну, додає його в виконуючу середу, потім створює екземпляр DoorService (реалізує IDoorService) і додає його в зовнішнє службу обміну даними.


Метод ExternalDataExchangeService.Add конструює проксі для кожної події, визначеного користувальницької службою, так що збережений робочий потік може бути завантажений до того, як буде доставлено подія. Якщо ви не ставите службу всередину зовнішньої служби обміну даними, то коли ви станете ініціювати події, ніхто не буде їх прослуховувати, тому вони не будуть доставлені відповідному робочому потоку.


Події використовують клас ExternalDataEventArgs, оскільки він включає ідентифікатор екземпляра робочого потоку, якому має бути доставлено подія. Якщо існують і інші значення, які потрібно передати з зовнішнього події в робочий потік, то ви повинні успадкувати клас від ExternalDataEventArgs і додати необхідні значення у вигляді властивостей в цей клас.


Хостинг робочих потоків


Код для хостингу WorkflowRuntime в процесі буде змінюватись в залежності від самого додатка.


Для додатків Windows Forms або Windows Service (служб Windows), типовим є конструювання виконуючого середовища при запуску програми і збереження її як властивості головного класу додатку.


У відповідь на деякий введення в додатку (наприклад, клацання користувача на кнопці користувальницького інтерфейсу) ви можете потім сконструювати примірник робочого потоку і запустити цей екземпляр локально. Робітникові потоку може знадобитися взаємодію з користувачем, тому, наприклад, ви можете визначити зовнішню службу, яка запросить користувача підтвердження, перш ніж відправить запит серверу заднього плану.


При хостингу робочих потоків в ASP.NET зазвичай ви не будете попереджати користувача через вікно повідомлення, а замість цього виконайте перехід на іншу сторінку сайту, яка спочатку зажадає підтвердження і потім надасть відповідну сторінку підтвердження. При розгортанні виконуючого середовища усередині ASP.NET прийнято перевизначати подія Application_Start і конструювати в ньому примірник виконуючою середовища робочого потоку, який буде доступний всім іншим частинам сайту. Ви можете зберегти екземпляр виконуючого середовища в статичному властивості, але краще зберегти його в стані програми та передбачити метод для доступу, який буде витягувати виконуючу середу зі стану додатки, щоб її можна було використовувати в будь-якому місці програми.


При будь-якому сценарії – Windows Forms або ASP.NET – ви будете конструювати примірник виконуючого середовища робочого потоку і додавати служби так, як показано нижче.





WorkflowRuntime workflowRuntime = new WorkflowRuntime();
workflowRuntime.AddService(
new SqlWorkflowPersistenceService(conn, true, new TimeSpan(1,0,0),
new TimeSpan(0,10,0))); / / Тут виконати робочий потік …

Для виконання робочого потоку знадобиться створити екземпляр цього робочого потоку, викликавши для цього метод CreateInstance виконуючого середовища. У цього методу є ряд перевантажень, які можна застосовувати для конструювання примірника робочого потоку на основі коду або робочого потоку, визначеного за допомогою XML.


Аж до цього місця цієї глави ви розглядали робочі потоки як класи. NET – і справді це одне подання робочого потоку. Однак ви можете визначити робочий потік, використовуючи для цього XML, а виконуюча середу створить його подання в пам’яті і потім виконає його, коли ви викличете метод Start з WorkflowInstance.


Всередині Visual Studioви можете створити робочий потік на базі XML, вибравши елемент Sequential Workflow (with code separation) (Послідовний робочий потік (з поділом коду)) або State Machine Workflow (with code separation) (Робочий потік у вигляді кінцевого автомата (з поділом коду)) в діалоговому вікні Add New Item (Додати новий елемент). Це створить XML-файл з розширенням. Xoml і завантажить його в конструктор.


У міру додавання дій в конструкторі вони будуть відображатися в XML, і структура елементів визначить відносини “батьківський-дочірній” між діями. Наведений нижче XML демонструє простий послідовний робочий потік, що містить IfElseAcvtivity і два кодових дії, по одному на кожну гілку IfElseAcvtivity.





<SequentialWorkflowActivity x:Class=”DoorsWorkflow.Workflow1″ x:
Name=”Workflow1″
xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”
xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/workflow”>
<IfElseActivity x:Name=”ifElseActivity1″>
<IfElseBranchActivity x:Name=”ifElseBranchActivity1″>
<IfElseBranchActivity.Condition>
<CodeCondition Condition=”Test” />
</IfElseBranchActivity.Condition>
<CodeActivity x:Name=”codeActivity1″ ExecuteCode=”DoSomething” />
</IfElseBranchActivity>
<IfElseBranchActivity x:Name=”ifElseBranchActivity2″>
<CodeActivity x:Name=”codeActivity2″ ExecuteCode=”DoSomethingElse” />
</IfElseBranchActivity>
</IfElseActivity>
</SequentialWorkflowActivity>

Властивості, визначені в діях, зберігаються в XML у вигляді атрибутів, а кожна дія зберігається як елемент. У XML нескладно помітити, що відношення між батьківськими діями (такими як SequentialWorkflowActivity і IfElseActivity) і дочірніми діями визначається структурою.


Виконання робочого потоку на основі XML ніяк не відрізняється від виконання робочого потоку, описаного в коді – ви просто використовуєте перевантаження методу CreateWorkflow, що приймає примірник XmlReader, і потім запускаєте цей екземпляр, викликаючи метод Start.


Одна перевага робочих потоків на основі XML перед робітниками потоками на основі коду полягає в тому, що ви легко можете зберегти його визначення в базі даних. Ви можете завантажити цей XML під час виконання та запустити робочий потік; крім того, дуже легко вносити зміни у визначення робочого потоку без необхідності перекомпіляції якогось коду.


Зміна робочого потоку під час виконання підтримується незалежно від того, чи визначено він в XML або в коді. Ви просто конструюєте об’єкт WorkflowChanges, що містить всі нові дії, які потрібно додати до робочого потоку, і потім викликаєте метод ApplyWorkflowChanges, визначений в класі WorkflowInstance, для фіксації цих змін. Це виключно зручно, оскільки бізнес-правила часто змінюються і, наприклад, вам може знадобитися застосувати зміни до робочого потоку політики страхування, щоб клієнтові відправлялося електронного листа з відповідним повідомленням за місяць до настання дати змін. Зміни вносяться на рівні примірника, тому якщо у вас є 100 таких робочих потоків політики в системі, вам доведеться внести зміни в кожен з них.


Конструктор Workflow Designer


І на завершення цієї глави розглянемо найцікавіше. Конструктор Workflow Designer, який ви використовуєте для проектування робочих потоків, не прив’язаний до Visual Studio. При необхідності ви можете розгорнути його в середовищі свого власного додатка.


Це означає, що ви можете поставляти систему, що включає робочі потоки, і дозволити користувачам налаштовувати її під свої потреби, без необхідності придбання копії Visual Studio. Розгортання конструктора, однак, досить-таки складна задача, і їй можна було б присвятити кілька глав. В Internet можна знайти чимало прикладів розгортання цього конструктора, крім того, рекомендується почитати статтю MSDN на дану тему, яка доступна за адресою msdn2.microsoft.com/en-us/library/aa480213.aspx.


Традиційний спосіб дозволити користувачам налаштовувати систему полягає у визначенні інтерфейсу і потім надання їм самостійно його реалізовувати для розширення функціональності.


У Windows Workflow це розширення стає в значній мірі графічним, оскільки ви можете надати користувачеві порожній робочий потік як шаблон і забезпечити панеллю інструментів, включає спеціальні дії, які відповідають потребам вашого застосування. Потім користувачі самостійно зможуть конструювати свої робочі потоки, додаючи ваші дії або розробляючи власні.


Резюме


Windows Workflow призведе до радикальних змін у способі конструювання додатків. Ви можете тепер сформувати складні частини програми у вигляді дій і дозволити користувачам змінювати роботу системи простим перетягуванням дій в робочий потік.


Майже не існує додатків, до яких не можна було б застосувати концепцію робочого потоку – від найпростіших утиліт командного рядка до найбільш складних систем, що складаються з багатьох сотень модулів. У той час як нові засоби WCF і засоби для користувача інтерфейсу WPF є значним кроком вперед для додатків в цілому, додавання Windows Workflow призведе до фундаментальних змін в способах розробки та конфігурування додатків.


Якщо у вас є час, щоб витратити його на одне з нових коштів. NET Framework 3.0, настійно рекомендуємо звернутися саме до Windows Workflow. Є думки, що за кілька років потреба у фахівцях по робочих потокам значно зросте.


Закінчення.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*