Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Service vs Client nodes/sections in Web.Config

Tags:

wcf

What is the difference between the Service node/section and the Client node/section in the configuration section? Why configure endpoints in one section over the other? Which is best for interoperability?

I'm currently building a service that talks to another service. I have endpoints for my clients and endpoints for the other service. Visual Studio seems to lump all the endpoints into the Client section.

I thought that client node was for your consumption and service node was for producing. But when you create a new wcf service visual studio puts your new service endpoint settings under the client node. I have moved my endpoint between both sections trying to figure out what the difference is.

When should I use service over client?

<system.serviceModel>
<services>
  <service> <!--I noticed some tutorials and using wcf config edit tool 
                puts producer endpoint settings here -->
    <endpoint  blah settings/>
    <endpoint  blah settings/>
  </service>
</services>
<client> <!--Visual Studio puts both producer and consumer endpoint 
             settings here -->
  <endpoint  blah settings /> 
  <endpoint  blah settings /> 
  <endpoint  blah settings /> 
</client>
<bindings>.....
</system.serviceModel>
like image 392
yedevtxt Avatar asked Mar 05 '26 05:03

yedevtxt


1 Answers

Many settings in the WCF web.config (or app.config for that matter) can be shared for both consumers of a service as well as publishers of a service including:

  • Bindings
  • Endpoint Behaviors
  • Diagnostics

However as you have discovered, some config is specific to a service. A well-written service usually specifies:

  1. It's base address. This is a convenience when defining a service as it allows your to define endpoints using relative addresses. Clients however don't use this particular setting as they need an absolute path. For this reason it makes no sense to specify in the section
  2. Services can also be clients. If the client and server endpoints were all plonked together, WCF would not be able to know which should utilise the base address for one thing
  3. Service behavior

By dividing up config between client and server, WCF is better able to know where to look for endpoints.

Which is best for interoperability?

I don't think that has anything to do with it. WCF is a means to achieve interopability but just by using WCF does not imply you will achieve it. Interopability is established when both parties agree on say a particular service contract; canonical data model; data transformation; message version or many of the other patterns as defined by SOA Patterns.org So there are various patterns you must follow. e.g. If you change a method on service contract but have not updated the clients then you have broken interopability by breaking the schema of the service.

Visual Studio seems to lump all the endpoints into the Client section

If your WCF process is both a consumer and producer of WCF services then it should not be putting all the endpoints under