What Is an Operation Contract?
An operation contract is a single method on a [ServiceContract] interface marked with [OperationContract], and it defines the exact request/response message exchange pattern a client can invoke: the input parameters, the return type, and by default a request-reply pattern where the client sends a request message and blocks (or awaits) until a response message arrives. Parameter and return types must themselves be serializable, either primitive types, [DataContract]-marked types, or types the serializer understands natively like arrays and collections. Each [OperationContract] method maps to a distinct WSDL operation and, by default, its own request and response SOAP message, named after the method unless overridden with the Name property.
Cricket analogy: An operation contract is like a single ball bowled in a match: the bowler sends a delivery (the request), and the outcome, runs scored or a wicket, comes back as a defined response before the next ball can be bowled, mirroring the default request-reply pattern.
One-Way Operations and Fault Contracts
Setting IsOneWay = true on [OperationContract] tells WCF the client should not wait for any response message at all — the call returns to the client as soon as the message is handed off to the channel layer, making it suitable for fire-and-forget scenarios like logging or notifications, but it means the caller gets no confirmation of success, no return value, and exceptions thrown inside the operation are not propagated back to the client. To communicate expected business errors back to callers in a structured, typed way (rather than as generic SOAP faults with .NET exception details), an operation declares one or more [FaultContract(typeof(SomeFaultType))] attributes, and the service implementation throws a FaultException<SomeFaultType> carrying a [DataContract]-marked payload the client can catch and inspect.
Cricket analogy: IsOneWay is like a scorer updating the electronic scoreboard after every run without the batsman waiting for confirmation the sign changed — the action fires and play continues regardless of whether the display actually updated correctly.
Async Operation Signatures
Modern WCF service and client code commonly exposes operations using the Task-based asynchronous pattern, where an [OperationContract] method returns Task or Task<T> instead of a synchronous type; WCF maps this to the same underlying request-reply SOAP message exchange, but frees up server threads while I/O-bound work (like a database call) is in flight, and lets client code await the call without blocking. On the client side, svcutil.exe or Visual Studio's Add Service Reference can generate both synchronous and Task-based asynchronous proxy methods from the same WSDL, so adopting async on the client doesn't require any change to the service's operation contract itself — it's purely a proxy generation and calling-convention choice.
Cricket analogy: Async operations are like a team management not idling the entire squad while the DRS review plays out — support staff keep preparing the next over's strategy in parallel rather than freezing all activity until the decision comes back.
[ServiceContract]
public interface IOrderService
{
// Standard request-reply, async on the server
[OperationContract]
Task<OrderStatus> GetOrderStatusAsync(int orderId);
// Fire-and-forget notification, no response expected
[OperationContract(IsOneWay = true)]
void LogOrderEvent(string message);
// Typed fault contract for expected business errors
[OperationContract]
[FaultContract(typeof(OrderNotFoundFault))]
OrderStatus GetOrderStatus(int orderId);
}
public OrderStatus GetOrderStatus(int orderId)
{
var order = _repository.Find(orderId);
if (order == null)
{
throw new FaultException<OrderNotFoundFault>(
new OrderNotFoundFault { OrderId = orderId },
new FaultReason("Order not found."));
}
return order.Status;
}[FaultContract] documents expected, typed error conditions in the WSDL so client tooling can generate strongly typed catch blocks (catch (FaultException<OrderNotFoundFault> ex)). Unhandled .NET exceptions still reach the client as an untyped FaultException unless includeExceptionDetailInFaults is enabled, which should stay off in production.
One-way operations (IsOneWay = true) cannot have a return value and cannot use [FaultContract] error reporting the caller can observe — any exception thrown inside a one-way operation is effectively swallowed from the client's perspective, so they're unsuitable for anything the caller needs to confirm succeeded.
- Each [OperationContract] method maps to a WSDL operation with its own request/response SOAP messages by default.
- Parameters and return types must be serializable ([DataContract] types, primitives, or natively supported collections).
- IsOneWay = true makes a call fire-and-forget: no return value, no fault propagation to the caller.
- [FaultContract(typeof(X))] declares typed, expected business errors that clients can catch specifically.
- FaultException<T> is thrown server-side to raise a typed fault matching a declared [FaultContract].
- Task/Task<T>-returning operations use the same wire protocol but free up threads and enable client-side await.
- Proxy generation tools can produce both sync and async client methods from the same service contract.
Practice what you learned
1. What is the default message exchange pattern for a WCF [OperationContract] method?
2. What is true about an operation marked with IsOneWay = true?
3. What is the purpose of [FaultContract(typeof(OrderNotFoundFault))] on an operation?
4. How does returning Task<T> from an [OperationContract] method change the wire protocol compared to a synchronous return type?
Was this page helpful?
You May Also Like
Service Contracts
How the ServiceContract and OperationContract attributes define the public interface of a WCF service, and the rules that govern them.
Data Contracts
How WCF uses [DataContract] and [DataMember] to define the exact wire shape of types exchanged between services and clients.
WCF Architecture: Address, Binding, Contract
How every WCF endpoint is built from three core elements — Address, Binding, and Contract — and how they fit into the layered WCF architecture.
What Is WCF?
An introduction to Windows Communication Foundation, the .NET framework for building service-oriented, message-based distributed applications.
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