WCF Extensibility
Over the next months I intend on writing a series of posts about the (many) extensibility points from WCF (up to .NET Framework 4.0). The cadence should be around one new post every 1-2 weeks (depending on the workload I have at work).
WCF is a very powerful framework for creating distributed, service-oriented applications, and if you want to stick to defining a few operations, exposing them to a service over one of the pre-defined bindings, and consuming them in a client, you can look at any of the many “hello world” examples out there and that will be enough. However, if you want to do something a little differently, almost everything (as I’ve found out while answering to questions on the WCF MSDN Forum and other sources of user complaint feedback) can be accomplished using one of the extensibility points in WCF.
The biggest problem is which one. There are over 30 different points in which one can hook up code in the whole WCF pipeline (including serialization and the service model) that most people simply get too confused about which one is the right for their specific scenario (and sometimes a solution actually needs code in more than one of those places to work together). I’ve worked with WCF for over 6 years now (since before it was released), and I still don’t know all of them (and this series will be a good motivation for me to learn more about the product I work on).
In each post, I’ll talk about one of the extensibility points. My plan is to present some scenarios in which it can help, and always have code samples for them. Whenever applicable, I’ll talk about different ways of accessing that extensibility point, and some tips about the specific hook which may not be present in the “official” MSDN documentation.
Here’s a list of topics I plan on writing about. It won’t be necessarily done in this order (I’ll likely write about the most used ones first, or one for which I’ve seen an issue at that week), and I may add more items to this index if I find (or remember) any more.
1. Service model extensibility
1.1. Behaviors
1.1.1. IServiceBehavior
1.1.2. IContractBehavior
1.1.3. IEndpointBehavior
1.1.4. IOperationBehavior
1.2. WCF Runtime
1.2.1. Message interception
1.2.1.1. I[Client/Dispatch]MessageInspector
1.2.1.2. IParameterInspector
1.2.2. Mapping between message and operation parameter
1.2.2.1. I[Client/Dispatch]MessageFormatter
1.2.3. Mapping between message and CLR operations
1.2.3.1. I[Client/Dispatch]OperationSelector
1.2.3.2. IOperationInvoker
1.2.4. Instance [context] creation / initialization
1.2.4.1. IInstanceProvider
1.2.4.2. IInstanceContextProvider
1.2.5. Error handling
1.2.5.1. IErrorHandler
1.2.6. Others
1.2.6.1. Initializer interfaces (IInstanceContextInitializer / IChannelInitializer / ICallContextInitializer)
1.2.6.2. IInteractiveChannelInitializer
1.3. Exposing / consuming metadata
1.3.1. IWsdlExportExtension
1.3.2. IWsdlImportExtension (and IOperationContractGenerationExtension / IServiceContractGenerationExtension)
1.3.3. IPolicy[Import/Export]Extension
1.4. Configuration
1.4.1. BehaviorExtensionElement
1.4.2. BindingElementExtensionElement / StandardBindingElement / StandardBindingCollectionElement
1.5. Web Hosting
1.5.1. ServiceHostFactory
1.6. WCF REST (3.5 / 4.0 model)
1.6.1. QueryStringConverter
1.6.2. Extending WebHttpBehavior
1.7. Others
1.7.1. Extensible objects: IExtensibleObject<T> and IExtension<T>
2. Channel extensibility
2.1. Protocol channels (client)
2.2. Protocol channels (server)
2.3. Message encoders
2.4. Transport channels
2.4.1. Request transport channels - part 1 (synchronous path)
2.4.2. Request transport channels - part 2 (interaction with runtime extensions)
2.4.3. Request transport channels - part 3 (asynchronous path)
2.4.4. Reply transport channels
2.4.5. Duplex transport channels
3. Serialization extensibility
3.1. Serialization callbacks (On[Ser/Deser]ializ[ing/ed])
3.2. IDataContractSurrogate
3.3. DataContractResolver
3.4. IExtensibleDataObject / IDeserializationCallback / IObjectReference
4. Miscellaneous extensibility scenarios
4.1. Hooking into the tracing mechanism
4.2. Custom serialization in Silverlight 4
4.3. Extensibility in Windows Phone / Silverlight 3
4.4. WCF RIA Services
5. Wrapping up
I hope you find this upcoming series interesting, and I’m looking forward to your feedback – I’ll bring them to the team to the best of my abilities.
By the way, the WCF team is aware that, although very powerful, the framework can sometimes be hard to use. One of the main focus of the upcoming release is exactly making it simpler to create / configure / consume WCF services.
Comments
Anonymous
March 14, 2011
Thank you thank you thank you.Your outline alone offers far more information than I've managed to find over the last couple of years.Anonymous
March 14, 2011
Good stuff!Anonymous
March 16, 2011
This looks real interesting. I hope you get more time to work on this and get us the articles sooner than later. Looking forward for more of these.ArunAnonymous
March 22, 2011
The comment has been removedAnonymous
April 12, 2011
Waiting for the upcoming release. Thanks you so much for your work.Anonymous
April 13, 2011
WCF is still terrible. Everything is internal, sealed and there is a serious lack of extensibility. Many standards, really a wrong word, is differently implemented in various framework, so it is still hard to be interoperable and tweak the little things, so they are truly interoperable.Anonymous
April 18, 2011
Excellent post Carlos - thank youAnonymous
May 09, 2011
Excellent Carlos !Anonymous
July 01, 2011
wonderfulAnonymous
July 01, 2011
wonderful!Anonymous
July 28, 2011
Amazing work!!!Anonymous
August 04, 2011
great job Carlos, this is very helpfulAnonymous
October 28, 2011
The comment has been removedAnonymous
October 31, 2011
Hi CarlosFigueira,I have read many of your articles. Thank you for all of them. They are all very great. Will you write some articles about WCF authentication pipeline?Anonymous
October 31, 2011
The comment has been removedAnonymous
October 31, 2011
Lcng, I don't have any current plans for writing about authentication (or security) in general (I don't have much experience in this area), but that could be something I could do after the end of this series.Anonymous
November 01, 2011
CarlosFigueira,thank you.Looking forward to the rest of this series and the "something" after them.好人好梦。Anonymous
November 08, 2011
Wow. It is like a book... and on a topic that is almost never covered in books. Looking forward to diving deeper into your blog post. There is a lot of gold to be found here...Anonymous
November 15, 2011
Lars,Please check the following hands-on session which I guess contains you want.by Miguel Castro on "Extensibility in WCF" on dnrTv.www.dnrtv.com/default.aspxHTHAnonymous
November 24, 2011
Ashok, that link doesn't contain the answer to Lars question. It's a good introduction to extensibility, though.Anonymous
January 31, 2012
Excellent! Thank you!!!Anonymous
June 06, 2012
Carlos,Can you please tell me how can I get Message before its get signed by the WCF?? I would like to make some changes then? Which WCF Extensibility option should I use???ThanksAnonymous
June 06, 2012
I want the security options applied and before wcf signs it i need to get the message with WSA headers in it.Anonymous
June 07, 2012
Hi ahmad_riaz, the message signing is usually done via the protocol channels added by the security binding element; that means that any of the extensibility points in the runtime, such as a Message Inspector, would be able to look at the message object prior to its signing. Regarding WSA headers, which are those? The ones used for signing itself?Anonymous
July 29, 2012
the best Guide to WCF Extensibility in the www universe.... Great Carlos!Anonymous
January 19, 2013
First of all, thank you very much for writing a great set of posts on WCF extensibility. This has been really helpful, especially the outline. I have a couple of questions regarding error handling.I am implementing an IErrorHandler that is supposed to firstly log the exception that has occurred and secondly to return the error information back to the client in the return value.Did I understand you correctly that things like logging should be done in IErrorHandler.HandleError, rather than in IErrorHandler.ProvideFault? My experience, seconded by a few other people seems to be that HandleError doesn't get called but ProvideFault does. In my case, I am not setting the fault parameter to anything in IErrorHandler.ProvideFault. Please clarify. If all my return values derive from a common base class that contains a property to contain any error information, how can I provide this error value back to the client, i.e., where do I create this within the WCF pipeline and how?Anonymous
February 05, 2013
excellent source to learn WCF extensibilityAnonymous
April 05, 2013
Beyond description! I have learnt more about WCF through your articles than any book I have read. Thanks you!