IIS 7.0 Побудова рішень веб-сервера з використанням наскрізної розширюваності

Веб-платформа IIS 7.0 підтримує більше число технологій інфраструктури додатків для розміщення багатофункціональних програм, ніж будь-яка попередня версія IIS, вона буквально напхана функціями, які можна використовувати для розгортання цих додатків відразу ж після установки. Однак у той же час ви бачите (в установці Windows ®) не обов'язково те, що завжди отримуєте.
Архітектура IIS 7.0 виконана таким чином, що дозволяє їй бути розширюваної зверху до низу, це дає можливість замінювати будь-яку частину вбудованого набору функцій на власні розробки, які найкращим чином відповідають вашим вимогам. У результаті цього замість латання клаптикової ковдри з модулів IIS 7.0 дає абсолютно унікальні можливості по розширюваності шляхом реалізації всіх власних функцій поверх загальнодоступною моделі розширюваності. Ця конструкція простежується по всій платформі, починаючи від самого модульного механізму веб-сервера і до системи настройки консолі диспетчера IIS.
У цій статті я постараюся зануритися в тонкощі моделі розширення IIS 7.0, розглянувши для цього вихідний код загального користування проекту модуля зміни відповіді, який дозволяє отримувати відгуки додатків IIS і змінювати їх "на льоту", використовуючи для цього настроюються правила зміни відгуків. Спочатку я побудую модуль веб-сервера, скориставшись вбудованою в сервервозможностью розширення ASP.NET. Потім я створю функції розгортання і управління для модуля, розробивши розділ для користувача настройки і створивши спеціальну сторінку керування для диспетчера IIS.


Розширення веб-сервера


Модульна архітектура IIS 7.0 надає можливість повністю перебудувати веб-сервер під необхідну робоче навантаження. Часто це може бути виконано просто шляхом встановлення тільки тих функцій, які необхідні для вашої програми, в результаті чого з'являється веб-сервер з урізаною функціональністю, що дозволяє робити тільки те, що необхідно, і нічого більше.
Однак це тільки перший крок. Найчастіше потрібна робоча навантаження вимагає наявності додаткових функцій, які можуть не входити у вбудований набір функцій IIS. Або ж у деяких випадках додатків може потрібно спеціальний набір функцій, для виконання яких вбудовані функції недостатньо пристосовані. Оскільки всі функції IIS 7.0 побудовані на загальнодоступних інтерфейсах розширюваності API, ви можете замінити будь-який з них власною розробкою, яка найкраще відповідає вашим вимогам.
IIS 7.0 надає два способи розробки модулів веб-сервера. По-перше, можна використовувати новий інтерфейс API для модулів на C + +, на якому заснована велика частина вбудованих функцій. Інтерфейс API модулів замінює розширення ISAPI і інтерфейс API фільтра, що застосовувалися в попередніх версіях IIS. Цей інтерфейс API є суттєвим удосконаленням у порівнянні з ISAPI, оскільки він здатний підтримувати всі функції IIS 7.0 і набагато простіше для використання в програмуванні. Дізнатися детальніше про вдосконалення у цьому інтерефейса API можна за адресою: mvolo.com/blogs/serverside/archive/2006/10/07/10-reasons-why-server-development-is-better-with-IIS7.aspx.
По-друге, в IIS 7.0 введена інтеграція з ASP.NET, яка дозволяє розробляти модулі IIS 7.0 з використанням добре знайомих інтерфейсів API модулів в ASP.NET. В об'єднаному режимі ASP.NET ці модулі стають повноправними учасниками конвеєрної обробки запитів IIS, як видно з рис. 1. Це дозволяє модулям ASP.NET отримувати доступ до вбудованих об'єктів IIS, таким як запити і відповіді, на всіх стадіях обробки й обробляти запити для всіх типів ресурсів – не тільки для тих, які обробляються платформою ASP.NET.


Рис. 1 Модулі ASP.NET в обробці запитів IIS 7.0


Це дозволяє використовувати однаково по всьому веб-сайту такі багатосторонні функції ASP.NET, як перевірка достовірності на основі форм, елементи управління входом в систему і служба членства. Для більш докладного вивчення того, як об'єднаний режим ASP.NET може бути використаний з метою підвищення функціональних можливостей додатків, написаних не для платформи ASP.NET, прочитайте мою статтю в січневому номері журналу MSDN ® Magazine за 2008 рік, розташовану за адресою: msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7.
Для розробників справжня цінність об'єднаного режиму ASP.NET полягає в можливості нарощувати функціональність веб-сервера IIS з використанням платформи Microsoft ®. NET Framework. Це дає суттєві переваги при швидкій розробці додатків шляхом забезпечення можливості будувати ці програми, на основі широкої підтримки платформ. NET Framework, ASP.NET, а також інших платформ, таких як Windows Workflow Foundation.


Модуль зміни відповіді


