元数据交换绑定的秘密
WCF提供了一种特殊的终结点——元数据交换终结点(MEX终结点),通过它,服务就能够发布元数据。此外,它专门提供了一个元数据交换的服务契约接口IMetadataExchange:
[ServiceContract]
public interface IMetadataExchange
{
[OperationContract]
Message Get(Message request);
}
既然要配置终结点,就必须有对应的绑定来支持。MEX终结点可以支持多种不同的传输协议,包括HTTP(S),TCP和Named Pipe,支持MEX传输的绑定的名称分别为mexHttpBinding、mexHttpsBinding、mexTcpBinding、mexNamedPipeBinding。例如,这样的配置文件:
<endpoint
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四个方法,如下所示:
public static class MetadataExchangeBindings
{
// 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.),例如:
public static Binding CreateMexHttpBinding()
{
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终结点的场景。
[ServiceContract]
public interface IMetadataExchange
{
[OperationContract]
Message Get(Message request);
}
既然要配置终结点,就必须有对应的绑定来支持。MEX终结点可以支持多种不同的传输协议,包括HTTP(S),TCP和Named Pipe,支持MEX传输的绑定的名称分别为mexHttpBinding、mexHttpsBinding、mexTcpBinding、mexNamedPipeBinding。例如,这样的配置文件:
<endpoint
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四个方法,如下所示:
public static class MetadataExchangeBindings
{
// 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.),例如:
public static Binding CreateMexHttpBinding()
{
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终结点的场景。