When teaching WCF I am always asked about the difference between getting the service’s metadata by using the WSDL’s http get url, and getting the metadata by calling the MEX endpoint.
To answer that question we first need to understand the different parts of the configuration that affect metadata creation.
The ServiceMetadata behavior
This behavior controls whether metadata is created for the service. When this behavior is used, the service is scanned, and metadata is created for the service’s contracts (a list of operations and types exposed by the service).
If the behavior is not used, no metadata will be created for the service, and you will not be able to create MEX endpoints.
The ServiceMetadata’s httpGetEnabled flag
This flag defines whether the metadata will be accessible by an http get request. If this attribute is set to true, then a default url will be created for the metadata (usually the service’s address with the suffix of ‘?wsdl’). The url will lead you to a WSDL file containing the description of the service operations, but without the description of the data contracts – these files are accessible by different urls, usually the service’s url with the suffix of ‘?xsd=xsdN’. The list of these urls are pointed out from the WSDL file.
If you do not set this attribute to true, you will not be able to access the metadata using http get requests. If you prefer using https for the get requests, you can use the httpsGetEnabled attribute instead of the httpGetEnabled.
There are several other settings for the get options – you can read more about them on MSDN.
The MEX endpoint
MEX endpoints are special endpoints that allow clients to receive the service’s metadata by using SOAP messages instead of http get requests. You can create MEX endpoint that can be accessed through http, https, tcp, and even named pipes.
The response that you will receive when calling a MEX endpoint’s GetMetadata operation will include the content of the WSDL and all the XSD files that are linked to it.
So what exactly is the difference between MEX and WSDL?
There is no difference!
MEX and WSDL both output the same thing – a web service description language (WSDL) document, only MEX does it by getting a SOAP message over some transport (http, tcp, named pipes) and returning one message with all the parts, while the WSDL urls use http get requests and require sending several requests to get all the parts.
Don’t believe me?
The following diff diagram was produced by comparing the output of a MEX call to the output of the aggregated results gathered by calling all the WSDL related urls using http get:
As you can see, there are only several sections that are different between the files (marked in red and yellow), while most of the content is identical. Let’s look at one of these parts:
The red lines come from the MEX result, and the yellow lines from the WSDL file. The difference is because when using WSDL files, the rest of the XSD files are linked by using the <xsd:import> tag with the schemaLocation attribute. Since the MEX response includes all the XSD content in it, the import tag doesn’t include the location attribute.
As for the other different sections – they are different because the MEX response wraps each WSDL/XSD part with an xml element that does not appear in the aggregated files. These elements are part of the MEX standard declared by the W3C – surprise surprise, MEX is a W3C standard, it’s not a Microsoft proprietary spec.
So they are the same, still, which one to use?
In most cases there is no need for MEX endpoint – using WSDLs with http get is usually enough.
The “Add Service Reference” option in Visual Studio 2010 will work for both options. The same goes for the svcutil command line tool.
So when would I use MEX?
- If you want to make as less calls as possible to your service in order to get its metadata (one call instead of several).
- If you don’t want to use HTTP to get the metadata, but prefer using TCP or named pipes (not so common).
- If you want people to ask you why you declared a MEX endpoint.
So is it a knockout or a tie? I say tie.