Exploring WCF Services

LANGUAGES: C#

ASP.NET VERSIONS: .NET 4.0 | WCF

 

What s New in WCF 4.0?

An Early Look at Forthcoming WCF Features

 

By Michele Leroux Bustamante

 

This month s column explores the next generation of features to be released with WCF 4.0 when the .NET Framework 4.0 ships.

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.

To provide you with a well-rounded view of the forthcoming release, I ll provide in this article a high-level summary of features we know will be released with WCF 4.0. In subsequent articles I ll explore these features in greater detail.

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. Figure 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>

Figure 1: Binding and behavior defaults in WCF 4.0.

When the ServiceHost is initialized, an endpoint will be created automatically 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 new extensibility that are 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

To guarantee exactly one instance of 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 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 also can remain locked by that particular service to retry processing. This reduces overhead because 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 one delivery when used without transactions, and when composed with transactions it guarantees exactly one delivery with performance benefits.

Web Programming

Since the release of .NET 3.5 it has been 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 they could provide feedback on features so .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 aware, there are a number of standards bodies that drive specifications implemented by platforms like WCF, including W3C (http://www.w3c.org), OASIS (http://www.oasis-open.org), and WS-I (http://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, and 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. 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 discover services within their subnet. In addition, services can announce themselves to clients listening for announcements. Figure 2 illustrates the flow of communication between clients and services.

Figure 2: 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, 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 3.

Figure 3: 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 also are 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, thus 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, and 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 4 illustrates this architecture.

Figure 4: 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 which is very useful for troubleshooting 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 experienced with earlier versions of WCF. I ll explore these enhancements in greater detail in future columns.

Michele Leroux Bustamante is Chief Architect of IDesign Inc., Microsoft Regional Director for San Diego, and Microsoft MVP for Connected Systems. At IDesign Michele provides training, mentoring, and high-end architecture consulting services focusing on Web services, scalable and secure architecture design for .NET, federated security scenarios, Web services, interoperability, and globalization architecture. She is a member of the International .NET Speakers Association (INETA), a frequent conference presenter, conference chair for SD West, and is frequently published in several major technology journals. Michele also is on the board of directors for IASA (International Association of Software Architects), and a Program Advisor to UCSD Extension. Her latest book is Learning WCF (O Reilly, 2007; updated in 2008); visit her book blog at http://www.thatindigogirl.com. Reach her at mailto:mlb@idesign.net, or visit http://www.idesign.net and her main blog at http://www.dasblonde.net.

Additional Resources

§    Learning WCF (O Reilly, 2007; reprinted for VS 2008, July 2008): http://www.thatindigogirl.com (get all the book code here!)

§    Michele s blog: http://www.dasblonde.net

§    IDesign: http://www.idesign.net