Sdílet prostřednictvím


Bindings and Binding Elements

Bindings are collections of special configuration elements, called binding elements, which are evaluated by the service runtime whenever a client or service endpoint is being constructed. The type and order of the binding elements within a binding determines the selection and stacking order of the protocol and transport channels in an endpoint's channel stack.

Bindings, especially the system-provided bindings, usually also have a number of configuration properties that reflect the most commonly modified properties of the encapsulated binding elements.

A binding must contain exactly one transport binding element. Each transport binding element implies a default message encoding binding element, which can be overridden by adding at most one message encoding binding element to the binding. In addition to the transport and encoder binding elements, the binding may contain any number of protocol binding elements that together implement the functionality needed to service and send a SOAP message from one endpoint to another. For details, see Using Bindings to Configure Services and Clients.

Extending Bindings and Binding Elements

Windows Communication Foundation (WCF) includes system-provided bindings that cover a wide range of scenarios. (For more, see System-Provided Bindings.) There may be times, however, when you need to create and use a binding that is not included in WCF. The following scenarios require the creation of a new binding.

  • To use a new binding element (such as a new transport, encoding, or protocol binding element), you must create a new binding that includes that binding element. For example, if you added a custom UdpTransportBindingElement for UDP transport, you would need to create a new binding to make use of it. For information about performing this behavior using the System.ServiceModel.Channels.CustomBinding type, see Custom Bindings.

  • To configure existing binding elements in a way that the system-provided bindings to not expose on public properties. For example, you must create a new binding to change the order in which signing and encryption operations are performed. For information about performing this behavior, see How to: Customize a System-Provided Binding.

  • To establish corporate standard bindings that expose only specific configuration options. For example, to create for your company a variant of the WSHttpBinding for your company in which security cannot be disabled, create a new binding that behaves like the WSHttpBinding, but with security always on. For details, see Creating User-Defined Bindings.

  • To perform some customization of metadata, typically but not necessarily to configure or use some custom binding element. For more information about providing metadata support to bindings and binding elements, see Configuration and Metadata Support.

Channels, Bindings, and Binding Elements

Bindings and binding elements are the connection between the application programming model, which includes the attributes and behaviors, and the channel model, which includes the factories and listeners, message encoders, and transport and protocol implementations. Typically, binding elements and bindings are implemented to enable channels to be used by the application layer.

The channel layer hands off or receives messages to and from the service layer and transports those messages between endpoints. On a client, the channel layer is a stack of channel factories that create channels to a network endpoint. On a service, the channel layer is a stack of channel listeners that accept channels received at a network endpoint.

There are two general types of channels: protocol channels and transport channels. Transport channels are responsible for the actual transmission of a message from one network endpoint to another. Transport channels must have a default message encoder and should be able to use an alternate message encoder supplied through a message encoder binding element. A message encoder is responsible for turning a System.ServiceModel.Channels.Message into a wire representation and vice-versa. Protocol channels are responsible for implementing SOAP-level protocols (for example, WS-Security or WS-ReliableMessaging).

The primary requirement for transport and protocol channels is that they implement the required channel interfaces. To create a working channel layer they must have associated factories and listeners, and so on. To use the channel implementations from WCF there needs to be an associated binding elements derived from BindingElement for each channel and there should be a related binding extension element for inclusion into configuration files that derives from BindingElementExtensionElement.

As mentioned earlier, binding elements for message encoders, protocol, and transport channel implementations can be stacked to form a channel stack and the mechanism to line them up into an ordered set is the binding. Bindings and binding elements connect the application programming model to the channel model. You can use your channel implementations from code directly, but unless encoders, transports, and protocols are implemented as binding elements they cannot be used from the service layer programming model.

For details about developing channels and their binding elements, see Extending the Channel Layer in Windows Communication Foundation.