The routing service that ships with WCF4 beta 2 is a very useful layer for implementing basic standard router facade which provides virtualization, versioning, protocol bridging, windows identity impersonation, transaction propagation and routing capabilities for your back-end services.
Unfortunately, I’m afraid that it has a lot to advance in order to be usable for advanced more-sophisticated layer as far as it goes for implementing an actual management layer for message brokering and a policy enforcement point.
Following are links to my previous posts concerning the routing service:
WCF 4 – Routing Service, The Beginning
WCF 4 Routing Service – Going Basic
WCF 4 Routing Service – Supported Bindings
WCF 4 Routing Service – O/W Operation and Corresponding Channel Shapes
WCF 4 Routing Service – Resolve Endpoint in Runtime
WCF 4 Routing Service – Runtime Governance
WCF 4 Routing Service as a PEP (Policy Enforcement Point)
Concluding failure points discussed in previous articles:
- WebHttp isn’t supported as much as I could tell
- I didn’t succeed with calling a O/W operation on a back-end service exposed with WsHttpBinding and Reliable Session enabled
- I didn’t find a way to control the contract of the channel shape used by the router service down the chain when calling to the back-end service. That prevented me from controlling the invocation pattern if I have more information regarding the target back-end service and operation.
- I didn’t find a way to get a hold of the reply messages in duplex communication mode in order to apply my custom logic such as logging the messages passed through it in runtime.
- The router service is difficult to extend, having control over its invocation process is extremely limited, making it impossible to utilize it as a PEP.