Discuss some new features in WCF 4.0

This article discusses my understanding of some new features in WCF 4.0 and how NIntegrate could work with WCF 4.0.

1. Configuration Based Activation

“Configuration based activation” means, instead of creating a physical .svc file for a WCF service be hosted in IIS, you could now set the equivalent configuration in the new <serviceActivations> element in <serviceHostingEnvironment> configuration section in the Web.config file.

It is an alternative of physical .svc files, and enables centrally management for the hosted WCF service addresses of a WCF host application. But it still does not support programmatically load the configuration of the <serviceHostingEnvironment> configuration section, which means, it is still  impossible to store them in a central configuration store, such as in database, for all your WCF host applications.

Remind you that, since even before WCF 4.0, there is one possible but limited approach to host WCF services in IIS without physical .svc files and even centrally store the addresses in anywhere, such as in database, which is through “VirtualPathProvider”. The limitation is it supports only HTTP bindings. In some previous version of NIntegrate, I used to provide one custom VirtualPathProvider implementation to manage WCF service addresses in database and deployment centrally. But I removed it in later versions of NIntegrate because it is not very hard to be implemented by yourself. Here I just advise you that you may want to consider this approach especially when your WCF application is RESTful only or uses HTTP bindings only.

2. System.Web.Routing Integration

“System.Web.Routing integration” allows you to host a WCF REST service that responds to URIs without an extension easier. Even without System.Web.Routing, it is also possible to “host a WCF REST service that responds to URIs without an extension ”, although with routing, it becomes much easier. Most of you should begin familiar with the routing ability of ASP.NET since the ASP.NET MVC framework. It is really attractive and helpful when you widely use WCF to implement RESTful services.

But do you even think “widely use WCF to implement RESTful services” is a good idea? OK, there are debates. Personally I’ll not use WCF to implement RESTful services, even now in WCF 4.0, there are lots of improvements for RESTful WCF services. A better way should be “use ASP.NET MVC 2 to expose RESTful services”. I’ll discuss more below when discussing the new features WCF 4.0 provided for RESTful WCF services.

3. Routing Service

First of all, please realize that “The Routing Service does not currently support routing of WCF REST services”. “Routing service” here means a new predefined WCF service in WCF 4.0 which implements the Intermediate Routing pattern, generically supports routing SOAP based WCF service messages to their destinations based on a set of customizable rules. This pattern is an important enterprise SOA design pattern which solves the problem that, for large and complex service composition, it is difficult to design service contracts for all possible runtime scenarios in advance.

4. Support for WS-Discovery

The Service Discovery feature enables client applications to dynamically discover service addresses at runtime in an interoperable way through WS-Discovery specification. The WS-Discovery specification is an OASIS standard, which means it is possible to exchange metadata with 3rd party WS-Discovery implementation, although I believe most people just needs the ability to discover services at runtime.

NIntegrate provides a programmatic object model for hosting WCF services, and also for client to discover WCF services at runtime easily. So for the ability of discover services, it should be more flexible than WS-Discovery. But since the core of the the WCF 4.0 WS-Discovery implementation – the discovery endpoint and behavior classes are standard WCF endpoints and behaviors, it could be used together with NIntegrate to give you the benefits of both.

5. WCF REST Enhancement

Fairly speaking, WCF 4.0 enhanced much a lot for RESTful services: output caching, dynamic response format & JSONP support, error handling and routing without extension. In WCF 3.5 where without the WCF 4.0 new features, using WCF to implement RESTful services is not easy. But there are some official & 3rd party extensions providing RESTful features such as output caching, JSON & JSONP response and routing without extension. Technically, WCF 4.0 makes all these features be official and easier to use, but it is still not enough reason to use WCF to implement RESTful services for me. Personally, I prefer to use ASP.NET MVC 2.

Below are the reasons I like ASP.NET MVC 2 more than WCF for implementing RESTful services:

1) Configuration and deployment cost

Although in WCF 4.0, more predefined standard endpoints make it easier to use. It still needs configuration, and also needs deployment effort.

In ASP.NET MVC 2, no special configuration and deployment effort for each RESTful service is required.

2) Output caching

WCF 4.0 has enhanced a lot here, but ASP.NET MVC 2 still has the maximal flexibility & extensibility for output caching.

3) JSON & JSONP

For JSON response, ASP.NET MVC 2 is easier to be integrated with 3rd party serializers such as JSON.NET. For JSONP support, with the JSONPModule provided by NIntegrate, any JSON (XML response could be automatically converted to JSONP soon in next release) response services could automatically have the cross domain AJAX ability without any additional effort.

4) Error Handling

Error handling in WCF RESTful services is still limited  by the WCF FaultException design, while in ASP.NET MVC 2, it is much more flexible and easy to control.

5) Routing

You smile when I try to compare the routing ability of WCF and ASP.NET MVC 2.

In summary

Any of the enhancement in WCF 4.0 for RESTful services is not as flexible and powerful than in ASP.NET MVC 2, and even leverages from ASP.NET MVC by design. Give me a reason to use WCF RESTful services then?

Tag标签: nintegrate, wcf, jsonp, json, ajax