Why WCF ?
Today, when we build distributed applications, we have number of programming models. In present .net 2.0 we can use following concept to build distributed applications.
1. ASP.NET Web Services (ASMX)
2. Web Services Enhancements (WSE)
3. MSMQ / System. Messaging
4. Enterprise Services
5. Remoting
Each programming model has a different set of APIs, different feature sets, and a different core set of scenarios like,
1. ASP.NET Web Services (ASMX)
Our current Web services stack provides basic Web services support and interoperability with Web services running on non-Microsoft platform.
2. Web Services Enhancements (WSE)
A supported extension to the .NET Framework that provides end-to-end standards-based security for Web services.
3. System. Messaging
This namespace in the .NET Framework provides managed APIs to MSMQ, enabling developers to build asynchronous reliable distributed applications.
4. Enterprise Services
Provided through the System.EnterpriseServices namespace in the .NET Framework, Enterprise Services (or “ES”) provides managed APIs to COM+. COM+ provides component-based programming for doing enterprise critical functionality such as transaction.
5. Remoting
Provided through the System.Remoting namespace in the .NET Framework, .NET Remoting exposes the CLR type system remotely and provides location transparency for objects.
Features Table 1
| Functionalities |
Web Service |
WSE |
MSMQ |
ES |
Remoting |
| Inter Operability |
YES |
YES |
NO |
NO |
NO |
| Security(End to End) |
NO |
YES |
YES |
YES |
YES |
| Reliable |
NO |
NO |
YES |
NO |
NO |
| Transaction |
NO |
NO |
NO |
YES |
YES |
| Performance |
NO |
NO |
YES |
YES |
YES |
While these technologies provide a wide range of functionality, they exist in silos – isolated from one another. This creates an impedance mismatch across the technologies hindering our ability as developers to “compose” or combine functionality across them. For example:
We want to use .NET Remoting for its rich extensibility model, but we want an ES-style transaction to flow. How do we do this? Or we want to use ASMX for its interoperability, but you want to provide direct reliable messaging guarantees. How is this accomplished?
Today, scenarios like these that involve the combination of functionality across these technologies are more of a challenge than it should be. They often involve hundreds and sometimes thousands of lines of code to accomplish. With WCF, the challenges of silo programming models become a thing of the past. WCF provides you with a unified programming model that brings together the best aspects of existing Microsoft technologies. What this means is that, with WCF, you will no longer need to wonder “which technology do I use (ASMX, Remoting, etc)” when building a connected system. All of the application-to-application and intra-application communication for your connected will be handled by WCF. This unified programming model is exposed to you through the System. Service Model namespace. Since WCF provides all of the features of these existing Microsoft technologies, WCF supports all of the scenarios currently supported by these technologies.
Features Table 2
| Functionalities |
WCF |
| Inter Operability |
YES |
| Security(End to End) |
YES |
| Reliable |
YES |
| Transaction |
YES |
| Performance |
YES |
In addition, WCF enables new scenarios that are currently not possible or very hard to implement with existing technologies because WCF allows you to compose functionality across these existing technologies. For example, this means that you’ll be able to achieve secure, reliable, transacted Web services by combining/composing the functionality that previously existed in silos.