Обзор проекта Katana

  • Статья

Говард Диркинг

Платформа ASP.NET framework уже более десяти лет, и платформа позволяет разрабатывать бесчисленные веб-сайты и службы. По мере развития стратегий разработки веб-приложений платформа смогла развиваться в ногу с такими технологиями, как ASP.NET MVC и веб-API ASP.NET. По мере того как разработка веб-приложений выполняет следующий эволюционный шаг в мире облачных вычислений, проект Katana предоставляет базовый набор компонентов для ASP.NET приложений, позволяя им быть гибкими, переносимыми, легкими и обеспечивать более высокую производительность. Другими словами, проект Katana cloud оптимизирует ASP.NET приложения.

Почему Катана - Почему сейчас?

Независимо от того, обсуждается ли платформа разработчика или продукт конечного пользователя, важно понимать базовые мотивы для создания продукта, и часть этого включает в себя знание того, для кого был создан продукт. ASP.NET изначально создавалась с учетом двух клиентов.

Первой группой клиентов были классические разработчики ASP. В то время ASP была одной из основных технологий для создания динамических управляемых данными веб-сайтов и приложений путем переплетения разметки и скрипта на стороне сервера. Среда выполнения ASP предоставляла скрипт на стороне сервера с набором объектов, которые абстрагировали основные аспекты базового протокола HTTP и веб-сервера и предоставляли доступ к дополнительным службам, таким как управление состоянием сеансов и приложений, кэш и т. д. В то время как мощные классические приложения ASP стали сложной задачей для управления по мере роста их размера и сложности. Это было в значительной степени связано с отсутствием структуры в средах скриптов в сочетании с дублированием кода в результате чередование кода и разметки. Чтобы воспользоваться преимуществами классического ASP при решении некоторых проблем, ASP.NET воспользовались организацией кода, предоставляемой объектно-ориентированными языками платформа .NET Framework при сохранении модели программирования на стороне сервера, к которой привыкли разработчики классических ASP.

Второй группой целевых клиентов для ASP.NET были разработчики бизнес-приложений Windows. В отличие от классических разработчиков ASP, которые привыкли писать разметку HTML и код для создания дополнительных html-разметки, разработчики WinForms (как и разработчики VB6 до них) привыкли к опыту разработки, который включал холст и широкий набор элементов управления пользовательского интерфейса. Первая версия ASP.NET, также известная как "веб-формы", предоставляла аналогичные возможности разработки наряду с моделью событий на стороне сервера для компонентов пользовательского интерфейса и набором функций инфраструктуры (например, ViewState), чтобы создать удобный интерфейс разработки между клиентским и серверным программированием. веб-формы эффективно скрывал веб-природу без отслеживания состояния в модели событий с отслеживанием состояния, знакомой разработчикам WinForms.

Проблемы, поднятые исторической моделью

Конечным результатом стала зрелая модель программирования среды выполнения и разработчика с широкими возможностями. Тем не менее, с этой особенностью богатства пришла пара заметных проблем. Во-первых, платформа была монолитной, с логически разрозненными единицами функциональных возможностей, тесно связанных в одной System.Web.dll сборке (например, основные объекты HTTP с платформой веб-форм). Во-вторых, ASP.NET была включена в состав более крупного платформа .NET Framework, что означало, что время между выпусками было порядка лет. Это затрудняет ASP.NET идти в ногу со всеми изменениями, происходящими в быстро развивающейся веб-разработке. Наконец, System.Web.dll сама по себе была связана несколькими способами с определенным вариантом веб-размещения: службами IIS.

Эволюционные шаги: ASP.NET MVC и веб-API ASP.NET

И много изменений произошло в веб-разработке! Веб-приложения все чаще разрабатываются в виде серии небольших, специализированных компонентов, а не больших платформ. Количество компонентов, а также частота, с которой они были выпущены, возрастают все более быстрыми темпами. Было ясно, что для того, чтобы идти в ногу с Интернетом, потребуется, чтобы платформы были меньше, разделены и более сосредоточены, а не более крупные и богатые возможностями, поэтому команда ASP.NET предприняла несколько эволюционных шагов, чтобы обеспечить ASP.NET как семейство подключаемых веб-компонентов, а не единую платформу.

