 |
|
|
|
ASP NET MVC. Веб-приложения самостоятельного размещения
ASP NET MVC Веб-сервер, не требующий инсталляции, управляемый из кода C# с возможностью размещения ранее созданных проектов веб-сервисов? Это легко! Обычно считается, что веб-приложения могут быть запущены только в рамках другого процесса – веб-сервера, например, Apache, nginx или IIS, или же на контейнере сервлетов, если речь идет о Java. Часто веб-серверы обладают богатым набором возможностей и, как следствие, большим набором конфигурационных файлов. Несмотря на то что настройка файлов конфигурации не является чем-то нетривиальным, но все же она нудное и трудоемкое занятие. Однако для решения некоторых задач инсталлируемые веб-серверы или запускаемые через командную строку не всегда подходят. Например, когда необходимо на CI-сервере (сервер непрерывной интеграции) запустить тесты веб-сервиса с реальными запросами. В этом случае хотелось бы иметь возможность с легкостью переносить сборку проекта с одного сервера на другой без инсталляции и утомительной настройки дополнительного программного обеспечения. Благодаря поддержке технологии самостоятельного размещения (self-hosted) в одном процессе можно запустить веб-сервер и развернуть веб-сервисы для тестирования реакции сервиса на запросы. Также эта технология может быть использована для удаленного взаимодействия с Windows-службой, консольным приложением. В этой статье будет рассмотрено, как организовать self-hosted-размещение веб-сервисов в различных .NET-проектах. Также хотелось бы отметить, что на базе self-hosted-технологии было реализовано интеграционное тестирование программных продуктов, разрабатываемых в компании ООО «НПО «САПФИР» и ориентированных для автоматизации задач бюджетного процесса. Особенности развертывания ASP NET веб-приложений Классическое ASP NET MVC-приложение является ориентированным на развертывание на веб-сервере IIS. Оно включает в себя файл Global.asax, в котором определяют класс, наследующий от System.Web.HttpApplication. В этом классе конфигурируются отдельные компоненты MVC для необходимого поведения при обработке запросов. За маршрутизацию передачи HTTP-запросов определенным обработчикам отвечает класс Router. HTTP-обработчики тесно связаны с веб-сервером IIS (см. рис. 1), они используют классы HttpHandler и HttpContext для доступа к параметрам запроса и ответа. Отчасти такое неудобство произошло благодаря наследию от ASP NET Web Forms и использованию этих компонент повсеместно в MVC.
Рисунок 1. Схема обработки HTTP-запросов ASP NET MVC веб-приложения Таким образом, едва ли можно представить себе полноценное использование ASP NET как Open Source-проекта ввиду того, что размещать его можно только на IIS веб-сервере. В результате классическое ASP NET-приложение не может быть самостоятельно развертываемым (self-hosted). Следующим шагом эволюции ASP NET стала разработка Web API. В нем компоненты System.Web используются не напрямую, а через адаптеры, также была устранена зависимость от IIS HTTP-обработчиков (HttpHandler) благодаря реализации слоя адаптеров (см. рис. 2). Данный подход позволит избавиться от IIS зависимости, а Web API можно рассматривать в рамках Owin (Open Web Interface).
Рисунок 2. Схема обработки HTTP-запросов ASP NET MVC Web API веб-приложения Также в Web API имеется слой, отвечающий за размещение (см. рис. 3), предусматривающий как возможность размещения на веб-сервере (web-hosted), так и самостоятельное в рамках Windows-процесса (self-hosted).
Рисунок 3. Структурная схема слоя размещения (hosting) Web API-приложения Статью целиком читайте в журнале «Системный администратор», №10 за 2014 г. на страницах 63-67. PDF-версию данного номера можно приобрести в нашем магазине. |
МИХАИЛ УШАКОВ, Уральский федеральный университет, разработчик электронной аппаратуры и программного обеспечения для ядерной гаммарезонансной спектроскопии, 
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
