What is your most interesting use of WCF?

Question

WCF provides a wealth of features and functionality that didn't exist in ASP.NET Web Services. I'm wondering if those with some real experience using the technology in a production environment can share their experiences on interesting usages now available because of the new functionality. I think it will be a helpful source of "oh, you can do what?" for those coming into it from ASP.NET Web Services.

Answer 1

This is a rather broad question. WCF does far more than asp web services.

I've used WCF to build a proxy ADO.Net data provider which routes all operations through a WCF service. This lets you work with databases which are accessible on a server, but not the client machine.

Answer 2

So, what are the glaring problems with that Web Services as they stand.

• No in-built encryption mechanism: You have to encrypt it yourself, or use HTTPS.
• No way to authenticate users: You can pass a username/password of course, but what if you want to do Windows Authentication? What about X509 Certificates?
• Cannot choose the transport mechanism: HTTP is a relatively verbose protocol. It is a text-based protocol on top of TCP/IP.
• Redirection: If you have a firewall, and you need to redirect the message when encrypted, you can't. This is unless the firewall unencrypts it, sees the destination and forwards on the message.
• Compression: Compression must be built carried out before the message is sent over the wire.

Well Microsoft addressed these issues with an intermediate release called Web Service Extensions version 2.0 and 3.0. These addressed these issues in one go. However, these were an add-on. I had the experience working with it and definitely required some hand crafting of code. They were added to conform with the WS-* Standards set out by the W3C Organsisations.

If you wanted to use the additional features of WSE, you had to ultimately re-compile your code. Your proxy on the client had to inherit from a new base class. You had to add additional configuration information. You could a basic 4/5 step process to update your client. But, it wasn't the most convenient.

When comparing WSE 3.0 and WCF you will see that all the features are much more easily implemented. If I compare it to the list above:

• Encryption can be at message level (encrypting the "data" section), or at transport level (encrypting it over the wire), by simply adding something like "messageAlgorithm=Basic128" to App.config.
• You can use Windows Authentication of the running application seamlessly and also require the use of a specific certificate to be installed on the client machine before calling it.
• The transport mechanisms can be changed to suit your need. We have HTTP, HTTPS, TCP, Named Pipes (for inter-process calls) and MSMQ. Note that these can be added to if you so wish, just by implementing a new base class and overriding the required methods. TCP is far faster over an corporate internal network than HTTP, plus you can implement encryption as well if you are really paranoid.
• The redirection was implemented in WSE 3.0 and I'm sure extends it even further. The use of redirection is important because a lot of organisations only have a few machines exposed to the internet, and filter based on IP address internally. However, there is also something called a UDDI, which allows multiple machines to register as having a service. So you don't necessarily hit the same machine as you intend to.
• Compression is implemented as the per the WS-* standards, and as implemented in the WSE 3.0. There is a compression standard defined to "attach" documents to the XML messages.

As well as these features, WCF implements the 4 SOA "rules" more openly. SOA is a large topic and can be searched about on the internet. Whole books have been written on SOA, but just accept that WCF is an implementation of a SOA architecture.

One of the SOA guidelines asks that you provide "contracts" (schemas), not objects/classes as objects/classes may signify an tie-in to OO languages. The schema is specified in XML to be language agnostic.

WCF also defines a service via a "contract". The basic principle is that you define a contract i.e. operations that can be performed first. In .NET this is implemented as an interface, decorated with certain attributes.

Then as a .NET developer implements the interface into a concrete class (decorated with some other attributes) and codes the methods to implement their functionality. This means that the "contract" is drawn from the interface and our classes only provide its implementation. This way .NET is providing its own way of implementing the standard.

Although you can code all of this, WCF gives you the option to specify it in the configuration file - like URIs, encryption mechanism, transport mechanisms for flexibility. Another SOA standard is the ability to be flexible with your implementation.

Thats a quick overview really. I hope it helps dip your toes in without being too specific.