At the end of May, we covered Windows Communication Foundation (WCF) during our Tech Tuesday presentation. WCF was chosen because many of us came to realize how very little we knew about the topic, thinking that we had a good understanding of WCF development prior to 2011—meaning, how hard is it to add a few XML nodes to a web.config file to expose a .NET CLR class as a WCF service through IIS? However, once we started digging into WCF we realized that there is a lot more to it than this. We have found that Microsoft does a pretty good job at applying the 80/20 rule to most technologies they publish–meaning that one can get 80% functionality through a 20% effort and, for Anexinet developers, WCF was no different.
Prior to 2011, our exposure to WCF was limited, primarily delivering WCF services using the Visual Studio “WCF Service” template. This approach allowed us to create true WCF services hosted in IIS and exposed over HTTP. This was perfect for the environments that we were already working in since those projects were Web based projects and, therefore, IIS was readily available. With IIS came access to existing SSL certificates to secure the content of the messages flowing to and from the service. And, since the organization was already using IP filtering to limit access into the DMZ, we had a way to “authorize” the client making the calls in to our services. We successfully deployed several WCF services in this fashion to support both internal and external communication and we delivered that project with a sense of accomplishment and feeling pretty good about our WCF knowledge.
Then came 2011. We started looking deeper into SOA from an architectural position and decided to do a deeper dive into the WCF technology. At that same time, we started working with a client that was looking at using WCF to support a centrally hosted SOA based routing engine. The deeper we dove and the more requirements that were gathered, the more we realized how little we really knew and understood about WCF. It became clear to us that WCF was a lot more than glorified IIS URLs.
Below are concepts that we feel represent some of the more important aspects of WCF:
- WCF Hosting: WCF services can be hosted in IIS or any other windows process using the System.ServiceModel.ServiceHost class. When hosting in IIS you use the web.config file to configure services and IIS takes care of the rest. When using a Windows process (e.g. a Windows service, a console application, or even a Windows forms application) you can use the app.config file OR you can programmatically create WCF services and manage all aspects of a service in code. Programmatic mode allows for dynamic creation of services providing complete control over all aspects of a WCF service.
- Protocols: WCF services hosted in IIS use the HTTP protocol by default to communicate. It is possible to support the NET TCP protocol in IIS but that requires additional installation and configuration in IIS. IIS cannot support the Named Pipes or MSMQ protocols. Hosting using the System.ServiceModel.ServiceHost class supports all WCF protocols without any additional installation or configuration.
- Security–Authentication: WCF services support protocol, message, or protocol and message security. Protocol security includes concepts like Kerberos, NTLM, and certificate. Message security includes concepts like Kerberos, NTLM, Username/Password, certificate, and issued token.
- Security–Authorization: WCF services support role based, identity based, and resource based authorization models.
- Cloud Computing: Microsoft has released an Azure SDK for Visual Studio that makes developing WCF and WF services for the cloud fairly straight forward. The SDK includes an emulator to test your application locally before deploying to the cloud.
- Extensibility: WCF was built to allow for complete extensibility. All aspects of the WCF “stack” can be extended if the functionality needed is not natively supported by WCF.