Understanding Metadata Exchange Services
A WCF client application communicates with the WCF service via an intervening proxy type. Although you
could most certainly author the proxy code completely by hand, doing so would be tedious and error prone.
Ideally, a tool could be used to generate the necessary grunge code, including the client side *.config file.
Thankfully, the .NET 3.5 SDK provides a command line tool (svcutil.exe) for this very purpose. Visual
Studio provides similar functionality via the Project | Add Service Reference menu option.
In order for these tools to generate the necessary proxy code / *.config file, they must be able to discover the
format of the WCF service interface. For example, what is the name of the contract, the methods, and the
parameters? What kind of binding is required? What is the format of custom data types?
MEX (metadata exchange) is a WCF ‘behavior’ that can be specified to fine-tune how the WCF runtime
handles your service. WCF provides numerous behaviors out of the box, and it is possible to build your own.
The HTTP MEX behavior (disabled by default) will intercept any metadata requests sent via HTTP GET.
If you want to allow svcutil.exe or Visual Studio to automate the creation of the require client-side proxy / *.
config file, you must enable MEX.
The WCF API supports numerous MEX implementations, based on the type of binding used to expose a
service endpoint. For example, MexHttpBinding / MexHttpsBinding can be used to enable MEX for HTTP
bindings. MexTcpBinding / MexNamedPipeBinding can be used to expose MEX over TCP or named pipes.
Each MEX implementation implements the IMetadataExchange interface (defined in the System.
ServiceModel.Description namespace). Notice metadata can be retrieved by a caller in a synchronous or
asynchronous manner.
// C# (VB interface definition would be similar)
public interface IMetadataExchange
{
IAsyncResult BeginGet(Message request, AsyncCallback callback,
object state);
Message EndGet(IAsyncResult result);
Message Get(Message request);
}
Enabling MEX is a matter of tweaking the host’s *.config file with the proper settings. First, you must add a
new <endpoint> just for MEX. If you are exposing MEX via HTTP, you need to define a WCF behavior to
allow HTTP GET access to the service’s address. Last, you need to associate this behavior by name to your
service via the behaviorConfiguration attribute on the opening <service> element.
Consider the following configuration file for a host exposing a service via HTTP:
<?xml version = "1.0" encoding = "utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name = "WcfMathService.MyCalc"
behaviorConfiguration = "WcfMathService.MyCalcBehavior">
<endpoint address = "http://localhost:8080/MyCalc"
binding = "wsHttpBinding"
contract = "WcfMathService.IBasicMath" />
<!-- Endpoint for MEX. -->
<endpoint address = "http://localhost:8080/MyCalc/mex"
binding = "mexHttpBinding"
contract = "IMetadataExchange" />
</service>
</services>
<!-- Behavior for MEX. -->
<behaviors>
<serviceBehaviors>
<behavior name = "WcfMathService.MyCalcBehavior">
<serviceMetadata httpGetEnabled = "True"
httpGetUrl = "http://localhost:8080/MyCalc/mex"/>
<serviceDebug includeExceptionDetailInFaults = "False" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
You can use the WCF Configuration Editor to update an existing host configuration file to expose a MEX
endpoint. This same tool can be used to disable MEX. This is useful, given that MEX is only necessary to
allow dynamic discovery of a WCF service. Production-level HTTP-based services will typically disable
MEX as allowing the world to view each endpoint could be a security issue.
Finally, be aware that it is possible to hardcode MEX behavior within the WCF service host. You have no
need to do so here, but look up the ServiceMetadataBehavior type if you are interested. Again, in most
cases this would not be desirable, given that there would be no simple way to disable this behavior.
With MEX enabled, you can restart your host and obtain metadata of your WCF service. As a quick test,
you can simply add ?wsdl to the end of the URI in a web browser. Also, notice the ‘svcutil.exe’ link in the
following screen shot, which allows you to obtain the WSDL definition of the WCF service.
http://localhost:8080/MyCalc?wsdl
A WCF client application communicates with the WCF service via an intervening proxy type. Although you
could most certainly author the proxy code completely by hand, doing so would be tedious and error prone.
Ideally, a tool could be used to generate the necessary grunge code, including the client side *.config file.
Thankfully, the .NET 3.5 SDK provides a command line tool (svcutil.exe) for this very purpose. Visual
Studio provides similar functionality via the Project | Add Service Reference menu option.
In order for these tools to generate the necessary proxy code / *.config file, they must be able to discover the
format of the WCF service interface. For example, what is the name of the contract, the methods, and the
parameters? What kind of binding is required? What is the format of custom data types?
MEX (metadata exchange) is a WCF ‘behavior’ that can be specified to fine-tune how the WCF runtime
handles your service. WCF provides numerous behaviors out of the box, and it is possible to build your own.
The HTTP MEX behavior (disabled by default) will intercept any metadata requests sent via HTTP GET.
If you want to allow svcutil.exe or Visual Studio to automate the creation of the require client-side proxy / *.
config file, you must enable MEX.
The WCF API supports numerous MEX implementations, based on the type of binding used to expose a
service endpoint. For example, MexHttpBinding / MexHttpsBinding can be used to enable MEX for HTTP
bindings. MexTcpBinding / MexNamedPipeBinding can be used to expose MEX over TCP or named pipes.
Each MEX implementation implements the IMetadataExchange interface (defined in the System.
ServiceModel.Description namespace). Notice metadata can be retrieved by a caller in a synchronous or
asynchronous manner.
// C# (VB interface definition would be similar)
public interface IMetadataExchange
{
IAsyncResult BeginGet(Message request, AsyncCallback callback,
object state);
Message EndGet(IAsyncResult result);
Message Get(Message request);
}
Enabling MEX is a matter of tweaking the host’s *.config file with the proper settings. First, you must add a
new <endpoint> just for MEX. If you are exposing MEX via HTTP, you need to define a WCF behavior to
allow HTTP GET access to the service’s address. Last, you need to associate this behavior by name to your
service via the behaviorConfiguration attribute on the opening <service> element.
Consider the following configuration file for a host exposing a service via HTTP:
<?xml version = "1.0" encoding = "utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name = "WcfMathService.MyCalc"
behaviorConfiguration = "WcfMathService.MyCalcBehavior">
<endpoint address = "http://localhost:8080/MyCalc"
binding = "wsHttpBinding"
contract = "WcfMathService.IBasicMath" />
<!-- Endpoint for MEX. -->
<endpoint address = "http://localhost:8080/MyCalc/mex"
binding = "mexHttpBinding"
contract = "IMetadataExchange" />
</service>
</services>
<!-- Behavior for MEX. -->
<behaviors>
<serviceBehaviors>
<behavior name = "WcfMathService.MyCalcBehavior">
<serviceMetadata httpGetEnabled = "True"
httpGetUrl = "http://localhost:8080/MyCalc/mex"/>
<serviceDebug includeExceptionDetailInFaults = "False" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
You can use the WCF Configuration Editor to update an existing host configuration file to expose a MEX
endpoint. This same tool can be used to disable MEX. This is useful, given that MEX is only necessary to
allow dynamic discovery of a WCF service. Production-level HTTP-based services will typically disable
MEX as allowing the world to view each endpoint could be a security issue.
Finally, be aware that it is possible to hardcode MEX behavior within the WCF service host. You have no
need to do so here, but look up the ServiceMetadataBehavior type if you are interested. Again, in most
cases this would not be desirable, given that there would be no simple way to disable this behavior.
With MEX enabled, you can restart your host and obtain metadata of your WCF service. As a quick test,
you can simply add ?wsdl to the end of the URI in a web browser. Also, notice the ‘svcutil.exe’ link in the
following screen shot, which allows you to obtain the WSDL definition of the WCF service.
http://localhost:8080/MyCalc?wsdl
Understanding Metadata Exchange Services
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services