Одним из ранних изменений стал рост популярности хорошо известного шаблона проектирования модель-представление-контроллер (MVC) благодаря платформам веб-разработки, таким как Ruby on Rails. Этот стиль создания веб-приложений дал разработчику больший контроль над разметкой приложения, сохраняя при этом разделение разметки и бизнес-логики, которая была одной из начальных точек продажи для ASP.NET. Чтобы удовлетворить спрос на этот стиль разработки веб-приложений, корпорация Майкрософт воспользовалась возможностью лучше позиционировать себя на будущее, разработав ASP.NET MVC вне диапазона (и не включив его в платформа .NET Framework). ASP.NET MVC был выпущен в виде независимого скачивания. Это дало команде разработчиков гибкость при доставке обновлений гораздо чаще, чем это было возможно ранее.

Еще одним важным сдвигом в разработке веб-приложений стал переход от динамических серверных веб-страниц к статической начальной разметке с динамическими разделами страницы, созданными клиентским скриптом, взаимодействующим с внутренними веб-API через запросы AJAX. Этот архитектурный сдвиг способствовал росту веб-API и разработке платформы веб-API ASP.NET. Как и в случае с ASP.NET MVC, выпуск веб-API ASP.NET предоставил еще одну возможность для дальнейшего развития ASP.NET как более модульной платформы. Команда разработчиков воспользовалась этой возможностью и создала веб-API ASP.NET таким образом, чтобы у нее не было зависимостей ни от одного из основных типов платформ, найденных в System.Web.dll. Это позволило две вещи: во-первых, это означало, что веб-API ASP.NET может развиваться полностью автономно (и может продолжать быстро выполнять итерацию, так как она поставляется через NuGet). Во-вторых, поскольку не было внешних зависимостей для System.Web.dll и, следовательно, зависимостей для IIS, веб-API ASP.NET включали возможность запуска на пользовательском узле (например, консольное приложение, служба Windows и т. д.).

Будущее: nimble Framework

Благодаря разделяя компоненты платформы друг от друга, а затем выпуская их в NuGet, платформы теперь могут выполнять итерацию более независимо и быстрее. Кроме того, возможности самостоятельного размещения веб-API оказались очень привлекательными для разработчиков, которым требуется небольшой, упрощенный узел для своих служб. Она оказалась настолько привлекательной, что другие платформы также хотели использовать эту возможность, и это столкнулось с новой проблемой в том, что каждая платформа выполнялась в своем собственном хост-процессе по своему базовому адресу и нуждалась в управлении (запуск, остановка и т. д.) независимо. Современное веб-приложение обычно поддерживает обслуживание статических файлов, динамическое создание страниц, веб-API, а также push-уведомления в режиме реального времени. Ожидать, что каждая из этих служб должна запускаться и управляться независимо, было просто нереалистично.

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

Открытый веб-интерфейс для .NET (OWIN)

Вдохновленные преимуществами, достигнутыми Rack в сообществе Ruby, несколько членов сообщества .NET намерены создать абстракцию между веб-серверами и компонентами платформы. Двумя целями проектирования абстракции OWIN было то, что она была простой и что для нее потребовалось наименьшее возможное количество зависимостей от других типов платформ. Эти две цели помогают обеспечить следующее:

  • Новые компоненты могут быть проще разрабатывать и использовать.
  • Приложения можно было бы легко перенести между узлами и, возможно, целыми платформами или операционными системами.

Результирующая абстракция состоит из двух основных элементов. Во-первых, это словарь среды. Эта структура данных отвечает за хранение всего состояния, необходимого для обработки HTTP-запроса и ответа, а также за любое соответствующее состояние сервера. Словарь среды определяется следующим образом:

IDictionary<string, object>

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

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

