Маршрутизация REST для именованных каналов в WCF

Question

Я хочу, чтобы запрос маршрута, отправляемый REST (WebHttp), был другим сервисом. Другая услуга будет прослушивать по именованным каналам или REST. Маршрутизатор - это простой сервис, который принимает все запросы в виде сообщений, направляет их к цели и отправляет ответ от цели обратно клиенту.

1) Когда я пытаюсь перенаправить REST на именованные каналы, возникает проблема с конвертом: у REST нет конверта, а у названных каналов есть SOAP. И в REST данные запроса закодированы в URL-адресе, тогда как в именованных каналах он закодирован в теле SOAP.

2) Когда я пытаюсь перенаправить REST на REST, запрос отправляется в службу, ответ приходит к маршрутизатору и отправляется, но я получаю «Request Error» на клиенте.

Как можно выполнить маршрутизацию в этом szenario?

Answer 1

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

[ServiceContract(Name = "SOADispatchService", Namespace = "<your namespace>")] 
public interface ISOADispatchService 
{ 
    [OperationContract(Action="*", ReplyAction="*")] 
    Message ProcessMessage(Message requestMessage); 
} 

[ServiceBehavior(AddressFilterMode=AddressFilterMode.Any)] 
public class SOADispatchService : RefCountedBaseHandler, ISOADispatchService 
{ 
    Message ProcessMessage(Message requestMessage) 
    { 
     dispatching code here 
    } 
} 

Это дает прямой доступ к запросу и ответу в сыром виде сообщений и позволяет вам определить тип запроса и точно контролировать struture и формат ответа. В нашем случае диспетчер принимает запросы SOAP и HTTP GET (aka REST) ​​и должен возвращать ответ SOAP или ответ REST (любой из XML, JSON, HTML). Это требует большего знания того, как WCF форматирует свои сообщения и взаимодействия между структурой сообщений и привязкой вашего диспетчера, но он дает вам как можно больше контроля.

С точки зрения диагностики второй проблемы, еще раз не уверен, что именно эта проблема связана с фрагментом конфигурации, может быть много чего. Два инструмента, которые мы нашли бесценными при диагностике подобных проблем, - это инструмент трассировки службы WCF и декомпилятор WCF. Инструмент трассировки является частью пакета visual studio. Для того, чтобы включить его добавить следующий конфиг:

<system.diagnostics > 
    <sharedListeners> 
     <add name="sharedListener" 
      type="System.Diagnostics.XmlWriterTraceListener" 
      initializeData="c:\traces\WCFTrace.svclog" /> 
    </sharedListeners> 
    <sources> 
     <source name="System.ServiceModel" switchValue="All, Verbose, ActivityTracing" > 
     <listeners> 
      <add name="sharedListener" /> 
     </listeners> 
     </source> 
     <source name="System.ServiceModel.MessageLogging" switchValue="All"> 
     <listeners> 
      <add name="sharedListener" /> 
     </listeners> 
     </source> 
    </sources> </system.diagnostics> 

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

Надеюсь, это поможет вам в правильном направлении. Если вы можете предоставить некоторые образцы кода, мы сможем дать вам больше рекомендаций.

Answer 2

Нужно ли использовать маршрутизацию в вашем сценарии?

У вас есть одна служба, которую вы публикуете как две конечные точки. REST и конечная точка namedpipes? Обе конечные точки будут выполнять один и тот же код, клиент может выбрать конечную точку, которую они хотели бы использовать.