[Из песочницы] OWIN и Katana: первый взгляд

Эта статья является частичным переводом.

Взглянем на текущую ситуацию с веб технологиями от 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 модулей. Вообще всячески рекомендую этот блог, много полезного, постоянно читаю.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:

• Massacres That Matter - Part 1 - 'Responsibility To Protect' In Egypt, Libya And Syria


• Massacres That Matter - Part 2 - The Media Response On Egypt, Libya And Syria


• National demonstration: No attack on Syria - Saturday 31 August, 12 noon, Temple Place, London, UK