Define Operation contracts
It is clear that in order to be able to call your service, you need to mark the contract interface/class with the ServiceContractAttribute. After this post, it’ll be also clear that you must mark your exposed methods with the OperationContractAttribute. In most cases you’ll be satisfied with the default settings, but there are certain cases (one-way or duplex messaging pattern) when you need to customize the OperationContractAttribute.
Fortunately, it exposes a set of named parameters for implementing such behaviors. Here’s a brief list of them:
|Named Parameters of OperationContractAttribute|
|Action||Controls the action on the request message. The default value is the fully qualified name of the method as an address, for example: http://TheServices/IContract/MyMethod. Set it to an asterisk to indicate an operation which handles all unmatched requests. There’s a constraint on this: there can be only one method like this, and it must take a message as parameter.|
|AsyncPattern||A Boolean value indicating whether the current pattern is asynchronous.|
|IsInitiating||A Boolean value indicating the marked method is the initiation of a session. The default is true.|
|IsOneWay||A Boolean value indicating that the operation returns nothing, and has no output parameters. The default is false. When you set this to true, and return anything else than void, an InvalidOperationException will be thrown at run time.|
|IsTerminating||A Boolean value indicating that after this method the session should be terminated, and the channel closed.|
|Name||Overrides the operation name from the default value: the contract’s method name. This is interesting from the clients point of view. They can call your through the proxy class by the name you specify here (think about IntelliSense support).|
|ProtectionLevel||A member of the System.Net.Security.ProtectionLevel enumeration, indicating the level of protection required by the method.|
|ReplyAction||Controls the action on the reply message. Use it in conjuction|
You must understand that by controlling these attributes with named parameters, you make changes in the underlying service metadata. Therefore, it’s essential to regenerate proxy classes after you’ve modified them, to prevent communication failures.
I don’t think there so much to say about Operation contracts. The best way is probably to try them out and inspect the changes in the generated metadata.