WCF Services—OperationContract Attribute

Visual C# Tutorials

.NET Framework Tutorials

WCF Services Requirements § Install .NET 3.0 Development Service Contracts § Contract First or Code? Service Design Programming Model "Hello, World" "Hello, World" with Interfaces Hosting on IIS ServiceContract Attribute OperationContract Attr. ServiceBehavior Attribute OperationBehavior Attr. Data Contracts § Summary

© 2007 Chris Peiris, Dennis Mulder

OperationContract Attribute

The OperationContract attribute, as with the ServiceContract attribute, provides for even greater control over the WSDL generation. Generally you’ll accept most of the defaults, but for certain features, such as duplex messaging, you’ll need to use options indicating the operation is one-way. Additionally, for session management, you’ll be leveraging some of the options for overall service session management.

Table 4-6 describes the properties in the OperationContract attribute type.

Table 4-6. OperationContractAttribute Properties

Class Property	Description
Action	Controls the action on the request (input) message; the default is the contract namespace, contract name, and operation name. Use this in conjunction with * to indicate the operation can handle all unmatched operation requests—there can be only one of these, and it must take a message as a parameter.
AsyncPattern	Provides for the implementation of an asynchronous process on the server, client, or both tiers. This feature aids .NET clients in supporting operations with the efficiency of using a single client thread.
IsInitiating	Indicates that this operation is an initiation of a session; the default is true, so if you require session initiation, you need to set all operations to false except the initiation operation.
IsOneWay	Indicates that the operation returns nothing (void) or can’t accept out parameters. The default is false; as a result, all operations without it return an empty message that is useful for capturing exceptions. If applying the value of true to an operation that is marked with a return type other than void, WCF doesn’t throw a compiler error. Instead, it throws an InvalidOperation exception when the WCF framework inspects the ServiceContract types at runtime.
IsTerminating	Indicates this operation terminates the session and the channel should close.
Name	Overrides the operation name from the method name on the interface.
ReplyAction	Controls the action on the reply (output) message. Used in conjunction with the Action property.

The solution Example06 has an updated version of the ITradeService service contract. In this version, the OperationContract properties have been explicitly set. You’ll also notice that the ServiceContract attribute now has a new property indicating it supports sessions. Without the ServiceContract.SessionMode property being set to SessionMode.Required, the OperationContract properties of IsInitiating and IsTerminating would be illogical. This condition is not caught at compile time, only at reflection time.

Listing 4-10 is a snippet from Example06. Notice that some added properties have been set in both the ServiceContract and OperationContract attribute initialization.

Listing 4-10. TradeService.cs with OperationContract Properties

[ServiceContract(
    Namespace = "http://PracticalWcf",
    Name = "TradeService",
    SessionMode = SessionMode.Required)
]
public interface ITradeService
{
    [OperationContract(
      Action="http://PracticalWcf/TradeSecurityNow",
      IsOneWay = false,
 
      IsTerminating = false,
      Name = "TradeSecurityNow"
      )]
    decimal TradeSecurity( string ticker, int quantity );
}

These changes provide control over the WSDL generated from the metadata on your service contract. If you take a brief "before" and after look, you’ll see some of the changes.

If you open the URL that points to the WSDL for the definitions, you’ll see the changes and added control. The URL to open is as follows (ensure your ASP.NET development server is running!):

http://localhost:8888/ExchangeWeb/TradeService.svc?wsdl=wsdl0

---

Note The generated URL by the .NET Framework may differ from the one shown here. To find the correct URL, look for the <wsdl:import...> element in the base URL.

---

Listing 4-11 is the generated WSDL before applying the OperationContract properties.

Listing 4-11. TradeService.cs WSDL Before Property Changes

<wsdl:input wsaw:Action="http://PracticalWcf/TradeService/TradeSecurity"
  message="tns:TradeService_TradeSecurityNow_InputMessage" />

Listing 4-12 shows the WSDL definition for a newly modified service contract.

Listing 4-12. TradeService.cs WSDL after Property Changes

<wsdl:input
    wsaw:Action="http://PracticalWcf/TradeSecurityNow"
    message="tns:TradeService_TradeSecurityNow_InputMessage"/>

Note the updated Action names for both the input and output messages. If you look inside the client proxy code generated as part of the project, you’ll see the updated matching names for the new contract.

---

Caution Whenever an update to metadata occurs, ensure you regenerate the proxy. You can do this by selecting the "map" file in Solution Explorer for the service reference, right-clicking, and choosing Update Service Reference. This resubmits the call through SvcUtil.exe for the regeneration of the proxy type in your client project. This assumes you’re working with Visual Studio integration.

---

Inside the client program, the only change required, other than updating the service reference through SvcUtil.exe, is to modify the method name on the proxy class from the following:

result = proxy.TradeSecurity( "MSFT", 2000 );

to the following:

result = proxy.TradeSecurityNow( "MSFT", 2000 );

The reason for this change is that the OperationContract.Name property is now set to TradeSecurityNow. As a result, when the call to SvcUtil.exe was made to regenerate the proxy, the new operation name instead of the old is used, which causes a break in the compile.