Наш ассоциированный член www.Bikinika.com.ua

Архітектура IIS і WAS

  1. ServiceHost
  2. Активація на основі повідомлень
  3. Хостинг IIS 6
  4. Модель IIS 7 і WAS
  5. Висновок
  6. Додаткові ресурси

Вивчення веб-служб WCF

МОВИ: VB.NET | C #

ТЕХНОЛОГІЇ: ASP.NET 2.0 | .NET 3.0 | WCF

Архітектура IIS і WAS

Як обробляються запити до служб WCF

Мішель Леру Бустаманте

У цьому стовпці розглядається хостинг-модель послуг WCF у IIS 6 та IIS 7 з службою активації Windows (WAS). Якщо у вас виникли запитання щодо міграції існуючих веб-служб ASMX або WSE до WCF, або запитань щодо WCF, пов'язаних з веб-службами, надішліть їх [захищена електронною поштою] .

У попередніх стовпцях я дав вам прискорений курс створення служб WCF, розміщених у IIS, і надав огляд прив'язок веб-служб, доступних для налаштування кінцевих точок обслуговування. Отже, якщо ви знайомі з створенням служб WCF і налаштуванням кінцевих точок для цих служб, ви, ймовірно, готові вивчити архітектуру хостингу для обробки повідомлень службам. У цьому стовпці я поясню тип ServiceHost; як активація на основі повідомлень працює для послуг WCF; переглянути, як хостинг IIS працює в загальних рисах; і порівняти архітектуру хостингу для IIS 6 і IIS 7 з службою активації Windows (WAS).

Для деяких джерел прочитайте мої попередні статті asp.netPRO ASP.NET і WCF: Знайдіть нову веб-службу з випуску лютого 2007 р.

ServiceHost

Для тих, хто є новим у WCF, я наведу короткий огляд типу ServiceHost, який є центром історії хостингу. Сервіс WCF можна розмістити в консольному додатку, додатку Windows, службі NT і IIS 6 або IIS 7 за допомогою служби активації Windows (WAS). У всіх випадках тип ServiceHost повинен бути побудований, щоб відкрити канал зв'язку, який обробляє повідомлення в службі. Це означає ініціалізацію ServiceHost за допомогою типу служби, щоб він знав, який тип буде побудовано, коли надходить повідомлення для конкретної операції. Ви також повинні надати службі ServiceHost щонайменше одну кінцеву точку, що описує:

  • Адреса, куди клієнти можуть надсилати повідомлення. Для інтернет-послуг це буде HTTP-адреса.
  • Прив'язка, що вказує правильні протоколи для виклику служби. Це, швидше за все, буде BasicHttpBinding або WSHttpBinding (для стовпця березня).
  • Контракт на надання послуг, що вказує набір операцій, що роблять доступними за вказаною адресою, над зазначеними протоколами.

У середовищі самостійного розміщення (non-IIS) ви можете ініціалізувати службу ServiceHost таким чином:

ServiceHost host = new

ServiceHost (typeof (HelloIndigo.HelloIndigoService));

host.AddServiceEndpoint (typeof (HelloIndigo.HelloIndigoService)

, новий WSHttpBinding (), "http: // localhost: 8000 / HelloIndigoService");

host.Open ();

// тримаємо хост живим до завершення процесу

host.Close ();

Коли викликається Open, конструюється канал зв'язку для кінцевої точки разом з диспетчером повідомлень. Клієнти використовують проксі для виклику операцій служби на певній кінцевій точці. Коли повідомлення досягає моделі служби, об'єкт обслуговування будується (якщо необхідно) для обробки вхідного повідомлення. 1 ілюструє цей потік для клієнта, який спілкується з сервісом, розміщеним у процесі служби Windows.

Малюнок 1: Хостинг моделі для служби Windows
Малюнок 1: Хостинг моделі для служби Windows.

Для служб, що розміщуються на IIS, модель обробки є такою ж, як тільки повідомлення досягає моделі обслуговування; однак клієнт надсилає повідомлення на кінцеву точку .svc, яка, у свою чергу, пов'язана з ServiceHost і типом служби. Зрештою, екземпляр ServiceHost живе в WWW Worker Process (часто називається робочим процесом ASP.NET), як показано на малюнку 2. У цьому випадку для створення та відкриття типу ServiceHost, який обробляється автоматично через повідомлення, не потрібно коду активація на основі (для обговорення). Файл .svc вказує, який тип послуг повинен обробляти повідомлення, націлені на кінцеву точку, наступним чином:

Рисунок 2: Модель хостингу IIS з високого рівня
Рисунок 2: Модель хостингу IIS з високого рівня.

