WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 3 | 4 ||

«том 2 альманах програ иста Тематический сборник материалов Library и Magazine ASP.NET Web-сервис Web-приложения альманах программиста Составитель Ю. Е. ...»

-- [ Страница 5 ] --

Табл. 2. Должностные обязанности (роли) Роль Вклад и важность Команда сетевых Настраивает оборудование для тестирования разработчиков на масштабируемость и разрабатывает спецификации продукта. Предоставляет информацию о трафике в производственной системе, Выявляет и устраняет узкие Важность: средняя. Если используется производственное оборудование, важность этой роли повысить Менеджер Обеспечивает контроль за тем, чтобы все внешние по контролю качества модули, нужные для развертывания, были проверены в лаборатории тестирования под нагрузкой и в группе контроля качества. Важность: средняя Самая важная роль у базы данных (DBA), который не входит в штат лаборатории. Корни большинства проблем с масштабируе мостью кроются в базе данных, стратегии доступа к данным (определяе мой, в том числе, хранимыми процедурами, готовыми SQL-выражениями или подставляемыми SQL-операторами) или технологии доступа к дан ным ODBC и т. д.). DBA помогает обнаружить и решить проблемы, связанные с данных: дорогостоящую индексацию, излишние блоки ровки и транзакций. В идеале для ключевых задач тестирования под нагрузкой нужно выделить отдельного администратора с высокой ква лификацией.

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

, Определите стратегию тестирования Ваш клиент может спросить: «Справится ли система с тысячами пользо вателей?» Обычный подход к тестированию под нагрузкой требует писать сценарии и тесты в попытке точно ответить на такой вопрос.

При этом вы должны определить, что понимать под словом «справится» и что 1000 пользователей будет делать с сайтом в типичном случае. Нужно создать разные сценарии, соответствующие разным видам их действий на сайте вроде покупки товара или регистрации новой учетной записи. Затем надо оценить распределение пользователей по этим действиям. Для боль шего реализма в имитации взаимодействия пользователя с системой вы должны сделать некие предположения о времени, которое будет уходить у каждого из них на раздумья перед выполнением той или иной операции (времени ожидания). Тогда срез активности при тестировании под нагруз кой будет примерно соответствовать тому, что будет делать с сайтом то же число пользователей на практике.

Рекомендации по тестированию под В этой методологии несколько огрехов. Во-первых, результаты точны на столько, насколько точны предположения. Очевидно, неверные предполо жения дадут неверные результаты.

Во-вторых, для имитации реальных пользователей понадобится множе ство клиентских компьютеров. С точки зрения процессорной мощности и памяти, требуемой для одного виртуального пользователя, типичный кли ентский компьютер может имитировать примерно 200 пользователей. Со ответственно, если тестирование проводится в расчете на 2000 пользова телей, нужно 10 клиентских компьютеров дороговато! Тестирование сайта, на котором используется HTTPS, потребует дополнительного кли ентского оборудования.

Наконец, такой подход затрудняет обеспечение разработчиков информа цией, связанной с определенными действиями. Когда что-то идет не так, воспроизвести проблему зачастую очень непросто.

В качестве альтернативы мы предлагаем разрабатывать тестовые ситуа ции, ориентируясь на важнейшие вопросы:

• где узкие места системы и сколько параллельных запросов она может обработать?

• сколько несинхронизированных суперпользователей способен обслу живать один компьютер с приемлемым временем отклика?

• линейно ли масштабируется система при наращивании оборудования?

• есть ли проблемы со стабильностью, препятствующие работе сайта в производственной среде?

При этом команда разработчиков должна обеспечить вас дополнительной информацией о том, где могут возникнуть проблемы. Сосредоточьтесь на этих областях. В предыдущем примере узким местом скорее всего окажет ся отправка сведений о заказе (order submission). Отсюда вы можете сфор мулировать более специфические вопросы вроде «сколько параллельных запросов может обслуживать процесс Прицельная атака в та ких областях — самый быстрый и дешевый способ выдать разработчикам информацию, необходимую для улучшения системы. Советуем вам учесть следующие рекомендации.

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

Такой подход «сначала данные, допущения потом» позволяет собрать нео бработанную информацию от а затем на основе ваших допу щений оценить результаты в первом приближении. Не тестируйте те час ти сайта, где вероятность возникновения проблем невелика. Так, провер ка справочных разделов сайта или документов, предназначенных только для чтения, скорее всего не выявит узкие места в системе.

Web-приложения Синхронизируйте запросы Нацельте на узкие места синхронизирован ные запросы. Идея в чтобы смоделировать худшую ситуацию — все пользователи сайта обращаются к его узкому месту. Синх ронизируя запросы, вы делаете тест воспроизводимым. Без синхронизации воспроизвести сбой может оказаться затруднительно. Для этого можно задействовать точки синхронизации — функциональность, доступную в большинстве серьезных (и дорогостоящих) средств тестирования. Точка синхронизации (synchronization point) заставляет каждого виртуального пользователя ждать, пока остальные пользователи не достигнут опреде ленной точки в сценарии. Следующий запрос выполняется только после этого. Точки синхронизации позволяют точно выяснить число пользовате лей, которых может одновременно обслуживать потенциально узкое мес то. Так, нижним пределом могут оказаться семеро параллельных синхро низованных пользователей.

Не тестирование под нагрузкой в среде разработки Лучше создать отдельную среду для тестирования под нагрузкой, не со разработки и тестирования. Во-пер вых, даже совпадает с малове что вы сможете его и ПО. тестирования под нагрузкой требуют стабильной так как вряд ли захотите постоянно вать сценарии от теста к Некоторые продукты позволяют рировать в HTML или коде Однако изменения в именах страниц и фреймов, а также в строках конечно же, приведут к сбоям в сценариях. Вам явно захочется минимизировать В отдельной ния переписывать сценарии потребуется только при новой версии, а не течение всего рабочего дня.

Кроме того, разработчиков увеличивает нагрузку на среду при тестировании изоляция рудняется.

