CODEWITHSUNDEEP
wcf
Thomas
Thomas

Reputation: 34208

How config file would look at service end for multiple endpoint

i am working with wcf service application where svc file is created. now i want to design my service in such a way that people can connect to my service by http url and as well as by tcp url

so i would like to add three endpoint in my config one for wshttp, one for wsDualhttp and another one for tcp. so please someone give me sample config entry with 3 endpoints for wshttp, wsDualhttp and tcp.

in this case do i need to have three different mex endpoint for wshttp, wsDualhttp and tcp.

also tell me 3 url by which i can create proxy classes at client side. thanks

Upvotes: 1

Views: 433

Answers (1)

marc_s
marc_s

Reputation: 755381

You could have something like this (assuming self-hosting, since only then can you really determine the full service addresses yourself - hosting in IIS, the service address(es) are most determined by where your .svc file lives):

  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="Default">
          <serviceMetadata httpGetEnabled="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <services>
      <service name="YourNamespace.YourService" behaviorConfiguration="Default">
        <endpoint name="Default" 
            address="http://YourServer/Services/MyService" 
            binding="basicHttpBinding" 
            contract="YourNamespace.IYourService"/>
        <endpoint name="TCP" 
            address="net.tcp://YourServer/ServicesTCP/MyService" 
            binding="netTcpBinding" 
            contract="YourNamespace.IYourService"/>
        <endpoint name="mex" 
            address="http://YourServer/Services/MyService/mex" 
            binding="mexHttpBinding" 
            contract="IMetadataExchange"/>
        <endpoint name="Dual" 
            address="http://YourServer/Services/MyService/Dual" 
            binding="wsDualHttpBinding" 
            clientBaseAddress="http://localhost:8001/client/"
            contract="YourNamespace.IYourDualService"/>
      </service>
    </services>
  </system.serviceModel>

This would define three endpoints:

  • a HTTP endpoint at http://YourServer/Services/MyService for your service
  • a HTTP MEX endpoint at http://YourServer/Services/MyService/mex for the metadata exchange (service discoverability)
  • a Net.TCP endpoint at net.tcp://YourServer/ServicesTCP/MyService for your service

You could of course also use two base addresses to make things a bit easier in the config:

  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="Default">
          <serviceMetadata httpGetEnabled="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <services>
      <service name="YourNamespace.YourService" behaviorConfiguration="Default">
        <host>
          <baseAddresses>
            <add baseAddress="http://YourServer/Services"/>
            <add baseAddress="net.tcp://YourServer/ServicesTCP"/>
          </baseAddresses>
        </host>
        <endpoint name="Default" 
            address="MyService" 
            binding="basicHttpBinding" 
            contract="YourNamespace.IYourService"/>
        <endpoint name="TCP" 
            address="MyService" 
            binding="netTcpBinding" 
            contract="YourNamespace.IYourService"/>
        <endpoint name="mex" 
            address="MyService/mex" 
            binding="mexHttpBinding" 
            contract="IMetadataExchange"/>
      </service>
    </services>
  </system.serviceModel>

This would configure the equivalent service endpoints.

The wsDualHttpBinding is different in that it requires at least a clientBaseAddress for the callback mechanism (the WCF service will call back your client to send back e.g. status messages) - so it needs some extra tweaks and it cannot really be bolted onto an existing service that works over wsHttpBinding - it needs to be done separately. But basically - it's still pretty much all the same thing....

Update: after reading up on the topic (it's not something I use very often), it does appear that duplex communication is indeed possible also using netTcpBinding, but only if you're self-hosting your service - IIS doesn't support duplex communication over netTcpBinding.

Creating a duplex service does still require extra steps and extra code - so you cannot really have a service that's both non-duplex using basicHttpBinding or wsHttpBinding and duplex at the same time. So it really doesn't make sense to have another endpoint in this example using the wsDualHttpBinding because that service either needs to be really duplex (then you can use wsDualHttpBinding and netTcpBinding) - or it's not duplex - then you can use basicHttpBinding, wsHttpBinding, netTcpBinding and a few more "exotic" bindings (like MSMQ, named pipes etc.)

Upvotes: 1

Related Questions