О трубопроводе OWIN

Question

У меня есть простой вопрос относительно трубопровода OWIN. Я в значительной степени понимаю всю концепцию этой спецификации, но есть кое-что, что я не полностью усвоил.

Согласно нескольким онлайновым сообщениям, существует конвейер OWIN, который состоит из нескольких модулей, определенных разработчиком (или компонентов промежуточного программного обеспечения) и который сконфигурирован хостом owin. Тогда есть сервер, который будет слушать запросы и передавать их через = через конвейер компонентов OWIN.

Дело в том, что я не совсем понимаю, почему нам нужен конвейер. Так, например, позволяет предположить, что в классе StartUp Фес мы имеем что-то вроде:

public class Startup 
{ 
    public void Configuration(IAppBuilder app) 
    { 
     app.Use<CustomMiddleware>(new CustomComponent()); 
     var config = new HubConfiguration { EnableCrossDomain = true }; 
     app.MapHubs(config); 
     string exeFolder = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location); 
     string webFolder = Path.Combine(exeFolder, "Web"); 
     app.UseStaticFiles(webFolder); 
    } 
} 

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

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

Answer 1

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

Answer 2

Вы ответите правильно, что посредники могут отказаться от обработки запроса. Многие реализации промежуточного программного обеспечения Katana благоприятствуют «мягкому 404» подходу, в котором промежуточное ПО интерпретирует значение 404 как «попытаться использовать промежуточное программное обеспечение next». Первое промежуточное программное обеспечение для завершения работы Task остановит дальнейшее распространение и завершит ответное сообщение. Вы можете оптимизировать путь, вставив middlewares в наиболее вероятный порядок производительности или общего использования.

Answer 3

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

Это возможно, потому что каждый компонент промежуточного программного обеспечения имеет ссылку на следующий, а the environment - словарь объектов, чей ключ является строкой, который дает доступ ко всем необходимым вещам для проверки запроса, создания ответа, и многое другое. (использование словаря является умным, потому что легко добавить любую информацию или исполняемый код, который не известен заранее).

Каждый компонент может сделать следующие вещи, но все они не являются обязательными:

• выполнить код перед вызовом следующего компонента (обычно проверка и изменение словаря среды)
• вызова следующего промежуточного компонента трубопровод (который будет делать то же самое)
• выполнить некоторый код после того, как следующий компонент завершает выполнение
• сгенерирует исключение (намеренно или из-за уна необработанной ошибки)

Выполнение трубопровода завершится на одном из этих случаев:

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

ПРИМЕЧАНИЕ: каждый «компонент промежуточного ПО» представляет собой реализацию Application Delegate

Имея ab unch компонентов имеет смысл, если они зарегистрированы в правильном порядке. Конвейер может выглядеть примерно так:

• аутентификации
• авторизации
• кэширование
• выполнение какой-то API или HTML поколения

Каждый компонент имеет достаточно информации для выполнения кода его ответственность. Например:

• Аутентификация будет выполнена, и укажите в описании слова директора. Затем будет указано следующее: компонент авторизации
• в зависимости от запроса и результата аутентификации, компонент авторизации будет решать, имеет ли у принципала разрешения для выполнения запроса и вызывает следующий компонент (кэширование) или отклонить запрос
• кэширование также может решить, может ли он вернуть результаты кэширования или должен вызвать следующий компонент
• последний компонент выполнит и, вероятно, создаст ответ, и он не будет вызывать никакой другой компонент. Стек вызовов будет выполняться в обратном порядке, предоставляя каждому компоненту возможность выполнять некоторую работу по эстрам. Например, компонент кэширования может кэшировать ответ, а следующие (авторизация и аутентификация) просто вернутся без выполнения какого-либо дополнительного кода.

Поскольку каждый компонент имеет весь запрос, отклик, контекст и любую другую желаемую информацию, у всех их есть достаточно информации, чтобы решить, нужно ли им что-то делать, модифицировать диктофон, calhehe next one или retunr ...

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

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

Таким образом, даже если компонент, находящийся в конвейере, может иметь дешевое исполнение, или он вообще может не запускаться в зависимости от запроса.

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