Наконец, при крайне важен контроль версий. Нужно результаты тестирования с номером конкретной версии. Без Этого вы не сможете точно разницу в производительности при очередных Применяйте суперпользователей Наконец, применяйте то, что мы назы ваем суперпользователями (super users). Время его раздумий равно 0. По мните, в обычной тестирования время раздумий вводится, чтобы виртуальные пользователи имитировали реальных. Однако умень шение времени раздумий виртуального пользователя увеличивает нагруз по тестированию Web-приложений под ку на сервер вдвое. с точки зрения нагрузки, для сервера важно лишь число запросов в секунду. Количество виртуальных пользователей в сочетании со временем их раздумий как раз и формируют нагрузку.

Для пояснения этой концепции воспользуемся математикой. Следующая формула позволяет оценить нагрузку (число запросов в секунду), создава емую реальными пользователями обращении к сайту:

Число запросов _ ( Число пользователей \( Число на страницу ) в секунду Например, у сайта 100 одновременных пользователей;

время передачи данных с сервера на клиентскую машину составляет 10 секунд, время раз думий — 30 секунд;

сайт генерирует примерно 2,5 страницы в секунду.

Предположив, что на одну страницу приходится 3 запроса, мы получим 7, запросов к Web-серверу в секунду.

Сравните количество запросов в секунду при запуске тестов с суперполь зователями и только что вычисленное значение. Наш опыт показывает, что соотношение реальных пользователей к суперпользователям обычно со ставляет 15:1. Для приведенного примера это означает, что суперпользова тели (100/15) генерируют нагрузку, сравнимую с нагрузкой 100 нормаль ных пользователей. Еще один пример. Допустим, время ответа становит ся неприемлемым, как только число суперпользователей достигает 10.

Отметьте себе это число запросов в секунду, чтобы пересчитать его потом применительно к реальным пользователям. Теперь вы можете делать лю бые предположения о времени раздумий и даже изменять его, не запуская тест повторно. Через несколько дней тестирования вы сможете автомати чески пересчитывать суперпользователей на реальных пользователей.

Этот подход позволяет обходиться сравнительно небольшим числом поль зователей, уменьшать потребность в клиентском оборудовании и сокра щать расходы на ПО для тестирования под нагрузкой.

Эти тесты с суперпользователями стоит проводить не только на одном компьютере. Чтобы протестировать сайт на масштабируемость, добавьте второй Web-сервер и компонент балансировки нагрузки, а затем повтори те тест с суперпользователями. В идеале вы сможете удвоить количество суперпользователей при сохранении того же времени отклика.

Чтобы ответить на вопрос о стабильности, запустите тест с разумным ко личеством параллельных несинхронизированных суперпользователей на длительное время. В своем прошлом проекте мы запускали на 24 часа, но конкретное время зависит от приложения. Мы называем это тестом на «выжигание Приняв меры для выявления и, возможно, устранения узких мест, повторите тест с точками синхрониза ции и посмотрите, поднялся ли нижний предел. Затем снова запустите тест на «выжигание с новым количеством параллельных поль зователей. Повторяйте этот цикл, стремясь улучшить показатели, пока не достигнете за которым качество обслуживания становится непри емлемым.

А сколько же пользователей?

Хотя такой подход обеспечивает разработчиков ценной информацией, он не дает ответа на вопрос того самого клиента. Но вы можете прикинуть, каким может быть ответ. Допустим, время отклика для самого узкого мес та сайта — более 10 секунд при 20 суперпользователях на Вы числения по предложенной нами формуле показывают, что это около реальных пользователей. На этом этапе вы делаете примерно те же пред положения, как и при обычной методологии. Сколько процентов пользо вателей чаще всего будет обращаться к этому разделу сайта?

ожидается, что к данному разделу обратятся 50%, а другие разделы, где, скажем, хранится документация или можно считать какие-то сведения из базы данных, не столь популярны. Значит, система с одним Web-сервером справится примерно с 600 пользователями.

До сих пор мы рассуждали о том, что делать, если можно точно указать на узкое место сайта, но как быть, если на производительность влияет не сколько таких мест? Ответ — создать тест-сценарии, индивидуально ана лизирующие каждое узкое место. Вначале запускайте сценарии по отдель ности, затем все вместе и сравните результаты, чтобы выяснить, как одна область сайта влияет на другую.

Четко определяйте показатели Теперь нужно четко определить показатели — например число обработанных в минуту, или время выполнения запроса к в мс. Показатели позволяют количественно оценить эффект от изменений, внесенных между тестами. Они также дают возможность проводить срав нение со стандартами, определенными для Web-приложения.

Решая, какие показатели нужно отслеживать, определите круг вопросов, на которые вы должны ответить. Этот шаг вполне понятен. Так, вас может интересовать время отклика при выписке счета. Не забудьте, вопросы сле дует формулировать с учетом стратегии тестирования и избегать нечетких вопросов, которые вы не сможете проверить.

После этого нужно определить планку качества (quality к значениям показателей, необходимых для ответа на каждый вопрос. Возьмем типич ный процесс отправки заказа. Допустим, сайт должен обрабатывать 10 зап росов в минуту при пиковой причем пользователь не должен ожидать выполнения запроса более 30 секунд. Установить такой стандарт по тестированию Web-приложений под нагрузкой вам помогут сведения из нескольких источников. для нача ла с бизнес-сообществом, чтобы прочувствовать, какие уровни производи тельности там рассматривают как приемлемые. Если какая-то версия ва шей системы уже работает в производственном режиме, нужные данные можно получить на основе текущей активности такого сайта и краткосроч ных прогнозов увеличения трафика или запросов к существующей базе данных для выявления тенденций.

Определив список вопросов и планки качества, можно выбрать подходя щие показатели. Если взять предыдущий пример, то количество заказов в минуту и число заказов в данном тесте — неплохие высокоуровневые по которые можно рассматривать как индикаторы рабочих характе ристик сайта в сравнении с заданной планкой качества. Именно об этих показателях вы сообщаете руководству в отчетах о ходе тестирования.

Показатели более низкого уровня отражают производительность и помо гают сократить число узких мест в системе (или вообще устранить их), а также бороться с нестабильностью. Рост производительности может на прямую повлиять на высокоуровневые показатели. Так, ускорение тран закций может привести к увеличению числа заказов в минуту.

Большинство средств тестирования под нагрузкой позволяет устанавли вать таймеры на отдельных страницах или их группах и наблюдать сред нее время выполнения теста. Однако выяснить, что именно в системе нуж но улучшить, это не поможет.

Вот тут вам пригодятся счетчики производительности (performance coun ters) в Windows. Например, вы можете следить за счетчиком Process:

Private Bytes для процесса dllhost, чтобы обнаружить утечки памяти в сво ем серверном пакете. Детальное описание счетчиков, относящихся к Mic rosoft Internet Information Services (IIS), см. по ссылке soft.com/TechNet/iis/iis5tune.asp;

кроме того, в табл. 3 дан список основ ных счетчиков, используемых в тестировании под нагрузкой.

Однако счетчики производительности полезны только в идентификации симптомов проблемы, а не ее причины. Если ваша система при 20 одновременных пользователях, счетчик Active Server Pages: Requ ests Timed Out может действительно подтвердить, что по крайней мере для одного пользователя время ожидания ответа истекло, но найти причину этого не проще, чем иголку в стоге сена. Дело в том, что счетчики произ водительности предоставляют данные в основном на уровне ОС и сети. А чтобы найти корень проблемы, нужны данные на уровне приложения.

Важнейшее условие решения этой задачи — создание распределенной си стемы протоколирования, которая собирает данные о рабочих характери стиках и об ошибках внутри вашего приложения и их в центра хранилище. Тогда вы сможете моментально узнавать, работа ет ли система. Если нет, у вас есть вся информация, необходимая для ло кализации проблемных участков.

3. Важнейшие счетчики производительности Счетчик Active Server Pages: Если счетчика низки на пиках трафика, Requests Second в приложении есть узкие места Active Server Pages: Если страница выполняется быстро и ей не приходится Requests Executing ждать операций ввода-вывода, показания этого счетчика скорее будут низкими. Если странице приходится ждать завершения таких операций, показания скорее всего будут выше Active Server Pages: Должен около 0, но при изменении нагрузки Requests Queued его могут варьироваться. По достижении пропускной способности сервера значения этого счетчика должны увеличиваться, иначе в вашем приложении имеет место конкуренция за ресурсы System: Processor Отражает число потоков, ждущих выполнения в очереди, Queue Length общей для всех процессоров в системе. Если этот счетчик заметно выше процессоров, узкое место в системе — количество процессоров System: Context Сводный показатель, указывающий частоту переключе Switches Per Second ния между потоками. Рост числа потоков может привес ти к такой частоте переключений контекстов, что производительность резко упадет. Наличие 10 и более переключений на запрос — уже много Process: Private Bytes Текущее количество байтов, выделенных данным в собственное пользование (к этой памяти не могут обращаться другие процессы). Чтобы обнару жить утечки памяти, понаблюдайте за этим показателем несколько часов Processor: Процентная доля времени, в течение которого процессор % Processor Time выполняет непростаивающий поток. Высокое значение этого счетчика в отсутствие чрезмерной нагрузки на сетевой адаптер и подсистему дискового ввода-вывода указывает на узкое место, связанное с процессорами Distributed Transaction Число активных в настоящее время транзакций Coordinator: Active Transactions Интерпретация показаний Теперь в ваших руках масса информации. Но как ею воспользоваться? Мы рассмотрим три варианта интерпретации показаний счетчиков: в Perfor mance Monitor, и средствах тестирования под нагрузкой, предостав дополнительные счетчики производительности.

Рекомендации по тестированию Web-приложений под нагрузкой Performance Monitor (PerfMon) в Windows 2000 позволяет значения счетчиков в виде графиков. Другая полезная функция — показаний счетчиков, записанных в файлы журналов, что позволяет визу ально оценивать результаты теста. Рис. 1 иллюстрирует, как с помощью Performance Monitor можно интерпретировать активность приложения онлайновой обработки заказов на сайте.

Рис. 1. Интерпретация в PerfMon активности сайта В состав Windows DNA Performance Kit Beta входит утилита, похожая на Performance Monitor, — Perfcol. Разница между ними в том, что последняя сохраняет собранную информацию в базе данных, а не в файле. Ее можно скачать по ссылке Некоторые средства тестирования под нагрузкой, в том числе Microsoft Application Center Test (ACT) и комплекс e-TEST от Empirix, поддержи вают встроенные счетчики и регистрируют их показания в ходе тестов.

Затем эти сведения записываются в базу данных для дальнейшего исполь зования. ACT из состава Visual Studio интегрируется со счетчиками Performance Monitor, сохраняя все данные тестов в единое хранилище.

Интегрирована в ваше средство тестирования какая-то функциональность мониторинга счетчиков или нет, все равно может понадобиться инстру мент наподобие Performance Monitor, особенно если у серверов, генериру ющих нагрузку, нет соответствующих прав доступа для мониторинга ров приложения (что не когда в среде установлены брандмауэры).

Независимо от выбранного инструмента мониторинга жизненно важно сохранять показатели каждого прогона теста для последующей оценки.

Чтобы понять, как система реагирует на внесенные изменения, потребуют ся и прошлые данные.

382 Web-приложения Мы рекомендуем создать средство для просмотра данных уровня прило жения, собранных системой протоколирования. Оно должно предостав лять прямой доступ к информации об ошибках и рабочих характеристиках из одного места. Это стоит затраченных усилий, так как альтернатива го раздо хуже — генерация SQL-запросов в командной строке всякий раз, когда вам нужны какие-нибудь данные.

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

Первое, о чем следует подумать, — бесплатные утилиты вроде Windows Application Stress Tool (WAST). Его можно скачать с сайта Microsoft (http:// На другом конце шкалы стоят более гибкие инструменты, например ACT или комплекс e-TEST от Интерфейс для генерации нагрузки (из комплекса е TEST), приведен на рис. 2, Очевидно, что WAST подходит для небольших, не слишком сложных сай тов. С ним легко протестировать несколько ключевых страниц сайта и получить представление о времени отклика. Однако это скорее средство изолированного тестирования, чем тестирования многостра ничного сайта. Кроме того, для тестирования сложных сайтов (и реализа ции некоторых рекомендаций из этой статьи) нужны определенные фун кции, которых в WAST нет. Получение комплексных результатов при ра боте с WAST потребовало бы дополнительной настройки приложения на тестирование под нагрузкой, что явно нежелательно.

Для проведения тестирования рекомендованного нами для сложных сай тов, больше подходит инструмент вроде ACT или комплекс типа e-TEST.

Если вы ведете разработки в среде ACT легко интегрируется в ваш цикл разработки. Но чтобы создавать мощные от вас потре буется знание объектной модели ACT и умение программировать. А в слу чае с e-TEST вам придется приобрести лицензию на пользование этим комплексом.

Качественный инструмент не только позволяет эффективно протестиро вать сайт, но и сообщает о результатах в удобной форме. И ACT, и e-TEST предоставляют гибкие средства для формирования отчетов и все возмож ности для построения любых графиков. Соответствующий интерфейс ACT показан на рис. 3. Стандартная функциональность и особенности каждо го из этих инструментов в табл. 4.

по тестированию под нагрузкой - • I Рис. 2. Инструмент Empirix e-Load •.

Рис. 3. Интерфейс для отображения результатов Если вам требуется более серьезный инструмент, имейте в что на его настройку понадобится немалое время. В документации на некоторые ин струменты утверждается, будто тест-сценарий можно написать за пару часов. Но это возможно лишь при наличии у вас опыта работы с этим или похожим инструментом;

приготовьтесь к тому, что вы потратите несколь ко дней или даже недель в зависимости от сложности вашего сайта. Наше первое тестирование потребовало примерно трехнедельной подготовки.

Даже потренировавшись на предлагаемых примерах, некоторые трюки можно освоить, только имея достаточный опыт и изрядно пообщавшись со службой технической поддержки. Стоимость часов, потраченных на осво ение инструмента, может перевесить стоимость учебного курса или опла Табл. 4. Сравнение функциональности инструментов тестирования Функция Комплект Empirix e-TEST Application Center Test Web Application Stress Tool Эмуляция Эмулирует Web-трафик. Ведет Предоставляет Записывает а затем браузера уровне объектов, от доступ к сценариям, генерирующим их. Не принимает во пробле мых изменений в коде. Генерирует запросы нагрузку. Эмулирует некоторые мы, связанные с потоками, сценариями, выпол браузера во множестве потоков, имитируя функции в частности, ав- няемыми на клиентской стороне, и ряд других реальный трафик томатически обрабатывает файлы факторов, влияющих на то, как реальный брау зер запрашивает страницу. Входящий ответ не cookie зависит от исходящего запроса Точки синхрони- Доступны путем настройки свойств Вручную программируются в Не поддерживаются зации Позволяет время и число итера- Позволяет указывать время, число Тесты привязаны ко времени, поэтому нет га теста ций или останавливать тест вручную итераций или останавливать тест рантии, что начальное состояние будет соответ вручную ствовать конечному Регрессивное Служит средством как создания Сценарии, применяемые тести- Данный инструмент предназначен тестирование так и тестирования рования под могут слу- только для тестирования под жить для функционального тестиро вания. Для выявления ошибок требу ет программирования сценариев Распределение Допускается Недоступно Допускается координация тестов, нагрузки на нескольких компьютерах на нескольких компьютерах клиентскими компьютерами Генерация Сохраняет информацию сеанса в базе дан- Сохраняет информацию сеанса вроде информацию сеанса в базе данных.

ных. Предоставляет таймеры страницы и статистики и поддержки таймеров страницы или профи таймеры профиля (варианта тестирования). ни приема первого/последнего байта ля. Отчеты выводятся только в виде таблиц Поддерживает отображение ответа. Отражает от гестов время теста) в к тесту в графиков виде Поддерживает, но в зависимости от сцена- Не поддерживает Не поддерживает ентских сценари- рия может потребовать наличия агента на ев клиентской стороне, который расходует больше памяти. Сначала попробуйте ис пользовать «тонкий» клиент Рекомендации по тестированию Web-приложений под ту опытного консультанта. Кроме того, вы не компенсируете потерянное время, если опоздаете с началом тестирования — в таком случае советуем вам и первое, и второе.

Храните свою Количество запускаемых в течение дня или даже недели, может варьироваться. Если вы настраиваете Web-сервер, вам может потребовать ся серия часовых тестов. Если цель — проверить стабильность приложе ния, скорее всего тест придется запустить на всю ночь. Но в любом случае, не располагая прошлыми данными, отслеживать прогресс от теста к тесту затруднительно. Очень важно, чтобы вы могли легко проверить, что уже •протестировано, с какими результатами и что нужно протестировать далее.

Как минимум, следует записывать начальное и конечное время выполне ния теста, число виртуальных пользователей в тесте, а также сведения о цели тестирования и внесенных изменениях. По окончании серии тестов надо описать их результаты.

Заключение Тестируя сложное будьте готовы к тому, что вы обнару жите проблемы, не выявленные при системном тестировании. Ошибки в архитектуре приложения раскрываются только при тестировании под на грузкой, т. е. при проверке на масштабируемость, производительность и стабильность. Для этого вам потребуется отдельная среда с оборудовани ем, сопоставимым с производственным, серьезный инструмент тестирова ния и определенный штат сотрудников (хотя бы несколько человек).

Правильно выбранные показатели позволят выяснить, соответствует ли ваша система установленной планке качества. С точки зрения тестирова ния на масштабируемость, важнейшими являются сведения об ошибках и рабочих характеристиках, собранные распределенной системой протоко лирования, так как она предоставляет информацию уровня приложения.

Применяя наши рекомендации и документируя все свои действия, вы обеспечите беспроблемное развертывание Web-приложения.

Джеф (Jeff Dunmall) — главный консультант в Imason Inc., консал тинговой фирмы, которая специализируется на интеграции унаследованных приложений создающих бизнес-приложения и приложения для электронной коммерции между предприятиями В2В). С ним можно связаться по адресу Кит Кларк Clarke) — независимый консультант из Торонто. Кроме тестирования на масштабируемость, занимается консалтингом в области серверных.NET-технологий и преподаванием. С ним можно связаться по адресу keith.clarke@imason.com.

