What Is a Web Service?
A Web service is a self-contained module of application logic that can be exposed to other applications over a network, usually the Internet. A Web service interface hides the technology used to implement the application logic, so that an application implemented in one particular technology can be accessed by using a Web service by another application implemented in a different technology, provided both adhere to the specification of the Web service interface.
There are several competing standards for describing Web services, but the best known is the Web Services Description Language (WSDL),[1] an XML format that describes XML-based services as an abstract set of methods, a binding of these abstract methods to a particular protocol (transport and data format used to invoke them), and the endpoint of the service. A commonly used binding extension to WSDL is SOAP, an XML protocol for invoking a service, usually (but not limited to) using HTTP.
[1] For an introductory article on WSDL, refer to http://www.ibm.com/developerworks/webservices/library/ws-soap/index.html?dwzone=ws. The WSDL specification can be found at http://www.w3.org/TR/wsdl.
SOAP[2] supports two interaction styles: remote procedure call (RPC) and document literal. RPC style is similar to invoking an object's method to perform some procedural functionality. RPC style is suited to synchronous interactions with a published API. In document style, any XML document can be exchanged. The document need not be limited to the SOAP body specification, and need not be predefined. Document style is suited to asynchronous interactions, where a contract is not necessarily published beforehand.
[2] To read the SOAP specification, refer to http://www.w3.org/TR/SOAP/.
In this chapter, we will use Web services that are modules of application logic invoked over the network, using SOAP in RPC style over HTTP and described with WSDL.
The benefits of Web services include:
Messages to and from a Web service are easy to read.
HTTP is almost always allowed through corporate firewalls.
Web services promise to be ubiquitous. They are based on XML and HTTP, which are widely supported by a broad range of devices with varying capabilities.
Just about every vendor supports Web services. Web services are becoming a common mechanism for integrating applications and systems, and tool support for creating them are now in their second generation of maturity.
They are implementation-neutral. Web services can be implemented in any language on any platform. The server and the client are happily ignorant of the technology or operating system used at the other end of the interaction.
However, there are some limitations (although these will diminish over time):
In practice, it is not yet straightforward to find a Web service and use it without knowing more about it than what is given in the WSDL file. Implementations vary between servers and clients. Writing a client for a particular Web service is still a matter of trial and error.
Because they are based on XML, which is rather verbose and takes time and resources to process, Web services are not well suited to extremely constrained devices with limited processing and memory capabilities.
Web services is a vast field, and rapidly expanding. If you want to find out more, a good starting point is IBM's developerWorks (http://www-106.ibm.com/developerworks/webservices/).
In this chapter, we will look at how to access functionality provided by a Web service, both from Palm and PocketPC clients. To get an end-to-end understanding, we will go through the process of developing the Web service, deploying it on the server, and demonstrating several ways of accessing it from a PDA.
