"Web Services" are a fairly generic term to describe a data interchange mechanism that usually operates over HTTP (although not restricted to). There are many types of ways to implement web services and in particular, ways to exchange data.
SOAP Web Services
The type of "Web Service" most (.NET) developers are probably familiar with are SOAP web services. SOAP web services are pretty mature, well defined and have a whole bunch of w3.org standards and specifications. SOAP web service support is burned into most development frameworks, .NET has had SOAP web service support since its inception and the Visual Studio tooling makes it really easy to start building SOAP web services out of the box.
The problem with SOAP web services is that they aren't lightweight. You need to publish a WSDL document that describes the service and the XML interchanged between systems can be quite heavy due to the constructs used to assemble a SOAP message - Envelope, Header and Body.
The problem with SOAP messages is that they aren't easily or naturally consumed by web browsers (Javascript), you need to do a lot of work to make that happen or use something like Microsoft's AJAX client side script libraries that aren't exactly pretty or lightweight either.
XML-RPC
Another, but older, type of "web service" protocol is XML-RPC. It's probably the daddy of HTTP web services and provided the groundwork for SOAP. XML-RPC is not well supported in .NET and as with SOAP has a fairly large metadata overhead in the XML payload just to send even small amounts of data. XML-RPC is also not easily or naturally consumed by web browsers.
Custom XML or other interchange formats
It's entirely possible to construct a web service that exchanges data using custom XML messages. In fact webservices don't even need to use XML (see below), you can even exchange data over HTTP using plain old CSV. However the disadvantage of using non-standard formats is that when you come to serialise or deserialise the interchange format then you're committing to writing your own custom code to do that. SOAP and JSON have built in support in many frameworks to serialise and deserialise your objects to and from these formats. Ideally you want to be using a format that your framework can understand and do the heavy lifting for you out of the box.
JSON
If you're going to be making calls to a "web service" endpoint and the consumers of these services are going to be varied (such as in your case), for example a .NET WPF application, AJAX calls from the browser or pulling data into a mobile application (iPhone, Android etc), then the one data interchange format to put at the top of your list is JSON.
JSON is a very lightweight data interchange format and has a multitude of libraries available for many different programming languages and platforms.
For .NET applications there is built-in support for serialising and deserialising JSON and there are also excellent third party libraries such as James Newton King's Json.NET library (which is my own preference).
For mobile applications, whilst there is fairly solid support for SOAP on most mobile platforms, JSON would be a better choice due to it being more compact, and compact has great advantages if your mobile application is pulling data over a low speed 2G or 3G connection.
JSON is also easily consumed by Javascript in the browser, Javascript will rehydrate JSON formatted data into objects you can use directly in your browser side script. jQuery makes transmitting and receiving JSON data between the browser and a web service a fairly pain free affair. In fact JSON is probably the de-facto way to consume web service data in the browser.
So, in conclusion and to answer your two questions -
How do we develop a webservice and which tools, technology and framework should I use for the same using C# language?
To build the web service itself - web service endpoints built using ASP.NET MVC is probably the path of least resistance. You can use WCF but the learning curve can be fairly high and there's a fair bit of configuration and infrastructure code that comes along with the territory. However, there is a MS project on CodePlex called WCF Web API aimed at simplifying using WCF over HTTP, however it's still at the preview stage.
My advice would be to start by getting the hang of sending and receiving JSON over HTTP using ASP.MVC. Either use the built-in .NET JSON support or use something like Json.NET.
How can I interact with this from a desktop WPF application, website and mobile app?
To allow the WCF application to communicate with the web service above I'd certainly go with Json.NET to serialise and deserialise the JSON data and make your requests to the web service endpoint just using simple HttpWebRequest's
Browser based clients can make AJAX calls to push and pull JSON data between the web service and the browser. The path of least resistance here is to use jQuery
For mobile applications (iPhone, Android or Windows Phone 7) there are numerous ways to send, receive and consume JSON. For example, here, here and here
To REST or not to REST
A decision you may want to take at some point is whether to make your web services RESTful. The principles of REST are well documented but often misunderstood (some developers claim their web services are RESTful simply because they use "clean" urls). There isn't enough space here to begin explaining the philosophy of REST, I couldn't do the subject any justice and I'd likely get it wrong, however I do recommend obtaining a copy of RESTful Web Services published by O'Reilly Media. There are few questions on REST on this site that you may find worthwhile perusing.
Hopefully this answer will give you a jumping of point to get you started.
Best Answer
Your consumer is probably accessing your API from behind a proxy. Do it's completely his/her responsibility to handle this.