XML web service can be defined as a unit of code that can be invoked via HTTP requests. Unlike a traditional web application, however, XML web services are not (necessarily) used to emit HTML back to a browser for display purposes. Rather, an XML web service often exposes the same sort of functionality found in a standard .NET code library.

Not only a Web based application but a console or windows from application can also use the functions provided by a web service.

Simplest example of a web service in our daily life can be given as a service that is used to validate credit card accounts when you are making electronic transactions. Every e-commerce web site validates the credit cards for transactions and there is no need for every such web site to have code written to do this in their own application. Instead, all e-commerce websites can access a single web service to validate the credit card.

In general, to use web services your applications have to do three things:

1. Find appropriate Service (Discovery Service):

Before a client can invoke the functionality of a web service, it must first know of its existence and location.

For finding the appropriate service, there are different options.
If you are the individual (or company) who is building the client and XML web service, the discovery phase is quite simple given that you already know the location of the web service in question.

In other cases, an application first uses the Universal Description, Discovery and Integration (UDDI) registry to determine where a specific service can be found. UDDI is a web-based distributed directory that enables web services to list themselves on the Internet and discover each other, similar to a traditional phone book’s yellow and white pages.

2. Determine what kind of messages web service will accept, and in what format (Descriptive Service):

Once a client knows the location of a given XML web service, the client must fully understand the functionalities provided by the service. He must know what inputs and in which format are required to use an operation of the service in question. For example, the client must know that there is a method named GetTemperature() that takes some input parameters and sends back a return value.

For this purpose XML-based metadata is used to describe a XML web service and it is termed the Web Service Description Language (WSDL).
Using this, a web service created in any language can be accessed by an application developed in any other or same language and any platform.
Using the WSDL description a client can find that what kind of operations the Service provides and what are the inputs that the operation expects and what it gives as a return value.

3. Communications mechanism to get data to and from the web service (Transport Protocol):

Hypertext Transport Protocol (HTTP) is used as the transport mechanism to access the Web Services. The data packets transferred apply the Simple Object Access Protocol (SOAP), with the use of XML statements. The XML provides a placeholder for data, either input to the web service or output back to the application.

SOAP is a standard of the World Wide Web Consortium, and its specification can be found at www.w3.org/tr/soap. It describes an XML-based message passing format for communications between networked computers and other devices.

HTTP GET and HTTP POST can also be used in place of SOAP but they are restricted to a limited set of core data XML schema types. On the other hand, SOAP can be used with complex types.

.NET web services use SOAP to transfer the data.