Why do i need both mex endpoint and httpGetEnable?

Question

I was wondering why do i need to declare this:

 <serviceMetadata httpGetEnabled="true" />

and also this

<endpoint contract="IMetadataExchange" binding="mexHttpBinding" address="mex" />

If i use only the first one - it is working via browser. so why do i need the second one ?

Can you give me example please for the situation which i'll have to use the latter ?

score 20 · Accepted Answer · answered Sep 02 '11 at 15:30

20

You need to

enable the service to publish metadata at all (that's the serviceMetadata behavior) - but you don't need the httpGetEnabled - that's optional
have a place (endpoint) where an inquiring client can go grab that service metadata - that's the MEX endpoint. This is for a machine-readable format of the metadata - one that Visual Studio or svcutil can use to create a client. It's not intended for human consumption

answered Sep 02 '11 at 15:30

marc_s

732,580
175
1,330
1,459

but he can do that also without the mex endpoint , meaning by wsdl ... so? – Royi Namir Sep 02 '11 at 15:32
If i omit "mex endoint" - the "svcutil " will not be able to grab it ? – Royi Namir Sep 02 '11 at 15:36
@mid787: you seem to be right - with `` in place, you (and `svcutil`, too) can get the WSDL from the URL without any MEX endpoint present - so you probably really don't need that, as long as your service publicly publishes a WSDL – marc_s Sep 02 '11 at 15:44
2

So why will i ever need the mex ? i believe VS can grab it even without the MEX point – Royi Namir Sep 02 '11 at 15:46
6

@mid787: if your service e.g. publishes only `nettcp` (or `msmq`) endpoints - you can't exactly "browse" to a netTCP address or an msmq queue... Also: lots of companies do not allow the `?wsdl` to be published "online" - it's prohibited by their corporate e.g. security guidelines - but a custom protocol like MEX is ok. – marc_s Sep 02 '11 at 15:46
thank you very very much but last question :') for the last sentence you wrote : So a company which doesn't want to exposure its WSDL via HTTP - can expose it by netTcp via mex - but the consumer will have to acquire the wsdl through the company ip. is it correct ? – Royi Namir Sep 02 '11 at 16:00
@mid787: no, not really - **if** you have a MEX endpoint, that's good enough - you don't need anything else. Most client generation tools (like `svcutil` or its Java counterparts) can create the client from the WS-Metadata that's exposed over the MEX endpoint - no need for a WSDL as such. – marc_s Sep 02 '11 at 17:21
Assume that I have only basicHttpBinding.So I need to make httpGetEnabled="true" only.. The `Mex` will come into play only if I have `netTcp` or `msmq`. Is my understanding correct? – LCJ Mar 17 '13 at 06:00

score 9 · Answer 2 · answered Jul 31 '13 at 07:53

This seems to be useful in the following situation...

<system.serviceModel>
    <services>
        <service name="WCFService.Service" behaviorConfiguration="ServiceBehavior">
            <host>
                <baseAddresses>
                    <add baseAddress="net.tcp://localhost:8080/WCFService"/>
                </baseAddresses>
            </host>

            <!-- Net.Tcp EndPoints-->
            <endpoint address=""
              binding="netTcpBinding"
              contract="WCFService.IService" />

            <endpoint address="mex"
              binding="mexTcpBinding"
              contract="IMetadataExchange" />

           </service>
        </services>
        <behaviors>
            <serviceBehaviors>
                <behavior name="ServiceBehavior">
                    <serviceMetadata httpGetEnabled="false" />
                </behavior>
            </serviceBehaviors>
        </behaviors>
</system.serviceModel>

There are no HTTP endpoints defined and you can get to your service in the following ways...

 - Browser: http://localhost/WCFService/Service.svc    
 - svcutil.exe net.tcp://localhost:8080/WCFService/Service.svc/mex

If you comment out the MEX endpoint then neither will work.

You wonder why the meta data can still be seen in the browser as

a) I don't have a HTTP endpoint and b) I have specifically set ...

<serviceMetadata httpGetEnabled="false" />

The reason for this is that in the advanced settings for the website I had the following defined for Enabled Protocols under Advanced Settings...

http,net.tcp

If you remove http then the metadata cannot be seen in the browser. It would seem that it is in this scenario, a net.tcp enabled only website, that you need the mex endpoint.

score 2 · Answer 3 · answered Dec 04 '14 at 12:06

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.

Why do i need both mex endpoint and httpGetEnable?

3 Answers3

Linked