The W3C defines a Web Service as a software system designed to support interoperable machine to machine interaction over a network. Web services are frequently just API's that can be accessed over a network, and executed on a remote system hosting the requested services.
Among the many ways devised to enable humans to use software running on distant computers, HTML transported over HTTP and presented via a web browser is surely the most successful yet. By using this relatively simple, accessible message format, applications can be used by people all over the world without installing custom client software on their computers.
What about when you want to connect one system to another that is running on a distant computer? Lots of approaches to distributed computing have been tried over the years, and many of these are still in use. But none has achieved the same degree of explosive growth and re-use as we have seen with HTML for web UI. The term "web services" encompasses applications that employ a specific combination of technologies to make themselves accessible to other systems running on remote machines. The most significant web services technologies address three questions:
- How do I find web services that I want to use?
- Once I find a service, how do I learn how it works?
- How do I format messages to a web service?
Finding a Web Service:
In the simplest case, you could learn about a web service in the normal course of communicating with your friends, co-workers and business partners. Universal Description, Discovery and Integration (UDDI) offers a more structured approach. UDDI is a standard for establishing and using registries of web services. A company could establish its own private registry of web services available internally, or to its partners and customers. There also are several public UDDI registries that anyone can search, and to which anyone can publish the availability of their own web services.
Understanding a Web Service:
Once you identify a web service that you'd like to use, you need to know how it works: What kinds of messages does it respond to? What does it expect each message to look like? What messages does it return, and how do you interpret the responses? The Web Services Description Language (WSDL) provides a way to declare what messages are expected and produced by a web service, with enough information about their contents to enable using the service successfully with little or no additional information. When you create a web service, you can create a description of the service using WSDL and distribute the description file (often called a WSDL file) to prospective users of the web service, either directly or by including a link to the WSDL file in a UDDI registry entry.
Communicating With a Web Service:
Now that you've obtained the WSDL description of a Web Service, you're ready to invoke it. Web Services communicate with one another via messages in a format known as XML. XML (Extensible Markup Language), like HTML, is a descendent of Standard Generalized Markup Language (SGML). HTML focuses on the way information is to be presented. XML, on the other hand, focuses on the structure of the information, without regard to presentation issues. That's one reason XML is well suited to exchanging information between automated systems. Web services exchange XML messages with one another, typically using either HTTP or SMTP (e-mail) to transport the messages. The Simple Object Access Protocol (SOAP) is a further specification of how to use XML to enable web services to communicate with one another. A SOAP message is just an XML message that follows a few additional rules, most of which deal with how the elements of the message are encoded, and how the message as a whole is addressed.
