Microsoft Windows Communication Foundation 4.0 Cookbook for Developing SOA Applications: Over 85 easy recipes for managing communication between applications

WCF services are exposed through service endpoints, which provide the basic access point for client to utilize the functionality offered by a given WCF service. Service endpoints consist of ABC and a set of behaviors. What is ABC? Well, A stands for Address, which tells service consumers “Where is the service?”, B stands for Binding, which describes “How to talk to the service?” and C stands for Contract, which shows “What functionality can the service provide?”

WCF provides plenty of built-in bindings (such as BasicHttpBinding, NetTcpBinding, NetMsmqBinding, and so on), which can help developers host service endpoints over various transport protocols. Behaviors also play an important role in WCF. By using behaviors, we can gain further manipulation over the WCF service at service or endpoint level.

This chapter provides eight recipes on using the built-in binding and behaviors to build various service endpoints, which represent some of the useful scenarios in general WCF service...

When programming with WCF, we will often need to create some simple WCF services for testing our ServiceContracts. These services often use very simple and typical endpoint and binding definitions. However, every time we need to set up such a service, we have to define the same endpoint and binding settings again and again, which really adds much duplicated work. Fortunately, WCF 4.0 introduces the Default Endpoint feature which saves us from defining common endpoint/binding settings repeatedly.

For a long time, MSMQ has been a great message-based communication component on the Microsoft platform. And the Microsoft .NET framework has also provided managed programming interfaces for developers to develop distributed applications based on MSMQ. However, it is still a bit complicated and time consuming for developers to build a complete distributed service through the raw or encapsulated MSMQ programming interface. As the new unified communication development platform on Windows, WCF provides more convenient means for developing a distributed service over the underlying MSMQ component.

Publish-Subscribe is a common design pattern that is widely used in client/server communication applications. In WCF service development, the Publish-Subscribe pattern will also help in those scenarios where the service application will expose data to certain groups of clients that are interested in the service and the data is provided to clients as a push model actively (instead of polling by the client). This recipe will demonstrate how to implement the Publish-Subscribe pattern in a WCF service through dual binding.

For traditional distributed communication services, we will open the service over a certain transport-specific endpoint such as HTTP endpoint. If we need to expose it via another different transport layer, we will probably have to add additional code to implement the new endpoint. The WCF programming model separates the service implementation and underlying transport layer so that we can conveniently expose a single service implementation via multiple heterogeneous endpoints (with different a transport layer and binding configuration).

WCF services by default use SOAP as the message format of service operations, which means each message transferred between the client and service is wrapped in a SOAP envelope that contains one SOAP body and some SoapHeaders. However, sometimes our WCF service will need to work with some legacy POX (Plain Old XML) clients or our WCF-based client will need to talk to some POX-style service. In such cases, it is necessary to let our WCF client or service generate arbitrary XML messages without strictly obeying the SOAP standard.

For WCF bindings that use message-layer security, a timestamp header will be added in the SOAP envelope to ensure the timely delivery of the message so as to prevent a potential message-replaying attach. However, some non-WCF service platforms may not expose this header. When working with this kind of service client or service, we will need to prevent the WCF message engine from generating the timestamp header.

private static Binding GetCustomHttpBinding()
{
   WSHttpBinding wshttp = new WSHttpBinding();
   var bec = wshttp.CreateBindingElements();

   SecurityBindingElement secbe = bec.Find&lt...

For a WCF service or client proxy, it is common to receive SoapHeaders within the coming request or returned response messages. SoapHeader has a mustUnderstand attribute that indicates to the target endpoint (or intermediate message processor) whether the SoapHeader must be processed. The following screenshot shows a typical SOAP message that contains a SoapHeader with the mustUnderstand attribute set to 1 (true).

Also for a XML Web Service or WCF service, we can dynamically insert SoapHeaders at runtime or statically apply them at design-time (which will be described via WSDL or service metadata).

By default, a WCF endpoint will perform validation on all the SoapHeaders within incoming messages, and if there are any unknown SoapHeaders (not predefined) which have a mustUnderstand attribute as 1 (or true), a validation exception will be raised by the runtime. However, sometimes it is useful to suppress this validation so that the...

WCF supports exposing a single service through multiple heterogeneous endpoints. Another great feature is letting multiple endpoints listen over the same physical transport address. For example, you want to host a WCF service that has multiple endpoints exposed. However, you only have a single HTTP URL open for listening. Then you can use this feature to make all those endpoints (as long as they’re using the same transport protocol) listen on the same URL.