Гарри Пирсон Настройка визуального представления сайта на основе Один из способов сделать и приложения удобнее для заказчиков — предоставить им возможность персонализации. Применительно к Web-сайтам это означает, что информационное наполнение (контент) должно ся так, как того хотят пользователи. А случае полнофункциональных клиентских приложений это подразумевает возмож ность выбора пользовательского интерфейса (UI) за счет поддержки скинов (skinning), аналогичных темам (themes) в Windows XP. Здесь узнаете, как применить такой прием к чтобы их функциональность доступна через сменные UI. Эта задача решается за счет использования многофункциональных XML-классов (rich XML classes) Framework и встроенной в ASP.NET поддержки расширяемости.

Поддержка скинов обеспечивает смену дизайна графического пользова тельского интерфейса (GUI) приложении, не влияя на функциональ ность самого приложения. Несмотря на популярность технологии скинов в мире полнофункциональных клиентских приложений и все ее преиму она пока редко применяется в Web. А ведь поддержка скинов на Web-сайтах позволила бы настраивать его для каждого пользователя в от дельности. Одна из причин такого положения вещей — отсутствие инст рументов для создания Web-приложений с поддержкой скинов.

Web-формы, предоставляемые ASP.NET, становятся популярным сред ством доставки динамического Web-контента. Фактически это просто страницы на основе заполняемые данными во время в Редакция. 2003. № 3 — Прим.