Имя ключа Описание значения
"owin.RequestBody" Stream с текстом запроса, если таковой имеется. Stream.Null может использоваться в качестве заполнителя, если текст запроса отсутствует. См. раздел Текст запроса.
"owin.RequestHeaders" Объект IDictionary<string, string[]> с заголовками запроса. См . раздел Заголовки.
"owin.RequestMethod" Объект string , содержащий метод HTTP-запроса запроса (например, "GET", "POST").
"owin.RequestPath" Объект , string содержащий путь запроса. Путь должен быть относительно "root" делегата приложения; См. раздел Пути.
"owin.RequestPathBase" Объект , string содержащий часть пути запроса, соответствующую "корню" делегата приложения; см. раздел Пути.
"owin.RequestProtocol" Объект , string содержащий имя и версию протокола (например, "HTTP/1.0" или "HTTP/1.1").
"owin.RequestQueryString" Объект , string содержащий компонент строки запроса универсального кода ресурса (URI) HTTP-запроса, без начального "?" (например, "foo=bar&baz=quux"). Значение может быть пустой строкой.
"owin.RequestScheme" Объект , string содержащий схему URI, используемую для запроса (например, "http", ); "https"см. схему URI.

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

Func<IDictionary<string, object>, Task>;

Тогда делегат приложения является просто реализацией типа делегата Func, где функция принимает словарь среды в качестве входных данных и возвращает задачу. Эта конструкция имеет несколько последствий для разработчиков:

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

С точки зрения реализации OWIN является спецификацией (http://owin.org/html/owin.html). Его цель — не быть следующей веб-платформой, а скорее спецификацией взаимодействия веб-платформ и веб-серверов.

Если вы изучили OWIN или Katana, возможно, вы также заметили пакет NuGet Owin и Owin.dll. Эта библиотека содержит один интерфейс [ IAppBuilder]/dotnet/api/microsoft.aspnetcore.builder.iapplicationbuilder), который формализует и кодифицирует последовательность запуска, описанную в разделе 4 спецификации OWIN. Хотя для создания серверов OWIN не требуется, интерфейс [IAppBuilder]/dotnet/api/microsoft.aspnetcore.builder.iapplicationbuilder) предоставляет конкретную точку отсчета и используется компонентами проекта Katana.

Проект Katana

В то время как спецификация OWIN и Owin.dll принадлежат сообществу и выполняются сообществом открытый код усилиях, проект Katana представляет набор компонентов OWIN, которые, хотя и открытый код, создаются и выпускаются корпорацией Майкрософт. Эти компоненты включают как компоненты инфраструктуры, такие как узлы и серверы, так и функциональные компоненты, такие как компоненты проверки подлинности и привязки к платформам, таким как SignalR и веб-API ASP.NET. Проект имеет следующие три высокоуровневые цели:

  • Переносимые — компоненты должны легко заменяться новыми компонентами по мере их доступности. Сюда входят все типы компонентов, от платформы до сервера и узла. Эта цель заключается в том, что сторонние платформы могут легко работать на серверах Майкрософт, а платформы Майкрософт могут работать на сторонних серверах и узлах.
  • Модульная или гибкая. В отличие от многих платформ, которые включают множество функций, включенных по умолчанию, компоненты проекта Katana должны быть небольшими и целенаправленными, предоставляя разработчику приложения контроль над определением компонентов, которые следует использовать в приложении.
  • Упрощенный, производительный и масштабируемый . Разбив традиционное понятие платформы на набор небольших, специализированных компонентов, которые явно добавляются разработчиком приложения, полученное приложение Katana может потреблять меньше вычислительных ресурсов и, как следствие, обрабатывать большую нагрузку, чем с другими типами серверов и платформ. Поскольку требования приложения требуют больше возможностей из базовой инфраструктуры, их можно добавить в конвейер OWIN, но это должно быть явное решение со стороны разработчика приложения. Кроме того, подстановка компонентов более низкого уровня означает, что по мере их доступности можно легко внедрять новые высокопроизводительные серверы для повышения производительности приложений OWIN без нарушения работы этих приложений.

