In order to route raw traffic, you will need to set up a contract to send and receive the WCF Message class with request and reply actions set to "*".

public interface IRequestReceiver
{
[OperationContract(Action="*", ReplyAction="*")]
Message Receive(Message message);
}

On the service implementation class, set the AddressFilterMode attribute to Prefix to tell the service if you would like to be able to receive messages at any path below the address used by the service host instead of only at the specified url.

Use a custom binding with WebMessageEncoder and HttpTransport on your service host and outgoing endpoints. If you want to force all traffic to be raw message data rather than validating the messages as XML, add a custom WebContentTypeMapper that always returns WebContentFormat.Raw.

For each received message, you can use HttpRequestMessageProperty.Name to look up HTTP specific details such as the query string. The received message can be send to the destination endpoint by using a ChannelFactory<IRequestChannel> to create a request channel with the same custom binding used by the request service.

.NET 4.0 includes a new message encoder for raw byte streams that doesn't require as many tricks because it isn't coupled to the REST support that the WebMessageEncoder was designed for.

Don't disagree. If all you want is basic raw HTTP support with no frills, you are probably better off just using HttpListener. As you mention, WCF itself uses HttpListener under the covers. However, WCF isn't just about doing the same thing in a different way. WCF is about a uniform communication model. The nice thing about this approach is that the same interface and concepts also work with TCP, MSMQ, and any other WCF binding with very minimal effort. WCF also adds a standard extensibility model for things like tracing, performance counters, instancing, security, etc. With HttpListener, you just get the basics.

WCF certainly doesn't go out of it's way to make messaging with anything other than interfaces and objects marked up with attributes easy, but it is possible. This topic is probably worth an entire blog post, so I'll write something up when I get a chance.

The component responsible for turning the representation of the message into data is the MessageEncoder. You see the base 64 tag because you are using the text message encoder. If you want to send raw binary data, you can implement a custom message encoder class with a custom xml dictionary writer that only writes out the raw byte array and writes it out directly as bytes. This is how the byte stream message encoding in 4.0 works. Message encoders are a pretty easy thing to implement compared to something like channels.

No, there are no special pitfalls when dealing with non-SOAP messages. As long as you set the message version to none, you will be fine. If doing REST work, you can use the WebMessageEncoder. Additionally, .NET 4.0 adds ByteStreamMessageEncodingBindingElement.

http://msdn.microsoft.com/en-us/library/system.se...