An early look at forthcoming WCF features
The .NET Framework 4.0 will be released with Visual Studio 2010 – bringing with it a plethora of new WCF features. WCF 4.0 will solve many pain points related to configuration, tracing and diagnostics, serialization and messaging. In addition this release will include exciting new enterprise-ready features such as service discovery and routing, and when combined with the power of WF 4.0 Workflow Services will greatly simplify how developers incorporate asynchronous programming models to offset expensive IO-intensive operations and improve overall application performance and throughput.
In this article I will provide a high level summary of features we know today will be released with WCF 4.0 – to provide you with a well-rounded view of the forthcoming release.
Simplified configuration
One of the major pain-points experienced by WCF developers is configuration. In WCF 4.0 we can look forward to a significant improvement in this area through configuration defaults, behavior inheritance, and implicit endpoints. Collectively these features can yield a truly configuration-free experience when you host your WCF services.
The idea is that you provide better binding configuration and behavior defaults for your specific application’s requirements, and the runtime picks up those defaults when it initializes the ServiceHost. Listing 1 illustrates providing default settings for WS2007HttpBinding and several behavior defaults. They are noted as defaults by using an empty string (“”) for the binding and behavior name.
<bindings>
<ws2007HttpBinding>
<binding name="" maxReceivedMessageSize="1000000" >
<readerQuotas maxArrayLength="1000000"
maxStringContentLength="50000"/>
<security mode="Message">
<message clientCredentialType="UserName"
negotiateServiceCredential="false"
establishSecurityContext="false" />
</security>
</binding>
</ws2007HttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="">
<serviceMetadata httpGetEnabled="true"/>
<serviceCredentials>
<userNameAuthentication
userNamePasswordValidationMode=
"MembershipProvider"/>
</serviceCredentials>
<serviceAuthorization
principalPermissionMode="UseAspNetRoles" />
<serviceThrottling maxConcurrentCalls="30"
maxConcurrentSessions="1000"/>
</behavior>
</serviceBehaviors>
</behaviors>
Listing 1: Binding and behavior defaults in WCF4.0
When the ServiceHost is initialized, an endpoint will be automatically created for each contract implemented by the service type – for each base address provided. When you combine this behavior with default binding configurations and behavior settings, configuration-free hosting actually seems plausible.
Serialization enhancements
The new DataContractResolver will provide a new extensibility hooks useful for customizing CLR type mapping for the DataContractSerializer. This can be useful for simple overrides such as altering the name and namespace for CLR types written to the wire, for overriding which CLR types are involved in serialization, and for dynamically managing known types.
Queued Messaging ReceiveContext
In order to guarantee exactly once delivery of messages from a queue in Microsoft Message Queuing (MSMQ) you must work with transactional queues and the WCF service operation must participate in the playback transaction. If an exception is thrown while processing the message, the service can guarantee the message doesn’t get lost by returning it to the queue – either the originating queue, the dead letter queue or a poison message queue, depending on configuration and MSMQ versions. This is quite useful, but has limitations in that there is no way to ensure that the same service processes the failed message the next time it is pulled from the queue, not to mention that transactions are expensive.
WCF 4.0 introduces ReceiveContext as an alternative technique for processing queued messages. The thrust of this new technique is that the message is not pulled from the queue until the message is successfully processed by the service. A ReceiveContext is associated with the message once it is “peeked” by a service and if an exception is thrown and the message cannot be completed, it remains in the queue but can also remain locked by that particular service to retry processing. This reduces overhead since the message need not be transmitted over the network again to another service.. ReceiveContext provides a way to explicitly complete the message so that it can be removed from the queue on success. ReceiveContext guarantees at least once delivery when used without transactions, and when composed with transactions it guarantees exactly once delivery with performance benefits.
Microsoft also released the WCF REST Starter Kit
Web programming
Since the release of .NET 3.5 it is much easier to build WCF services that bypass SOAP processing requirements including Plain-Old-XML (POX), Java Script Object Notation (JSON) and Representational State Transfer (REST) – the latter of which is an architectural approach for designing POX or JSON services. These techniques fall under the web programming model for WCF services. Microsoft also released the WCF REST Starter Kit which considerably improves productivity when building services for this web programming model. The WCF REST Starter Kit includes the following:
- Many Visual Studio templates for the most common scenarios for POX, REST and Atom/Pub.
- New features to support better error reporting to the browser. Supporting types are WebProtocolException and new behaviors installed with WebServiceHost2 and WebServiceHost2Factory.
- A much needed extensibility hook for HTTP requests through RequestInterceptor.
- The ability to more easily override HTTP verbs for clients that don’t support PUT and DELETE.
- Cached operation responses with WebCacheAttribute.
- Tons of code samples illustrating how to work with these features.
The idea behind releasing the starter kit was to get these features into the hands of RESTful WCF developers so that they could provide feedback on features so that .NET 4.0 can include the most relevant features and include any refinements. Thus, many of these features will be included in the WCF 4.0 feature set.
Basic Profile 1.2
As you may be familiar, there are a number of standards bodies that drive specifications implemented by platforms like WCF, including: W3C (www.w3c.com), OASIS (www.oasis-open.org) and WS-I (www.ws-i.org). The goal of the latter is to simplify how the plethora of standards is implemented in vendor platforms. In WCF, BasicHttpBinding supports Basic Profile (BP) 1.1 which is based on SOAP 1.1. This profile is grossly out of date, does not support WS-Addressing semantics or MTOM. Thus, a new profile was born – BP 1.2. This new profile addresses errata for BP 1.1 and includes support for WS-Addressing and MTOM. WCF 4.0 will support this profile.
NOTE: Do not confuse BP 1.2 (based on SOAP 1.1) with BP 2.0 (based on SOAP 1.2) which is still a work in progress.
Service discovery
Speaking of protocol support, WCF 4.0 includes a long-awaited implementation of WS-Discovery. This specification documents a multicast protocol that issues SOAP messages over UDP. Services that implement discovery endpoints can receive probe messages from clients that wish to discovery services within their subnet. In addition, services can announce themselves to clients listening for announcements. Figure 1 illustrates the flow of communication between clients and services.
WCF 4.0 includes implementation of WS-Discovery
Fig. 1: Discovery probes and announcements from a high level
Discovery messaging works because communication endpoints are well-known UDP addresses. WCF 4.0 makes it very easy to implement service discovery with a few simple steps:
- Services that wish to be discoverable implement a discovery endpoint and enable discovery with a service behavior.
- Services that wish to send discovery announcements enable announcements as part of the discovery behavior.
- Clients that wish to probe services within the subnet use a built-in DiscoveryClient and supply heuristics for searching for the desired services.
There are many architectural scenarios that can implement discovery, and this will be the subject of a future article.
Router service
Routers can be very useful when you need to introduce load balancing using custom heuristics, content-based or priority routing, versioning scenarios, or when you need to introduce a security boundary between remote clients and services that live behind the DMZ. Implementing a custom router is a significant undertaking but WCF 4.0 aims to relieve this effort by supplying us with a built-in router equipped to work with one-way, two-way and duplex messaging.
You host the new RouterService as you would any other WCF service and then configure routing rules using a filter table and a set of associated filters. The filters are ultimately evaluated to determine the correct downstream service endpoint to forward messages to. This architecture is illustrated in Figure 2.
Fig. 2: Configuring the RouterService in WCF 4.0
Many filtering options are available through a simple configuration such as XPath queries for content-based routing and queries based on the SOAP action header. There are also extensibility hooks available for deeper control over filters and routing decisions.
Workflow services
New features in WCF 4.0 and WF 4.0 yield a more compelling story for implementing services operations as Workflow Services. In .NET 3.5 one usually restricted the use of Workflow Services to asynchronous, long-running processes that could withstand the overhead of the Workflow Runtime. In .NET 4.0 the Workflow Runtime performance is significantly improved removing that limitation. Instead the choice to use Workflow Services is purely driven by design choices and singular benefits such as:
- Increased visibility through correlated WF tracking and WCF tracing events.
- Greatly simplified approach to implementing asynchronous programming models. For example issuing downstream service calls in parallel and correlating responses.
- Implementing declarative (XAMLX) services which provide an alternative to deploying, updating and versioning – and make it possible to deploy Workflow Services to the cloud.
High-performance tracing
WCF 4.0 trace events are based on Event Tracing for Windows (ETW) which significantly enhances tracing and diagnostics performance. From a high level the architecture of ETW is simple: event providers push events to sessions under a registered provider ID, controllers are used to enable or disable sessions that collect events and associate providers with sessions, sessions can optionally persist events to a log, consumer applications listen to real-time session events or pick events up from trace logs. ETW is buffered to reduce contention when persisting events to a file-based trace log. Figure 3 illustrates this architecture.
Fig. 3: WCF Tracing and WF Tracking with ETW
Both WCF and WF share the same ETW event provider so that a correlated view can be presented for WF tracking events and WCF tracing events – very useful for trouble-shooting Workflow Services. Furthermore, Dublin provides a friendly interface to enabling and configuring tracking and tracing through IIS Manager.
Conclusion
The new features in WCF 4.0 traverse a number of areas including configuration, tracing, serialization, message queuing, service discovery, routing and workflow services. All of these new features specifically address pain points that developers have with earlier versions of WCF.
This article originally appeared in the 2009/April issue of asp.netPRO magazine and is reprinted with express permission of Penton Media (www.aspnetpro.com).
Additional resources