New Features in WCF 4 that Will Instantly Make You More Productive WCF 4 is all about productivity.
A number of new features in WCF 4.0 will provide an immediate boost to productivity by simply lowering the learning curve for getting up and running quickly and easily. Whether you are new to WCF or a seasoned veteran, subtle yet powerful improvements to the configuration experience will help you accomplish more with less while new features around discovery and routing will reduce the cost-value gap in implementing more sophisticated service-oriented patterns for building smarter, more resilient applications with greater reach and looser coupling. In this article, I’ll walk you through the simplified configuration experience in WCF 4.0-the latest release of the Windows Communication Foundation that ships with .NET 4.0 as well as introduce support in WCF 4 for dynamically discovering available services on a network. In my next article, I’ll dive deeper into more advanced discovery scenarios that will build on the foundational knowledge introduced here as well as a look at new support for advanced messaging scenarios using the Routing Service. Convention Over Configuration While the WCF programming model provides tremendous flexibility by exposing service and channel configuration knobs to the developer both imperatively and declaratively, in previous versions of WCF, developers new to WCF had to become quite intimate with service model concepts such as services, endpoints, addresses, bindings, contracts, endpoint behaviors and service behaviors just to get up and running. This became a source of frustration and confusion for those new to WCF who just wanted to get a service up and running in a style more familiar to them such as ASP.NET Web Services (ASMX) which required little more than an address to identify where the service would be listening. As the MSDN forums and comments/questions on my blog can confirm, even more experienced WCF developers were not impervious to the occasional configuration oversight that would cause hours of frustration. In response to this feedback, the Connected Framework team worked hard to improve the configuration experience in WCF 4. The result is a more conventional approach in which the most basic configuration options are applied in lieu of explicit configuration. These changes allow developers to get up and running quickly and take their time learning more advanced concepts within the service model. Default Endpoints The most significant improvement to the configuration experience in WCF 4 is the automatic application of default endpoints. To quickly review, an endpoint consists of an address, a binding and a contract. While every WCF service is comprised of one or more endpoints, the developer no longer needs to be burdened with specifying this boilerplate configuration. | " |
The most significant improvement to the configuration experience in WCF 4 is the automatic application of default endpoints.
| " |
Listing 1 shows a very simple yet common example of the boilerplate configuration that is typical for configuring a simple WCF service. The service and endpoint is explicitly defined as is the binding configuration and behavior configuration. For this particular service, when the host is opened, the WCF service model will create a service named Service1 with one endpoint listening on the HTTP protocol/scheme that is compatible with the WS-I Basic Profile 1 standard. When a message arrives at the endpoint, the service model will dispatch the message to the matching method that has been implemented per the configured contract. In addition, I have specified (via a service behavior) that I would like the service to provide a WSDL file over HTTP if requested, and in the event of an exception, the service should serialize low-level .NET exception details and return them in SOAP faults. What I’ve just described is very typical of a standard configuration (in a production environment, it is highly advisable to set includeExceptionDetailsInFaults to false). While the intimidation factor of such a configuration is quickly eased with a bit of practice, whether you are new to WCF or a seasoned veteran, wouldn’t it be nice to dispense with the formalities and just hit F5 to get up and running? | " |
Wouldn’t it be nice to dispense with the formalities and just hit F5 to get up and running?
| " |
This is exactly what Default endpoints in WCF 4 provide. Look at the configuration snippet below. There is absolutely no configuration whatsoever, but if you host this service with this configuration, you will find that a default endpoint is automatically created for every combination of protocol/schemes and service contracts your WCF service implements: <configuration>
<system.serviceModel/>
</configuration>
Demo1, found in the samples provided for this article, includes this basic configuration. If you run it, you will see the basic confirmation page in your browser with a link to view the WSDL document. If you deploy the service to IIS 7 WAS, and configure the protocol bindings as shown in Figure 1, the service model will create three endpoints for you automatically; one for each protocol scheme. Because I’ve enabled the generation of a WSDL document over HTTP via the service behavior, if I append ?wsdl to the address in my browser or click on the link generated in the service page, I can confirm that the following endpoints are, in fact, ready to be consumed as shown in the excerpt from the WSDL in Figure 2: 
Figure 1: IIS 7 WAS protocol bindings automatically take advantage of default endpoints in WCF 4.
Figure 2: One endpoint is automatically created for each protocol scheme.- A default endpoint with a BasicHttpBinding binding called BasicHttpBinding_IService1
- A default endpoint with a NetTcpBinding binding called NetTcpBinding_IService1
- A default endpoint with a NetNamedPipeBinding binding called NetNamedPipeBinding_IService1
As you can see, the service model is smart enough to enumerate the base addresses provided by IIS and create a default endpoint for each service contract that the service implements (i.e., the type mapped to the Service attribute in the svc file). What if you want to take advantage of default endpoints, but instead of using BasicHttpBinding as the default binding for HTTP, you’d rather use a WS-* binding like WsHttpBinding or a REST binding like WebHttpBinding? You can accomplish this very easily by simply adding a “protocolMapping” element to your configuration as shown below: <protocolMapping>
<add scheme="http" binding="wsHttpBinding"/>
</protocolMapping>
After adding the element above, the default endpoint for the HTTP protocol will be configured with the WSHttpBinding binding. Try it! The last productivity improvement around endpoints I want to talk about is the standard endpoint. A standard endpoint is simply a canned configuration of an endpoint for which properties of the endpoint typically have default settings, making it therefore redundant or unnecessary (not to mention error prone) to express in configuration. | " |
The DiscoveryClient provides the ability to send probe requests across the network to any services that are configured to respond to probe requests, be they WCF services or services implemented on other vendor stacks.
| " |
A great use of standard endpoints is exposing your service for metadata exchange. As opposed to creating the same boilerplate endpoint with properties/attributes that do not change; the same result can be accomplished by using the “mexEndpoint” standard endpoint as follows: <services>
<service name="Demo1.Service1"
behaviorConfiguration="metadata">
<endpoint address="wsdl"
name="wsdl"
kind="mexEndpoint" />
<!- - More Endpoints -- >
</service>
</services>
Note the pithy endpoint configuration including the new “kind” attribute which essentially saves you from having to remember static properties like the fully qualified IMetadataExchange contract. Hopefully you are starting to see a theme around improved productivity take shape. As you’ll see later, another great example of using a standard endpoint is in simplifying the process of exposing UdpDiscoveryEndpoint endpoints on services, but there are other standard endpoints configured by default that will come in handy as you explore other new features in WCF 4 and WF 4. | & | | 
By: Rick Garibay
With over 13 years’ experience delivering solutions on the Microsoft platform across industry sectors such as finance, transportation, hospitality and gaming, Rick is a developer, architect, speaker and author on distributed technologies and is the General Manager of the Connected Systems Development Practice at Neudesic.
Rick specializes in distributed technologies such as Microsoft .NET, Windows Communication Foundation, Workflow Foundation, and Windows Azure to deliver business value and drive revenue while reducing operational costs.
Rick serves as a member of the Microsoft Application Platform Partner Advisory Council and is an advisor to Microsoft in a number of capacities including long-time membership on the Business Platform and Azure Technology Advisors group. As a five-time Microsoft Connected Systems MVP, Rick is an active speaker, writer and passionate community advocate in the national .NET community. Rick is the Co-Founder of the Phoenix Connected Systems User Group, celebrating four years in operation.
Recent presentations include talks at the Microsoft SOA and Business Process Conference in Redmond, WA, Microsoft TechEd, DevConnections, .NET Rocks, Desert Code Camp, and numerous Microsoft events throughout North America. Rick is a frequent contributor to industry publications such as CODE Magazine, and is the co-author of Windows Server AppFabric Cookbook by Packt Press.
When not immersed in the work he loves, Rick enjoys mountain biking and spending time with his wife, Christie and two children, Sarah and Ricky.
|