Windows server appfabric

Отримання даних в додаток через сервіси стає все більш популярним. На Windows це найчастіше означає реалізацію таких сервісів на базі Windows Communication Foundation (WCF). А в зв'язку з тим, що логіка таких сервісів дуже часто може бути представлена ​​у вигляді робочих потоків, існує можливість реалізовувати WCF-сервіси за допомогою Windows Workflow Foundation (WF).

Але виникає питання, де всі ці сервіси повинні запускатися? Ні WCF ні WF не вимагають наявність певного хост-процесу, так що розробники можуть використовувати їх так як вважатимуть за потрібне. Однак, створення ефективного і керованого хоста не така проста задача. Було б набагато легше, якби Windows Server пропонував більше підтримки для хостингу і управління цими сервісами.

І це саме те, що пропонує сервіс AppFabric Hosting Services. Для того, щоб краще розуміти цю частину Windows Server AppFabric було б корисним спочатку швидко пробігтися по базовим технологіям WCF і WF.

основи технології

WCF пропонує спільний шлях для створення і споживання сервісів. WF пропонує підтримку створення бізнес-логіки у вигляді робочих потоків. Так як робочі потоки WF зазвичай використовують сервіси для взаємодії із зовнішнім світом, ми почнемо саме з WCF для опису цих двох технологій.

Створення сервісів: Windows Communication Foundation

WCF дозволяє розробнику створювати і використовувати різні типи сервісів - SOAP, RESTful і інші - через загальну програмну модель. Малюнок 1 показує основи:

Windows server appfabric

Рис.1. Схема WCF-сервісів

За допомогою Visual Studio (або іншого інструменту) розробник може реалізувати сервіс, який здатний запропонувати будь-який функціонал. Такий сервіс стає доступним для клієнтів через одну або більше кінцевих точок (endpoints). кожна з яких надає певний інтерфейс (так само відомий як контракт).

Сервіс звичайно розділяє свої функції на деяке число операцій, кожна з яких відповідає за той чи інший аспект бізнес-логіки. Наприклад, сервіс реалізує додаток для електронної комерції може мати операції для створення кошика, додавання предмета в кошик, видалення предмета, оплати покупки і так далі. Клієнт цього сервісу викликає кожну з операцій у міру потреби.

Створення робочих потоків: Windows Workflow Foundation

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

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

Як логіка такого роду повинна бути реалізована? Насправді це серія кроків з правилами визначальними порядок в якому ці кроки повинні бути виконані. Реалізація так само повинна підтримувати стан - кошик - протягом усього процесу, який може займати години, дні або навіть більше. Особливо в тих випадках, коли метою стає побудова масштабується додатки, реалізація такої логіки у вигляді робочих процесів побудованих на базі WF буде найкращою. Робочі потоки WF спроектовані так, щоб спростити створення процесів і вони можуть стати хорошим вибором при розробці деяких типів сервісів.

WF складається з простих базових частин: дизайнера для побудови блоків бізнес-логіки й середовища виконання для реалізації логіки на базі робочих потоків. Малюнок 2 ілюструє роботу WF:

Windows server appfabric

Рис.2. WF - основа для створення процессооріентірованной бізнес-логіки

Кожен робочий потік WF створюється на основі активностей, кожна з яких реалізує деяку част бізнес-логіки процесу. WF пропонує стандартну бібліотеку Base Activity Library (BAL) з набором активностей реалізують базові функції такі як if або While. Розробники можуть вільно створювати свої власні активності для задоволення потреб своєї бізнес-логіки. Для того щоб створити робочий потік розробник може використовувати дизайнер робочих потоків WF, який є частиною Visual Studio, для того щоб розподілити активності. Незалежно від того які будуть використані активності, всі вони виконуються за допомогою середовища виконання WF runtime.

Робочий процес пропонує набір корисних речей розробнику, який реалізує процес. Наприклад, коли робочий процес очікує введення, такий як запит на додавання або видалення елемента кошика, середовище виконання WF може автоматично зберегти стан робочого потоку і вивантажити його з пам'яті. Коли отримають новий запит, середа перезавантажує стан і запускає робочий потік для обробки запиту. Це дозволяє спростити розробку масштабованих додатків, так як робочі потоки не споживають пам'ять, системні потоки або інші ресурси, в моменти коли вони не виконуються. Середовище виконання може зберегти запис кожного виконання робочого потоку, відому як трекінг, дозволяючи розробнику бачити різні корисні речі, наприклад коли в робочому потоці включаються і вимикаються кожна з активностей.

