Theory
Apps talking to apps
Everything so far has been your server talking to a human's browser. But sometimes a program needs to talk to another program. Suppose the college's mobile app wants FestConnect's list of events, or a partner site wants to show them. They do not want an HTML page; they want the raw data, to use in their own way.
That is what a web service is for: it lets one application call another over the web and exchange structured data, machine to machine. This closing technical topic covers the basics and how you interact with one.
Theory
What a web service is
A web service exposes functionality over the web so that other programs (not people in a browser) can use it. Instead of returning a web page, it returns structured data the caller can process.
Classically, the caller and service exchange XML messages using a protocol called SOAP, over HTTP. The service publishes a contract, a WSDL document, that describes exactly what operations it offers and what data they take and return, so a caller knows how to talk to it. The defining trait: it is language-independent. A web service written in .NET can be called by a program written in Java, PHP, or anything else.
Formula
The point is interoperability
Why standardise on XML/SOAP messages and a WSDL contract? So that any platform can call the service. FestConnect's events service, written in .NET, can be consumed by an Android app in Java, a website in PHP, or another .NET app, because they all agree on the same message format over HTTP.
This cross-platform cooperation is called interoperability, and it is the whole reason web services exist: shared functionality that does not care what language the caller speaks.
Theory
Creating and consuming one
In classic ASP.NET you create a web service as an .asmx file: a class whose callable methods are marked with the [WebMethod] attribute. Only methods with that attribute are exposed to callers.
To consume (call) a web service, a client program adds a reference to it. Tools read the service's WSDL and generate a proxy: a local stand-in object with the same methods. The client then calls those methods as if they were local, and the proxy handles sending the request and receiving the response behind the scenes. Interacting with a remote service ends up looking like calling an ordinary method.
Practical
A tiny FestConnect web service, and calling it
// CREATE: expose a method other programs can call (in an .asmx service)
public class EventsService : System.Web.Services.WebService
{
[WebMethod] // this attribute makes it callable
public string[] GetEventNames()
{
return new[] { "Robotics Workshop", "Coding Contest", "Music Night" };
}
}
// CONSUME: after adding a reference, a client calls it like a local method
// var svc = new EventsService();
// string[] names = svc.GetEventNames(); // proxy handles the web callQuiz
What is the defining purpose of a web service?
- To display nicely styled HTML pages to human visitors
- To let other programs call it over the web and exchange structured data, independent of their language or platform
- To store the connection string for an application
- To replace the database with an XML file
Show the answer
To let other programs call it over the web and exchange structured data, independent of their language or platform
A web service exposes functionality over the web for OTHER PROGRAMS to consume, exchanging structured data (classically XML/SOAP) in a language-independent way, so a .NET service can be called by Java, PHP, or any platform. Option A describes ordinary web pages meant for humans; a web service serves programs, not browsers, and returns data, not styled HTML. Option C confuses it with web.config, which holds settings. Option D is wrong: a web service is not a data store and does not replace a database; it is an interface that other applications call. The key idea is machine-to-machine interoperability across languages and platforms.
Think first
Why expose a web service instead of just sharing the database?
If a partner app wants FestConnect's events, why not just give it access to the database directly? Then tap.
Show the answer
Because a web service gives you a controlled, stable, safe INTERFACE, while direct database access gives away far too much. If you handed a partner your database credentials, they would see your entire schema, could read or even change data you never meant to share, and your app would break theirs the moment you renamed a table. A web service exposes only the specific operations you choose, GetEventNames, say, and nothing else; the caller never touches your tables, sees your internal structure, or holds your database password. You can add validation, security, and rules behind the service, and you can restructure your database freely as long as the service's contract (its WSDL) stays the same. It is also language-independent, so any platform can call it, whereas a raw database connection ties callers to specific drivers and credentials. In short, a web service is a deliberate front door: it shares exactly what you want, safely and stably, instead of handing over the keys to the whole building. Expose an interface, not your internals.
Summary
Key takeaways
- A web service lets one application call another over the web, machine to machine, rather than serving pages to a browser.
- It exposes functionality to other programs and returns structured data, classically XML messages via SOAP over HTTP.
- A WSDL document is the service's contract, describing its operations and their data so callers know how to use it.
- Web services are language-independent: a .NET service can be called from Java, PHP, or anything, enabling interoperability.
- In classic ASP.NET you create a service as an .asmx file with methods marked [WebMethod]; only those are callable.
- A client consumes a service by adding a reference; a generated proxy lets it call remote methods like local ones.
- Memory hook: a web service is a safe front door for programs, sharing data across any language.