начало работы с компонентами Katana

Когда он был впервые представлен, одним из аспектов платформыNode.js , который сразу же привлек внимание людей, была простота, с помощью которой можно было создавать и запускать веб-сервер. Если цели Katana были обрамлены в свете Node.js, можно было бы подытожить их, сказав, что Katana приносит многие преимущества Node.js (и подобных платформ), не заставляя разработчика выбрасывать все, что ей известно о разработке веб-приложений ASP.NET. Чтобы это утверждение соответствовало действительности, начало работы с проектом Katana должно быть столь же простым по своей природе, чтобы Node.js.

Создание "Hello World!"

Одним из заметных различий между разработкой javaScript и .NET является наличие (или отсутствие) компилятора. Таким образом, отправной точкой для простого сервера Katana является проект Visual Studio. Однако мы можем начать с самого минимального типа проекта: пустого ASP.NET веб-приложения.

Снимок экрана: меню ASP.Net Project — WebApplication1, в котором показано, как создать проект

Далее мы установим в проект пакет NuGet Microsoft.Owin.Host.SystemWeb . Этот пакет предоставляет сервер OWIN, который выполняется в конвейере запросов ASP.NET. Его можно найти в коллекции NuGet и установить с помощью диалогового окна диспетчера пакетов Visual Studio или консоли диспетчера пакетов с помощью следующей команды:

install-package Microsoft.Owin.Host.SystemWeb

Microsoft.Owin.Host.SystemWeb При установке пакета будет установлено несколько дополнительных пакетов в качестве зависимостей. Одной из этих зависимостей является Microsoft.Owinбиблиотека , которая предоставляет несколько вспомогательных типов и методов для разработки приложений OWIN. Эти типы можно использовать для быстрой записи следующего сервера hello world.

public class Startup
{
   public void Configuration(IAppBuilder app)
   {
      app.Run(context =>
      {
         context.Response.ContentType = "text/plain";
         return context.Response.WriteAsync("Hello World!");
      });
   }
}

Этот очень простой веб-сервер теперь можно запускать с помощью команды F5 Visual Studio и включает полную поддержку отладки.

Переключение узлов

По умолчанию предыдущий пример hello world выполняется в конвейере запросов ASP.NET, который использует System.Web в контексте IIS. Это само по себе может принести огромную ценность, так как позволяет нам воспользоваться гибкостью и составностью конвейера OWIN с возможностями управления и общей зрелостью IIS. Однако в некоторых случаях преимущества, предоставляемые СЛУЖБАми IIS, не требуются и требуется меньший и упрощенный узел. Что же необходимо для запуска простого веб-сервера за пределами IIS и System.Web?

Чтобы проиллюстрировать задачу переноса, при переходе с узла веб-сервера на узел командной строки необходимо просто добавить новый сервер и зависимости узла в выходную папку проекта, а затем запустить узел. В этом примере мы разместим наш веб-сервер на узле Katana с именем OwinHost.exe и будем использовать сервер на основе HttpListener Katana. Как и другие компоненты Katana, они будут получены из NuGet с помощью следующей команды:

install-package OwinHost

В командной строке можно перейти в корневую папку проекта и просто запустить OwinHost.exe (которая была установлена в папке tools соответствующего пакета NuGet). По умолчанию настроен для поиска сервера на основе HttpListener, OwinHost.exe поэтому дополнительная настройка не требуется. При навигации в веб-браузере http://localhost:5000/ отображается приложение, которое теперь выполняется через консоль.

Снимок экрана: команда разработчика Promt и окно браузера, на котором показано сравнение команд, введенных в командной строке, и того, как проект Hello World будет выглядеть в веб-браузере.

Архитектура Katana

Архитектура компонента Katana разделяет приложение на четыре логических уровня, как показано ниже: узел, сервер, ПО промежуточного слоя и приложение. Архитектура компонента учитывается таким образом, что реализации этих слоев можно легко заменить, во многих случаях, не требуя повторной компиляции приложения.