Настройка визуального сайта ASP.NET на основе XML-классов роса. Применение скинов в таких страницах требует изменений в HTML шаблоне каждого типа страниц. Подобные изменения требуют написания большого объема кода. Короче нужен новый инструмент. К счас тью, расширяемость ASP.NET избавляет от необходимости заново изобре тать колесо.

Расширение ASP.NET В исходной модели ASP система обработки Web-запросов была нерасши ряемой. Каждый Web-запрос отображался на ASP-файл, который по сути действовал как функция, возвращающая строку. Если вы хотели получить контент в некоем нейтральном формате, а затем отображать его в браузе ре с определенным скином, всю работу приходилось выполнять самостоя тельно. Следовало либо вручную кодировать для представ ления данных в нейтральном а затем применять к ним скин, выб ранный пользователем, либо создавать свое API-расширение. ISAPI тре бовал обработки всех низкоуровневых деталей — таких абстракций, как Request и Response, вы лишались. Все нужно было делать самому.

При проектировании ASP.NET стала очевидной необходимость в примене нии минимум двух моделей обслуживания Web-запросов;

Web-формы и Web-сервисы Поскольку требовалась поддержка более чем одной модели, имело смысл абстрагировать базовую функциональность в некую инфраструктуру, на которую могли бы опираться конкретные модели. Раз работчики ASP.NET так и поступили.

