Message Flow Interception Points

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

Comments

• Anonymous
  March 07, 2007
  What does the trace message "The pool of the native MSMQ messages is full. This may affect performance."

• Anonymous
  March 30, 2007
  First of I'd like to thank Guy for his excellent screencast - very convenient, so thanks. Specifically

• Anonymous
  April 26, 2007
  I've been playing around a little with WCF, and will play it a lot next month (for my thesis). I've

• Anonymous
  May 17, 2007
  My favorite design patterns is Provider design pattern (abstract factory – GoF definition) . I like it