What an Endpoint Represents
An endpoint is the concrete, callable combination of an Address, Binding, and Contract — it's the actual door through which a client reaches a service operation. A single WCF service can expose multiple endpoints simultaneously, each with a different address, binding, or even a different (but related) contract, so the same OrderProcessor class might expose a wsHttpBinding endpoint for external partners, a netTcpBinding endpoint for internal callers, and a mexHttpBinding endpoint purely for publishing metadata (WSDL) — none of which interfere with each other.
Cricket analogy: An endpoint is like a specific gate at a stadium: the stadium (service) has multiple gates (endpoints), each leading to different seating sections (bindings) but ultimately all matches (contracts) played on the same ground.
Behaviors: Cross-Cutting Runtime Policy
A behavior is configuration that changes how the WCF runtime processes messages without changing the contract itself — things like whether metadata (WSDL) is published (ServiceMetadataBehavior), how much exception detail leaks into SOAP faults (ServiceDebugBehavior), how many concurrent instances are allowed (ServiceThrottlingBehavior), or how errors are logged (a custom IErrorHandler). Behaviors attach at three levels — service, endpoint, and operation — via serviceBehaviors, endpointBehaviors, and operation-level attributes respectively, and multiple behaviors can stack on the same target.
Cricket analogy: A behavior is like ground regulations layered on top of the match itself — DRS availability, over-rate penalties, dew rules for evening matches — none of which change the sport's core rules (contract), just how it's officiated.
Common Service and Endpoint Behaviors
ServiceMetadataBehavior (httpGetEnabled or an explicit mex endpoint) publishes WSDL so tools like svcutil.exe can generate client proxies. ServiceThrottlingBehavior caps maxConcurrentCalls, maxConcurrentSessions, and maxConcurrentInstances to protect a service from being overwhelmed. ServiceDebugBehavior's includeExceptionDetailInFaults controls whether raw .NET exception details (stack traces, internal messages) are serialized into SOAP faults — invaluable in development, but a serious information-disclosure risk in production. Endpoint-level behaviors, like a custom IEndpointBehavior for adding a custom message inspector, attach only to a single endpoint rather than the whole service.
Cricket analogy: ServiceThrottlingBehavior is like a stadium capping ticket sales at capacity to prevent overcrowding, regardless of how much demand there is for a high-profile India versus Pakistan match.
// Programmatic endpoint and behavior configuration
var host = new ServiceHost(typeof(OrderProcessor));
// Add two endpoints to the same service
host.AddServiceEndpoint(
typeof(IOrderProcessor), new WSHttpBinding(),
"http://localhost:8080/OrderProcessor");
host.AddServiceEndpoint(
typeof(IOrderProcessor), new NetTcpBinding(),
"net.tcp://localhost:808/OrderProcessor");
// Attach a service behavior for metadata + throttling
var metadataBehavior = new ServiceMetadataBehavior { HttpGetEnabled = true };
host.Description.Behaviors.Add(metadataBehavior);
var throttling = new ServiceThrottlingBehavior
{
MaxConcurrentCalls = 32,
MaxConcurrentSessions = 64,
MaxConcurrentInstances = 64
};
host.Description.Behaviors.Add(throttling);
host.Open();Behaviors can also be applied purely in code via host.Description.Behaviors.Add(...), as shown above, without touching config files at all. This is common when hosting parameters need to vary dynamically at startup, such as reading throttling limits from an environment variable before the ServiceHost opens.
Leaving includeExceptionDetailInFaults set to true in a production ServiceDebugBehavior configuration is a common and serious mistake: it causes full .NET stack traces, internal type names, and sometimes connection strings embedded in exception messages to be serialized directly into the SOAP fault sent back to any calling client, including untrusted ones.
- An endpoint is the concrete Address+Binding+Contract combination a client actually calls.
- A single service can expose multiple endpoints with different addresses, bindings, or contracts.
- Behaviors are cross-cutting runtime policies that don't alter the contract itself.
- Behaviors attach at the service, endpoint, or operation level and can stack.
- ServiceThrottlingBehavior protects a service from being overwhelmed by concurrent calls.
- ServiceMetadataBehavior publishes WSDL so client proxies can be generated automatically.
- includeExceptionDetailInFaults must be disabled in production to avoid leaking internal details.
Practice what you learned
1. What three elements combine to form a concrete, callable WCF endpoint?
2. Can a single WCF service expose more than one endpoint?
3. What does ServiceThrottlingBehavior control?
4. Why is setting includeExceptionDetailInFaults to true risky in production?
5. At which levels can WCF behaviors be attached?
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.
WCF Configuration Basics
How WCF services are wired together through web.config/app.config, and the essential Address-Binding-Contract structure behind every endpoint.
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