2
votes

My service has no svc file. See the config entry and definitely notice one thing that one mex endpoint has been declared for one tcp endpoint.

So my question is when my service will have many endpoint like wshttp, wsDualhttp, tcp,m smq etc then do i need to declare mex endpoint for each type of different endpoint?

Here is my service config detail where service is hosted.

<services>
  <service name="ChatService.ChatHandler" behaviorConfiguration="behaviorConfig">
    <host>
      <baseAddresses>
        <add baseAddress="net.tcp://localhost:1648/ChatService/" />
        <add baseAddress="http://localhost:1647/ChatService/" />
      </baseAddresses>
    </host>
    <endpoint address="tcp"
                      binding="netTcpBinding"
                      bindingConfiguration="tcpBinding"
                      contract="ChatService.IChat"/>

    <endpoint address="net.tcp://localhost:1645/ChatService/mex"
                      binding="mexTcpBinding"
                      contract="IMetadataExchange"/>
  </service>
</services>

Edited Part

So from what I can understand about Marc_S's answer: Even without any MEX endpoints, my service will be fully operational.

If someone wants to interface with your service, you'll need to provide the relevant information in some other way, though, since those clients cannot "auto-discover" and inspect the service via MEX - you'll have to e.g. provide a download of your WSDL and accompanying XSD files so someone can build a client without interactively querying your service's MEX endpoints.... so if i do not expose mex then i have to create wsdl file and i have to pass that wsdl to client manually....am i right?

Is there any other way for client to create proxy of my service when mex will be disable?

Then is there any way to determine from service end which protocol client use to invoke my service....suppose i have multiple endpoint like wshttp, wsdualhttp, tcp, msmq etc?

2

2 Answers

3
votes

The MEX endpoint - as it name, Metadata EXchange implies - is used to make your service discoverable, e.g. someone trying to write a client for your service can point his browser and/or development tool (like Visual Studio or svcutil) at this endpoint and through a defined data exchange, the client can find out what your service offers in terms of service methods and in terms of data structures.

This is a nicety and a convenience - but it's really only needed for creating the client-side proxy code - usually only once.

There is no requirement to have MEX endpoints, or if you're security conscious, you might decide to explicitly not expose that information for everyone to see and to inspect. Even without any MEX endpoints, your service will be fully operational. If someone wants to interface with your service, you'll need to provide the relevant information in some other way, though, since those clients cannot "auto-discover" and inspect the service via MEX - you'll have to e.g. provide a download of your WSDL and accompanying XSD files so someone can build a client without interactively querying your service's MEX endpoints.

As such - there is no requirement to expose one MEX endpoint for each protocol (net.tcp, http) that you plan to support. You can very easily have five different endpoints using different protocols, and yet only expose the most often used HTTP MEX endpoint (which allows clients and developers to browse to the MEX endpoint in their browser to get the "help page" and see the contents of the WSDL = Web Service Description Language file that describes your service)

3
votes

Metadata exchange endpoint is not required, you can declare one endpoint or create service without any Metadata exchange endpoints