The secret of metadata exchange bindings

The secret of metadata exchange bindings

WCF provides a special endpoint-the metadata exchange endpoint (MEX endpoint) through which services can publish metadata. In addition, it specializes in providing a meta data Exchange service contract interface IMetadataExchange:

[ServiceContract]
public interface IMetadataExchange
{
[OperationContract]
Message Get (message request);
}

Now that you want to configure an endpoint, you must have a corresponding binding to support it. The MEX endpoint can support a number of different transport protocols, including HTTP (S), TCP and named Pipe, and the names of the bindings that support Mex transport are mexhttpbinding, mexhttpsbinding, mextcpbinding, Mexnamedpipebinding. For example, such a configuration file:

<endpoint
Address = "MEX"
binding = "mexHttpBinding"
Contract = "IMetadataExchange"
/>
<endpoint
Address = "MEX"
binding = "Mextcpbinding"
Contract = "IMetadataExchange"
/>

So, do you need to configure a corresponding binding for the MEX endpoint? However, if we try to find a WCF-related assembly such as system.servicemodel, we cannot find such a binding class. Aaron Skonnard a secret in his blog that, in his view, Microsoft's developers played a trick, and those binding elements didn't map to a specific class, Instead, it is unified into a single class metadataexchangebindings, (the trick is these binding element names don ' t map to individual classes but rather To a single class named Metadataexchangebindings.) it provides createmexhttpbinding, createmexhttpsbinding, Createmexnamedpipebinding and Createmextcpbinding Four methods, as follows:

public static Class Metadataexchangebindings
{
Methods
public static Binding createmexhttpbinding ();
public static Binding createmexhttpsbinding ();
public static Binding createmexnamedpipebinding ();
public static Binding createmextcpbinding ();
//...
}

Looking at the implementations of these methods, you can see that they all create the built-in bindings for WCF, then adjust some default values as appropriate, and override the binding name and namespace (If you inspect the implementation of any of the These methods, You'll notice they just create one of the built-in bindings, adjusting some of the defaults, and then they override the BI Nding name and namespace.), for example:

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;
}

The purpose of this is to make it meaningless to define a new binding specifically for metadata exchange because the MEX endpoint of the different transport protocols is only slightly different in the configuration file. (They probably figured it wouldn ' t make sense to define completely new binding classes just for the MEX scenarios...th EY ' re really just slightly different configurations. ）

As you can see from this implementation, when we configure a MEX endpoint, it is not necessary to use the MEX binding provided by WCF, and we can also specify the built-in binding for it, as long as the binding conforms to the scenario of the MEX endpoint.

Secret of metadata exchange bindings