What is the relationship between WCF and REST&SOAP? Is WCF based on one of those technologies (REST or SOAP) or it is a separate technology?
WCF is a messaging framework for building distributed systems. Distributed systems is mostly just another word for web services.
What this means is that you can write methods in C# (or any of the .NET languages) and then apply a bunch of configurations to the code that make your code accessible to others and turn your code into a web service.
Those "bunch of configurations" are WCF. WCF allows you to expose your methods to other computers or applications using REST if you set up the WCF configurations around your C# code to expose it as a RESTful service. Or, you can easily take the same C# methods and make them available via the SOAP protocol.
If you have a method called "GetData()", you can set up the WCF configuration to make that method available in a service that is hosted in IIS. When someone calls that service, they can send an HTTP GET request to http://www.yourdomain.com/SomeService/GetData, and the GetData method will receive the message and send back a response. When you make a GET request over HTTP, you're using the REST. REST is pretty much tied to HTTP as the transport protocol. REST also has no standard message format. Whatever you want to send in your HTTP message, and however you want to send it is OK. You can send XML, or JSON, or just plain text. You can use POST, or GET or PUT or any of the HTTP verbs as well.
With SOAP, your messages can be sent to the service using any transport protocol -- you aren't tied to HTTP. SOAP messages are designed to be transport neutral. They are encoded in XML and the XML always has a head and a body node inside of an envelope node. There are lots of web standards around SOAP -- standards for putting security, sessions and other features into the header of the message, for example. Also, with SOAP, you get a WSDL, which I won't go into explaining here, but it makes it a LOT easier for clients to program against. Most programming languages have a method of taking a WSDL and converting it into strongly-typed methods and objects so that your service is easy to call.
REST is very popular on the internet and is as scalable as the internet (i.e. VERY scalable). SOAP is very popular in business-to-business applications.
WCF isn't automatically REST or SOAP, but you can make it that way. What you need here is a tutorial:
WCF
http://www.codeproject.com/Articles/406096/A-beginners-tutorial-for-understanding-Windows
REST
http://rest.elkstein.org/
Here's some other interesting stuff:
WCF - REST / SOAP
https://msdn.microsoft.com/en-us/library/hh323708(v=vs.100).aspx
WCF and REST
https://msdn.microsoft.com/en-us/library/ee391967.aspx
Or you can do a google/bing/metacrawler/altavista search on your own.....
From MSDN
The WCF programming model provides various capabilities, such as SOAP
services, web HTTP services, data services, rich internet application
(RIA) services, and workflow services. SOAP services support
interoperability between systems that are built with Java, other
platforms, and those that use messaging standards that are supported
by Microsoft®. SOAP services also support transports such as HTTP,
TCP, named pipes, and MSMQ. Web HTTP services and data services both
support REST. Web HTTP services enable you to control the service
location, request and response, formats, and protocols. Data services
enable you to expose data models, and data-driven logic as services.
WCF also includes two programming models: The service model and the
channel model. The service model provides a framework for defining
data contracts, service contracts and service behaviors. The channel
model supports specifying formats, transports, and protocols.
Both SOAP and REST services can provide functionality to web
applications, and both can be used to exchange information in the
web's distributed environment. Each one has its own advantages, and
limitations.
Although, this question has got several good answers, just putting in my 2-cents, in an attempt for newbies to WCF vs SOAP vs REST-full services, to make it a bit easier for them to understand.
We get confusions, whether WCF supports both REST and SOAP ? And, normally, we just see generic definitions about SOAP and REST. So , we need something from Microsoft to make us feel the truth : ) So here's a screenshot from Microsoft MSDN :
So, yes, WCF supports both .
In context with OP:
SOAP services: in WCF programming model support interoperability between systems that are built with Java, other
platforms, and those that use messaging standards that are supported
by Microsoft®. These also support transports such as HTTP,
TCP, named pipes, and MSMQ.
Web HTTP services : in WCF programming model supports REST. [Source: MSDN]
I am developing a WCF service (VS2010, .NET 4.0). If in the WCF service I utilise REST type functionality (i.e. decorate my methods with WebGet, etc), since REST heavily leverages the HTTP protocol, am I locked into hosting the WCF service as HTTP - i.e. do I have the option to host as net.tcp ?
Short answer - Yes, unless you want to write your own HTTP stack analog.
Is there any particular need in Tcp?
I am reading through the WCF 4.0 Cookbook, I am impressed by the unification protocol capability of WCF, and I just come up with this question:
Is a hosted service using 1 protocol like HTTP\named pipe? or a hosted service can be consumed by different protocol client like HTTP, named pipe at the same time?
If you setup the service with Multiple Bindings then yes it can listen and respond on different transport protocols.
Obviously if you initiate communication on http then you will get a response back over the same transport.
This msdn link provides details on when you would choose the different transports.
http://msdn.microsoft.com/en-us/library/ms733769.aspx
What benefits does WCF bring to the table and why should I use this new technology over good old ASP.Net web services?
Maybe you don't need to transition to WCF if regular Web-Service will work for you,
however WCF encompasses more than just Web-Services.
With WCF you can utilize different communication channels (such as Web-Services, MSMQ, named pipes...) utilizing the same end-point service handler code.
WCF also has different built-in security mechanisms, allows you to utilize different serialization mechanisms (if something other than Soap is needed like raw JSON), hosting of services without the requirement of needing a web project etc...
As such WCF is more a general service hosting framework that can replace regular ASMX web services
Here is a good article from msdn that talks about the differences between ASMX and WCF
A few key areas
Serialization - Asmx uses XmlSerializer while WCF uses the DataContractSerializer. The Datacontract serializer is about 10% faster (source along with other information)
Differences Between ASMX and WCF Services
Greater protocol support (HTTP, TCP, ICP, MSMQ for WCF), ASMX only supports HTTP
Why we are going for WCF when web services (ASMX) exist ??
Here is a nice article that you can look at
Comparing ASP.NET Web Services to WCF Based on Development
WCF supports protocols beyond HTTP (TCP and MSMQ come to mind) and message formats beyond XML, so it could be used for tasks they are unsuitable e.g. because these tasks require better performance.
WCF could be self-hosted so no need for hosting in IIS.
WCF supports preserving service object state between calls.
Another rather interesting and thoughtful comparison:
http://www.keithelder.net/blog/archive/2008/10/17/WCF-vs-ASMX-WebServices.aspx
Download the PowerPoint and have a look at it - also, watch Keith's DotNetRocks TV appearance for a great screencast intro to WCF and its advantages over ASMX.
Marc
Web services require use of HTTP protocol on standard HTTP ports, right? WCF is more flexible. It can be based on HTTP, TCP, UDP and such. It allows you to design an application with network connectivity without caring so much about the protocol used. Then you can more easily switch the network protocol without affecting the application.