Routing REST to named pipes in WCF

Question

I want to route request comming in by REST (WebHttp) to another service. The other service will listen via named pipes or REST. The router is a simple service which takes all requests as messages, routes them to the target and sends the answer from the target back to the client.

1) When I try to route REST to named pipes there is the envelope problem: REST has no envelope and named pipes has SOAP. And in REST the reqest data is encoded in the url while in named pipes it is encoded in the SOAP body.

2) When I try to route REST to REST the reqest is routed to the service, the reply comes to the router and is send, but I get a "Request Error" at the client.

How can routing be done in this szenario?

Answer 1

In order to help you with the first part of your scenario I'd have to understand a bit more about the design constraints you might have. There are several different approaches you might be trying, so it is unclear where to start. I can say that when we built a similar "dispatching" service the approach we used was to implement the most general contract possible, like this:

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

This gives you direct access to the request and response in raw message form and allows you to both determine the type of request and precisely control the struture and format of the response. In our case the dispatcher accepts both SOAP and HTTP GET (aka REST) requests and has to return either a SOAP response or a REST response (any one of XML, JSON, HTML). This does require more knowledge of how WCF formats its messages and of the interactions between the message structure and the binding of your dispatcher, but it gives you as much control as is possible.

In terms of diagnosing your second problem, again not sure exactly what the issue is from the config snippet, could be lots of things. Two tools that we have found invaluable in diagnosing similar issues are the WCF service trace tool and a WCF decompiler. The trace tool is part of the visual studio package. To enable it you add the following config:

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

This gives you a trace file (in the specified location) which you can read using SvcTraceViewer.exe. It shows all the details of the exchage and can provide clues as to what you aren't doing that WCF is expecting you to. The decompiler is useful because sometimes to understand why something is a requirement you just have to see what the code is up to. WCF has only about a million extension options (that's only a slight exageration) so figuring out how they interact without code access can be maddening.

I hope this helps point you in the right direction. If you can provide some code samples we might be able to give you more directed advice.

Answer 2

Do you need to use routing in your scenario?

Could you have one service which you publish as two endpoints. a REST and a namedpipes endpoint? Both endpoints would execute the same code, the client could choose which endpoint they wished to use.