Эта статья является частичным переводом.
Взглянем на текущую ситуацию с веб технологиями от Microsoft. Основным средством разработки с 98 года является конечно ASP .Net. Это классика: богатый функционал, разделение логики от разметки, .net, новая модель разработки веб приложений. Много плюсов и минусов тоже: Все логически-разнородные компоненты тесно связанны в одну единственную сборку System.Web (объекты ядра HTTP, webforms и т.д.). Ко всему этому ASP .net включен в состав большого NET Framework, а значит время между отдельными релизами может составлять несколько лет. И это не позволяет ASP .NET идти в ногу со временем и поспевать за веб технологиями. Монолитная архитектура делает все это богатство неповоротливым и инертным, а какие-либо изменения затрагивают множество компонентов.
Со временем ситуация на рынке меняется: ASP .NET получает MVC framework и Ajax уже в виде отдельных модулей, не входящих в основную сборку и это позволяет разработчикам этих компонентов ускорить выпуск новых версий и своевременно реагировать на ситуацию в сфере веб разработки. ASP .NET становится семейством подключаемых компонентов, а не единой структурой.
MVC framework был создан Microsoft с оглядкой на Ruby on Rails. Логичный и современный шаг. Этот продукт дал разработчикам больший контроль над разметкой, сохраняя при ее отделение от бизнес логики.
Следующим важным шагом Microsoft в направлении веб разработки стал выпуск WebApi, который не имеет зависимости от System.Web. Приложения все больше стали использовать не динамически генерируемые сервером страницы, а статические с использованием Ajax. Новые версии доставляются очень быстро благодаря использованию NuGet. Мощность и гибкость Web API, а так же возможность self-hosting оказалась очень привлекательной для веб разработчиков, настолько привлекательной, что многие другие фреймворки тоже стали self-hosting. И тут всплывает новая проблема. Среднестатистическое современное веб приложение может поддерживать: статические веб страницы, динамическую генерацию страниц, Web Api, real-time/push уведомления. Ожидать, что каждый из этих сервисов должен быть запущен, и управляется отдельно просто нереально. Возникает необходимость в новом уровне абстракции между и приложениями, дабы связывать все модули и в то же время не заботится о деталях реализации , т.н. middleware. И у RoR уже была подобная абстракция — Rack.
OWIN
Вдохновленные Rack, несколько разработчиков .NET решили создать свою абстракцию между веб сервером и компонентами инфраструктуры. Разработчики преследовали две цели:
- Новые компоненты будут просты в разработке и использовании.
- Приложения могут быть легко переносимы с хоста на хост, возможно даже на разных платформах
И вот что вышло.
OWIN (The Open Web Interface for .NET) — это спецификация определяющая интерфейс и описывающая взаимодействие между всеми компонентами.
Основой работы OWIN является словарь IDictionary<string, object>, который используется для получения доступа к HTTP запросам, заголовку запроса и окружению хоста. Все ключи описаны в спецификации OWIN.
Owin-совместимый сервер отвечает за заполнение этого словаря данными.
Следующий элемент OWIN Это делегат:
Func<IDictionary<string, object>, Task>;В качестве входных данных он принимает выше описанный словарь, а возвращает объект Task по завершению процесса.
Библиотека Owin.dll (доступна в NuGet) содержит всего один интерфейс IAppBuilder:
public interface IAppBuilder
{
IDictionary<string, object> Properties { get; }
IAppBuilder Use(object middleware, params object[] args);
[SuppressMessage("Microsoft.Naming", "CA1716:IdentifiersShouldNotMatchKeywords", MessageId = "New", Justification = "By design")]
IAppBuilder New();
}
Данный интерфейс связывает все модули, разработанные по спецификации OWIN. Каждый отдельный модуль не имеет никакой внешней зависимости, одними из таких компонентов являются SignalR, и WebAPI которые полностью OWIN-совместимы.
OWIN хостинг
Используя OWIN, мы вольны подключать только те компоненты, которые нам нужны прямо сдесь и сейчас, будь то модуль авторизации, тот же SignalR, статические страницы и т.п. И в отличие от IIS, например, наш сервер не будет перегружен ненужным функционалом, а значит будет производительнее.
Katana — это OWIN-совместимый хост написанный Microsoft. Помимо реализации спецификации OWIN, Katana содержит различные вспомогательные классы и обертки для упрощения разработки, содержащиеся в библиотеке Owin.Types. Например два класса-адаптера упрощающие работу со словарём: OwinRequest и OwinResponse, реализация WebSocket для Owin — OwinWebSocket, вспомогательный класс для работы с заголовками и другими параметрами запросов — OwinHelpers.
Важный момент: Katana не завязана на использовании каких либо интерфейсов или базовых типов, вместо этого определены соглашения, которым должны следовать разработчики.
Практика
В качестве задачи для практики мы реализуем WebApi на базе OWIN. Для начала нам нужно определится со способом запуска Katana. Попробуем сделать это self-host. Создадим простой консольный проект WebApiOwinSelfHostDemo Нам понадобится соответствующая реализация WebApi. Ставим через NuGet.
Install-Package Microsoft.AspNet.WebApi.OwinSelfHost -Pre
Эта команда установит все нужные библиотеки OWIN.
Далее добавляем в наш проект новый класс Startup. И пишем следующий код:
Создавая этот класс мы следуем одному из соглашений Katana: при запуске веб приложения Katana ищет класс Startup и вызывает его метод Configuration(), для создания и конфигурирования конвеера обработки сообщений.
Далее добавим простой WebApi контроллер:
Наше приложение готово, теперь нужно запустить OWIN хост и послать запрос используя HttpClient:
После запуска приложения получаем следующий вывод.
Все отлично!
Вариант запуска на сервере IIS
Все это конечно хорошо, но было бы неплохо запуститьь все это на настоящем сервере, а не просто в консольном приложении.
Библиотека Microsoft.Owin.Host.SystemWeb реализует Owin для IIS, это то, что нам нужно.
Создадим пустой проект ASP .NET. Почему ASP .net? Это даст нам уже настроенный для запуска в IIS express проект.
Добавляем WebAPI:
Install-Package Microsoft.AspNet.WebApi.Owin -PreДобавляем реализацию OWIN для IIS:
Install-Package Microsoft.Owin.Host.SystemWebМожно так же использовать Katana Tooling. Это шаблон, содержащий все необходимые библиотеки. И по умолчанию в этом шаблоне проект запускается именно под IIS, но в комплекте идет скрипт для настройки запуска на собственном Owin хосте OwinHost.exe. Но это не принципиально.
Остальное все абсолютно тоже самое. Класс Startup и класс контроллера из self-host проекта.
Ремарка: на последней версии Katana Tooling Web Api нормально запустить не удалось, вываливается в ошибку, причину пока не выяснил. Может просто у меня кривые руки.
Я описал только базовые вещи, для ознакомления с новой OpenSource технологией от Microsoft. Ниже приведу ссылки на материалы, использованные в статье а так же более подробные примеры для заинтересовавшихся.
http://owin.org/ — собственно OWIN.
An Overview of Project Katana — статья про Katana от одного из разработчиков. Все очень круто и понятно, большинство моментов из этой статьи я вольно перевел здесь.
Hosting nancy with OWIN
Katana Project
OWIN и Katana — в этом блоге подробно описана работа с Katana и способы запуска, а так же детально разобрано создание собственных OWIN модулей. Вообще всячески рекомендую этот блог, много полезного, постоянно читаю.
Автор: RayAtlas
