OWIN-спецификация: представление и базовые понятия

| Суббота, 6 июля, 2013

Метки: OWIN Комментарии: 0

Статья рассказывает о новой развивающейся открытой спецификации OWIN (Open Web Interface for .NET), что это такое и какие преимущества она может принести в технологию .NET. Также рассмотрим кратко, как начать работать с OWIN и технологиями, построенными вокруг OWIN.

OWIN, что это?

В последнее время количество проектов с поддержкой OWIN становится все больше и больше, и данная спецификация в сообществе веб-разработчиков становится все популярнее. OWIN – это простая спецификация, описывающая процесс взаимодействия компонентов в конвейерной обработке запросов HTTP (HTTP pipeline). Детали взаимодействия для каждого компонента различны, но существуют и некоторые общие элементы. OWIN – это не технология, это просто спецификация.

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

Func<IDictionary<string, object>,Task>

Это функция, которая принимает простой словарь объектов со строковым ключом. Возвращает эта функция объект Task. Объекты в словаре данных - это различные сущности, передаваемые в качестве параметров.

Часто можно встретить такое использование функции:

using AppFunc = Func<IDictionary<string, object>,Task>

Реализация функции может выглядеть так:

public Task Invoke(IDictionary<string, object> environment) 
{ 
   var someObject = environment["some.key"] as SomeObject; 
   // и так далее… 
}

Это ключевой момент, показывающий как компоненты передают информацию (environment) в конвейерной среде HTTP. А из параметра environment можно извлечь данные следующим образом:

var httpRequestPath = environment["owin.RequestPath"] as string; 
Console.WriteLine("Your Path is: [{0}]",httpRequestPath);

Например, если запрос HttpRequest сделан, по адресу "http://localhost:8080/Content/Main.css", то вывод будет таким:

Your Path is [/Content/Main.css]

Дополнительно, рассмотрим интерфейс IAppBuilder, который не является частью спецификации, но является функциональным ядром модуля OWIN. Этот модуль принято называть middleware, что можно определить, как связующее программное обеспечение.

public interface IAppBuilder 
{ 
    IDictionary<string, object> Properties { get; }
    object Build(Type returnType); 
    IAppBuilder New(); 
    IAppBuilder Use(object middleware, params object[] args); 
}

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

И что дальше? Это все можно сделать и без OWIN.

Да, все выше изложенное выглядит не новаторски, но это ядро OWIN и ключ к пониманию того, что спецификация предлагает. Этот приведенный базовый механизм работы, позволяет создавать изолированные компоненты, которые работают в цепочке обработки информации запросов HTTP. Не нужно копаться в настройках IIS (Internet Information Server). Просто собираем цепочку компонентов OWIN вместе, и получаем нужный набор функциональных возможностей, которыми должен обладать HTTP-сервер. Компоненты не имеют никаких внешних зависимостей, в этом и есть преимущество любого OWIN-совместимого компонента.

При данном подходе можно использовать любой хостинг, в который можно помещать любые компоненты цепочки обработки HTTP-запросов. OWIN спецификация обеспечивает совместимость этих модулей и упрощает добавление и удаление компонентов.

Internet Information Services предоставляет большое количество обработчиков запросов, имеет богатую функциональность, различные настройки и специальные возможности, что делает веб-сервер очень обширным и всеобъемлющим.

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

Покажите мне код!

Для начала приведем диаграмму, иллюстрирующую предыдущий параграф. Так как OWIN это всего лишь спецификация, какой интерфейс предоставлять и как с ним работать, то модули, написанные в соответствии с этой спецификации должны быть размещены на хостинге в зависимости от потребностей. Получается на концептуальном уровне OWIN-совместимый хостинг и Internet Information Server можно сравнивать так:

А так как OWIN-хостинг пустой изначально, то нужно программно добавить необходимые OWIN-модули:

На диаграмме выше, изображен OWIN-хостинг, c тремя модулями: статические файлы, аутентификация и SignalR. (SignalR – это популярная библиотека обмена сообщениями в реальном времени, которая написана в виде OWIN-совместимого модуля)