WCF Part 1: Why WCF?

When I create a WCF service, I feel like it is a very easy task but when somebody asks me, why you have created it? then the simplest answer is, I got the requirement like this. But to be honest, nobody tells us to use WCF specifically. Then why there is there a roar over WCF? This post will touch the ‘why’ perspective of WCF and in subsequent articles, we will touch base with WCF through coding or programming.

What’s the Idea Behind WCF?

Idea behind WCF can be described as simplified communication between applications or programs written in different languages or residing at different locations.

We will try to see two important concepts which are required to understand how communication between components can be a possibility.

Note: Here, component refers to a program or functionality which can exist independently.

1. Remote Procedure Calls (RPC)

As per Wikipedia, “a remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction” .

In simple words, we have two machines: Server and Client, there is an independent code/program/component available or placed on Server to perform some function. Client like our remote machine is also running a code/program/component, which sends a request to Server to execute program residing on server machine and once execution is over, Server should share the result with program on Client machine who has waited for Server to finish the job.

2. Interfaces

Now we have some idea about RPC, here, we can deduce that Server has to tell the client which all methods are available for use. Now, there is a catch, Server should not expose their methods directly. There should be a level of encapsulation and abstraction applied to protect the functionality. We have interfaces to achieve this kind of feature.

Interface ICalls()
{
    public void GetCount();
}

An Interface defines the expected behavior and it is available when Server side component implements this interface by inheritance. This interface can only exist if the component is instantiated. This interface is exposed to the client and, as it hides all the complexities of implementation, client just needs to call the method exposed through interface.

RPC Calls:

Client => Interface=>Server

All the service oriented technologies like COM, DCOM, Remoting, WebService, WCF were developed on this model and can be described as improvised versions of RPC calls via interface. We will try to see the improvements achieved by each of these technologies.

1. COM

Component Object Model - COM can be considered as the birth of communication between the components. In this model, two independent components interact with each other through interface pointers like IUnknown. There is no server and client approach established with COM but components developed on different platforms followed binary standard for function calling between components. Here, the point of interest is communication happens between the components residing at the same location.

2. DCOM

Distributed Component Object Model- As COM was not efficient in communication between components residing on remote locations, DCOM came into existence. Wiki has mentioned “The addition of the “D” to COM was due to extensive use of DCE/RPC (Distributed Computing Environment/Remote Procedure Calls)”. DCOM was Microsoft’s version of handling calls between remote components. DCOM was one of the first attempts of distributed environment where client components can request services from server components on other computers in a network.

3. Remoting

DCOM was an improvement over COM but it didn’t achieve a global distribution adaptation so Microsoft came out with .NET Remoting. .NET Remoting helped in improving inter-process communication by providing loose coupling between remote object and client, also made the communication independent of specific formatting. As a result, it was easy to replace one communication protocol with another, or one serialization format with another without recompiling the client or the server. Remoting was able to use HTTP or TCP, and messages could have been formatted as Binary or SOAP.

4. Web Services

Though Remoting was considered more useful, there were some grey areas and web services took care of that.

• Web Services are interoperable with many software vendors, languages and platforms and not limited to .NET like Remoting
• Audience is unlimited and available to World Wide Web
• Easy development, deployment and maintenance
• Highly scalable
• Follows open web standards (such as SOAP, HTTP, and XML)

With all the above information, we have passed the journey of communication between components and reached the latest edition of communication, WCF.

How Can We Say It Is An Improvement?

Till WCF came into the picture, every technology was an improvement over the previous one but WCF was one complete product, created and built from the ground up. It can be termed as a unified platform having all the improvisations achieved earlier by COM, DCOM, Remoting, WebService. We can compare it with immediate predecessor.

• Web services technology uses open web standards and build applications that send and receive messages via the Simple Object Access Protocol (SOAP) over HTTP. The messages sent or received were defined using XML Schema. Same with WCF.
• There were only simplex and request-response communication possible in WebServices. WCF have simplex, request-response, full duplex communication.
• Web Services supported only HTTP whereas WCF supported more like TCP, IPC, MSMQ.

We can say at this point why we require WCF compared to other options. In the second article, we will describe WCF and its implementation.

Related Posts

1. Concepts: S O L I D