An application using a Web service (a client application) can invoke it and pass data to and from it very easily, because all communication between them is in the form of XML files sent using a standard protocol such as HTTP. This means the client application has no need to know details of how the component is deployed, what language it is in, and so on.
In theory, exposing a component as a Web service means it can be invoked across the Web by anyone in the world. For example, a credit card company might provide a Web service to be called by retailers to validate card details. They are often used across companies' intranets, for use in internal applications and as a means of integrating disparate internal applications.
Web Services is built around three standards that define the format of the XML files needed to link clients to services:
A file containing information in this format is made available to people wanting to write clients that call a Web service. It describes the interface that the service expects and what format the data will be in. This is, in effect, the contract for the Web service that must be obeyed by both parties. You can also generate a client application directly from a WSDL file.
SOAP is how the actual data that allows the web service client and service to communicate is formatted. A typical web service interaction will consist of a SOAP Request followed by a SOAP Response. These packets of data are sent across the network using the HTTP protocol.
Lists, or registries, of services are published on the Web in this format. It may be advantageous to think of a UDDI repository as a type of telephone directory or ‘Yellow Pages’ of Web services.
For the latest specifications of WSDL, SOAP, HTTP and UDDI, see the World Wide Web consortium Web site.