Эта абстракция хорошо заметна в структуре пространств имен, относя щихся к Web. Базовая функциональность содержится в пространстве имен В нем хранятся такие классы, как HttpRequest и HttpRespon se. Над базовой функциональностью надстраиваются пространства имен и с классами для Web-форм и Web сервисов XML соответственно. В этой статье я построю модель обработки Web-запросов, отделенную от Web-форм и Web-сервисов XML, но осно ванную на той же базовой функциональности ASP.NET.

Конвейер ASP.NET Прежде чем расширять модель следует изучить, как ASP.NET обрабатывает Web-запросы. Первый элемент в конвейере — Microsoft Internet Information Services (IIS), через который проходят все HTTP-зап росы. При установке ASP.NET устанавливается пере сылающее запросы на файлы типов, поддерживаемых ASP.NET, в испол няющую среду ASP.NET. Пересылка осуществляется на основании расши рения запрошенного файла.

Заметьте, что в Windows Server эта процедура слегка изменилась. Там код прослушивания HTTP перенесен в ядро операционной системы и мо жет использоваться любым процессом. Таким образом, сервисам, обраба тывающим Web-запросы напрямую (как ASP.NET), больше не нужна пе ресылка запросов через IIS. это изменение затрагивает лишь кон фигурацию сервера, и практически не от ражается на коде, который я покажу в своей статье.

Запрос, перенаправленный ASP.NET, попадает в конвейер ASP.NET и ини циирует ряд событий. Некоторые из и обрабатываются специальными классами — так называ емыми HTTP-модулями (HTTP modules), аналогичными рам. Эти классы регистрируются на обработку определенных запросов при запуске и выполняют такие задачи, как идентификация пользователей и проверка прав доступа к запрашиваемому ресурсу. Одна ко эти модули не участвуют в генерации контента, возвращаемого клиен ту. Эту функцию выполняет HTTP-обработчик (HTTP handler).

— это классы, реализующие интерфейс IHttpHandler, который состоит из двух метода ProcessRequest и свойства только для чтения. ProcessRequest вызывается конвейером ASP.NET для генерации контента в ответ на запрос. Свойство IsReusable использу ется лишь для поддержки пула обработчиков (handler pooling). По нему исполняющая среда определяет, можно ли повторно задействовать данный экземпляр обработчика или его надо уничтожить и создать новый экзем пляр для обработки следующего запроса. ProcessRequest принимает один параметр — класс HttpContext, исполняющий функции контейнера для глобальных внутренних объектов классического ASP: Request, Response, Server, Session и Application. Кроме того, он предоставляет новые внутрен ние объекты, например свойства User, Cache и Trace. При вызове Process Request динамически создает контент и записывает его в поток context. Output, Информация о находится в файле Каж дое Web-приложение хранит в таком файле все параметры своей конфи гурации. Параметры наследуются, поэтому базовую конфигурацию мож но однажды задать в файле и больше не записывать ее в каждый файл Web.config на сервере. В разделе HTTP-обработчиков (http Handlers) пути и имена файлов (с символами подстановки) сопоставляют ся конкретным обработчикам, которые будут обслуживать запросы. Най дите в разделе строку:

