Manually Adding MEX Endpoints

One of the changes in a recent version was that MEX endpoints no longer get added to your service host by default. Instead, you either need to supply the ServiceMetadataBehavior or supply the ServiceMetadataBehavior and manually add your favorite type of MEX endpoint. Let's talk about the case where you want to specifically add your own MEX endpoint.

Adding your own MEX endpoint is a two step process. First, you need to add a ServiceMetadataBehavior to the service host.

 ServiceMetadataBehavior behavior = new ServiceMetadataBehavior();
host.Description.Behaviors.Add(behavior);

This step is required because the service host validates the contract type you specify for endpoints. Normally, the contract of the endpoint must be compatible with the contract declared as the type parameter for your service host. However, you probably don't have a service that uses the IMetadataExchange contract for your business logic. Inside the service host, if the contract for the endpoint does not match the contract of the host, the service host will then look at the collection of registered behaviors. If there is a ServiceMetadataBehavior present, then the service host checks the contract for the endpoint against the list of acceptable metadata contracts held by ServiceMetadataBehavior. Right now, that list of acceptable contracts contains only IMetadataExchange. In any case, this allows you to add a MEX endpoint to the service while still strongly validating the contract types of endpoints.

The second step is to add the MEX endpoint. You need to choose a compatible MEX binding using MetadataExchangeBindings and a MEX address. You can choose a non-standard MEX binding as well but you then have the problem of communicating the configuration for that binding to your clients. There's no special magic in the MEX address as compared to the normal address of an endpoint.

 host.AddServiceEndpoint(
   typeof(IMetadataExchange),
   MetadataExchangeBindings.CreateMexNamedPipeBinding(),
   "net.pipe://localhost/service/mex/"
);

MetadataExchangeBindings supports HTTP, HTTPS, TCP, and named pipes for MEX transports. The HTTP(S) MEX bindings use the WSHttp binding with the SecurityMode set appropriately. The TCP and named pipe MEX bindings are custom bindings containing just the transport. All of the bindings are in the https://schemas.microsoft.com/ws/2005/02/mex/bindings namespace.

You should also see An Unanticipated Addendum for Certain MEX Scenarios if you're using port sharing.

Next time: Why is the RequestContext Null?

Comments

• Anonymous
  August 22, 2006
  To finish up the series on one-way HTTP requests, I promised to supply a custom channel that fixes the...

• Anonymous
  September 05, 2006
  In the previous articles about MEX endpoints, I always used the MetadataExchangeBindings class to create...

• Anonymous
  September 19, 2006
  PingBack from http://blogs.msdn.com/drnick/archive/2006/08/23/713297.aspx

• Anonymous
  October 08, 2006
  In the previous articles about MEX endpoints , I always used the MetadataExchangeBindings class to create

• Anonymous
  December 12, 2006
  The idea of metadata is to provide a description of your service such that someone, with no other information