На схеме архитектурных слоев показаны четыре гистограммы, изображающие логические слои, на которых делится архитектура приложения.

Узел

Узел отвечает за:

  • Управление базовым процессом.

  • Оркестрация рабочего процесса, который приводит к выбору сервера и созданию конвейера OWIN, с помощью которого будут обрабатываться запросы.

    В настоящее время существует 3 основных варианта размещения приложений на основе Katana:

IIS/ASP.NET. Используя стандартные типы HttpModule и HttpHandler, конвейеры OWIN могут выполняться в IIS как часть потока запросов ASP.NET. ASP.NET поддержка размещения включается путем установки пакета NuGet Microsoft.AspNet.Host.SystemWeb в проект веб-приложения. Кроме того, так как СЛУЖБЫ IIS выступают как узел и сервер, в этом пакете NuGet используется различие между серверами OWIN и узлами. Это означает, что при использовании узла SystemWeb разработчик не может заменить реализацию альтернативного сервера.

Пользовательский узел. Набор компонентов Katana предоставляет разработчику возможность размещать приложения в собственном пользовательском процессе, будь то консольное приложение, служба Windows и т. д. Эта возможность похожа на возможность локального размещения, предоставляемую веб-API. В следующем примере показан пользовательский узел кода веб-API:

static void Main()
{
    var baseAddress = new Uri("http://localhost:5000");

    var config = new HttpSelfHostConfiguration(baseAddress);
    config.Routes.MapHttpRoute("default", "{controller}");
       
    using (var svr = new HttpSelfHostServer(config))
    {
        svr.OpenAsync().Wait();
        Console.WriteLine("Press Enter to quit.");
        Console.ReadLine();
    }
}

Настройка локального узла для приложения Katana аналогична:

static void Main(string[] args)
{
    const string baseUrl = "http://localhost:5000/";

    using (WebApplication.Start<Startup>(new StartOptions { Url = baseUrl })) 
    {
        Console.WriteLine("Press Enter to quit.");
        Console.ReadKey();
    }
}

Одним из заметных различий между примерами веб-API и самостоятельного размещения Katana является отсутствие кода конфигурации веб-API в примере с локальным размещением Katana. Чтобы обеспечить переносимость и компонуемость, Katana отделяет код, запускающий сервер, от кода, который настраивает конвейер обработки запросов. Код, который настраивает веб-API, затем содержится в классе Startup, который дополнительно указан в качестве параметра типа в WebApplication.Start.

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        var config = new HttpConfiguration();
        config.Routes.MapHttpRoute("default", "{controller}");
        app.UseWebApi(config);
    }
}

Класс стартапа будет рассмотрен более подробно далее в этой статье. Однако код, необходимый для запуска процесса самостоятельного размещения Katana, выглядит поразительно похоже на код, который вы можете использовать сегодня в веб-API ASP.NET локальных приложений.

OwinHost.exe. Хотя некоторые из пользователей хотят написать пользовательский процесс для запуска веб-приложений Katana, многие предпочитают просто запустить готовый исполняемый файл, который может запустить сервер и запустить свое приложение. Для этого сценария набор компонентов Katana включает в себя OwinHost.exe. При запуске из корневого каталога проекта этот исполняемый файл запускает сервер (он использует сервер HttpListener по умолчанию) и использует соглашения для поиска и запуска класса запуска пользователя. Для более детального управления исполняемый файл предоставляет ряд дополнительных параметров командной строки.

Снимок экрана: командная строка разработчика с примером кода командной строки при запуске приложения на сервере.

Сервер

