Evolution of WCF

Introduction

In this article I discuss the evolution of Windows Communication Foundation (WCF), basically how it developed and its advantages for which one should learn WCF.

Picture 1

In the early 1980's people were using FoxPro and Microsoft Access for developing applications and these were also managing databases, that means the database and the logic for managing data as per a given business requirement existed together. So applications were very huge. It was only one developer or a team of developers who were doing things from the ground up. There was no concept of re-usability. Everything was supposed to be done by the team as per the requirements and once they have finished a project, nothing of the project would have been useful in another project. In another project everything again would be required to be done as it is.

Picture 2

In later stages databases took the form of SQL Server/Oracle where databases were installed in one place, but then, the front-end application still managed the data, which will be installed on many client machines, still requiring a lot of time. Because everything was centralized in one place, then also, except databases, otherwise everything else was in one place. The presentation, the business requirement logic, the code for managing data, communicating with the data was in once place. So initially, application development began and it was referred to as a Monolithic Application, one place, everything was being done. Disadvantages: it would require a lot of time and there was no code reusability.

Picture 3

In the later 1980s the industry came up with Object Orientation. Wherein we have polymorphism, encapsulation, sub-classing etcetera. A synonym for polymorphism is simply reusability. If you develop some code like a class then you can simply reuse that code as it is in any other place of the project for creating the instance of the class and using it. But then this approach also had a problem. For example, if you write a class in C++, you would be able to use that class only in C++, you would not be able to make use of that class in other programming languages. There was absolutely no language interoperability. And moreover, once the class was developed and integrated into the application and when the application was built and deployed on the client or the target machine, any kind of enhancements were not possible. Because even if a small change has to be made to the class, the entire application must be rebuilt and deployed on the client machine. Basically a class was statically included into the application itself. So even though we did get reusability, it was not at the application level, it was only for a given application we were getting reusability and of course the language was another big issue.

Picture 4

That's were Microsoft came up with the COM component specification where in people were able to write a component and reuse it in multiple applications. An additional advantage provided by COM was that you would write a COM component, let us say in Visual C++ and use that in developing applications in Visual Basic. That means we now had language interoperability. COM did also extend facilities like location transparency. We could deploy the COM component anywhere on our machine and use it in many applications and tomorrow if you want to upgrade the component, you would only upgrade it in one place where I've actually deployed it and automatically all the applications could get the benefit, the latest would be used. But then there was certain problems like tight coupling. What the exact meaning of tight coupling is that when the client application was built it was built for that specific COM component alone and that should be present on that machine only. That was basically the biggest problem. If you want to have a COM component shared over a network COM was not actually made for it. And also, unless we had a reference to a COM component, we were never able to use the COM component. So suppose the same component was stretched on multiple machines, it lost performance, it lost scalability, it was the major disadvantage of COM. So after Object orientation, COM, yes, was really a very big boon to the industry for reusing the code but the code was localized to a given machine. This was the time when Microsoft came up with DCOM.

Picture 5

They called it as it's just a network version of COM wherein a COM component we put it on one machine and share it across the network. It was considered the biggest failure technology of Microsoft in a way that, there was absolutely no scalability and reliability of the components that were shared on a network and developed using COM specification. So Microsoft very soon upgraded DCOM with COM+ wherein DCOM and Transaction Services (Microsoft Transaction Services) both developed together and provided the benefits of using COM components over a network.

Picture 6

Also, it provided facilities like object pooling and Just In Time Activation. COM+ was really very much used up to year 2001 for development of distributed applications. Now with the evolution of .NET there was a replacement provided in .NET that was .NET Remoting Applications.

Picture 7

.NET Remoting is basically for developing distributed applications in .NET but then the limitation of .NET Remoting was both the client and the server would need to be confined to the same network. Your client applications and your server applications should all belong to the same network. Because the protocols we used were not friendly on the internet. That's where the industry came up with Web Services.

Picture 8

Web Services really changed the way people looked at the service providing architecture. Basically, the way we now provide services have dramatically changed with the advent of the Web Services. People now developed Services, hosted on the Web Server and using HTTP protocol clients could make use of those services having standards drafted in the form of SOAP for communication with the Web Service deployed on a Web Server. So Web Services provided facilities where one could develop a web service (let us say in Java) and use that in .NET. This was possible because HTTP was the protocol used for communication and the format of the data that is exchanged over the network was XML. Both are pretty much interoperable on different platforms and different languages and different technologies. So the major advantage of Web Services that was provided to the industry was they are language independent, technology independent, platform independent and are the way to provide some ready-made facilities to developers all over the world, not just local to a given network. Web services were later integrated into WCF.

Image 9

Basically we can say that WCF is the next generation of Web Services. There are many advantages of WCF over Web services but the most important are the following:

• Supports sending messages not only using HTTP but also using TCP and named-pipes and MSMQ protocols. Whereas Web Services were confined only to HTTP. HTTP has some problems like Statelessness, Slow communication because of text-based communication.
• Support for sending messages using formats other than SOAP that includes REST and Plain Old XML (POX) for communication between client and server.
• Web Services are hosted only in a web server, they cannot be hosted as a standalone application, whereas WCF Services have various options for hosting including Web Server, you can host it as Console Based Application, Windows Application even as a Windows Service.
• WCF has extra capability of managing Transactions and reliable sessions that are again not there in Web Services.

In Web Services we have only stateless objects whereas using WCF we are free to build stateful objects.

WCF is the framework that has been introduced with .NET Framework 3.0 and enhanced in .Net Framework 3.5. All the libraries and classes that are provided are under the namespace "System.ServiceModel". As a .NET developer you'll need to explore the classes that exist in the namespace "System.ServiceModel." The biggest aspect of WCF is that it brings multiple technologies under one umbrella. Earlier people used to develop Web Services, Remoting Applications, Enterprise Services, Attribute Based programming basically making use of COM+ services in .NET; they had one approach for them separately. Asynchronous applications had a different approach towards programming. What WCF has done now is, all these facilities, Web Services, Web Services Extension, Remoting, Enterprise Services and MSMQ are combined. WCF now provides a common API for programming various kinds of applications. Let us say you have an organization in which you're providing some service to the applications that are running within the organization on the local network. You've now purchased another company in some other part of the country. Now the service that was earlier implemented as .NET Remoting, you'll need to make available to the people or the applications that you would deploy in the new organization. The basic problem then is that .NET Remoting would not work in this situation. One would need to then upgrade .NET Remoting to something like a Web Service and then .NET Remoting and Web Services have completely different architecture. One would need to write the entire thing again like re-inventing the wheel from the scratch. So you might want a facility where you would have a service, some clients can use it like a .NET Remoting (that means locally), and sometimes it should be usable on the internet also like a Web Service. Sometimes you might want to have asynchronous communication, Distributed Transaction Management and many extra facilities you want, all these things have been unified into a single programming model that is called Windows Communication Foundation (WCF). So if you go for WCF then the biggest advantage you get is you don't need to separately learn Web Services, Web Services Extensions, .NET Remoting, Enterprise Services. For all of them you have a common API or platform or framework referred to as WCF. It's a programming model for building Service Oriented applications. It's a Microsoft's next generation platform for SOA (Service Oriented Architecture). It's the latest mechanism developers can use to build distributed and interoperable applications talking to each other.

Hope you enjoy reading this article :) Follow for more!