Настройка представления сайта на основе Она указывает на то, что любой Web-запрос файла будет обрабо тан классом Я помещу подобную стро ку в файл своего приложения ASP.NET, чтобы обрабатывать XML-файлы собственным HTTP-обработчиком.

Возможность вставки в конвейер обработчика Web-запросов на определенные файлы — вещь полезная, но ASP.NET предоставляет еще более мощный механизм для обработки таких запросов — фабрику обра ботчиков (handler factory). Это реализация общеизвестного шаблона Fac tory, позволяющая определять, какой обработчик должен обслужить дан ный Web-запрос.

В файле Web.config (или можно сопоставить определен ный путь не самому обработчику, а фабрике обработчиков. Пример такого сопоставления можно найти в файле odd При запросе конвейер ASP.NET вызовет метод GetHandler фабрики обра ботчиков. Фабрика с любого из своих механизмов создаст экзем пляр класса обработчика, в том числе класса, динамически генерируемого при первом запросе данной страницы. Именно так Web-формы ASP.NET поддерживают скомпилированные Web-страницы. сопостав ляются классу который компилирует данную Web страницу в исполняемый класс при первом запросе к ней. Затем Page HandlerFactory извлекает исполняемый модуль из кэша сервера, создает новый экземпляр и возвращает этот обработчик для данного Web-запроса.

Поддержка скинов для Чтобы задействовать скины на Web-сайтах, контент страниц нужно вать в нейтральном к UI формате. Сгенерировав такой вы приме няете к нему нужный скин. Очевидно, что представить контент в нейт ральном к формате лучше всего через XML, а это подразумевает ис пользование XSLT в качестве средства форматирования скинов. Решения на основе таких промышленных как и XSLT, дают воз можность сосредоточиться в основном на специфической реализации Web-скинов. Кроме того, это позволяет задействовать глубокую поддерж ку и XSLT, предоставляемую Microsoft Framework Base Class Library.

В качестве отступления замечу, что SQL Server 2000 поддерживает меха низм шаблонов для динамической генерации и применения XSLT.

Этот механизм служит отправной точкой для создания механизма поддер 390 Web-приложения однако факторы ограничивают применение XML-шаблонов из SQL Server 2000 для поддержки Web-скинов. Во-пер вых, такие шаблоны могут получать данные только из одной базы SQL Server 2000. Во-вторых, в них нет механизмов выборки данных из других потенциальных источников, например от бизнес-объектов. Наконец, от сутствует механизм динамической смены XSLT-скина в период выполне ния. Имя должно либо статически встраиваться в шаблон, либо передаваться в строке запроса. Мой механизм поддержки Web-ски нов, о котором я расскажу, устраняет эти ограничения.

Как и SQL-механизм XML-шаблонов, механизм поддержки Web-скинов использует ряд специальных представляющих динамический кон тент, получаемый в период выполнения. Эти тэги определены как часть пространства имен отображаемого по соглашению на префикс «skin». Эти тэги позволяют находить контент, полученный в результате запросов FOR XML (SQL Server 2000) от биз нес-объектов или внутренних данных в HTTP-запросах (строки запроса, форм, cookie и т. д.). Список тэгов приведен в табл. 1;

он может быть расширен для поддержки других источников данных, например Web сервисов и SQL Server 2000.

Табл. 1. XML-тэги динамического контента для Тэг Описание Class Создает экземпляр -объекта и присваивает ему имя переменной Вызывает метод бизнес-объекта, объявленного через class.

Сохраняет метода в Database Создает соединение с базой данных SQL Server 2000 и присваивает ему определенное переменной Query Выполняет запрос FOR XML к базе данных SQL Server 2000, объявленной через тэг database. Сохраняет результат запроса в Parameter Указывает параметр Значение может быть указано явно или получено от одного из наборов HTTP-запросов Принимает данные одного из внутренних наборов HTTP запросов, переводит их в формат XML и сохраняет в Transform Вызывает метод бизнес-объекта, через тэг class.

Метод строку, содержащую имя XSLT-файла. который применяется к контенту, клиенту Любые XML-узлы, не входящие пространство имен схемы Web-скинов, не изменяются. Это позволяет вводить в документ не кую статическую структуру — подобно тому, как может включать в свои страницы статические HTML-тэги.

Настройка визуального представления сайта на основе XML-классов Реализация обработчика В файле проекта обработчика содержится два класса: SkinHandler и Skin Util. включает весь код, необходимый для обработчика ASP.NET: он реализует интерфейс IHttpHandler и предоставляет метод ProcessRequest, Однако некоторые из вспомогательных функций находят ся в классе SkinUtil и определены как статические методы. Это позволит повторно использовать вспомогательные функции SkinUtil в динамичес ки создаваемых классах SkinHandler, когда чуть позднее я создам фабри ку SkinHandlerFactory.

Главная функция класса SkinHandler — метод ProcessRequest. Исходный код класса можно скачать по ссылке http://msdn.microsoft.com/msdnmag/ (в разделе за март), а здесь я рассмотрю лишь некоторые его фрагменты.

В отладочных целях первое, что делает метод ProcessRequest, — проверя ет значение admin из строки запроса. Если оно равно метод просто передаст исходный XML-шаблон без всякой обработки.

Этот блок кода размещен внутри оператора условной компиляции #if так как он нужен только на этапе отладки.

После проверки на режим отладки ProcessRequest загружает экземпляр с запрашиваемым XML-файлом и обращается к DOM через метод TagName для выборки всех узлов из документа в простран стве имен WebSkin. Важно отметить, что этот запрос возвращает динами ческий список XmlNodeList, т. е. при внесении изменений в нижележащий DOM меняется и XmlNodeList. Далее я перебираю этот список и заменяю все узлы WebSkin соответствующим динамическим Как видно из следующего фрагмента, я не столько перебираю список, сколько по вторно и удаляю его первый элемент до тех пор, пока список не опустеет:

// Получаем список узлов в пространстве SkinUI XmlNodeList = // Обрабатываем каждый узел while > 0) XmlNode node = // Обрабатываем и удаляем узел После того как список подлежащих обработке узлов получен, оператор switch сверяет имя каждого узла со списком узлов пространства имен (табл. 1). Узлы каждого типа (кроме Parameter и Transform) обрабатываются собственной вспомогательной функцией. Узлы Parameter всегда вложены в узлы Query и обрабатываются вспомогательной функци ей для Query. XML преобразуется после обработки всех остальных узлов, поэтому код для Transform просто сохраняет данные этого узла во вспомо гательном классе. Поскольку к XML-документу можно применить только одно преобразование, код обработки Transform следит и за тем, чтобы в документе был лишь один узел Transform, и выдает ошибку, если таких узлов больше.

Запросы FOR XML В пространстве имен WebSkin три узла для работы с запросами SQL Server 2000: database, query и Сначала узел database при помощи стро ки подключения устанавливает соединение с базой данных SQL, Кроме того, он определяет имя переменной, через которую можно будет ссылать ся на это соединение. Используя указанную строку подключения, обработ чик узла database создает экземпляр SqlConnection, а затем сохраняет его в объектном словаре (object dictionary), инициализируемом при запуске функции, обрабатывающей запрос. Этот словарь хранит все соединения с базой данных и экземпляры бизнес-объектов, объявленные через узлы class и database. Для перехвата ошибок в ProcessRequest служит конструк ция В блоке finally объектный словарь просматривается, и все соединения с базами данных закрываются.

После объявления базы данных можно определять запросы с помощью узла query. В нем указывается соединение, для которого формируется зап рос, и тип запроса (например текст или хранимая процедура). Текст узла должен представлять запрос или хранимую процедуру, возвращающую XML. В узел query может быть вложено несколько узлов parameter. Вог как выглядит узел query с дочерним узлом parameter из приложения-примера:

/> SELECT * Products WHERE = AUTO В этом узле query параметр передается как элемент id строки запроса. Параметр позволяет сослаться на любой набор запросов и указать значение по умолчанию, которое следует использовать, если указанного элемента в наборе нет.

Код, обрабатывающий данный узел, создает объект исполь зуя указанный экземпляр SqlConnection и текст команды. Затем он пере Настройка визуального сайта ASP.NET на основе бирает все дочерние узлы в поисках узлов parameter. Найденные узлы parameter преобразуются в объекты-параметры и добавляются в список параметров По завершении обработки команда исполняется через ExecuteXmlReader вспомогательной функцией Execute из класса SkinUtil. Полученный импортируется как фрагмент докумен который подставляется вместо узла query. Класс содер жит очень полезную функцию преобразующую потоковый XmlReader в DOM-представление XmlNode. Главная часть вспомогатель ной функции Execute выглядит так:

XmlReader = = XmlNode xn;

while = null) { Пространство имен WebSkin содержит два узла для работы с бизнес объектами: class и Узел class действует подобно узлу database.

Он указывает сборку, имя класса и имя переменной для бизнес-объекта.

При обработке узла class указанная сборка динамически загружается из подкаталога bin Web-приложения с поддержкой скинов. Затем создается экземпляр указанного класса, и этот экземпляр сохраняется в том же объектном словаре, что и соединения с базами данных. То есть пе ременных для соединений с базами данных и для бизнес-объектов не дол жны совпадать. Вот как выглядит код, динамически класс по имени:

string filename = + + Assembly a = Object о = "class"), true);

