"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.
Your example getStudents() is what is confusing you. I realize you've selected this as a simple example, but that's the problem. It is so simple in your mind you don't see any logic being applied.
Taken literally, you are going to return every student ever entered into the system since the beginning of time. Is there really a need for that? Does this include students who enrolled, but left the school before ever finishing one class? Do all the students have to be accepted? Have they graduated?
Once you start considering the real benefit of your application (it's not just a list of students and their coursework), you'll see where the logic is needed. Here are a few examples:
- Enroll a student in a class, but check for prerequisites, conflicting classes, availability, faculty approval, etc.
- Expell a student - create a workflow and notification process to get all the necessary approvals.
- GetFullTimeStudentsByGradingPeriod(gradingperiod)- calculate the number of credit hours enrolled during the given period to determine full-time status.
- AssignStudentCourseGrade(student, course) - Check if enrolled and is the user allowed to enter grades for this course.
If your application is nothing but a "skin" on a database, then you don't really hve much logic to worry about, but I think you're making a lot of assumptions that you'll soon learn will require logic to be performed by the service and not that application using the service.
Best Answer
Integrating a business rules engine does not come for free, you do not simply plug it in and then write any business rules you want. Instead, usually each type of business rule you want to implement needs to have code written in the underlying product to support. For example, a fact has to be loaded into the engine before a rule can use it.
This is why it is useless to integrate a BRE until you have an actual use case. And that use case must include fairly complicate business rules that change frequently. In any other case, I believe you are better served by writing the logic you want in the code, and wait for the configuration use-case (with well defined expecations) to come along.