[ServiceContract] Attribute in WCF

By | |

The [ServiceContract] attribute identifies an interface or class as a service contract. This attribute explicitly defines the interface as a CLR interface and enables it to carry out WCF contract operations, with each [ServiceContract] attribute being mapped to an equivalent WDL portType declaration.
The following list contains the parameters available for use with the [ServiceContract] attribute.
More than one parameter can be applied to the attribute, and these parameters can be used in any order:

  • CallbackContract
  • ConfigurationName
  • Name
  • Namespace
  • ProtectionLevel
  • SessionMode

The following sections discuss these parameters in detail.

CallbackContract

The CallbackContract parameter gets or sets the type of callback contract when the contract is communicating in duplex mode. This parameter contains a Type value that specifies the callback contract. The Type value should contain a CallbackContract = typeof(ClientContract) that represents the required opposite contract in a two-way (duplex) message exchange operation, or in other words, the client callback contract.
It is possible to have callback contracts on one-way operations as well. In this scenario, the callback contract represents outgoing calls from the service that can be received by the client.
Specifying this parameter informs the client that it needs to listen for inbound method calls coming from the service. These inbound method calls operate independently of other client activity.
The following example shows the CallbackContract attribute in use:

[ServiceContract(CallbackContract = typeof(IClientContract))]
public interface IBookOrder
{
    ...
}

In this example, the service specifies a callback contract, IClientContract. The default value for this parameter is a null reference.

ConfigurationName

The ConfigurationName parameter gets or sets the name used to locate the service element in a configuration file. This value is a string data type. If not specified, the default is the name of the service implementation class.
The following example uses the ConfigurationName parameter to specify the service element in the service configuration file:

[ServiceContract(ConfigurationName = “service”)]
public interface IBookOrder
{
    ...
}

The application configuration file for the preceding example would look like the following:

<configuration>
  <system.servicemodel>
    <services>
      <service name = “BookOrder”>
      </service>
    </services>
  </system.servicemodel>
</configuration>

Name

The Name parameter gets or sets the name for the <portType> element in WSDL (Web Service Description Language). The default value for this parameter is the name of the service class or interface to which this parameter is applied.
As a refresher, the <portType> element in WSDL contains all the necessary information for a service, such as the operations it can perform and the messages that are involved.
The Name parameter for the [ServiceContract] attribute sets the name of this element. The following example sets the Name parameter:

[ServiceContract(Name=”IBookOrder”)]
public interface IBookOrder
{
    ...
}

Namespace

The Namespace parameter gets or sets the namespace for the <portType> element in WSDL (Web Service Description Language). The default value for this parameter is “http://tempuri.org”.
The Namespace parameter for the [ServiceContract] attribute sets the namespace of this element.
The following example sets the Namespace parameter:

[ServiceContract(Namespace=”http://www.WonderBooks.com”)]
public interface IBookOrder
{
    ...
}

ProtectionLevel

The ProtectionLevel parameter specifies the protection-level binding requirement. This includes encryption, digital signature, or both, for each endpoint that exposes the contract.
The value of this parameter comes from the System.Net.SecurityLevel.ProtectionLevel enumeration. The following enumeration values are available:

  • EncryptAndSign – Encrypt and sign data to ensure the confidentiality and integrity of transmitted data.
  • None – Authentication only.
  • Sign – Sign data to help ensure the integrity of the transmitted data, but do not encrypt.

The following example sets the protection level of the service contract to that of None, meaning that only simple authentication is required:

[ServiceContract(ProtectionLevel = System.Net.Security.ProtectionLevel.None)]
public interface IBookOrder
{
    ...
}

This property has a hierarchical structure, in that the topmost value establishes the default for all lowerlevel scopes ([OperationContract] attribute) unless a specific value is specified for the lower-level scopes. It is important to note that the value specified on this property is the default value for all operation messages.
If the associated binding supports security and no protection level is specified on the contract, the protection level defaults to EncryptAndSign for the entire contract. If the binding does not support security, the protection level defaults to None.

SessionMode

The SessionMode attribute specifies the type of support for reliable sessions that a contract requires or supports.
The value of this parameter comes from the SessionMode enumeration. The following enumeration values are available:

  • Allowed – Specifies that the contract supports reliable sessions if the incoming connection supports them.
  • NotAllowed – Specifies that the contract never supports reliable sessions.
  • Required – Specifies that the contract requires a reliable session at all times.

The following example sets the session mode of the service contract to Required, signifying that a service contract must always use reliable sessions:

[ServiceContract(SessionMode = SessionMode.Required)]
public interface IBookOrder
{
    ...
}

Reliable sessions are implemented via the WS-Reliable Messaging protocol. WCF reliable messaging is implemented to provide reliable end-to-end message transfer between two SOAP endpoints, regardless of the number of intermediaries between the two endpoints. You should consider using reliable sessions in the following scenarios:

  • You want sessions over HTTP.
  • You have intermittent connectivity between the endpoints.
  • Proxy intermediaries or transport bridges exist.
  • SOAP intermediaries exist between endpoints.
Tagged . Bookmark the permalink.

Leave a Reply