Understanding Bindings
By now, you should appreciate that bindings are an important part of the framework provided by WCF. A binding consists of one or more binding elements. A binding element handles one particular non-functional aspect of a service, such as whether it supports transactions or how the service implements security. You compose binding elements together in various combinations to create a binding. Every binding should have a single binding element describing the transport protocol, and a binding should also contain a binding element that handles message encoding. You can add further binding elements to provide or enforce further features in a service. A binding element corresponds to a channel. Remember that when a host opens a service, the WCF runtime uses each binding element in the binding to create the channel stack. A client also creates channel stack when it connects to the service by opening a proxy object. To ensure that a client application can communicate successfully with a service, it should use a binding that provides binding elements that match those implemented by the service.
The WCF Predefined Bindings
The WCF library contains a number of classes in the System.ServiceModel.Channels namespace that implement binding elements. Examples include the BinaryMessageEncodingBinaryElement class that performs binary encoding and decoding for XML messages, the AsymmetricSecurityBindingElement class that enables you to enforce security by performing asymmetric encryption, the HttpsTransportBindingElement that uses the HTTPS transport protocol for transmitting messages, and the ReliableSessionBindingElement that you can use to implement reliable messaging. Most binding elements also provide properties that enable you to modify the way in which the binding elements work. For example, the AsymmetricSecurityBindingElement class has a property called DefaultAlgorithmSuite that you can use to specify the message encryption algorithm to use. WCF also enables you to define your own custom binding elements if none of the predefined binding elements meets your requirements. (Creating custom binding elements is beyond the scope of this book.)
The composability of binding elements into bindings provides a great deal of flexibility, but clearly not all combinations of binding elements make sense. Additionally, if you are building solutions for a global environment, it is worth remembering that not all client applications and services in a distributed solution will necessarily have been developed by using WCF; you should use bindings that are interoperable with services and applications developed by using other technologies.
 |