Справа в тому, що в обох випадках екземпляр ServiceHost повинен бути побудований, пов'язаний з типом послуги, розкрити кінцеві точки для цього типу послуг і відкритий для створення каналів зв'язку, які обробляють повідомлення.

Активація на основі повідомлень

Послуги, не розміщені в IIS або WAS, називаються службами самостійного розміщення. Це означає, що розробники повинні забезпечити процес і логіку для побудови ServiceHost. Одним з недоліків самостійного розміщення є те, що хост-процес повинен виконуватися, перш ніж запит до служби може бути оброблений (так що канали зв'язку ServiceHost готові до обробки повідомлень). Іншим є те, що всі повідомлення переносяться до одного і того ж хост-процесу, тому немає автоматичного розподілу навантаження або активного моніторингу здоров'я доступних процесів.

У випадку IIS і WAS хостингу, хост-процес і екземпляр ServiceHost будуються (якщо необхідно) у відповідь на вхідні повідомлення, відомі як активація на основі повідомлень. З високого рівня це означає, що повідомлення ставляться в чергу в очікуванні створення доступного робочого процесу та екземпляра ServiceHost. Крім того, один або більше робочих процесів можуть бути розподілені для обробки повідомлень, збільшуючи пропускну здатність і масштабованість. Існують відмінності в тому, як це працює для IIS 6 і IIS 7 / WAS, але високий рівень перегляду, що відповідає обом хостинговим середовищам, показаний на малюнку 3.

Рисунок 3: Черги запитів і активація на основі повідомлень
Рисунок 3: Черги запитів і активація на основі повідомлень.

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

Хостинг IIS 6

На машині Windows Service 2003 ви будете використовувати IIS 6 для розміщення кінцевих точок HTTP для ваших послуг WCF. За допомогою IIS 6 запити спочатку надходять на ядро ​​http.sys і в кінцевому підсумку передаються робочому процесу, в якому живе служба ServiceHost. Служба WWW запускає робочі процеси за вимогою, щоб обробляти запити і переконується, що запит надіслано до відповідної черги запитів.

IIS 6 має бути налаштований таким чином, щоб вхідні запити для файлів .svc пересилалися до aspnet_isapi.dll, як і інші розширення ASP.NET, такі як .aspx та .asmx. Це означає, що запити до служб WCF, розміщених у IIS, спочатку обробляються конвеєром ASP.NET; однак, сервісні запити врешті-решт обробляються службовою моделлю, а не ASP.NET.

Конвеєр ASP.NET шукає обробника HTTP, щоб обробити кожен запит, але, по дорозі, модулі HTTP, які були завантажені в домен програми, мають можливість взаємодіяти з подіями додатків до і після виклику обробника. У випадку служб WCF, простір імен System.ServiceModel.Activation надає два таких типи:

  • HttpModule. Реалізація IHttpModule призначена для захоплення обробки запитів для сервісів, щоб надіслати запит моделі обслуговування.
  • HttpHandler. Реалізація IHttpHandler, яка обробляє запити, які передаються через традиційний конвеєр ASP.NET, якщо ввімкнено режим сумісності ASP.NET.

На малюнку 4 показано, як IIS 6 обробляє запити до HttpModule і HttpHandler, де естафету передається до сервісної моделі.

Малюнок 4: Як IIS 6 і ASP
Малюнок 4: Як IIS 6 і ASP.NET обробляють запити сервісу WCF.

Наразі я зосереджуся на моделі обробки за замовчуванням для послуг WCF (змішаний транспортний режим). У цьому режимі, хоча в теорії запит на .svc-файли призначені для налаштованого типу HttpHandler для обробки, HttpModule підключає подію додатків PostAuthenticateRequest і отримує шанс на початку циклу запиту перенаправляти обробку на службову модель і обходити ASP. NET трубопровід. Під час PostAuthenticateRequest HttpModule перевіряє, чи включена сумісність ASP.NET; якщо ні, то запит пересилається на службову модель для обробки за допомогою HttpChannelListener з System.ServiceModel.Channels. Відповідно до малюнка 4, HttpHandler ніколи не викликається в цьому випадку. Крім того, коли модуль перенаправляє запити до моделі обслуговування, він вивільняє потік ASP.NET і передає керування потоку з пулу потоків WCF. Таким чином, інші запити ASP.NET можуть використовувати потік ASP.NET, але що більш важливо, це дозволяє WCF послідовно використовувати свою власну конфігурацію пулу потоків для всіх хостингових середовищ.

Що стосується режиму сумісності ASP.NET, ця функція дозволяє службам WCF оброблятися традиційним конвеєром ASP.NET, за допомогою якого HttpHandler буде в кінцевому підсумку обробляти запит. Крім того, це означає, що інші налаштовані модулі HTTP можуть взаємодіяти з запитом протягом всього життєвого циклу, наприклад, для кешування, аутентифікації, сеансу, обробки помилок, профілів та інших. Зрештою, HttpHandler полегшить обробку запиту (виконання операції) у способі сервісної моделі, і операції матимуть доступ до HttpContext серед інших функцій, характерних для додатків ASP.NET. Цей режим в основному орієнтований на ситуації, які вимагають зворотної сумісності або міграції послуг ASMX.

Модель IIS 7 і WAS

На машинах Windows Longhorn Server ви розміщуєте свої послуги WCF за допомогою служби активації Windows (WAS). WAS - це служба активації процесу, інстальована за допомогою IIS 7, яка відокремлює архітектуру активації від IIS для того, щоб підтримувати протоколи, що не є протоколами HTTP, такі як імена труб, TCP і MSMQ. Подібно IIS 6.0, WAS також надає функції для простою часу управління, моніторингу здоров'я, процесу переробки та інструменти управління для налаштування пулів програм, серед іншого.

Для HTTP-запитів архітектура хостингу дуже схожа на IIS 6:

  • Запити спочатку отримує ядро ​​http.sys.
  • Нова служба WAS відповідає за налаштування пулів програм, серед іншого.
  • Служба WWW відповідає за активацію пулів програм і запитує черги на обробку вхідних запитів. Крім того, цей сервіс має новий адаптер HTTP Listener Adapter, який перенаправляє запити до HttpHandler для обробки запиту (без необхідності aspnet_isapi.dll).
  • Якщо режим сумісності ASP.NET вимкнено, HttpModule перехоплює запит, як обговорювалося в попередньому розділі.
  • Якщо ввімкнено режим сумісності ASP.NET, HttpModule дозволяє запиту перейти до HttpHandler, як обговорювалося.

Архітектура хостингу IIS 7 і WAS показана на малюнку 5. Звичайно, ASP.NET задіяна лише в тому випадку, якщо служба розміщена через HTTP.

Малюнок 5: Як IIS 7, WAS і ASP
Малюнок 5: Як IIS 7, WAS і ASP.NET обробляють запити на обслуговування.

Є багато переваг цієї архітектури, включаючи:

  • Запити більше не проходять через aspnet_isapi.dll для обробки; замість цього, запити надсилаються безпосередньо до відповідного обробника.
  • Багато протоколів, включаючи звичайні (розширювані) протоколи, можуть підтримуватися за допомогою конфігурації WAS. Це дає змогу вивчити одну модель для всіх розгортань служб, навіть ті, що знаходяться за брандмауером.
  • Ви можете скористатися перевагами поліпшень конфігурації та функцій моніторингу здоров'я для робочих процесів.

Висновок

На цьому етапі ви повинні мати гарне уявлення про те, як IIS, ASP.NET і WCF взаємодіють, обробляючи запити до служб, які піддаються HTTP. Приємно, що ви можете виділяти пули програм для вхідних запитів до служб, так само, як і для ресурсів додатків ASP.NET. Саме в перенесенні до конвеєра ASP.NET при залученні моделі обслуговування забезпечується послідовна обробка для всіх служб, незалежно від їх хостингового середовища. Якщо ви ввімкнете режим сумісності ASP.NET, ви отримаєте знайомі моделі ASMX, що стосуються конвеєра ASP.NET, але в ідеалі ви будете використовувати це лише для міграції.

Додаткові ресурси

Головна сторінка WCF: http://wcf.netfx3.com

Навчання WCF , O Reilly 2007: http://www.thatindigogirl.com (отримайте весь код книги тут!)

Блог компанії Мікеле: http://www.dasblonde.net

Ідентифікатор: http://www.idesign.net

Мішель Леру Бустаманте є головним архітектором компанії IDesign Inc., регіональним директором Microsoft для Сан-Дієго, Microsoft MVP для Connected Systems і технічним директором BEA. В IDesign Michele надає послуги з навчання, наставництва та консалтингу архітектури високого класу, що спеціалізується на масштабованому та безпечному архітектурі .NET архітектури, глобалізації, веб-службах та сумісності з платформами Java. Вона є членом правління Міжнародної асоціації архітекторів програмного забезпечення (IASA), учасником конференції, конференцією кафедри веб-сервісів і веб-розробок SD, а також часто публікується автором. Michele нещодавно завершив роботу над книгою «Навчання WCF», опублікованою O Reilly (книжковий блог: http://www.thatindigogirl.com ). Досягніть її http://www.idesign.net або http://www.dasblonde.net .

Новости