What is a Web service?
Many people and companies have debated the exact
definition of Web services. At a minimum, however, a Web
service is any piece of software that makes itself
available over the Internet and uses a standardized XML
XML is used to encode all communications to a Web
service. For example, a client invokes a Web service by
sending an XML message, then waits for a corresponding
XML response. Because all communication is in XML, Web
services are not tied to any one operating system or
programming language--Java can talk with Perl; Windows
applications can talk with Unix applications.
Beyond this basic definition, a Web service may also
have two additional (and desirable) properties:
First, a Web service can have a public interface,
defined in a common XML grammar. The interface describes
all the methods available to clients and specifies the
signature for each method. Currently, interface
definition is accomplished via the Web Service
Description Language (WSDL). (See FAQ number 7.)
Second, if you create a Web service, there should be
some relatively simple mechanism for you to publish this
fact. Likewise, there should be some simple mechanism
for interested parties to locate the service and locate
its public interface. The most prominent directory of
Web services is currently available via UDDI, or
Universal Description, Discovery, and Integration. (See
FAQ number 8.)
Web services currently run a wide gamut from news
syndication and stock-market data to weather reports and
package-tracking systems. For a quick look at the range
of Web services currently available, check out the
XMethods directory of Web services.
What is new about Web services?
People have been using Remote Procedure Calls (RPC) for
some time now, and they long ago discovered how to send
such calls over HTTP.
So, what is really new about Web services? The answer is
XML lies at the core of Web services, and provides a
common language for describing Remote Procedure Calls,
Web services, and Web service directories.
Prior to XML, one could share data among different
applications, but XML makes this so much easier to do.
In the same vein, one can share services and code
without Web services, but XML makes it easier to do
these as well.
By standardizing on XML, different applications can more
easily talk to one another, and this makes software a
whole lot more interesting.
I keep reading about Web services, but I have never
actually seen one. Can you show me a real Web service in
If you want a more intuitive feel for Web services, try
out the IBM Web Services Browser, available on the IBM
Alphaworks site. The browser provides a series of Web
services demonstrations. Behind the scenes, it ties
together SOAP, WSDL, and UDDI to provide a simple
plug-and-play interface for finding and invoking Web
services. For example, you can find a stock-quote
service, a traffic-report service, and a weather
service. Each service is independent, and you can stack
services like building blocks. You can, therefore,
create a single page that displays multiple
services--where the end result looks like a
stripped-down version of my.yahoo or my.excite.
What is the Web service protocol stack?
The Web service protocol stack is an evolving set of
protocols used to define, discover, and implement Web
services. The core protocol stack consists of four
Service Transport: This layer is responsible for
transporting messages between applications. Currently,
this includes HTTP, SMTP, FTP, and newer protocols, such
as Blocks Extensible Exchange Protocol (BEEP).
XML Messaging: This layer is responsible for encoding
messages in a common XML format so that messages can be
understood at either end. Currently, this includes XML-RPC
Service Description: This layer is responsible for
describing the public interface to a specific Web
service. Currently, service description is handled via
Service Discovery: This layer is responsible for
centralizing services into a common registry, and
providing easy publish/find functionality. Currently,
service discovery is handled via the UDDI.
Beyond the essentials of XML-RPC, SOAP, WSDL, and UDDI,
the Web service protocol stack includes a whole zoo of
newer, evolving protocols. These include WSFL (Web
Services Flow Language), SOAP-DSIG (SOAP Security
Extensions: Digital Signature), and USML (UDDI Search
Markup Language). For an overview of these protocols,
check out Pavel Kulchenko's article, Web Services
Acronyms, Demystified, on XML.com.
Fortunately, you do not need to understand the full
protocol stack to get started with Web services.
Assuming you already know the basics of HTTP, it is best
to start at the XML Messaging layer and work your way
What is XML-RPC?
XML-RPC is a protocol that uses XML messages to perform
Remote Procedure Calls. Requests are encoded in XML and
sent via HTTP POST; XML responses are embedded in the
body of the HTTP response.
More succinctly, XML-RPC = HTTP + XML + Remote Procedure
Because XML-RPC is platform independent, diverse
applications can communicate with one another. For
example, a Java client can speak XML-RPC to a Perl
To get a quick sense of XML-RPC, here is a sample XML-RPC
request to a weather service (with the HTTP Headers
<?xml version="1.0" encoding="ISO-8859-1"?>
The request consists of a simple element, which
specifies the method name (getWeather) and any method
parameters (zip code).
Here is a sample XML-RPC response from the weather
<?xml version="1.0" encoding="ISO-8859-1"?>
The response consists of a single element, which
specifies the return value (the current temperature). In
this case, the return value is specified as an integer.
In many ways, XML-RPC is much simpler than SOAP, and
therefore represents the easiest way to get started with
The official XML-RPC specification is available at XML-RPC.com.
Dozens of XML-RPC implementations are available in Perl,
Python, Java, and Ruby. See the XML-RPC home page for a
complete list of implementations.