As described in Chapter 1, many specifications and protocols have been defined, aimed at ensuring interoperability between Web services. Examples include the WS-Security specification defining how Web services can communicate in a secure manner, WS-Transactions for specifying how to implement transactions across a disparate collection of Web services, and WS-ReliableMessaging that describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. Collectively, these specifications are known as the WS-* specifications. To ensure interoperability, you should create Web services that conform to these specifications.
|
The designers of WCF have provided a selection of predefined bindings in the WCF library, in the System.ServiceModel namespace. You have already used two of them: BasicHttpBinding and NetTcpBinding. Some of these bindings are aimed at clients and services primarily running on the Windows platform, but others (mainly the Web services bindings) are compatible with the WS-* specifications and the WS-I Basic Profile 1.1. Table 2-3 describes the bindings available in the WCF library:
| Binding | Description |
|---|---|
| BasicHttpBinding | This binding conforms to the WS-I Basic Profile 1.1. It can use the HTTP and HTTPS transport protocols and encodes messages as XML text. Use this binding to maintain compatibility with client applications previously developed to access ASMX-based Web services. |
| WSHttpBinding | This binding conforms to the WS-* specifications that support distributed transactions, and secure, reliable sessions. It supports the HTTP and HTTPS transport protocols. Messages can be encoded as XML text or by using the Message Transmission Optimization Mechanism (MTOM). MTOM is an efficient encoding mechanism for transporting messages that contain binary data. You will learn more about MTOM in Chapter 12. |
| WSDualHttpBinding | This binding is similar to WSHttpBinding, but it is suitable for handling duplex communications. Duplex messaging enables a client and service to perform two-way communication without requiring any form of synchronization (the more common pattern of communication is the request/reply model where a client sends a request and waits for a reply from the service). You will learn more about using duplex messaging in Chapter 14, “Using a Callback Contract to Publish and Subscribe to Events.” Using this binding, messages can be encoded as XML Text or by using MTOM. However, this binding only supports the HTTP transport protocol, not HTTPS. |
| WSFederationBinding | This binding supports the WS-Federation specification. This specification enables Web services operating in different security realms to agree on a common mechanism for identifying users. A collection of cooperating Web services acting in this way is called a federation. An end-user that successfully connects any member of the federation has effectively logged into all of the members. WS-Federation defines several models for providing federated security, based on the WS-Trust, WS-Security, and WS-SecureConversation specifications. You will learn more about federation in Chapter 15, “Managing Identity with WIndows CardSpace.” |
| NetTcpBinding | This binding uses the TCP transport protocol to transmit messages using a binary encoding. It offers higher performance than the bindings based on the HTTP protocols but less interoperability. It supports transactions, reliable sessions, and secure communications. It is ideally suited for use in a local area network, and between computers using the Windows operating system. |
| NetPeerTcpBinding | This binding supports peer-to-peer communications between applications using the TCP protocol. This binding supports secure communications and reliable, ordered delivery of messages. Messages are transmitted by using a binary encoding. Using peer-to-peer communications is outside the scope of this book, but for more information see the “Peer to Peer Networking” section in the Windows SDK Documentation. |
| NetNamedPipeBinding | This binding uses named pipes to implement high-performance communication between processes running on the same computer. This binding supports secure, reliable sessions and transactions. You cannot use this binding to connect to a service across a network. |
| NetMsmqBinding | This binding uses Microsoft Message Queue (MSMQ) as the transport to transmit messages between a client application and service both implemented by using WCF. This binding enables temporal isolation; messages are stored in a message queue, so the client and the service do not both have to be running at the same time. This binding supports secure, reliable sessions and transactions. Messages use a binary encoding. |
| MsmqIntegrationBinding | This binding enables you to build a WCF application that sends or receives messages from an MSMQ message queue. It is intended for use with existing applications that use MSMQ message queues (the NetMsmqBinding binding uses MSMQ as a transport between a WCF client and service). |
Open table as spreadsheet
|
When you implement a Web service, you should endeavor to maintain interoperability with other Web services, regardless of the technology you are using. When you create a Web service, you make use of a number of technical standards, such as XML, WSDL, SOAP, and WS-Security. Each of these specifications is a standard in its own right. New versions of these standards are continually emerging and will inevitably become adopted in the future. This poses a challenge. For example, if you create a Web service that exposes its interface by using WSDL 2, and a client application is using WSDL 1.1, will the client application still work? If you factor in the possibility that various applications could potentially support different versions, or subsets of the various standards, then interoperability, which is one of the most important value propositions of Web services, becomes difficult to achieve. This is where the WS-I Basic Profile comes in.
WS-I, or the Web Services Interoperability organization, defines a specific list of standards, versions, and additional rules that Web services and their clients should adopt to maintain interoperability. WS-I groups these items together into what is referred to as a profile. The current WS-I profile is called the WS-I Basic Profile 1.1. Web services that conform to the WS-I Basic Profile 1.1 should automatically be compatible with client applications and other Web services that also conform to the WS-I Basic Profile 1.1, regardless of how the Web services and client applications are implemented or the technologies used.
For a full list of the standards in WS-I Basic Profile 1.1, see the WS-I Basic Profile page at http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html.
|
Configuring Bindings
You can programmatically instantiate a binding and use it to create an endpoint for a service by using the AddServiceEndpoint method of the ServiceHost class. Similarly, you can write code to add a binding in a client application (you will see examples of these in Chapter 10, “Programmatically Controlling the Configuration and Communications”). However, as you have already seen, it is common to use a configuration file to specify the binding configuration information for a client and service. You can also set the properties for a binding in this way. As an example, examine the 
app.config file for the ProductsClient application:
<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.serviceModel> <bindings> <basicHttpBinding> <binding name="BasicHttpBinding_IProductsService" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true"> <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" /> <security mode="None"> <transport clientCredentialType="None" proxyCredentialType="None" realm="" /> <message clientCredentialType="UserName" algorithmSuite="Default" /> </security> </binding> </basicHttpBinding> </bindings> <client> <endpoint address="http://lon-dev-01/ProductsService/ProductsService.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IProductsService" contract="ProductsClient.ProductsService.IProductsService" name="BasicHttpBinding_IProductsService" /> </client> </system.serviceModel> </configuration>
To recap from earlier, the <client> section specifies the endpoints for the client application. Each endpoint indicates the binding to use. The <bindings> section of the configuration file sets the properties of each binding–this section is optional if you are happy to use the default values for a binding. The example shown above explicitly sets the value for every property of the basicHttpBinding used by the client endpoint. You can find a full list of the properties for each binding in the “Bindings” section of the “Windows Communication Foundation Configuration Schema” topic in the Windows SDK Documentation provided with the Windows SDK.
EAN: 2147483647
Pages: 105