System.ServiceModel 4.0.0.0 System.Attribute System.AttributeUsage(System.AttributeTargets.Class | System.AttributeTargets.Interface | System.AttributeTargets.All, Inherited=false)

Use the attribute on an interface (or class) to define a service contract. Then use the attribute on one or more of the class (or interface) methods to define the contract's service operations. When the service contract is implemented and combined with a binding and an object, the service contract is exposed for use by clients. For an overview of the process using simple examples, see Getting Started. For more information about creating service contracts, see Defining Service Contracts.

The information expressed by a and its interface is loosely related to the Web Services Description Language (WSDL) <portType> element. A service contract is used on the service side to specify what the service’s endpoint exposes to callers. It is also used on the client side to specify the contract of the endpoint with which the client communicates and, in the case of duplex contracts, to specify the callback contract (using the property) that the client must implement in order to participate in a duplex conversation.

An interface or class that is decorated with must also have at least one method marked with the attribute to expose any functionality. See the Examples section for a code example of the simplest use of the two attributes to define and implement a service.

Use the properties to modify the service contract.

The property specifies the name of the service element in the configuration file to use.

The and properties control the name and namespace of the contract in the WSDL <portType> element.

The property specifies whether the contract requires a binding that supports sessions.

The property specifies the return contract in a two-way (duplex) conversation.

The and properties indicate whether all messages supporting the contract have a explicit value, and if so, what that level is.

Services implement service contracts, which represent the data exchange that a service type supports. A service class can implement a service contract (by implementing an interface marked with that has methods marked with ) or it can be marked with the and apply the attribute to its own methods. (If a class implements an interface marked with , it cannot be itself marked with .) Methods on service types that are marked with the are treated as part of a default service contract specified by the service type itself. For details about service operations, see .

By default, the and properties are the name of the contract type and http://tempuri.org, respectively, and is . It is recommended that service contracts explicitly set their names, namespaces, and protection levels using these properties. Doing so accomplishes two goals. First, it builds a contract that is not directly connected to the managed type information, enabling you to refactor your managed code and namespaces without breaking the contract as it is expressed in WSDL. Second, explicitly requiring a certain level of protection on the contract itself enables the runtime to validate whether the binding configuration supports that level of security, preventing poor configuration from exposing sensitive information. For more information about protection levels, see Understanding Protection Level.

To expose a service for use by client applications, create a host application to register your service endpoint with indigo1. You can host indigo2 services using Windows Activation Services (WAS), in console applications, Windows Service applications, ASP.NET applications, Windows Forms applications, or any other kind of application domain.

Hosting in the WAS is very similar to creating an ASP.NET application. For details, see How To: Create a Basic IIS-Hosted Service.

Clients either use the service contract interface (the interface marked with ) to create a channel to the service or they use the client objects (which combine the type information of the service contract interface with the class) to communicate with your service. For details on client channels to services, see the class and WCF Client Overview.

Using a class or interface to inherit from another class or interface extends the parent contract. For example, if an IChildContract interface is marked with and inherited from another service contract interface, IParentContract, the IChildContract service contract contains the methods of both IParentContract and IChildContract. Extending contracts (whether on classes or interfaces) is very similar to extending managed classes and interfaces.

The most flexible approach to creating services is to define service contract interfaces first and then have your service class implement that interface. (This is also the simplest way to build your services if you must implement service contracts that have been defined by others.) Building services directly by marking a class with and its methods with works when the service exposes only one contract (but that contract can be exposed by more than one endpoint).

Use the property to indicate another service contract that, when bound together with the original service contract, define a message exchange that can flow in two ways independently. For details, see .

Indicates that an interface or a class defines a service contract in a indigo1 application.

- Constructor
  4.0.0.0

  The constructor creates an instance of the attribute with no session requirements, no callback contract, and the default name and namespace.

  Initializes a new instance of the class.

