I have talked a lot about WCF's extensibility model and I never knew how much of the core functionality can be extended until a recent deep dive session with one of our customers developing on WCF. The client had a multi tier application with the middle tier using SOAP based messaging to communicate with the back end. They wanted to investigate using WCF for the middle tier and hence the deep dive session. They did the hard job of creating ServiceContract's for all the functionality the WCF middle tier service will expose. The customer had invested heavily in current pipeline that handled processing and dispatch of the incoming SOAP messages to the backend and wanted to reuse that. The ServiceContract they developed had lots of Operations and this posed additional overhead on the logic port. Their ideal solution would be to somehow transform the SOAP message coming in from WCF to a format matching the format as expected by the backend.
Basically they wanted to avoid implementing the huge ServiceContract and just plug in a small wrapper that will perform the transform. The first solution that comes to mind is to implement a "facade Contract" that had one generic operation that accepted and returned a SOAP message and that did the message transformation. This was an acceptable solution but this meant that clients generating proxy to this facade contract will not have all the Operations of the original contract. The customer also wanted to retain functionality provided by individual operations like addressing and additional custom header information for a required context that could be used by the backend that was lost when using one generic operation. They wanted to avoid serializing and deserializing incoming and outgoing arguments as they could be large and hence avoid the performance hit from such conversions.
Some extensibility points that come to mind for this scenario are IInstanceProvider and IOperationInvoker. IInstanceProvider was ruled out coz the need was to extend the actual Operation invoked on the instance not extend the way instances were created. Ideally we ended up with an extensibility model that used IOperationInvoker and IDispatchMessageFormatter and here is how it works.
Let’s see how this extensibility processes an incoming request.
As you can see, we never use the dummy instance implementation and reduced the need for the extra serialize/deserialize step in the contract implementation to invoke the back end. Result - Another happy customer :)
Since this extension has no effect on the way messages are received/sent by WCF's runtime, all the message and transport level security options continue to work. When this extension is coupled with IInstanceContextProvider, IInstanceProvider, Custom Channels we can practically replace the all major operations of WCF runtime.
A sample program showing off the above extensibility is attached.