Every Windows Communication Foundation (WCF) service relies on three fundamental elements: Address, Binding, and Contract. These components are unified through endpoints, where each endpoint must incorporate all three aspects. Host processes expose these endpoints for client consumption. While each endpoint corresponds to a unique address, multiple endpoints can share identical bindings and contracts. A single service can expose several endpoints to accommodate various client requirements.

WCF configuration files consist of two distinct sections: server-side configuration and client-side configuration. Due to their different functional purposes, each section has specific configuration requirements.

Server-Side Configuration Structure

The server configuration primarily encompasses endpoint definitions, binding configurations, and behavior specifications. A typical server-side configuration includes the following primary XML sections:

<system.serviceModel>
  <services>
    <service>
      <endpoint/>
    </service>
  </services>
  <bindings>
    <!-- System-provided binding elements like <basicHttpBinding> -->
    <!-- Custom binding elements like <customBinding> -->
    <binding>
      <!-- Specific binding configuration such as <BasicHttpBinding> -->
    </binding>
  </bindings>
  <behaviors>
    <!-- System-provided behavior elements -->
    <behavior>
      <!-- Specific behavior elements like <throttling> -->
    </behavior>
  </behaviors>
</system.serviceModel>

Services Configuration Section

The <services> section allows definition of multiple services, each encapsulated within individual <service> elements. The hosting application utilizes these definitions to publish available services.

The <service> element requires two key attributes: name and behaviorConfiguration. The name attribute specifies the fully qualified type name implementing the service contract, including namespace information. The behaviorConfiguration attribute references corresponding behavior definitions in the <behaviors> section.

The <endpoint> element forms the core of service configuration, defining the three essential components: Address, Binding, and Contract. Since binding specifics are configured separately in the <bindings> section, the endpoint references these through the bindingConfiguration attribute:

<services>
  <service name="BruceZhang.MyService" 
           behaviorConfiguration="MyBehavior">
    <endpoint address="" 
              binding="netTcpBinding"
              bindingConfiguration="DuplexBinding" 
              contract="BruceZhang.IHello" />
  </service>
</services>

Multiple endpoints can be defined for a single service:

<services>
  <service name="Microsoft.ServiceModel.Samples.CalculatorService" 
           behaviorConfiguration="CalculatorServiceBehavior">
    <endpoint address="" 
              binding="wsHttpBinding"
              contract="Microsoft.ServiceModel.Samples.ICalculator" />
    <endpoint address="mex" 
              binding="mexHttpBinding" 
              contract="Microsoft.ServiceModel.Samples.IMetadataExchange" />
  </service>
</services>

When the address field is empty, the endpoint uses the default base address. For instance, the ICalculator service would be accessible at http://localhost/servicemodelsamples/service.svc, while the IMetadataExchange service would be at http://localhost/servicemodelsamples/service.svc/mex. Base addresses can be explicitly defined using the <host> element within the service configuration:

<service name="Microsoft.ServiceModel.Samples.CalculatorService"
         behaviorConfiguration="CalculatorServiceBehavior">
  <host>
    <baseAddresses>
      <add baseAddress="http://localhost/ServiceModelSamples/service.svc"/>
    </baseAddresses>
  </host>
  <endpoint ... />
</service>

Behaviors Configuration Section

While clients require binding and address information to consume services, service behaviors define runtime characteristics and execution properties. Behaviors enable configuration of various service aspects and allow insertion of custom functionality.

For example, the ServiceMetadataBehavior enables metadata publication for WCF services:

<behaviors>
  <serviceBehaviors>
    <behavior name="metadataSupport">
      <serviceMetadata httpGetEnabled="true" httpGetUrl=""/>
    </behavior>
  </serviceBehaviors>
</behaviors>

In WCF, behaviors are implemented as attributes, with System.ServiceModel.ServiceBehaviorAttribute and System.ServiceModel.OperationBehaviorAttribute being the most commonly used. Although behaviors can be applied programmatically, defining them in configuration files provides greater flexibility.

ServiceBehavior and OperationBehavior attributes control various service properties includign:

• Object instance lifetime management
• Concurrency and asynchronous processing
• Configuration behavior settings
• Transaction handling behavior
• Serialization behavior customization
• Metadata transformation rules
• Session lifecycle management
• Address filtering and message header processing
• User impersonation capabilities

Instance context mode can be configured through ServiceBehavior:

<behaviors>
  <serviceBehaviors>
    <behavior name="instanceManagement">
      <serviceBehavior instanceContextMode="PerCall" />
    </behavior>
  </serviceBehaviors>
</behaviors>