- Property
  4.0.0.0
  System.Type To be added.

  Specify an interface in the property that represents the required opposite contract in a two-way (or duplex) message exchange. This enables client applications to listen for inbound operation calls that the server-side service application can send independently of client activity. Callback contracts that have one-way operations represent calls from the service that the client can handle.

  The attribute is ignored on callback contracts. To configure runtime behavior of callback objects, use the .

  Gets or sets the type of callback contract when the contract is a duplex contract.

- Property
  4.0.0.0
  System.String To be added.

  To set the value by which the configuration system locates a contract value in the configuration file, see .

  Gets or sets the name used to locate the service in an application configuration file.

- Property
  4.0.0.0
  System.Boolean To be added.

  The property indicates whether a protection level value other than false has been set for the contract.

  Gets a value that indicates whether the member has a protection level assigned.

- Property
  4.0.0.0
  System.String To be added.

  Use the and the properties to control the name and namespace of the <portType> element in WSDL.

  Gets or sets the name for the <portType> element in Web Services Description Language (WSDL).

- Property
  4.0.0.0
  System.String To be added. To be added.

  Gets or sets the namespace of the <portType> element in Web Services Description Language (WSDL).

- Property
  4.0.0.0
  System.Net.Security.ProtectionLevel To be added.

  Use the property to specify the degree to which the contract binding requires encryption, digital signatures, or both for endpoints that expose the contract. The value set here is the default value for all operation messages including faults.

  It is important to remember that the protection behavior at runtime is the combination of the protection-level values set on the following properties. These properties have a hierarchical structure. Setting the outermost value establishes the default setting for all narrower scopes unless a different value for a narrower scope is explicitly set. In this case, the outer value remains the default for all narrower scopes with the exception of that specifically set.

  For example, if is set to and no other narrower scopes have protection level settings, all messages in an operation contract are encrypted and signed. If, however, one of those operations has the set to , then the messages for that operation are signed but all other messages in the contract are encrypted and signed.

  For details about protection levels and their assumptions and scopes, see Understanding Protection Level.

  The scopes at which these values are set are:

  The property on .

  The property on .

  When there is no protection level explicitly specified on the contract and the underlying binding supports security (whether at the transport or message level), the effective protection level for the whole contract is . If the binding does not support security (such as ), the effective is for the whole contract. The result is that depending upon the endpoint binding, clients can require different message or transport level security protection even when the contract specifies .

  Specifies whether the binding for the contract must support the value of the property.

- Property
  4.0.0.0
  System.ServiceModel.SessionMode To be added.

  Use the property to require bindings that support sessions between endpoints. A session is a way of correlating a set of messages exchanged between two or more endpoints. If your service supports channel sessions, you can then use the property to specify the relationship between instances your service contract implementation and the channel session. If a binding does not support sessions, an exception is thrown.

  For example, if the property is set to and the property is set to , clients can use the same connection to make repeated calls to the same service object.

  For more information about sessions and service instances, see Using Session and Sessions, Instancing, and Concurrency.

  A channel that supports sessions supports the default association of a service instance with a particular session. However, different session implementations support different features in addition to session-based instancing control. indigo2 provides four types of sessions that you can use to provide sessionful application behavior; each type of session provides additional behavior specific to the type of session it is.

  The supports security sessions, in which both ends of communication have agreed upon an encryption and/or digital signature process; all messages are correlated with that specific secure conversation. For more information, see Securing Services. For example, the , which contains support for both security sessions and reliable sessions, by default uses only a secure session which encrypts and digitally signs messages.

  The supports the sessions exposed by the TCP/IP connections to ensure that all messages are correlated by the connection session at the socket level.

  The , which implements the WS-ReliableMessaging specification, provides support for reliable sessions in which messages are delivered in order and exactly once, enabling confidence even when messages travel across multiple nodes during the conversation. For more information, see Reliable Sessions.

  The provides MSMQ datagram sessions. For more information, see Queues in Windows Communication Foundation.

  Remember that setting the property does not specify the type of session the contract requires, only that it requires one.

  Gets or sets whether sessions are allowed, not allowed or required.