代码下载：点我 作为备份
Artech的代码要在他的博客里面找的
Artech大师级的“总分总”式的风格，的确是和高手过招用，作为一面菜鸟，纠结了老半天才明白，原来写博客也可以前后呼应
于是把这个小节点整理到一起已被以后不时只需
5 、自定义CallContextInitializer （Step 12 & Step 18）
提到CallContextInitializer，我想有一部分人会马上想到System.Runtime.Remoting.Messaging.CallContext。CallContext为我们创建基于当前线程的Ambient context提供了便利。通过CallConext，我们和容易地将一些contextual information保存在TLS（Thread Local Storage）中。
类似地，DispatchOperation的CallContextInitializers提供了一个 CallContextInitializer的集合，这些CallContextInitializer可以帮助我们对TLS进行初始化和释放回收的工作。比如在某个service 方法被真正之前，我们希望设置一些Context的数据，这些数据可能使业务有关，但大部分是和具体的业务逻辑没有关系的，比如一些Auditing的数据。在方式执行完成后，对这些context数据进行清理和回收。 WCF下的所有CallContextInitializer实现了System.ServiceModel.Dispatcher.ICallContextInitializer interface：
public interface ICallContextInitializer
{
// Methods
void AfterInvoke(object correlationState);
object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message);
}
再给大家介绍一个使用CallContextInitializer的场景。假设有一个service专门提供 message，考虑到Localization，当客户访问你的service获取某项message entry的时候，你希望根据该client的当前culture/UI culture返回具体的message。但是你不希望将这个culture作为API的一部分。这样你就可以这样做：在client端，通过自定义ClientMessageInspector将当前的Culture附加到outgoing message的header中。在service端，通过一个自定义的CallContextInitializer，将culture的值从incoming message header取出，并用这个culture设置当前线程的Culture和UICulture。那么message的获取只需要考虑当前线程的Culture就可以了。我将在本系列后续的文章介绍这个应用。
剩下的地方在Artech这里：点我
看Artech文章时，一直在郁闷，到底什么是扩展？为什么介绍了一个接口，又介绍一个接口，知道把文章全部看了一边，虽然没看懂，才知道这家伙小时候写作文喜欢“总-分”式，
wcf整体来说的结构模型感觉和iis是一个思想的产物，都是管道模型，然后信息和数据从这个管道留到另外一个管道，
扩展的地方主要是要弄清楚3点
1：要扩展哪一个环节
2：扩展的这个环节要解决什么问题
3：扩展的这个环节如何附加到管道和管道的交界处
对与CallContextInitializer扩展防范只有一个
但将扩展应用到管道有两种方式
1通过OperationBehavior应用CallContextInitializer
2通过EndpointBehavior运用CallContextInitializer
而通过EndpointBehavior将扩展附加到管道上时可以配置的相对来说较为灵活
Artech的例子也是这么做例子的
test