В чем разница между RequestInterceptor и MessageInspector?

Question

В чем разница между RequestInterceptor и MessageInspector?

У меня есть два вопроса здесь:-

1) В чем принципиальная разница между Microsoft.ServiceModel.Web.RequestInterceptor and System.ServiceModel.Dispatcher.DispatchRuntime.MessageInspectors (IdispatchMessageInterceptor)

Похоже, что оба они являются перехватчиками запросов / сообщений, которые можно использовать для реализации пользовательских проверок / перехватчиков в конвейере запросов.

Когда использовать один на другой?

2) Также как подключить RequestInterceptor в RouteTable.Routes.Add(new ServiceRoute())

У меня есть такой класс -

public class AuthenticationInterceptor : RequestInterceptor
{
   //Authentication logic goes here......
}

и определение маршрута, как это:-

RouteTable.Routes.Add(new ServiceRoute(routePrefix, new MyServiceHostFactory(container, (sh) => {
                foreach (System.ServiceModel.Dispatcher.ChannelDispatcher cd in sh.ChannelDispatchers)
                {
                    foreach (System.ServiceModel.Dispatcher.EndpointDispatcher ed in cd.Endpoints)
                    {
                        ed.DispatchRuntime.MessageInspectors.Add(new AuthenticationInterceptor());
                    }
                }
                return sh; })));

Вот определение MyServiceHostFactory:-

public MyServiceHostFactory(IocContainer container, Func<ServiceHost, ServiceHost> createservicehost = null);

Теперь выдает следующую ошибку:

The best overloaded method match for 'System.Collections.Generic.SynchronizedCollection<System.ServiceModel.Dispatcher.IDispatchMessageInspector>.Add(System.ServiceModel.Dispatcher.IDispatchMessageInspector)' has some invalid arguments

на этой линии:-

ed.DispatchRuntime.MessageInspectors.Add(new AuthenticationInterceptor());

Я знаю почему, это только потому, что я пытаюсь подключить RequestInterceptor в MessageInspector. Оба входят в различную иерархию интерфейса.

Так что мне здесь делать?

Редактировать:

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

7

c# asp.net wcf wcf-rest idispatchmessageinspector

Источник

user2560395 18 июн '14 в 07:18

1 ответ

Решение

Другие вопросы по тегам c# asp.net wcf wcf-rest idispatchmessageinspector

user1304519 28 июн '14 в 19:47 2014-06-28 19:47 · Accepted Answer · 2014-06-28 19:47

Вот ответы на ваши вопросы (вам нужно прочитать пункт 2, чтобы немного понять перехватчиков и инспекторов):

1. Решение ошибки (вам нужно добавить к ней свою логику кода)

Реализуйте IDispatchMessageInspector в следующем коде. Обратите внимание, что имя следующего класса должно измениться на Инспектор, но, как вы упомянули, вы не можете изменить его, поэтому вам следует реализовать интерфейс здесь. В противном случае рекомендуется создать другой класс с суффиксом Matching Inspector и реализацией.

public class AuthenticationInterceptor : RequestInterceptor, IDispatchMessageInspector
{
    //Authentication logic goes here......
    object IDispatchMessageInspector.AfterReceiveRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel, System.ServiceModel.InstanceContext instanceContext)
    {
        //Your code here.
    }
    void IDispatchMessageInspector.BeforeSendReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
    {
        //Your code here.
    }
}

2. Разница между RequestInterceptor и MessageInspectors

В любом общении клиент-сервер может быть два важных этапа общения. Во-первых, когда клиент устанавливает соединение с сервером, и во-вторых, когда они оба общаются.

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

Хороший пример изменения маршрута - это когда:

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

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

Таким образом, в WCF стартовый комплект Rest предоставляет вам дополнительную возможность перехватывать запрос на этапе установления соединения. Перехватчик (в вашем случае AuthenticationInterceptor) должен аутентифицировать такие запросы, и если запрос недействителен, он может регистрировать необходимые записи и просто отказываться обрабатывать любые сообщения дальше от этого отклоненного клиента / сеанса.

У нас есть много преимуществ наличия RequestInterceptor:

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

Инспекторы сообщений: MessageInspectors можно рассматривать как часть второй фазы взаимодействия клиент-сервер, когда запрос подтвержден и соединение установлено, и, следовательно, это время, когда клиент-сервер должен начать обмен данными, передавая сообщения друг другу. Теперь в вашей прикладной среде возможно, что сообщения будут передаваться в двоичном, сериализованном формате xml или json. Там могут быть применимы шифрования.

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

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

В WCF перехватчики и инспекторы могут работать вместе, и их обязанности различны. Перехватчик проверяет конечного пользователя / соединение / изменение маршрута, а инспектор проверяет / обрабатывает сообщение.

Несколько моментов:

Вы можете создать свои собственные инспекторы сообщений, реализовав IClientMessageInspector для клиентской стороны и IDispatchMessageInspector на серверной стороне.
Вы можете реализовать оба интерфейса в одном классе, если вы являетесь владельцем клиентских и серверных компонентов.
Здесь, в вашем случае, кажется, вам нужно реализовать IDispatchMessageInspector.

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

Обратите внимание, что к этому времени на уровнях инспектора любое поступающее сообщение уже обрабатывается на различных уровнях стека каналов и назначается тому, какая служба WCF будет обрабатывать этот запрос. Если вы используете какое-либо шифрование между ними, то сообщение уже было расшифровано. Но сообщение еще не десериализовано.

Использование вашего собственного Инспектора может привести к тому, что ваша система реализует собственный формат сериализации, такой как (протокол SWIFT/FIX в банковской сфере) или другой уровень кодирования zip/unzip и т. Д.

Этот пользовательский инспектор может десериализовать данные и передать их вашему компоненту COMP, который фактически предназначен для работы с десериализованными данными.

Интерфейс IDispatchMessageInspector имеет два метода, которые необходимо реализовать:

а) AfterReceiveRequest и

б) BeforeSendReply (ссылка Сообщение, Объект).

AfterReceiveRequest - это метод, который может десериализовать данные и передать их в COMP, а BeforeSendReply - это метод, который снова сериализует данные и выполняет любую операцию над сообщением.

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

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

http://msdn.microsoft.com/en-us/library/ee391967.aspx

http://msdn.microsoft.com/en-us/library/aa717047%28v=vs.110%29.aspx

С уважением Каджал