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 Web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services.

Examples of web services deployed today are those supported by information utilities such as FedEx, Amazon, eBay, and more.  By using such web services, you can programmatically post a listing on eBay, order a book on Amazon, or schedule a shipment on FedEx.

At a simple level, web services are a remotely invocable operation.  While this has been done several times before (RPC, DCE, CORBA, etc.), web services are a more open and standards-driven version of the concept.

Web services enable what is called a “Service Oriented Architecture“.  We’ve written about this in other postings on this blog.

The Web Services Platform

So what is the web services platform?  The answer is that web services are an application of XML plus HTTP. Let’s review each of these.  HTTP is a ubiquitous protocol, running practically everywhere on the Internet.  XML is all about representation, it provides a metalanguage in which you can describe and communicate specialized content.  Far more descriptive that HTML, XML deals with the data objects rather than the presentation facilities.  Internally, then, the architecture of a web service provider looks like:

This shows how the request comes in, is dispatched and processed, and then the response is generated. 

By using web services, an application may be making calls to a number of back-end services, thus becoming a “composite application”.

Benefits of Web Services

There are several business and technological benefits, including:

• Interoperability
• Flexibility
• Additional delivery platform
• Support for SaaS

Using XML technologies and the ubiquitous HTTP as a transport provides interoperability that spans multiple applications.  As we will see below, the client-side code uses only a definition (or description) of the service in order to invoke it.  These definitions are called WSDL files.  The client is decoupled from needing to know how the other side is implemented. The task of integrating applications and data formats can be carried out far more easily.

Versatility of web services again stems from the decoupling.  They act as smaller “building blocks of functionality” that can be put together in different ways.  They can be invoked by a Web-based client interface, or through code in another application.  A web service can even call another web service.

Web services provide an additional delivery platform for your business.  Rather than having to build out an entire user-oriented front end to your service, it becomes feasible to simply offer the web services based API to your customers.  As we will see in the section at the end on current business use, this is becoming popular.

Nearly all of today’s Software as a Service (SaaS) deployments are based on web services.  In fact, it is really web services and the associated standards that have driven the acceptance of SaaS from a technology point of view.

Web services take advantage of ubiquitous protocols and the web infrastructure, so that the technology investment is reduced.  This is an improvement over the proprietary protocols and technology of earlier solutions.  For instance, much of the development efforts and training can be preserved.

Web Services Protocols

The basic protocol is called SOAP, which is a facility for specifying the operation to be performed and the arguments for the operation.

In the example below, a GetStockPrice request is sent to a server. The request has a StockName parameter, and a Price parameter will be returned in the response. The namespace for the function is defined in “http://www.example.org/stock” address.

POST /InStock HTTP/1.1 Host: http://www.example.org/
   Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope xmlns:soap=http://www.w3.org/2001/12/soap-envelope
       soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:Body xmlns:m="http://www.example.org/stock">  
  <m:GetStockPrice>   
   <m:StockName>IBM</m:StockName>   
  </m:GetStockPrice>
 </soap:Body>
</soap:Envelope>

This shows an example of a web services request, and a response is similarly formatted.  The syntax is all standard XML, while the organization of the tags and elements is specified by SOAP.

Within the protocol are standards for representing complex data types, for representing error results and exceptions, and for specifying optional parts of the content.

Describing Web Services

Most of the examples so far have replied on simple request/response invocations, and simple datatypes in the request and repose objects.  In addition, the examples so far have relied on manual or explicit building of the SOAP objects to be sent or received.

WSDL files provide an interoperability language.  They are similar to those used in COM, CORBA, etc.

A SOAP request to or response from a service is generated according to the services’ WSDL definition. A WSDL document describes a service. It is an XML document that provides information about what the service does, the methods that are available, their parameters, and parameter types. It describes how to communicate with the service in order to generate a request to or decipher a response from the service. The purpose of a WSDL is to completely describe a web service to a client. A WSDL defines where the service is available and what communications protocol is used to talk to the service. It defines everything required to write a program to work with a web service.

Web Services enable a Service-Oriented-Architecture, in which system elements interact with each other, where each one is exporting one or more services.  The services can be fine-grain, like lookup or fetching, or can be entire business processes such as “order validation”.

Also, web services have concepts of description and discovery that were not present (as completely) in the earlier approaches.  These facilities for description are called WSDL files are specifications how to use a given web service.  XML is ubiquitous in the web services area, and in particular, the XML Schema facilities for describing complex data structures.  WSDL uses XML Schema in many areas.

The idea of metadata-driven specification of invocation information allows for interoperability between web service providers and requestors, even on different platforms.  The interoperability stacks are:

• Wire
• Description
• Discovery

Technology for Web Services

We have focused on the Apache Group’s Axis software.  This is an example of an open-source toolkit for implementing the XML message generation and processing, the SOAP protocol, and the service dispatching facilities.  It also has extensions for a variety of other transports upon which web services and XML are used, including e-mail-based.

Starting in late-2007, we switched to Axis2, which offers higher performance.

Business Use of Web Services

The largest users of web services in the commercial area are currently eBay and Amazon.

eBay has supported XML and web services based API’s since around 2000-2001, with an active developer support community.  In fact, by late 2005, 47% of the auction listings on eBay were entered via the web services API rather than stepping through the multi-part auction submission screens.

Amazon has long supported XML and web services for e-Commerce, and starting in 2006 has made web services a major part of efforts to become an e-Commerce information utility.  See their developer pages and notes.

The primary business use case that is enabled by web services is composite applications.  These are applications that make use of back-end facilities from a number of other applications.  Many enterprise applications developed in the last few years are organized this way.

The secondary use case that is enabled is to provide a service with no conventional front end.  For instance, a number of weather, news, and finance sites provide simply XML or RSS outputs.  Another example of this are sites that provide parts catalogs, equipment databases, pricing guides, compatibility/compliance guides, etc.