Introduction
In this series, we are learning WCF from the very beginning. In our previous chapters, we learned the basic vocabulary of WCF and related to services and we hosted one simple WCF service in a self-hosting environment. You can read them here.
In this chapter, we will understand a little more about the theory of WCF applications. I can guarantee you that if you go for a .NET interview and if the interviewer wishes to ask a question about WCF then they will definitely ask about these theoretical topics. So I hope you will read this chapter carefully, at least for a better opportunity. Ha..Ha... OK, let's start our explanation.
To understand those three vocabularies we need a reminder of a previous explanation a little. We have explained that there was a problem calling one application from another application. That's why services began to be used and the next question is, how will the service send data to another service or client, and here the concept of messages developed.
Now the concept is, each and every service has a few characteristics; rather it is more appropriate to say that a good service has the following characteristics.
Where: Where will the service be hosted.
How: How to consume the service.
What: What is to be hosted in this service.
What is Address?
An address is nothing but where we need to understand where the service will be hosted. For example, if we want to get information on a specific employee of an HR portal then the service location might be very similar to:
www.employeetest/services/employee/1
Where the right-most part of the URL is (1) specifying the parameter value of the specific employee. So this is an example of an entire address where the service will execute.
So in conclusion, an address indicates where we can find the service. The address is a URL, that points to the location of the service.
What is binding?
It is nothing but the characteristic of the service. It determines how this end can be assessed. It determines how communication will be done. Say for example one service has been exposed and there are various ways and protocols to consume the service. It may be consumed by SOAP over HTTP or it may support Binary over TCP.
So it is all about communication protocol and message type. For each of those communications mediums, two bindings will be created.
What is a contract?
A contract is nothing but the properties of the service. It's one kind of agreement between two parties. The contracts represent information related to the service. In other words, the name of the service, the parameter necessary to consume the service, and the return type of the service.
So, in conclusion, it defines the protocol of how the client should communicate with your service. Technically, it describes parameters and the return value for a method.
Now the question is. How to determine this information?
At first, we need to specify that the information in the web.config file of the service application. Have a look at the following code snippet.
<endpoint address="http//localhost/services" bindings ="wsHttpBinding" contract="Iservice" />
This is the XML tag we need to specify for the service application. The address part specifies the location of the service. Binding specifies the protocol type to consume the application. The contract is nothing but the interface name of the service application.
Conclusion
In this chapter, we explained about the address, binding, and contract.