Об'єднаний конвеєр ASP.NET дає можливість модулям ASP.NET виконувати широкий спектр завдань в ході обробки кожного запиту. Цей спектр містить все, починаючи від завдань перевірки автентичності або авторизації і до зміни вихідних відповідей перед їх відправкою клієнту.
Призначенням модуля зміни відповіді є виконання зміни відповіді: він дозволяє змінювати існуючі відповіді "на льоту" за допомогою набору правил заміни. Для цього можна використовувати механізм фільтрації відповідей ASP.NET, який, завдяки об'єднання із середовищем виконання, забезпечує фільтрацію вихідних відповідей будь-якого змісту, включаючи статичні файли, а також сценарії ASP і PHP.
Якщо в минулому ви розробили модуль ASP.NET, то вас, безсумнівно, обрадує той факт, що ви зможете використовувати ті ж інтерфейси API для розробки модулів ASP.NET на платформі IIS 7.0. Фактично, наявні у вас модулі продовжують працювати точно так само, як вони працювали в попередніх версіях IIS (якщо тільки не потрібно використовувати переваги об'єднаного режиму IIS 7.0 і запускати їх для обробки всіх запитів). Модуль є класом, що реалізує інтерфейс System.Web.IHttpModule і реєструвальних обробники подій для подій конвеєрної обробки одного або декількох запитів. Модуль зміни відповідей саме такий:

class ResponseModificationModule : IHttpModule
{
public void Init(HttpApplication app)
{
// Wire up the filter in PreRequestHandlerExecute
app.PreRequestHandlerExecute +=
new EventHandler(OnPreRequestHandlerExecute);
}

public void OnPreRequestHandlerExecute(
Object source, EventArgs e)
{

}
}


По суті, модуль підписується на подію PreRequestHandlerExecute, яке відбувається всякий раз перед виконанням обробника запиту. Метод OnPreRequestHandlerExecute використовується для читання відомостей налаштування з метою визначити, чи має відповідь якісь застосовні для нього правила заміни (докладніше про налаштування – далі в цій статті), і в разі наявності таких реєструвати потік фільтра відповідей, який потім буде використаний для фільтрації вихідних відповідей, як показано на рис. 2.
Figure 2 Фільтр відповідей

 public void OnPreRequestHandlerExecute (Object source, EventArgs e)
{
HttpApplication app = (HttpApplication)source;
HttpContext context = app.Context;

// Read configuration
ResponseModificationConfigurationSection config;

// Get the list of filters
ResponseFilterList filters = GetApplicableFilters (context, config);

// Create the filter and wire it up
if (null != filters && filters.Count > 0)
{
context.Response.Filter =
new ChainedBufferedStringResponseFilter(
context, filters);
}
}


Фільтрація відповідей виконується всередині класу ChainedBufferedStringResponseFilter, який відповідає за перетворення байтів відповідей в рядок за допомогою набору символів відповідей, а також за виклик одного або кілька фільтрів відповідей, які застосовні до даного запиту. Модуль пов'язує фільтр з відповіддю шляхом установки властивості HttpResponse.Filter. Це властивість приймає всі об'єкти, породжені від абстрактного класу System.IO.Stream, і пізніше використовує їх для фільтрації тіла екземпняра вихідного відповіді.
Функція фільтрації відповідей ASP.NET – всього лише один з механізмів, які стає можливим використовувати при розробці модулів ASP.NET для об'єднаного режиму платформи IIS 7.0. Крім того, можна переписувати URL-адреси, виконувати перевірку автентичності та авторизацію запитів, модифіковані або випускати файли "cookie" і заголовків, журналіровать запити і багато іншого. Більшість завдань, які раніше вимагали розробки в середовищі ISAPI в машинному коді, тепер можуть бути реалізовані шляхом простого написання модулів ASP.NET. Поетапні вказівки по збірці модулів ASP.NET для IIS 7.0, параметрам середовища розробки та виконання розгортання можна знайти за адресою: mvolo.com / blogs / serverside / archive / 2007/08/15/Developing-IIS7-web-server-features-with-the-.NET-framework.aspx.
При розробці модуля IIS 7.0 можна використовувати можливості ряду функцій IIS, використовуваних для цілей управління і розгортання. Одна з таких функцій – можливість вказувати призначену для користувача настройку модуля у файлах налаштування IIS 7.0 і або примусово розгортати цю настройку автоматично самим додатком, або управляти нею за допомогою ряду засобів адміністрування IIS 7.0 та інтерфейсів API. Виконання такої процедури є запорукою того, що всі функції, що їх модулем, будуть правильно налаштовані і керовані кінцевими користувачами.


Розширення налаштування


Нова система налаштування є основою для великого числа основних варіанти розгортання та управління, можливих для платформи IIS 7.0. Замість того, щоб бути машинно-орієнтованим зраніліщем налаштування закритого формату, система налаштування IIS 7.0 заснована на структурованих файлах налаштування формату XML, що розташовуються в тих же файлах налаштування, використовуваних системою налаштування ASP.NET. Більше того, синтаксис даних налаштування IIS ідентичний сінатксісу даних налаштування ASP.NET; ці дані можуть бути спільно записані в розповсюджувані файли web.config, з якими розробники ASP.NET дуже добре знайомі.
Така схема відкриває багато дверей. По-перше, вона дозволяє додаткам вказувати дані налаштування IIS разом зі своїм прикладним вмістом, що спрощує процес їх розгортання до простої публікації вмісту на сервері. Це гарантує, що додатки будуть працювати правильно без необхідності змінювати дані машинної налаштування, що зберігаються на кожному сервері, на якому ці програми, розгортаються, а також без необхідності мати повноваження адміністратора на кожному сервері. Структурований файл настройки формату XML спільно з можливістю розміщувати настройку ASP.NET разом з налаштуванням IIS в одному файлі значно спрощує завдання розробників створювати ці налаштування, пов'язані з IIS, і управляти ними. Це завдання може виконуватися за допомогою редактора файлів XML, наприклад Notepad і Visual Studio ®, або може бути автоматизоване з допомогою інтерфейсів API налаштування, що надаються стеком адміністрування IIS 7.0.
Та найкращим тут є той факт, що система налаштування IIS 7.0 є повністю розширюваною. Можливість надавати спеціальному веб-сервера право публікації налаштувань, які можуть встановлюватися і управлятися разом з налаштуванням IIS 7.0, грає ключову роль у побудові повних рішень для IIS 7.0.
На відміну від системи настройки. NET, додавання нового розділу налаштування IIS 7.0 не вимагає використання програмного коду, оскільки самі розділи IIS 7.0 визначаються з використанням схеми, заснованої на XML. Фактично, всі вбудовані розділи налаштування IIS 7.0 визначаються з використанням цього механізму. Знайти визначення всіх розділів налаштування IIS можна знайти в каталозі% windir% system32inetsrvconfigschema у файлі IIS_Schema.xml. Наприклад, розділ налаштування <defaultDocument>, який включає і налаштовує документи за умовчанням для вашої програми, визначається таким чином:

 <sectionSchema name="system.webServer/defaultDocument">
<attribute name="enabled" type="bool" defaultValue="true" />
<element name=”files”>
<collection addElement=”add” clearElement=”clear”
removeElement=”remove” mergeAppend=”false”>
<attribute name="value" type="string" isUniqueKey="true"/>
</collection>
</element>
</sectionSchema>

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


Налаштування модуля зміни відповіді


Модуль зміни відповіді вимагає наявності власного розділу налаштування для налаштування ряду спеціальних параметрів, в тому числі відомостей про те, які правила фільтрації застосовні для цього додатка. Щоб надати можливість використовувати цей розділ у файлах налаштування IIS, в першу чергу необхідно створити файл схеми, який описував би структуру розділу (див. рис. 3). Цей файл визначає розділ responseModification і його структуру, включаючи необхідні атрибути і колекцію правил фільтрації, які можуть налаштовуватися для виклику різних фільтрів з додатковою інформацією про те, що і чим повинно замінюватися.
Figure 3 Схема налаштування модуля зміни відповіді

<configSchema>
<sectionSchema name=”responseModification”>
<attribute name="enabled" type="bool" defaultValue="false" />
<collection addElement=”add” clearElement=”clear”
removeElement=”remove”>
<attribute name=”name” type=”string” required=”true”
isUniqueKey = "true" validationType = "nonEmptyString" />
<attribute name="conditionType" type="string" required="false" />
<attribute name="condition" type="string" required="false" />
<Attribute name = "replaceType" type = "string" required = "true"
validationType=”nonEmptyString” />
<attribute name="replace" type="string" required="false" />
<attribute name="replaceWith" type="string" required="false" />
<attribute name="options" type="string" required="false" />
</collection>
</sectionSchema>
</configSchema>

Для установки цього розділу настройки необхідно зробити дві речі. По-перше, необхідно скопіювати файл responsemod_schema.xml, що містить відомості про схему розділу, в папку% windir% system32inetsrvconfigschema. Потім оголосіть розділ налаштування в основному файлі настройки сервера, applicationHost.config. Останнє завдання зажадає написання деякого коду, якщо ви побажаєте виконати цю установку за допомогою програми.
Щоб спростити процес установки розділу налаштування IIS 7.0, я написав службову програму iisschema.exe, яка виконує обидві ці задачі автоматично. Цю програму можна отримати за адресою: mvolo.com/blogs/serverside/archive/2007/08/04/IISSCHEMA.EXE-_2D00_-A-tool-to-register-IIS7-configuration-sections.aspx. З використанням цієї програми процедура установки розділу схеми настройки стає однокрокової:

IisSchema.exe /install responsemod_schema.xml

Після того як схема розділу налаштування встановлена, а сам розділ оголошений у файлі applicationHost.config, можна почати використовувати його для визначення даних налаштування модуля.
Для управління налаштуванням розділу можна використовувати будь-яке з засобів настроювання IIS або інтерфейсів API, точно так само, як це робилося б з будь-яким вбудованим розділом налаштування IIS 7.0. Наприклад, я хочу включити функцію зміни відповідей для мого програми за допомогою AppCmd, засоби командного рядка IIS 7.0:

 % Windir% system32inetsrvAppCmd Set Config "Default Web Site /"
/section:responseModification /enabled:true

Крім того, я можу додати в розділ налаштування responseModification колекцію правил:

 % Windir% system32inetsrvAppCmd Set Config "Default Web Site /"
“/+[name=”StripWhitespace”,replaceType=
“Mvolo.ResponseModification.Filters.HtmlDeflate”]”

Якщо тепер ви відкриєте файл web.config в кореневій папці веб-сайту за замовчуванням (звичайно це% windir% inetpubwwwroot), ви виявите наступний код:

<configuration>
<responseModification enabled=”true”>
<add name=”StripWhitespace”
replaceType = "Mvolo.ResponseModification.Filters.HtmlDeflate" />
</responseModification>
</configuration>

Якщо ви виправили файл програми web.config з метою зміни даних настройки модуля, а потім завантажили його на сервер, додаток буде налаштоване таким чином, щоб використовувати ці нові параметри. Точно так само, якщо ви завантажили додаток на інший сервер, на якому встановлений розділ налаштування, ви можете бути впевнені, що дане застосування буде використовувати потрібні параметри без необхідності перенастроювання його на цьому сервері.
На додаток до AppCmd, тепер можна використовувати для управління даними налаштування даного розділу будь-який інтерфейс API налаштування IIS 7.0, включаючи керований інтерфейс Microsoft.Web.Administration, постачальник WMI з IIS 7.0, об'єкти COM налаштування IIS 7.0, а також Windows PowerShell ®. Крім встановлення і читання даних налаштування, можна виконувати будь-які завдання управління, підтримувані системою налаштування IIS 7.0, включаючи управління процесом делегування даного розділу додаткам, захист їх вмісту шляхом шифрування налаштування і т.д. Ті мені менш, щоб ці дані налаштування були корисними, вам буде потрібно можливість читати їх з модуля зміни відповіді.
Інтерфейс API Microsoft.Web.Administration є новим інтерфейсом. NET Framework, що надаються IIS 7.0; він дозволяє програмам мати доступ до даних налаштування IIS 7.0. Крім того, що цей інтерфейс надає програмам настройки і установки можливість керувати налаштуванням, він також дає можливість зчитувати дані налаштування безпосередньо з керованого модуля.
Можна використовувати цей інтерфейс API для читання розділу налаштування з модуля відразу ж після реєстрації розділу налаштування, оскільки інтерфейс API надає нестрого типізовану модель для читання розділів налаштування. Перед тим як робити це, вам необхідно додати посилання на файл Microsoft.Web.Administration.dll, який знаходиться в папці% windir% system32inetsrv. Зауважимо, що ця бібліотека DLL входить до складу лише IIS 7.0 під Windows Vista ® або Windows Server ® 2008 і не поставляється в складі. NET Framework або комплекту SDK для Windows.
Після того, як посилання додана, можна читати ці налаштування модуля:

ConfigurationSection section =
WebConfigurationManager.GetSection(
context,
“responseModification”);

bool enabled = (bool)section[“enabled”];


Клас WebConfigurationManager в просторі імен Microsoft.Web.Administration майже ідентичний WebConfigurationManager в просторі імен System.Web.Configuration і покликаний замінити останній для роботи з керованими модулями IIS 7.0, які виконують читання налаштування IIS 7.0. Метод GetSection вибирає об'єкт розділу налаштування по шляху, вказаному в поточному запиті HTTP.


Строго типізований клас налаштування


Об'єкт ConfigurationSection надає нестрого типізований доступ до будь-якого розділу налаштування, не вимагаючи написання додаткового коду. Можна отримати доступ до включеному атрибуту шляхом простого вилучення його імені в індексатор об'єкта розділу та приведення його до очікуваного типу.
Тим не менш, можна просунутися на один крок вперед, створивши суворо типізовану оболонку для розділу налаштування. Можна швидко створити клас оболонки за допомогою службової програми, написаної Канвальетом Синглом (Kanwaljeet Singla), учасником команди IIS; цю програму можна завантажити за адресою: blogs.iis.net / ksingla/archive/2006/12/04/tool-to-generate-strongly-typed-classes-for-configuration-sections . aspx. Вона дозволяє створювати клас оболонки для розділу, що має приблизно такий вигляд, як показано на рис. 4. Цей клас просто обгортають нижележащий клас ConfigurationSection і надає суворо типізовані властивості для доступу до вихідних даних налаштування.
Figure 4 Строго типизированная обгортка розділу налаштування

class ResponseModificationSection : ConfigurationSection
{
public bool Enabled
{
get { return (bool)this[“enabled”]; }
set { this[“enabled”] = value; }
}

public ResponseModificationRuleCollection FilterRules
{
get
{
return (ResponseModificationRuleCollection)
GetCollection (typeof (ResponseModificationRuleCollection));
}
}
}


Як видно з реалізації властивості Enabled, обгортання атрибутів налаштування є досить простим. Обгортання дочірніх елементів і колекцій вимагає подальшої реалізації класів обгорток, успадкованих відповідно з ConfigurationElement і ConfigurationCollection (не показані), точно таких же, як сама обгортка розділу.
Після того, як клас обгортки створений, його можна скомпілювати в окрему збірку і вказати посилання на нього в проекті модулів або просто додати його у вигляді файлу вихідного коду. Це дозволить модулю мати безпечний щодо типів доступ до розділу налаштування:

ResponseModificationSection section =
(ResponseModificationSection) WebConfigurationManager.GetSection (
context,
“responseModification”,
typeof(ResponseModificationSection)
);

bool enabled = section.Enabled;


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


Розширення IIS Manager


Отже, я вже показав, як створити модуль зміни відповіді і дозволити йому читати спеціальний розділ настройки, який керує його поведінкою. Ця установка може зберігатися в тих же файлах налаштування, що містять залишилися дані налаштування IIS, може розгортатися разом з додатком у файлах web.config, а також може оброблятися за допомогою різних програмних засобів та інтерфейсів API, в тому числі AppCmd.exe і Microsoft.Web.Administration.
До цього моменту модуль зміни відповіді може бути розгорнуто і відповідним чином налаштований в будь-якому середовищі IIS. Тим не менш, можна просунутися ще на один крок вперед, надавши функції спеціальні можливості управління для консолі диспетчера IIS. Зробивши це, ви отримаєте ряд переваг. Це дозволить системним адміністраторам без праці налаштовувати модуль за допомогою консолі диспетчера IIS, не вимагаючи від них правити безпосередньо файли налаштування або використовувати інші низькорівневі службові програми та інтерфейси API. Це також дозволяє обробляти дані налаштування модуля за допомогою засобів віддаленого адміністрування диспетчера IIS, які надають користувачеві переваги служби веб-управління (WmSvc).
На відміну від інших засобів, які теж підтримують функції віддаленого адміністрування, архітектура віддаленого адміністрування диспетчера IIS має ряд ключових переваг. По-перше, вона дозволяє користувачам, що не володіє правами адміністратора на сервері, керувати веб-вузлами та додатками, які доступні для них. По-друге, механізм віддаленого адміністрування диспетчера IIS використовує протокол HTTPS, а не DCOM, який простіше проходить через корпоративні брандмауери. У поєднанні обидві ці можливості роблять диспетчер IIS Manager привабливим для делегованого віддаленого управління веб-вузлами IIS, особливо в середовищах спільного веб-розміщення.
У повній відповідності з основною ідеєю IIS 7.0, диспетчер IIS має розширювану архітектуру, на якій засновано більшість вбудованих функцій диспетчера IIS. З метою спрощення випадку віддаленого управління кожна функція управління складається з двох частин: компонентів клієнтської частини, яка надає користувальницький інтерфейс всередині диспетчера IIS, і серверних компонентів, які надають власне самі служби управління.
Служба на стороні сервера завантажується всередині диспетчера IIS Manager у випадках локального управління або усередині служби веб-урядування у випадках віддаленого управління. У другому випадку диспетчер IIS підтримує необхідний обмін даними між компонентами в диспетчері IIS на машині клієнта і службою, запущеної всередині WmSvc на машині приймаючої сервера.


Створення служби


Клієнтські і серверні компоненти зазвичай виконані у вигляді двох окремих збірок. NET, які не посилаються один на одного. Обмін даними між клієнтськими і серверними компонентами здійснюється за допомогою абстракції ModuleServiceProxy диспетчера IIS, яка використовує для обміну інформацією набір нестрого типізованих властивостей і основних типів. NET.
Серверна збірка зазвичай містить реалізацію класу Microsoft.Web.Management.Server.ModuleProvider, який виконує необхідну реєстрацію служб і клієнтських модулів, а також реалізацію класу Microsoft.Web.Management.Server.ModuleService, який представляє методи служб для виконання необхідних завдань управління.
Моя збірка Mvolo.ResponseModificationUI.Server.dll містить клас ResponseModificationModuleProvider, який відповідає за реєстрацію класу служб ResponseModificationModuleService на додаток до класу клієнтського модуля ResponseModificationModule, як це показано на рис. 5.
Figure 5 Клас постачальника модулів

public sealed class ResponseModificationModuleProvider :
ConfigurationModuleProvider
{
public override Type ServiceType
{
get { return typeof(ResponseModificationModuleService); }
}

public override ModuleDefinition
GetModuleDefinition(IManagementContext context)
{
return new ModuleDefinition(Name,
"Mvolo.ResponseModification.UI.Client.ResponseModificationModule," +
“Mvolo.ResponseModificationUI.Client,” +
“Version=1.0.0.0, Culture=neutral,” +
“PublicKeyToken=309ac0e1b5482072”);
}

protected override string ConfigurationSectionName
{
get { return “responseModification”; }
}
}


Клас ResponseModificationModuleService породжується від класу ConfigurationModuleProvider, який надає вбудовану підтримку для управління функціями делегування диспетчера IIS, заснованими на стані делегування нижчого розділу налаштування. Все, що потрібно зробити, – вказати ім'я розділу налаштування, responseModification, і диспетчер IIS автоматично перемкне стан делегування функцій в залежності від того, заблоковано або розблоковано цей розділ для окремих шляхів налаштування. Інфраструктура Microsoft.Web.Management надає кілька інших базових класів ModuleProvider, які підтримують трохи інші випадки делегування для засобу диспетчера IIS.
Метод GetModuleDefinition повертає тип модуля диспетчера IIS, який буде створений на стороні клієнта, щоб зареєструвати необхідні компоненти інтерфейсу користувача диспетчера IIS, такі як сторінка управління.
Зверніть увагу на те, що тип класу ResponseModificationModule на стороні клієнта – рядковий, але не об'єкт типу Type, оскільки серверна збірка може не посилатися на складання клієнта, яка буде завантажена в диспетчер IIS на машині віддаленого клієнта. Це один з побічних ефектів, обумовлений тим фактом, що компоненти клієнта і сервера можуть бути запущені в різних процесах і не можуть спільно використовувати користувацькі типи.
Клас ResponseModificationModuleService відповідає за реалізацію функцій управління і використання методів служб, які зголосились сторінкою управління в диспетчері IIS (див. рис. 6).
Figure 6 Клас служби модулів

 public sealed class ResponseModificationModuleService: ModuleService
{
[ModuleServiceMethod]
public ArrayList GetFilterRules()
{
ArrayList items = new ArrayList();

ResponseModificationSection section =
(ResponseModificationSection)ManagementUnit.Configuration
.GetSection(“responseModification”,
typeof(ResponseModificationSection));

foreach (ResponseModificationRuleElement rule in section.Rules)
{
items.Add(GetPropertyBag(rule));
}

return items;
}

}


Метод GetFilterRules є прикладом використання декількох методів службою, що виконує завдання управління з використанням системи настроювання, а також інших ресурсів, локальних для сервера. Примірник служби завжди створюється на сервері, так що він постійно працює на локальних ресурсах, тому немає необхідності хвилюватися про роздільне доступі до ресурсів у випадку віддаленого адміністрування. Зверніть увагу на те, що я знову використовую інтерфейс API Microsoft.Web.Administration для доступу до розділу налаштування responseModification, при цьому використовую суворо типізовану обгортку ResponseModificationConfigurationSection, створену для забезпечення доступу модуля до налаштування.
Властивість ManagementUnit є основною точкою доступу до локального сервера, воно надає ряд інших об'єктів, які забезпечують доступ до системи налаштування та іншим об'єктам управління, зосередженим на сервері, які були створені за допомогою платформи Microsoft.Web.Management з метою допомогти в реалізації завдань управління сервером. Практичний досвід показує, що реалізації служб повинні завжди використовувати блок управління для задач управління локальною налаштуванням, а не створювати власні системи настройки.
Методи зразок GetFilterRules можуть повертати клієнту дані, використовуючи основні типи, наприклад, ArrayList, для пересилки даних клієнтським компонентів. Знову зверніть увагу на те, що не можна здійснювати обмін даними ІПРІ допомоги суворо типізованих класів, визначених на серверної або клієнтської збірках, тому що вони призначені для роздільного використання і не повинні посилатися один на одного. Служба ResponseModificationModuleService також визначає додаткові методи служб, аналогічні GetFilterRules, в тому числі EditFilterRule, AddFilterRule і DeleteFilterRule, призначені для виконання операцій управління, які можуть бути затребувані сторінкою модуля зміни відповіді.

Створення сторінки модуля
Клієнтські компоненти визначають функції графічного інтерфейсу користувача (GUI), що надаються користувачеві за допомогою диспетчера IIS. Клієнтська збірка зазвичай містить реалізацію наступних класів:
Клас Microsoft.Web.Management.Client.Module, відповідальний за реєстрацію всіх потрібних сторінок диспетчера IIS і інших розширень користувальницького інтерфейсу.
Клас Microsoft.Web.Management.Client.ModulePage, який містить опис поточної сторінки управління, яка відображається диспетчером IIS.
Клас Microsoft.Web.Management.Client.ModuleServiceProxy, коор надає клієнтські компоненти спільно з класом локального проксі для виклику методів служб, використовуваних ModuleService.
Збірка Mvolo.ResponseModificationUI.Server.dll містить клас ResponseModificationModule, показаний на рис. 7 (не плутати власне з класом IhttpModule, що надають служби модуля при конвеєрної обробці запитів IIS), який надає головну точку входу для реєстрації всіх необхідних компонентів для користувача інтерфейсу в диспетчері IIS. Цей клас реєструє клас ResponseModificationModulePage, який містить опис поточної керуючої сторінки.
Figure 7 Клас модулів

public sealed class ResponseModificationModule : Module
{
protected override void Initialize (IServiceProvider serviceProvider,
ModuleInfo moduleInfo)
{
base.Initialize(serviceProvider, moduleInfo);

IControlPanel controlPanel =
(IControlPanel)GetService(typeof(IControlPanel));

controlPanel.RegisterPage(
new ModulePageInfo(this,
typeof(ResponseModificationModulePage),
Resources.PageTitle,
Resources.PageDescription,
null,
null,
Resources.PageText
));
}
}


Кожна реалізація модуля створюється одноразово за час керуючого підключення, виоплненного диспетчером IIS, вона відповідальна за реєстрацію всіх сторінок управління та елементів призначеного для користувача інтерфейсу, необхідних для цього підключення. ResponseModificationModule реєструє клас ResponseModificationModulePage, який визначає вміст керуючої сторінки.
Чесно кажучи, я не великий шанувальник програмування користувальницьких інтерфейсів, я волів би програмувати низькорівневі серверні програми, які не потребують розробки інтерфейсу. На щастя для мене, платформа Microsoft.Web.Management надає цілий ряд базових класів і підтримуючих класів, призначених для створення звичайних керуючих сторінок, включаючи клас Microsoft.Web.Management.Client.Win32.ModuleListPage, який я використовував для ResponseModificationModulePage.
Цей клас має вбудоване представлення у вигляді списку для перегляду списків елементів і роботи з ними, включаючи впорядкування списків і роботу з елементами списку. З мінімальними переробками я зміг створити сторінку управління, що містить перелік правил зміни відповідей (див. центральну панель на рис. 8).


Рис. 8 Сторінка зміни відповідей в диспетчері IIS


Потім я створив перелік дій, показаний в правому вікні, що дозволяє додавати, змінювати і видаляти правила зміни відповідей. При створенні цього переліку завдань я використовував можливості класу Microsoft.Web.Management.Client.TaskList (Див. праву панель на рис. 8).
Ще трохи зусиль, і функція зміни, показана на рис. 8, є на світло. Можна вивчити деталі користувальницького інтерфейсу, подивившись вихідний код для платформи зміни відповіді.
Операції створення нової сторінки, додавання, редагування і видалення, що запускаються з панелі дії, виконуються за допомогою методів класу ResponseModificationModuleServiceProxy, який надає локальний проксі для методів модулів, вимагає служба модулів:

 public sealed class ResponseModificationModuleServiceProxy:
ModuleServiceProxy
{
public ArrayList GetFilterRules()
{
return (ArrayList)Invoke(“GetFilterRules”);
}

public void AddFilterRule(PropertyBag bag)
{
Invoke(“AddFilterRule”, bag);
}


}


Диспетчер IIS автоматично передає виклики, зроблені до класу проксі служби модулів, на пов'язану службу модуля по каналу обміну даними, який може представляти собою локальний канал використовується спільно пам'яті або канал https на віддалений сервер.


Розгортання розширення


При розгортанні розширення диспетчера IIS врахуйте, що потрібно зареєструвати тип постачальника модуля у файлі налаштування диспетчера IIS на сервері (% windir% system32inetsrvconfigadministration.config). Налаштування, показана на рис. 9, реєструє постачальник модуля і надає можливість використовувати його на всіх веб-сайтах за замовчуванням. Зауважимо, що і клієнтська, і серверна збірки, утворюють розширення, Mvolo.ResponseModificationUI.Server.dll і Mvolo.ResponseModificationUI.Client.dll, повинні бути зареєстровані в глобальному кеші зборок (GAC) і, отже, повинні мати суворе ім'я і підпис. Це вимога, що дозволяє виконати установку розширень диспетчера IIS.
Figure 9 Налаштування розширення диспетчера IIS

<moduleProviders>

<!– Mvolo ResponseModification –>
<add name=”ResponseModification”
type=”Mvolo.ResponseModification.UI.Server
.ResponseModificationModuleProvider,
Mvolo.ResponseModificationUI.Server,
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=895e90205a14f2aa,
processorArchitecture=MSIL” />
</moduleProviders>

<!– For all Sites –>
<location path=”.”>
<modules>

<add name=”ResponseModification” />
</modules>
</location>


Коли диспетчер IIS використовується для віддаленого управління сервером, він автоматично запропонує користувачеві завантажити клієнтську збірку незалежно від того, є вона вже або ще немає (це відбувається при управлінні IIS 7.0 на Windows Server 2008 клієнтом Windows Vista SP1, Windows XP або Windows Server 2003 з використанням віддаленого диспетчера IIS, що доступний за адресою: iis.net / downloads /? tabid = 34 & g = 6 & i = 1524). Перш ніж почати установку, переконаєтеся в тому, що довіряєте як сервера, до якого підключилися, так і видавцеві розширення диспетчера IIS, оскільки в іншому випадку це може привести до запуску на вашому комп'ютері шкідливого коду з повноваженнями вашого профілю.


Остаточне складання


Після розгортання модуля і установки схеми розділу настройки і розширення диспетчера IIS функція зміни відповіді готова до використання. Тепер можна застосовувати цю функцію до будь-якого додатка на вашому сервері і налаштовувати його за допомогою будь-якої програми налаштування або інтерфейсів API IIS 7.0.
Крім того, можна використовувати диспетчер IIS для швидкого управління правилами зміни відповідей у додатках як на локальному, так і на віддаленому сервері. Використовуючи підтримку делегування диспетчера IIS, можна встановити, хто з користувачів має право віддалено створювати і змінювати правила зміни відповідей для певних веб-вузлів сервера.
Для демонстрації функції зміни відповідей у дії на рис. 10 показано, як налаштовані правила для програми Qdig моєї галереї зображень (див. msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7). На рис. 11 показано, як використаний фільтр Mvolo.ResponseModification.Filters.RegExReplace, що поставляється в складі платформи зміни відповіді, щоб вставити текст колонтитулів на всіх сторінках веб-сайту без зміни початкового коду програми.
Figure 10 Вмикання колонтитулів

<responseModification enabled=”true”>
<add name=”Header”
conditionType=
"Mvolo.ResponseModification.Conditions.ContentTypeCondition"
condition=”text/html”
replaceType = "Mvolo.ResponseModification.Filters.RegExReplace"
replace=”<body([^>]*)>”
replaceWith = "<body$1> <h1 align="center">
Welcome to my gallery!</h1>”
options=”IgnoreCase” />

<add name=”Footer”
conditionType=
"Mvolo.ResponseModification.Conditions.ContentTypeCondition"
condition=”text/html”
replaceType = "Mvolo.ResponseModification.Filters.RegExReplace"
replace=”</body>”
replaceWith=”<h3 align="center">
Copyright mvolo 2007</h3></body>”
options=”IgnoreCase” />
</responseModification>




Рис. 11. Використання модуля зміни відповідей для зміни відповідей


Модуль зміни відповідей може бути також використаний для виконання будь-якої кількості призначених для користувача вставок, підстановок гіперпосилань та інших схем зміни відповідей за допомогою фільтрів замін. Ці фільтри можуть бути розгорнуті глобально або разом з додатком і налаштовані за допомогою правил налаштування в розділі налаштування responseModification.


Створюйте самі


Є не так багато корисних способів використання функції зміни відповіді, а саме кожного разу, коли неможливо домогтися такого ж результату шляхом зміни вихідного коду програми (що завжди більше ефективно, ніж зміна відповіді "на льоту"). Наприклад, я завжди використовую її для впровадження невеликого сценарію в відповіді формату HTML, що змінює теги зображень для використання варіантів зображень з високим ступенем стиснення і потім "на льоту" замінює їх варіснатмі більш високої якості, в результаті забезпечується більш швидкий огляд при використанні повільних клієнтів. При цьому також використовується обробник зображень, який дозволяє отримати зображення формату JPEG з будь-якої необхідної ступенем стиснення для статичних зображень за допомогою інтерфейсів API компонента роботи із зображеннями Microsoft Windows. На рис. 11 показаний результат роботи, включаючи верхній і нижній колонтитули та попередньо завантажені зображення з низьким дозволом (перед тим, як вони автоматично будуть заміщені якісними зображеннями).
Зміна відповідей "на льоту" може бути досить дорогим механізмом як з точки зору завантаження ЦП, так і потреб в пам'яті, оскільки для зберігання змінних відповідей повинне бути виділено безліч буферів великого розміру. Така додаткове навантаження може виявитися неприйнятною для робітників веб-вузлів залежно від типу використовуваних фільтрів зміни відповідей, їх числа і вимог до продуктивності додатки.
Щоб отримати додаткові відомості про використання модуля зміни відповідей, слід завантажити сам модуль і його вихідний текст з веб-сайту розробників модуля зміни відповідей: (www.mvolo.com / responsemod). Коли ви ознайомитеся з роботою фільтрів відповідей і зможете спланувати їх застосування при наявності обмежень продуктивності для їх використання, вивчіть приклади, наведені на веб-сайті розробників модуля зміни відповідей. Для отримання додаткових відомостей про розширення IIS 7.0 настійно рекомендуємо відвідати веб-сайт за адресою: iis.net і мій блог mvolo.com, який присвячений розробці та використанню IIS 7.0.

Майк Володарський (Mike Volodarsky) є технічним керівником програми в групі "Web Platform and Tools" корпорації Майкрософт. Протягом останніх чотирьох років він керував розробкою і створенням основної функціональності для ASP.NET 2.0 та IIS 7.0. В даний час його зусилля зосереджені на тому, щоб допомогти користувачам використовувати можливості цих технологій в середовищі Windows Server 2008.

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


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

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

Ваш отзыв

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

*

*