Вспомогательная функция GetAttribException из XML-узла именованный атрибут. Если такого атрибута генерируется исключе ние. Если наличие атрибута необязательно, используйте вспомогательную функцию которая при его отсутствии возвращает null, Для обработки узла methodcall, предоставляющего имена переменной и вызываемого метода, обработчик использует механизм отражения 394 Web-приложения Механизм отражения в позволяет запрашивать объект, поддер живает ли он метод с именем. Следующий код выдает такой запрос к объекту и запускает соответствующий метод через отражение:

Type t = = = null);

Указанный метод должен определенной сигнатуре. Мето ды, вызываемые через тэги должны возвращать объект XmlNode (или null) и не принимать никаких параметров. Внутри бизнес-объекта информация о текущем HTTP-контексте доступна через статическое ство Current.

Требуя определенной сигнатуры механизм Skin не в состоянии вызывать произвольные методы или бизнес-объекты. Это значит, что биз должны быть рассчитаны на взаимодействие с и не должны использоваться повторно. Можно было бы предусмотреть меха низм для передачи параметрон вроде того, который применяется в запро сах к базам данных. Однако неспособности наборов HTTP-запросов хранить типы (complex types) такой механизм был бы чески бесполезен. SQL-запросы и хранимые процедуры используют в ка честве параметров простые типы и возвращают А во многих бизнес объектах для входных или выходных параметров применяются составные типы, например структуры, для обработки которых потребуется дополни тельный код. Чтобы обращаться к не соответствующим заданной сигнатуре, пришлось бы создать специальный интерфейсный объект.

Наборы Последним источником контента являются разнообразные наборы HTTP запросов (HTTP request collections): Cookie, и Param. для доступа к этим наборам называется В нем указывается набор, из которого следует получать данные.

При этом можно задать имя переменной и целевое пространство имен.

Если имя переменной не в DOM включается весь набор. Задавая целевое пространство имен, вы сопоставляете создаваемому XML-доку менту определенное пространство имен. Если оно не указано, использует ся пространство имен родительского узла.