Створення сервісу на базі робочого потоку

Робочі потоки WF можуть бути використані для реалізації досить великого числа різноманітних типів бізнес-процесів - вони не обмежені тільки створенням сервісів. Проте WCF-сервіс, логіка якого була створена на базі WF, заслуговує власного імені - сервіс на базі робочого потоку. Малюнок 3 демонструє такий підхід:

Windows server appfabric

Рис.3. Сервіс на базі робочих потоків

Уявіть собі розробника, який створює сервіс на базі робочих потоків або простий WCF-сервіс, який не використовує WF. Ні WCF ні WF не визначають явно хост процесу, в якому сервіс повинен бути запущений. Гарне в цьому те, що розробник вільний у виборі того, який процес він буде використовувати - WCF і WF не обмежують його в цьому. Це особливо важливо для промислової розробки, коли основною метою є створення бізнес-логіки, а побудова хост-процесу для сервісу є зайвою роботою. Зрештою, цей процес є частиною інфраструктури, а питання інфраструктури - це відповідальність Windows Server. Рішення всіх запитів хостингу сервісів в інфраструктурі і є те, чим допомагає AppFabric Hosting Services.

Введення в AppFabric Hosting Services

AppFabric Hosting Services (кодове ім'я "Dublin") не призначений для створення якоїсь абсолютно нової інфраструктури. Навпаки, він побудований на тому, що вже пропонується сервером IIS і механізмом Windows Process Activation Service (WAS). Грунтуючись на цьому фундаменті, AppFabric Hosting Services додає нові можливості для запуску та управління WCF-сервісами, включаючи сервіси на базі робочих потоків. Малюнок 4 ілюструє це:

Windows server appfabric

Рис.4. AppFabric Hosting Services спрощує запуск і управління сервісами

Як показано на малюнку, WCF-сервіси та сервіси на базі робочих потоків запускаються в робочих процесах, що обслуговуються IIS - це означає, що AppFabric Hosting Services не створює якихось власних процесів. Ця технологія так само використовує можливості WAS, які дозволяють запускати сервіс в момент отримання повідомлення по HTTP або іншому протоколу. AppFabric Hosting Services побудований на існуючій інфраструктурі, додаючи можливості запуску певних сервісів відразу після розміщення, без очікування отримання повідомлень. Це дозволяє сервісу бути більш чуйним для клієнтів. які першими звертаються до нього, так як їм не доводиться очікувати коли сервіс запуститься.

Як показано на малюнку 4, AppFabric Hosting Services так само розширює IIS Manager новими інструментами управління сервісами. Використовуючи ці розширення адміністратор може управляти конфігурацією WCF, запускати або зупиняти сервіси, досліджувати кінцеві точки сервісів, призупиняти, відновлювати або припиняти роботу певних примірників сервісів на базі робочих процесів. Разом з цим AppFabric Hosting Services пропонує набір командлетів PowerShell для керування сервісами, дозволяючи адміністраторам створювати свої власні скрипти.

Для того щоб спростити життя розробникам, Visual Studio пропонує вбудовані шаблони проектів для створення і WCF- і WF-сервісів. Сервіси створені на базі цих шаблонів можуть бути негайно розміщені в AppFabric Hosting Services - розробникам не потрібно робити нічого зайвого. І після того, як сервіс розгорнуть, він може бути доступний для споживання безліччю різних способів. Розглянемо їх на сценаріях.

Сценарій: хостинг сервісу на базі робочих потоків

Хоча AppFabric Hosting Services може бути використаний для роботи з будь-яким WCF-сервісом, він пропонує додаткову підтримку для запуску та управління сервісів на базі робочих потоків. Малюнок 5 показує деякі з найбільш важливих таких можливостей:

Windows server appfabric

Рис.5. AppFabric Hosting Services містить додаткові інструменти

Як зазначалося раніше, середовище виконання WF автоматично зберігає стан робочого потоку, який очікує введення даних, а потім відновлює його коли дані надходять. Але де стан зберігається? Якщо використовувати WF як окремий механізм, розробнику доводиться самостійно створити і конфігурувати БД для збереження стану. Проте, як показано на малюнку 5, AppFabric Hosting Services пропонує Переднастроєні сховище станів. WF так само дозволяє відстежувати виконання робочого потоку, автоматично дозволяючи розробнику отримувати детальну інформацію про виконанні. І знову, WF сам по собі не визначає де саме зберігати інформацію стеження. Як показано на малюнку 5, AppFabric Hosting Services пропонують вбудовану БД для моніторингу. Потрібно пояснити, що сховище станів і БД моніторингу відокремлені від будь-якої з баз даних програми, які можуть бути використані робочим потоком.

Як і для будь-якого іншого WCF-сервісу, для робочих потоків існують механізми моніторингу та управління. Нарівні з описаними раніше елементами управління сервісами, AppFabric розширює IIS Manager додатковими функціями, які застосовуються тільки до сервісів на базі робочих потоків. Для прикладу, погляньте на одне з розширень під назвою AppFabric Dashboard зображене на малюнку 6.

Windows server appfabric

Рис.6. Панель управління AppFabric Dashboard

Як показано на малюнку, AppFabric Dashboard пропонує панель управління AppFabric Hosting Services. Зверху ви можете бачити статус поточних WF-сервісів, в якому відображається число знаходяться в різних станах сервісів. Трохи нижче у вікні відображається історія останніх викликів, виключень і так далі. Microsoft також пропонує додатковий пакет Management pack for System Center Operations Manager, який дозволяє відстежувати події AppFabric Hosting Services за допомогою стандартних засобів управління Windows. Метою цих інструментів є надання ясної інформації про те, що відбувається в оточенні хостингу сервісів в поточний момент часу.

Сценарій: робимо сервіси робочих потоків більш масштабованими

Здатність WF автоматично зберігати і відновлювати стан робочих потоків дозволяє розробникам створювати масштабовану бізнес-логіку. AppFabric Hosting Services дозволяє розробникам створювати сервіси на базі робочих потоків навіть ще більш масштабованими. Малюнок 7 демонструє це:

Windows server appfabric

Рис.7. Масштабна архітектура сервісів на основі робочих потоків

У цьому сценарії три веб-сервера запускають копії одного і того ж додатка ASP.NET з балансуванням навантаження. ASP.NET використовується тільки для генерації користувальницького інтерфейсу. Бізнес-логіка програми, може бути це кошик магазину, реалізована у вигляді сервісу на базі робочих потоків (і щоб не було плутанини: хоч це і не показано на малюнку, як правило, кожен сервіс на базі робочого потоку запускається у вигляді робочого процесу IIS) .

Перший запит користувача відправлений верхньому веб-сервера (крок 1). Сторінка ASP.NET отримала цей запит викликає першу операцію в сервісі на базі робочого потоку, наприклад, створення кошика. Це запит відправляється до примірника сервісу запущеного на окремому сервері (крок 2). Як тільки операція виконується і результат повертається, середовище виконання WF автоматично записує стан сервісу в сховище, яке постачається AppFabric Hosting Services (крок 3).

Наступний запит користувача відправлений балансувальник навантаження на інший веб-сервер (крок 4). Цього разу сторінка ASP.NET, яка обробляє запит, наприклад на додавання елемента в кошик, відправляє запит до сервісу, який запущений на відмінному від першого сервері (крок 5). Незважаючи на те, що цей другий запит виповнюється сервісом на іншому сервері, середовище виконання WF дозволяє завантажить ь стан екземпляра робочого потоку зі сховища і обробити запит (рисунок 6).

Як показано на прикладі, AppFabric Hosting Services дозволяє одним і тим же сервісів на базі робочих потоків виконуватися в різний час на різних фізичних серверах. Це робить сервіси більш масштабованими, так як тепер ми можемо розміщувати безліч проміжних серверів для обробки будь-якого числа запитів. Так само як додаток ASP.NET може масштабироваться простим додаванням веб-серверів, так само і бізнес-логіка реалізована у вигляді робочих потоків може масштабироваться за допомогою додаткових серверів.

Схожі статті