We've been looking at the flow of messages (Part 1 and Part 2), but have never stopped along the way to look at the extensibility points where you can plug in your own code. Being a highly-extensible framework, WCF has piles and piles of these extensibility points. Some of the extensibility points are more likely than others to be confused with the proper use of channels. I'm just going to list out a sequence of points, not intended to be exhaustive, where you can execute custom code in the message flow. We'll go in chronological order from the client to the server to match the earlier articles.

1. Client code- Obviously, you have total control here over when service methods get called.
2. Generated client proxy- If your proxy object is generated ahead of time instead of dynamically, then you can extend the proxy to run code whenever a particular service method is invoked.
3. Message serializer- The message serializer sits below the proxy and converts CLR objects into an XML message.
4. Client message inspector- The client-side message inspector lives above the channel stack and is the first one to see the newly-generated XML message. You could alternatively have added a new channel to the top of the channel stack.
5. Client channel stack- The channel stack has all of the protocol and transport channels that were specified in your binding.
6. Network intermediaries- Once on the wire, anything can happen to the byte stream during transmission.
7. Service activation- Service activation is an optional layer that automatically controls the lifetime of service processes.
8. Service host- The host of the service actually has many extensibility points inside. You can replace the factory that is used to stamp out host instances or you can modify the behavior of the host itself.
9. Service channel stack- The service channel stack is the receive-side collection of protocol and transport channels.
10. Dispatch message inspector- A server-side message inspector lives above the service channel stack and functions similarly to its client-side equivalent.
11. Dispatch operation selector- Once we've gotten the message into a particular service, we need to figure out which one of the service operations is being called.
12. Message deserializer- Message deserialization reverses the serialization process by converting an XML message back into CLR objects.
13. Dispatch parameter inspector- Parameter inspection is the equivalent of a message inspector for the CLR objects that get produced during deserialization.
14. Dispatch operation invoker- We know which call to make and what information to give it. Now, we just need to make that call.
15. Service code- Again, you have total control over what happens inside the service method.

Next time: Channel Shapes