предоставляет наборы HTTP-запросов как (к набору cookie это не относится). Поскольку все наборы реализованы единообразно и одинаково предоставляют доступ к своим данным, для обработки большинства узлов достаточно одного общего мето да. Метод обработчика служит оболочкой вызова метода Настройка визуального представлений сайта ASP.NET на основе XML-классов который использует вспомогательную функцию преобразующую элемент набора (collection entry) в XML. Если задано имя переменной, метод вызывает вспомогательную функцию только в ином слу чае она вызывается по одному разу для каждого элемента набора, ASP.NET предоставляет набор cookie в виде — набо ра объектов HttpCookie. Кроме значения, объекты HttpCookie содержат информацию о домене, сроке действия, пути и параметрах так что функции и работают практически идентично методам и Они отличают ся лишь типом наборов и механизмом кодирования элементов наборов.

Было бы неплохо использовать один набор методов для их обработки, но у объектов и HttpCookieCollection нет общих роди классов (кроме Преобразование Обработав все следует применить и только по том отправить контент браузеру. Тэг transform может ссылаться на статически или динамически. Если в нем указан атрибут XSLT файл для скина назначается статически. Но если в тэге заданы имена пе ременной и метода, обработчик определяет XSLT-файл вызовом указанно го метода. Это очень похоже на способ обработки тэга с тем отличием, что метод тэга transform возвращает не XML-узел, а строку.

После выбора XSLT-файла скина обработчик вызывает для преобразования. Если вместо выбранного файла возвращается null или пустая строка, клиентскому браузеру передается простой без скина. В ином случае создается новый объект Он загружа ется с выбранным и применяется к XML DOM, содержаще му контент. Для большей производительности XSLT-файл после заг рузки в объект XslTransform помещается в кэш HTTP-контекста. При пос ледующих запросах к этому XSLT-файлу обращаться к диску не понадо бится. Для каждого элемента кэша создается объект который обеспечивает синхронизацию и автоматически удаляет объект из кэша, если XSLT-файл на диске изменяется. Объект XslTransform загружа ется и помещается в кэш следующим образом:

XslTransform = if == null) I xslt = new xslt, new Web-приложения null, Приложение-пример В коде, который можно скачать к статье, вы найдете инструмент WebSkin и пример Web-приложения, работающего со скина ми, — DevHawk Books. Books выводит информацию о книге, ее авторе и издательстве из базы данных Pubs, Для запуска приложения ну жен SQL Server или Microsoft SQL Server 2000 Desktop Engine 2000). Каждая содержит тэг database, подключающий ся к базе данных Pubs на через доверяемое соединение. Если ваша база данных установлена в другом месте, измените строки подключения в тэгах database на каждой странице.

На рис. 1 показан простой отображающий черный текст на белом фоне, а на рис. 2 — красивый XSLT-скин с цветным логоти пом. Переключение между ними выполняется вызовом метода SetSkin объекта Controller. Он получает имя нового скина из строки запроса и за писывает cookie. Этот объект также содержит метод полу чающий текущий скин из cookie.

• DevHawk Books Рис. 1. Простой XSLT-скин Настройка представления сайга ASP.NET на основе XML-классов Рис. 2. Более яркий XSLT-скин Все в приложении DevHawk Books имеют расширение Поскольку IIS по умолчанию не передает HTTP-запросы к XML файлам в ASP.NET, я включил простой файл сценария на VBScript, выпол няющий соответствующую настройку. Я также включил сценарий на VB Script, настраивающий подкаталог DevHawk Books как виртуальную Web папку. Оба сценария выполняются при запуске файла install.bat.

Заключение ASP.NET как будто угадывает ваши желания. Если вы когда-нибудь смот рели на сайт и думали: «Мне нужно что-то другое», — то наверняка уже обнаружили, что архитекторы ASP.NET предусмотрели механизм, позво ляющий подключать нестандартную функциональность. В данном случае я заменяю встроенную поддержку Web-форм и Web-сервисов собствен ным механизмом, обслуживающим Web-запросы по своей схеме.

Масштабируемость можно повысить, создав механизм компиля ции Web-страниц со скинами. Писать код, создающий другой код, всегда не просто, но Microsoft Framework предоставляет объекты простран ства имен CodeDOM, которые берут на себя всю работу.

Гарри Пирсон Pierson) — старший архитектор в группе Architecture Team в С ним можно через сайт http://www.devhawk.net.

Учебный центр SoftLine Ваш курс начинается завтра!

С E R Т I F I E D Подготовка сертифицированных Technical Education и администраторов Microsoft Center и авторские курсы по:

Учебный центр SoftLine • Windows 119991 г. Москва, ул. Губкина, д. Sun Solaris • Visual Studio e-mail: educ@softline.ru • Электронной коммерции Безопасности информационных систем и еще более 40 курсов по самым современ ным технологиям.

В Дневные и вечерние занятия.

Опытные преподаватели.

* • Индивидуальные консультации.

Microsoft Corporation 8 ttkresoft Анализ требований и определение архитектуры решений Microsoft Учебный курс № 70- к подробно Microsoft Corporation о на Microsoft с Visual Basic и Visual C# Учебный курс экзамены № 70-305, № 70- версий Visual Basic С* на платформе Кроме эти Microsoft Corporation Разработка курсы для на Microsoft Visual и Microsoft к Visual C# Учебный курс MCAD/MCSD по программам и экзамены № 70-306, набор учебных и тестов, Кб издательство литературы учебные для а КНИГ Создавайте для Журнал для разработчиков программного Русская Редакция обеспечения ASP.NET освоение разработки с ASP.NET Starter стц внешнего с помощью объектов стиля таблиц и стиля столбцов Применение кода для упрощения и поддержки Microsoft Подписной индекс по каталогу Агентства — Подписной индекс по каталогу Агентства «Книга-сервис» — Интернет-магазин издательства http://www.ITbook.ru Представитель издательства в Украине на Петровке» (044) 268- ISBN 9 785750

Pages:     | 1 |   ...   | 3 | 4 ||



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.