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

Question

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

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

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

Как можно сделать маршрутизацию в этом сценарии?

Answer 1

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

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

Answer 2

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

[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
    }
}

Это дает вам прямой доступ к запросу и ответу в виде необработанного сообщения и позволяет вам как определять тип запроса, так и точно контролировать структуру и формат ответа. В нашем случае диспетчер принимает запросы SOAP и HTTP GET (иначе 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 есть только около миллиона вариантов расширения (это всего лишь небольшое преувеличение), поэтому выяснение того, как они взаимодействуют без доступа к коду, может привести к сумасшествию.

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