The Address, Binding, Contract (ABC) Triad
Every WCF endpoint is defined by exactly three things, often remembered as ABC: Address (where the service lives, a URI), Binding (how communication happens, covered in the bindings topic), and Contract (what operations the service exposes, usually a C# interface decorated with [ServiceContract] and [OperationContract]). Configuration in WCF exists almost entirely to wire these three pieces together for one or more endpoints under a <service> element, either declaratively in web.config/app.config's <system.serviceModel> section, or imperatively in code using ServiceHost.AddServiceEndpoint().
Cricket analogy: The ABC triad is like a match being fully defined by the venue (Address, say Eden Gardens), the format (Binding, say a T20), and the two competing teams' agreed rules (Contract) — leave out any one, and there's no match to play.
Reading a system.serviceModel Section
The <system.serviceModel> section groups configuration into <services> (one <service> element per implementation class, containing its <endpoint> elements and optional <host> base addresses), <bindings> (named binding configurations that endpoints reference via bindingConfiguration), and <behaviors> (cross-cutting settings like metadata publishing or error handling, applied via behaviorConfiguration). Understanding this three-way grouping is the key to reading any WCF config file: a <service> ties together an Address (from the endpoint or base address), a named <binding>, and a Contract (the fully-qualified interface name), while <behaviors> layer on extra runtime policies that aren't strictly part of the ABC triad.
Cricket analogy: Reading system.serviceModel is like reading a full tournament rulebook organized into sections: fixtures (services), pitch and format regulations (bindings), and code-of-conduct rules (behaviors) — each section serves a distinct purpose.
<configuration>
<system.serviceModel>
<services>
<service name="OrderService.OrderProcessor"
behaviorConfiguration="metadataBehavior">
<host>
<baseAddresses>
<add baseAddress="http://localhost:8080/OrderProcessor" />
</baseAddresses>
</host>
<endpoint address="" binding="wsHttpBinding"
contract="OrderService.IOrderProcessor" />
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="metadataBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>An endpoint's final Address is the base address plus the endpoint's relative address. In the example above, the base address is http://localhost:8080/OrderProcessor and the endpoint's address is empty, so the effective endpoint URI is exactly http://localhost:8080/OrderProcessor. The metadata exchange endpoint resolves to http://localhost:8080/OrderProcessor/mex.
Client-Side Configuration
On the consuming side, a matching <client> section under <system.serviceModel> defines endpoints the client will call, typically generated automatically by Visual Studio's 'Add Service Reference' or the standalone svcutil.exe tool when pointed at a running service's metadata endpoint. Each client <endpoint> element specifies the address to call, the binding configuration (which must be compatible with the service's binding), and the contract interface name generated in the proxy code, so the ChannelFactory or generated client class knows exactly how to construct and open a channel.
Cricket analogy: Client-side configuration is like an away team studying the host ground's exact pitch conditions and format rules before the match, making sure their equipment and strategy match what the host stadium requires.
Auto-generated client configuration from 'Add Service Reference' captures a snapshot of the service's binding at generation time. If the service's binding configuration changes later (say, a security mode update), the client config will not update automatically — it must be regenerated or manually edited, or calls will fail with a binding mismatch even though the code compiles fine.
- Every WCF endpoint is defined by the ABC triad: Address, Binding, and Contract.
- system.serviceModel groups configuration into services, bindings, and behaviors sections.
- A service's effective endpoint address combines its base address with the endpoint's relative address.
- behaviorConfiguration attaches cross-cutting policies like metadata publishing to a service.
- Client-side config must be compatible with the service's binding or calls fail at runtime.
- Auto-generated client config is a snapshot and does not update automatically when the service changes.
Practice what you learned
1. What does the 'C' in the WCF ABC triad stand for?
2. Where are named binding configurations defined so an <endpoint> can reference them via bindingConfiguration?
3. How is an endpoint's effective address determined when a <host><baseAddresses> element is set?
4. What happens if a service's binding configuration changes after a client's proxy was generated with Add Service Reference?
5. What is the purpose of the <behaviors> section in system.serviceModel?
Was this page helpful?
You May Also Like
WCF Bindings Explained
A tour of WCF's built-in bindings and how each one shapes the transport, encoding, and security of a service contract.
Endpoints and Behaviors
How WCF endpoints expose service operations and how behaviors attach cross-cutting runtime policies to services, endpoints, and operations.
Hosting WCF Services
How WCF services get activated and run, from self-hosted console applications to IIS and Windows Activation Services.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics