none
Want to understand httpGetEnabled and Mex Endpoint RRS feed

  • Question

  • i often saw people design their web service with both httpGetEnabled and Mex Endpoint but i do not know like

    1) why mex endpoint is require ? what it does ? if we omit mex endpoint then what will occur ? if i omit mex endpoint then any .net application or java application could call my web service? help me the real usage of mex endpoint like when it is required and when not ?

    2) what is httpGetEnabled

    if i omit httpGetEnabled then any .net application or java application could call my web service?

    any .net client can add web reference of my web service if httpGetEnabled is set false of does not exist? what is the default value of httpGetEnabled ?

    what httpGetEnabled does ? please explain the usage httpGetEnabled with example or scenario.

    thanks

    Tuesday, March 31, 2015 11:59 AM

Answers

  • Hi,

    There're 2 ways to expose metadata:

    One with MEX endpoint and one with <serviceMetadata httpGetEnabled="true" />. The first one will expose metadata using WS-MetadataExchange and second one will use WSDL.

    The Metadata Exchange Endpoint (MEX) is a special endpoint in WCF that exposes metadata used to describe a service. Depending upon our binding, the corresponding MEX binding will vary. There is support for HTTP, TCP, and Named Pipes.

    MEX and WSDL are two different schemes to tell potential clients about the structure of your service.

    So we can choose to either make the service contracts public as "metadata exchance format" (MEX) or in the "web service description language" (WSDL) -- the latter being accessible via HTTP(s).

    The httpGetEnabled configuration lets us set an http endpoint that would allow a non-mex proxy to be generated using WSDL, such as a legacy .NET webservice proxy.

    For more information, you could refer to:

    http://blogs.msdn.com/b/saurabs/archive/2012/04/27/http-get-v-s-mex-end-point.aspx

    Regards

    Wednesday, April 1, 2015 1:42 AM
    Moderator
  • Hi,

    For this situation, 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, 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.

    For more detailed information:

    http://blogs.microsoft.co.il/idof/2011/08/10/wsdl-vs-mex-knockout-or-tie/

    Regards

    Thursday, April 2, 2015 1:35 AM
    Moderator

All replies

  • Hi,

    There're 2 ways to expose metadata:

    One with MEX endpoint and one with <serviceMetadata httpGetEnabled="true" />. The first one will expose metadata using WS-MetadataExchange and second one will use WSDL.

    The Metadata Exchange Endpoint (MEX) is a special endpoint in WCF that exposes metadata used to describe a service. Depending upon our binding, the corresponding MEX binding will vary. There is support for HTTP, TCP, and Named Pipes.

    MEX and WSDL are two different schemes to tell potential clients about the structure of your service.

    So we can choose to either make the service contracts public as "metadata exchance format" (MEX) or in the "web service description language" (WSDL) -- the latter being accessible via HTTP(s).

    The httpGetEnabled configuration lets us set an http endpoint that would allow a non-mex proxy to be generated using WSDL, such as a legacy .NET webservice proxy.

    For more information, you could refer to:

    http://blogs.msdn.com/b/saurabs/archive/2012/04/27/http-get-v-s-mex-end-point.aspx

    Regards

    Wednesday, April 1, 2015 1:42 AM
    Moderator
  • thanks for reply.

    i like to know suppose if my service has no mex endpoint then what will happen? other .net and java client will not be able to create proxy for my web service if this exist <serviceMetadata httpGetEnabled="true" /> only.

    i guess if mex is off then a proxy can not be created for tcp binding .net pipe? if mex is off then tell me name of those bindings for which client can not create proxy ?

    u said "MEX and WSDL are two different schemes to tell potential clients about the structure of your service."

    i like to know in details that what is the difference between MEX and WSDL ?

    if only httpGetEnabled is true then which bindings will work only ?

    Wednesday, April 1, 2015 8:10 AM
  • Hi,

    For this situation, 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, 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.

    For more detailed information:

    http://blogs.microsoft.co.il/idof/2011/08/10/wsdl-vs-mex-knockout-or-tie/

    Regards

    Thursday, April 2, 2015 1:35 AM
    Moderator