The ABC of WCF Endpoints
Every WCF service exposes one or more endpoints, and every endpoint is fully defined by exactly three elements known as the ABC: Address, Binding, and Contract. The Address is a URI specifying where the service is located, such as http://server/GreetingService or net.tcp://server:8090/GreetingService. The Binding specifies how the endpoint communicates — the transport protocol (HTTP, TCP, named pipes, MSMQ), the message encoding (text, binary, MTOM), and the security model. The Contract specifies what the endpoint offers: the operations, data types, and message exchange patterns a client can rely on. A single service can expose multiple endpoints, each with a different combination of these three, letting the same business logic serve intranet clients over netTcpBinding and internet clients over wsHttpBinding simultaneously.
Cricket analogy: Think of the Address as the stadium location, the Binding as the match format (Test, ODI, T20) determining the rules of play, and the Contract as the official scorecard rules everyone agrees to follow — Sachin Tendulkar's century means the same thing regardless of which ground it happens at.
Layered Architecture: From Contracts to Channels
Internally, WCF is organized in layers. At the top sits the Contracts layer (service, data, message, and fault contracts) that describes the shape of the application. Below that is the Service Runtime, which handles behaviors like throttling, instance management, transaction propagation, and error handling. Below that is the Messaging layer, made of channels — a stack of components (transport channel, encoding channel, security channel) that process a message on its way in or out. At the bottom is the Hosting layer, which determines where the service lives: self-hosted in a console app or Windows Service, hosted in IIS, or hosted in Windows Process Activation Service (WAS) for non-HTTP protocols.
Cricket analogy: This layering is like a cricket broadcast pipeline: the commentary team (Contracts) describes what's happening, production staff (Service Runtime) manage replays and graphics, the transmission chain (Messaging channels) encodes and sends the signal, and the broadcaster's ground infrastructure (Hosting) determines whether it airs on Star Sports or a streaming app.
Configuring Endpoints
Endpoints can be defined declaratively in a configuration file (App.config or Web.config) under the system.serviceModel section, or programmatically in code using ServiceHost.AddServiceEndpoint. Configuration-based endpoints are preferred in production because they let operations teams change addresses, bindings, or security settings without recompiling, while programmatic configuration is common for self-hosted scenarios, unit tests, or dynamically constructed services. Behaviors, such as serviceMetadata to expose WSDL or serviceDebug to control fault detail exposure, are attached separately from endpoints and apply service-wide or per-endpoint.
Cricket analogy: Configuring endpoints via XML config versus code is like a team management choosing its playing XI from a published team sheet before the toss versus a captain making an on-field tactical call — both set the same match parameters through different mechanisms.
<system.serviceModel>
<services>
<service name="MyCompany.Services.GreetingService">
<endpoint address=""
binding="wsHttpBinding"
contract="MyCompany.Services.IGreetingService" />
<endpoint address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:8080/GreetingService" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>Setting includeExceptionDetailInFaults to true exposes internal .NET stack traces to clients over the wire, which is convenient for debugging but a serious information-disclosure risk in production. Always turn it off (or override it per environment) before deploying.
The mexHttpBinding endpoint publishes WSDL metadata, allowing tools like Visual Studio's 'Add Service Reference' or the svcutil.exe command-line tool to generate client proxies automatically from a running service.
- Every WCF endpoint is defined by Address (where), Binding (how), and Contract (what).
- A single service can expose multiple endpoints with different ABC combinations for different client types.
- WCF's architecture layers Contracts, Service Runtime, Messaging channels, and Hosting.
- Endpoints can be configured declaratively in config files or programmatically in code.
- Behaviors like serviceMetadata and serviceDebug are configured separately and control cross-cutting service behavior.
- mexHttpBinding exposes WSDL metadata used by tools to auto-generate client proxies.
- Never expose full exception details to clients in production; disable includeExceptionDetailInFaults.
Practice what you learned
1. In the WCF ABC model, what does the 'B' stand for and what does it configure?
2. Which WCF architectural layer is responsible for handling instance management, throttling, and transaction propagation?
3. What is the purpose of a mexHttpBinding endpoint?
4. Why is it recommended to configure endpoints in App.config/Web.config rather than only in code for production services?
Was this page helpful?
You May Also Like
What Is WCF?
An introduction to Windows Communication Foundation, the .NET framework for building service-oriented, message-based distributed applications.
Service Contracts
How the ServiceContract and OperationContract attributes define the public interface of a WCF service, and the rules that govern them.
Operation Contracts
How [OperationContract] defines individual callable methods on a WCF service, including one-way calls, faults, and async patterns.
Data Contracts
How WCF uses [DataContract] and [DataMember] to define the exact wire shape of types exchanged between services and clients.
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