In Today’s discussion, we’ll be discussing more about WCF and its features. So, before delving in WCF directly. Let’s look at the basics like how WCF came into picture. WCF is all about connected systems. Basically, a connected system is the one which is distributed across multiple machine nodes. you can see the glimpse of connected system in below diagram.
Now, if you see closely, you will notice that these machines communicate with each other via some medium. Currently, i just labeled it with communication. It means, different machines will pass information to and fro via some protocol. So, this is the connected system in a nutshell. Now, let’s see how can we build connected systems on Windows. Years before, we used to have “DCOM/COM+/ES“, a component oriented architecture. So, here we used to take our COM components and deploy them on the network and then invoke them remotely. One of the key features of this was Distributed Transactions, where basically logical transactions are handled by multiple COM components spanned throughout the network. Now, the disadvantage of this feature was, it did require to have DCOM Infrastructure installed on each and every machine.
Now, at the next level with the release of .NET, they also released a distributed object technology known as .Net Remoting. It was also very similar to COM based architecture but only difference is that it runs under the Managed Execution environment of CLR. As a result, .Net Remoting became very simple, extensible but still in this case as well it depends on .Net CLR.
And then MSMQ came into picture. It’s very different from other two frameworks. MSMQ is completely based on messaging. It allows you take a message and transmit it between two machines in a connected system in a asynchronous durable and reliable fashion. It has nothing to do with components. But, it still requires MSMQ infrastructure installed on each and every participating machine.
so, here in the above case, each infrastructure comes with it’s own programming style which means developers need to learn different styles of coding before they jump start execution. Also, there is one more disadvantage of this system as each of these restricts its execution to Windows environment only.
So, now in today’s era interoperability is the key demand across all the companies. For example, consider the below example, companies need to have environment where in they can seamlessly do transactions.
so, here in the above diagram, this connection is via services. A service is the simple unit of functionality which you can expose to any ecosystem via messaging. So, we can implement services on each of these nodes and then expose the functionality via messaging. Now, the way we achieve interoperability via standard protocols like HTTP and message formats like XML. So, this way we can easily achieve more loosely coupled architecture.
Now, Let’s discuss a design strategy a bit.
So, as you can see in the above diagram, the 1st one is the SOAP which also incorporates various WS-* specifications. Now, this style has been used for several years and still working nicely. This design is very popular across enterprise level where in projects are basically Intranet based. Another design strategy which is gaining traction these days is REST(Representational State Transfer). This design approach is very popular at internet space.
Now, let’s discuss the same in detail. Below is the basic diagram of SOAP based architecture.
As you can see in the diagram that SOAP and WS-* based specifications build on a full fledged stack of different technology suites. So, the 1st thing is Transport Neutrality which is the foundation of this approach. Now, in-order to accomplish the same we need to make use of XML based messaging layer. Now, this is the place where in SOAP comes into picture. SOAP is basically XML for bundling the messages which we need to transmit across our services. Then comes various WS-* based specifications like Security, Reliable Messaging(RM), Transactions etc. Now, if you are using any of these advanced features, we also need to provide Metadata to our clients
Now, on the other hand Restful service is completely different from SOAP based. In fact, they don’t try to achieve Transport Neutrality as they support only HTTP protocol. So, basically with REST services are modeled as resources with Unique identifiers also known as URIs. Now, in order to interact with these resources we need to have a uniform interface which is commonly known as “GET,POST,PUT,DELETE….”. Now, in order to represent these resources, we need to have concrete format like XML, JSON, RSS, ….
Now, let’s look at the below picture. It basically shows Microsoft Services in a nutshell.
So, as you can see that the 1st one is ASP.NET Webservices also known as ASMX. So, basically it provided support for SOAP 1.1 and 1.2. Just after this, they came with Web Service Enhancements also known as WSE. This is basically meant for supporting WS-* protocols. It means it actually added, Security, Secure Conversation etc. Now, one can use WSE standalone or in conjunction with ASMX to add some of these behaviors to ASMX services. But, again this approach was also quite limited in terms of Transport neutrality.
Later on, Microsoft realized, they need to work on one framework which will complement Uniform programming model for building any kind of service oriented architecture. Hence, they tried to incorporate below listed dependencies under the same hood.
So, in a nutshell above diagram shows that it has got every required things under one programming model and hence, It turned out to be the birth of WCF.
So, in today’s discussion, we have just discussed birth of WCF by focusing on the evolution of connected systems and services. In the next section, we’ll start with WCF programming from the scratch. Till then stay tuned and Happy Coding.