Наверное многие разработчики уже сталкивались с названиями OWIN и Katana в статьях и презентациях Microsoft. Давайте разберемся что и для чего это нужно.
Немного истории
Рассмотрим классическое ASP.NET веб-приложение. Характерной его чертой является зависимость от System.Web. Эта сборка входит в .NET Framework и, по сути, представляет функциональность IIS. Схематически это представить следующим образом:
Здесь сразу можно отметить первый недостаток – сильная связь веб-приложения с System.Web. Это означает, что перенести его на другой тип сервера (например, self-host) без изменений не возможно.
Второй недостаток виден не сразу. System.Web это часть .NET Framework , а значит её новые версии появляются только с очередным обновлением самой платформы. С учетом текущих темпов развития веб-технологий это достаточно медленно.
Разработчики в Microsoft решили исправить ситуацию. Первым шагом стали NuGet и библиотека ASP.NET MVC. Её обновления стали появляться чаще, чем новые версии .NET Framework. Затем проследовала ASP.NET WebAPI, у которой к тому же не было зависимости от System.Web. И наконец, вышла signalR с аналогичными свойствами.
Стало ясно, что нужная некая абстракция, представляющая собой сервер и позволяющая строить свой конвейер обработки запросов. Так появились OWIN и Katana.
OWIN
OWIN (Open Web Interface for .NET) – это спецификация (не библиотека и не платформа), определяющая интерфейс, который устраняет сильную связанность веб-приложения с конкретной реализацией сервера. Схематически это выглядит так:
Это позволяет запускать приложение на любой платформе, поддерживающей OWIN, без изменений. Для работы оно использует готовые или созданные самим разработчиком модули. В свою очередь, спецификация задает интерфейс взаимодействия последних с сервером. Её основа – делегат:
using AppFunc = Func<
IDictionary<string, object>, // Environment
Task>; // Done
Он отвечает за обработку запроса к серверу. Параметр IDictionary<string, object> содержит текущее окружение сервера, запрос и ответ (имена ключей описаны в спецификации). Результатом является объект типа Task, т.е. некая выполняемая задача.
В момент запуска веб-приложения, разработчик конфигурирует нужные модули в конвейер обработки запросов. Таким образом используется только необходимая функциональность.
Еще раз стоит подчеркнуть, что и модули и приложения, написанные для OWIN , способны работать на различных типах серверов. Так достигается гибкость решения. Это хорошо заметно на примере библиотек WebAPI и signalR, которые могут работать как под IIS, так и в отдельном приложении.
Может показаться, что для создания даже самого простого решения необходим большой объем кода. Ведь разработчик остается один на один с запросом и формированием ответа на него. Кроме того, требуется реализация OWIN для конкретного веб-сервера. Здесь на помощь приходит проект Katana.
Katana
Katana – это реализация спецификации OWIN от Microsoft, которая:
- позволяет запускать приложения под IIS и в виде самостоятельного приложения (self-host);
- предоставляет вспомогательные типы и методы, которые упрощают создание модулей OWIN. Например, вместо IDictionary – удобные объекты OwinRequest и OwinResponse.
В её рамках уже разработаны и доступны модули WebAPI и signalR.
Возможно некоторые разработчики зададутся вопросом – не придется ли теперь все изучать c нуля? Ответ: нет. Нововведения касаются только кода, который связан непосредственно с веб-сервером. Например то, что настраивалось в global.aspx. Вместо него появляется класс Startup для настройки модулей. Интерфейсы и принципы работы signalR и WebAPI не изменяются.
В следующей части рассмотрим создание простого веб-приложения с использованием Katana и WebAPI.