Хотя узел отвечает за запуск и обслуживание процесса, в рамках которого выполняется приложение, сервер должен открыть сетевой сокет, прослушивать запросы и отправлять их через конвейер компонентов OWIN, указанных пользователем (как вы уже заметили, этот конвейер указан в классе Startup разработчика приложения). В настоящее время проект Katana включает две реализации сервера:

  • Microsoft.Owin.Host.SystemWeb: как упоминалось ранее, СЛУЖБЫ IIS совместно с конвейером ASP.NET выступает как узел и сервер. Поэтому при выборе этого варианта размещения службы IIS управляют проблемами на уровне узла, такими как активация процесса, и прослушивают HTTP-запросы. Для веб-приложений ASP.NET он отправляет запросы в конвейер ASP.NET. Узел Katana SystemWeb регистрирует ASP.NET HttpModule и HttpHandler, чтобы перехватывать запросы по мере их прохождения через конвейер HTTP и отправлять их через указанный пользователем конвейер OWIN.
  • Microsoft.Owin.Host.HttpListener: как указывает его имя, этот сервер Katana использует класс HttpListener платформа .NET Framework для открытия сокета и отправки запросов в конвейер OWIN, указанный разработчиком. В настоящее время это выбор сервера по умолчанию как для API самостоятельного узла Katana, так и для OwinHost.exe.

ПО промежуточного слоя или платформа

Как упоминалось ранее, когда сервер принимает запрос от клиента, он отвечает за его передачу через конвейер компонентов OWIN, указанных в коде запуска разработчика. Эти компоненты конвейера называются ПО промежуточного слоя.
На самом базовом уровне компонент ПО промежуточного слоя OWIN просто должен реализовать делегат приложения OWIN, чтобы он был вызываемым.

Func<IDictionary<string, object>, Task>

Однако для упрощения разработки и создания компонентов ПО промежуточного слоя Katana поддерживает несколько соглашений и вспомогательных типов для компонентов ПО промежуточного слоя. Наиболее распространенным из них является OwinMiddleware класс . Пользовательский компонент ПО промежуточного слоя, созданный с помощью этого класса, будет выглядеть следующим образом:

public class LoggerMiddleware : OwinMiddleware
{
    private readonly ILog _logger;
 
    public LoggerMiddleware(OwinMiddleware next, ILog logger) : base(next)
    {
        _logger = logger;
    }
 
    public override async Task Invoke(IOwinContext context)
    {
        _logger.LogInfo("Middleware begin");
        await this.Next.Invoke(context);
        _logger.LogInfo("Middleware end");
    }
}

Этот класс является производным от OwinMiddleware, реализует конструктор, который принимает экземпляр следующего ПО промежуточного слоя в конвейере в качестве одного из своих аргументов, а затем передает его базовому конструктору. Дополнительные аргументы, используемые для настройки ПО промежуточного слоя, также объявляются как параметры конструктора после следующего параметра ПО промежуточного слоя.

Во время выполнения ПО промежуточного слоя выполняется с помощью переопределенного Invoke метода. Этот метод принимает один аргумент типа OwinContext. Этот объект контекста предоставляется пакетом NuGet, описанным Microsoft.Owin выше, и предоставляет строго типизированный доступ к словарю запросов, ответов и среды, а также несколько дополнительных вспомогательных типов.

Класс ПО промежуточного слоя можно легко добавить в конвейер OWIN в коде запуска приложения следующим образом:

public class Startup
{
   public void Configuration(IAppBuilder app)
   {
      app.Use<LoggerMiddleware>(new TraceLogger());

   }
}

Так как инфраструктура Katana просто создает конвейер компонентов ПО промежуточного слоя OWIN, а компоненты просто должны поддерживать делегат приложения для участия в конвейере, компоненты ПО промежуточного слоя могут быть самыми сложными: от простых средств ведения журнала до целых платформ, таких как ASP.NET, веб-API или SignalR. Например, для добавления веб-API ASP.NET в предыдущий конвейер OWIN требуется добавить следующий код запуска:

public class Startup
{
   public void Configuration(IAppBuilder app)
   {
      app.Use<LoggerMiddleware>(new TraceLogger());

      var config = new HttpConfiguration();
      // configure Web API 
      app.UseWebApi(config);

      // additional middleware registrations            
   }
}

