元数据交换绑定的秘密
WCF提供了一种特殊的终结点——元数据交换终结点（MEX终结点），通过它，服务就能够发布元数据。此外，它专门提供了一个元数据交换的服务契约接口IMetadataExchange：
public interface IMetadataExchange
{
[OperationContract]
Message Get(Message request);
}
既然要配置终结点，就必须有对应的绑定来支持。MEX终结点可以支持多种不同的传输协议，包括HTTP(S)，TCP和Named Pipe，支持MEX传输的绑定的名称分别为mexHttpBinding、mexHttpsBinding、mexTcpBinding、 mexNamedPipeBinding。例如，这样的配置文件：
address = "MEX"
binding = "mexHttpBinding"
contract = "IMetadataExchange"
/>
<endpoint
address = "MEX"
binding = "mexTcpBinding"
contract = "IMetadataExchange"
/>
那么，是否需要为MEX终结点配置一个相应的绑定呢？不过，如果我们试着去查找System.ServiceModel等与WCF有关的程序集，是找不到这样的绑定类的。Aaron Skonnard在其博客中揭开了一个秘密，他认为，在这里，微软的开发人员玩了一个花招，那些绑定元素并没有分别映射到一个专门的类中，而是统一放到了一个单独的类MetadataExchangeBindings，（The trick is these binding element names don't map to individual classes but rather to a single class named MetadataExchangeBindings.）它提供了CreateMexHttpBinding, CreateMexHttpsBinding, CreateMexNamedPipeBinding和CreateMexTcpBinding四个方法，如下所示：
{
// Methods
public static Binding CreateMexHttpBinding();
public static Binding CreateMexHttpsBinding();
public static Binding CreateMexNamedPipeBinding();
public static Binding CreateMexTcpBinding();
//...
}
查看这些方法的实现，可以发现它们都创建了WCF的内建绑定，然后根据情况调整了某些默认值，并重写了绑定的名称和命名空间（If you inspect the implementation of any of these methods, you'll notice they just create one of the built-in bindings, adjusting some of the defaults, and then they override the binding name and namespace.），例如：
{
return CreateHttpBinding();
}
private static WSHttpBinding CreateHttpBinding()
{
WSHttpBinding binding = new WSHttpBinding(SecurityMode.None, false);
binding.Name = "MetadataExchangeHttpBinding";
binding.Namespace = "http://schemas.microsoft.com/ws/2005/02/mex/bindings";
return binding;
}
这样做的目的是由于不同传输协议的MEX终结点在配置文件中的配置只是稍有不同，为了元数据交换而专门定义一个新的绑定，是没有意义的。（they probably figured it wouldn't make sense to define completely new binding classes just for the MEX scenarios...they're really just slightly different configurations.）
从这一实现可以看出，当我们在配置MEX终结点时，使用WCF提供的MEX绑定并非必须的，我们也可以为其指定内建绑定，只要该绑定符合MEX终结点的场景。
