For greater flexibility our router can be something like a pass through router. If we are just calling a backend service then we can use a generic contract to receive and forward messages to the back end service as shown below.

Pros

1. Loosely Coupling
2. Potentially can avoid a lot of serialization and deserialization cost. (Encoders need to match for this)
3. Changes in the backend usually do not require changes in the Broker provided the broker uses generic client contracts.

Cons

1. Synchronous pattern has its overhead and not scalable.
2. The router has to be of very high capacity to support high loads even though backend machines may block on IO.

Best Practices

1. Match your encoders – Encoder mismatches can cause a heavy serialization and deserialization on the router. This is because any change between the backend and the frontend encoders on the binding would require re-encoding of the message and hence a full read and write at the encoder layer.
2. Avoid having to create message copy. If the backend can create the copy/validate you save the routers CPU for more messages per second.
3. Make sure you use fast message copy  - Buffered messages have a very optimized message copy path that WCF would take provided you haven’t changed parts in the message. I will talk about how to hit this fast path next.

  Next – How to Optimize Message Copying using CreateBufferedCopy?

I use the term broker and router very loosely here since they follow very similar guidelines as described here - WCF Broker Overview. Apologies for not being very rigid with these terms.

I will dive into best practices of building a router by progressing from a very simple implementation to a robust one through different scenarios and varying degrees of complexities.

The easiest implementation is by using a strongly typed contract with message forwarding as shown below.

[ServiceContract]
public interface IOrderService
{
    [OperationContract]
    Order[] GetOrders(int numOrders);
}


class OrderService:IOrderService
{
    Order[] GetOrders(int numOrders)
    {
      return backendProxy.GetOrders(numOrders);
    }        
}

Pros

1. Very easy to implement.

Cons

1. Tight coupling between router and backend.
2. The router needs to serialize and deserialize the whole message and hence very inefficient.
3. Any change to backend would require changes to router as well.
4. Not a scalable solution since higher loads would choke the server due to heavy serialization issues.

Next – Router Implementation – Message Forwarding – Copy/Pass through

A broker is usually a central point for message forwarding and pass-through for clients and backend services. There are many types of brokers that come into mind

1. Security broker – Usually a gate check for incoming message which transitions from one security protocol to another without mucking with the message most of the time.
2. Protocol transition broker (http to tcp)
3. Central work load balancer – Routing of some form
4. 
   Message transformer and service busses
   1. Aggregators/ Scatter gather/Composition & other patterns
5. Encoding transition – SOAP/XML/Rest/Binary etc.
6. Relaying persistent brokers (Persistent stores that holds on the message and later forwards it)
   1. Glorified queuing
7. The list goes on… and you can derive a ton when using a combination of Message exchange patterns -

But they mostly fall into the below basic model unless the client manages to bypass the broker with a P2P communication with the backend itself.

Router Implementation – Strong Typed with Message Forwarding

Update:

Aug’5’10

Here are 2 really good articles on MSDN that I would recommend for the functional aspects to architect your your router.

1. Building a WCF Router, Part 1 (Addressing semantics)
2. Building A WCF Router, Part 2 ( Scenarios and Message Exchange patterns)