Инфраструктура Katana создаст конвейер компонентов ПО промежуточного слоя в соответствии с порядком их добавления в объект IAppBuilder в методе Configuration. В нашем примере LoggerMiddleware может обрабатывать все запросы, которые проходят через конвейер, независимо от того, как эти запросы обрабатываются в конечном итоге. Это позволяет реализовать эффективные сценарии, в которых компонент ПО промежуточного слоя (например, компонент проверки подлинности) может обрабатывать запросы для конвейера, который включает несколько компонентов и платформ (например, веб-API ASP.NET, SignalR и статический файловый сервер).

Приложения

Как показано в предыдущих примерах, OWIN и проект Katana следует рассматривать не как новую модель программирования приложений, а как абстракцию, чтобы отделить модели программирования приложений и платформы от серверной инфраструктуры и инфраструктуры размещения. Например, при создании приложений веб-API платформа разработчика будет продолжать использовать платформу веб-API ASP.NET независимо от того, выполняется ли приложение в конвейере OWIN с использованием компонентов из проекта Katana. Единственным местом, где код, связанный с OWIN, будет видимым для разработчика приложения, будет код запуска приложения, в котором разработчик составляет конвейер OWIN. В коде запуска разработчик регистрирует серию инструкций UseXx, обычно по одной для каждого компонента ПО промежуточного слоя, который будет обрабатывать входящие запросы. Этот интерфейс будет иметь тот же эффект, что и регистрация модулей HTTP в текущем мире System.Web. Как правило, более крупное ПО промежуточного слоя платформы, например веб-API ASP.NET или SignalR, регистрируется в конце конвейера. Сквозные компоненты ПО промежуточного слоя, такие как компоненты для проверки подлинности или кэширования, обычно регистрируются в начале конвейера, чтобы они обрабатывали запросы для всех платформ и компонентов, зарегистрированных позже в конвейере. Такое разделение компонентов ПО промежуточного слоя друг от друга и от базовых компонентов инфраструктуры позволяет компонентам развиваться с разными скоростями, обеспечивая при этом стабильность системы в целом.

Компоненты — пакеты NuGet

Как и многие текущие библиотеки и платформы, компоненты проекта Katana предоставляются в виде набора пакетов NuGet. Для предстоящей версии 2.0 пакет Katana граф зависимостей выглядит следующим образом. (Щелкните изображение для большего представления.)

Схема компонентов — иерархия пакетов NuGet. На этом изображении показаны деревья библиотеки, в которых платформы подключаются для компонентов проекта и доставляются через набор NuGets.

Почти каждый пакет в проекте Katana напрямую или косвенно зависит от пакета Owin. Вы помните, что это пакет, содержащий интерфейс IAppBuilder, который предоставляет конкретную реализацию последовательности запуска приложения, описанной в разделе 4 спецификации OWIN. Кроме того, многие пакеты зависят от Microsoft.Owin, которая предоставляет набор вспомогательных типов для работы с HTTP-запросами и ответами. Оставшуюся часть пакета можно классифицировать как пакеты инфраструктуры размещения (серверы или узлы) или ПО промежуточного слоя. Пакеты и зависимости, которые являются внешними по сравнению с проектом Katana, отображаются оранжевым цветом.

Инфраструктура размещения для Katana 2.0 включает серверы на основе SystemWeb и HttpListener, пакет OwinHost для запуска приложений OWIN с помощью OwinHost.exe и пакет Microsoft.Owin.Hosting для самостоятельного размещения приложений OWIN в пользовательском узле (например, консольное приложение, служба Windows и т. д.).

Для Katana 2.0 компоненты ПО промежуточного слоя в основном ориентированы на предоставление различных средств проверки подлинности. Предоставляется еще один компонент ПО промежуточного слоя для диагностика, который обеспечивает поддержку начальной страницы и страницы ошибок. По мере роста OWIN в абстракции размещения де-факто растет и количество компонентов ПО промежуточного слоя, разработанных корпорацией Майкрософт и сторонними производителями.

Заключение

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

Дополнительные сведения о Катане

Благодарности