A web service is a software system designed to support interoperable machine-to-machine interaction over a network. Web services are casually described as “Web APIs”  by web service providers such as Flickr, Google, Twitter, etc. Web services can communicate over any choice of network protocol, however, Hypertext Transfer Protocol  (HTTP) over TCP/IP is the de facto standard protocols of choice.

Anatomy of a web service

Web services live on the web, thus requiring at the minimum web server functionality that is capable of sending and receiving HTTP messages. A typical web service accepts an HTTP request from some I/O channel, processes it internally, and outputs an HTTP response, which is sent back to the client. This is done in a loop, until the application is commanded to exit. This does not necessarily mean that the web application speaks HTTP directly: it just means that the web application accepts some kind of representation of an HTTP request.

Web services are implemented following one of four architectures:

1. The web application is contained in an application server. This application server may or may not be able to contain multiple web applications. The application server is then connected to the web server. The web server dispatches requests to the application server, which in turn dispatches requests to the correct web application, in a format that the web application understands. Conversely, HTTP responses outputted by the web application are sent to the application server, which in turn sends them to the web server, and eventually to the HTTP client.

1. The web service is contained in a web server. In this case, the web server acts like an application server. This is the case for PHP applications, on Apache servers with mod_php. Note that this does not necessarily mean that the web service is run inside the same process as the web server: it just means that the web server manages applications.

1. The web application is a web server, and can accept HTTP requests directly. This is the case for the Trac bug tracking system, running in its standalone server. In many setups, such web applications sit behind a different web server, instead of accepting HTTP requests directly. The front-end web server acts like a reverse HTTP proxy.

1. The web application does not speak HTTP directly, but is connected directly to the web server through some communication adapter. CGI, FastCGI and SCGI are good examples of this.

Types of web services

There are two types of web services, big web services and RESTful web services.

These web service types can be differentiated upon inspection of how they answer the following questions:

How does the client convey its intentions (method information) to the server?

Big web services convey method information by passing a XML document which contains elements that indicate the method to be invoked. RESTful web services have the client convey method information using a restricted set of standardized HTTP methods (GET, PUT, POST, DELETE, HEAD, etc).

How does the client convey which part of the data set (scoping information) to operate on?

Big web services convey scoping information the same way they convey method information, passing scoping information in the same XML document. RESTful web services convey scoping information within the Uniform Resource Identifier (URI).

Big web services

Big web services today are generally web services which employ a number of web service specifications, including SOAP, WSLD, UDDI, and the WS-* suite of specifications. Big web services generally have one URI representing the entire service. All method and scoping information is passed with a SOAP message.

SOAP

SOAP stands for simple object access protocol as is a protocol specification for exchanging structured information in web services. SOAP messages are essentially an XML document that is added to the entity-body of an HTTP envelope. SOAP also utilizes XML schemas to govern and restrict the structure of the SOAP XML document, including the document structure and XM-defined standardized data types. SOAP messages are structured as:

<Envelope>

<Header>

</Header>

<Body>

</Body>

</ Envelope>

WSDL

WSDL is an XML based language (adhering to standard and application specific namespaces and schemas) used for describing the interface of a web service. WSDL allows client applications to use code generation tools to generate stub classes based on interpreting the WSDL document. WSDL documents may also include non-functional descriptors to share metadata about the web service. Examples of such non-functional data are QoS, availability, and security considerations.

UDDI

UDDI is a XML based framework for machine-to-machine registry and discovery of web services through the use of a centralized registry. – UDDI registry entries consist of white pages (info about the services owner and contact info), yellow pages (industrial categorizations based on standardized global taxonomies), and green pages (the attached WSDL document). Public UDDI registries on the internet now seem nonexistent after Microsoft, IBM, and SAP chose to close their public UDDI nodes on January, 2006.

WS-* specifications

the WS-* suite of specifications provide added-features to SOAP-based messaging to support reliable messaging, security, addressing, and other features. Additional information about the suite of WS-* specifications can be found at http://www.infoq.com/articles/ws-standards-wcf-bustamante.

RESTful web services

REST stands for representational state transfer, a term coined by Roy Fielding, one of the principle authors of the HTTP specification for versions 1.0 and 1.1. Representational state transfer refers to the transferring of representations of resources on the internet, each expressed with a URI, through a standard uniform interface. RESTful web services conform to REST by using the standard uniform interface provided by HTTP’s set of methods to convey its method information to the server.

Todays web is mostly scattered with RESTful/RPC hybrid web services. These services are mostly RESTful, yet choose to put method information inside the URI and call the same HTTP GET method for any type of method invocation (ex. calling HTTP GET for reading data or deleting that same data).

When writing RESTful web service clients, it is important to find a HTTP library that supports at least the five main HTTP methods, allows for customizing data sent as the entity-body of a PUT or POST request, allows for customizing a HTTP requestʼs headers, and is able to communicate through a HTTP proxy, and supports HTTPS and SSL certificate validation. You will also need an XML or JSON parser depending on what the service uses as a data-interchange format.

Resource-Oriented Architecture (ROA)

The Resource-Oriented Architecture is a RESTful architecture that focuses on providing addressability, statelessness, connectedness, and a uniform interface in a web service implementation and is built on the notion that everything on the web with a URI is a resource:

Addressability - The ability to reference any resource that a web service provides. A resource is anything thats important enough to be referenced as a thing in itself. It is something that can be stored on a computer and represented as a stream of bits. This could be a document, the result of running an algorithm, or the representation of a physical object like an apple.

Statelessness – Every HTTP request happens in complete isolation – All HTTP requests include all information necessary for the server to fulfill the request. Possible states of the service are also resources, and should be addressable and given their own URIs.

Connectedness – Resources should have URI links to close or related resources in an appropriate context for that resource, much in the same way the HTML web works. This allows easy navigation between states, as states are

considered resources and have their own URIs.

Uniform Interface – Use of existing HTTP methods to convey method information on a given resource (GET, PUT, POST, DELETE, etc).

Common data-interchange formats used by web services

Interaction with any web service requires the exchange of data. An application could be receiving a list of names or adding a new name to the same name list that resides on the web service. In one first case, data is being sent from the web service server to the client application. In the second case, data is being sent from the client application to the web service. Today’s web services use structured, open-specification data-interchange formats for providing a uniform interface when providing and parsing through formatted data. The most popular data-interchange formats in use today are EXtensive Markup Language (XML) and JavaScript Object Notation (JSON).

XML

XML is a self-descriptive markup language which shares syntax similar to HTML through the use of tags. The author of a XML document can invent their own tags, using keywords in tags to describe the data they encapsulate. The following is an example of an XML representation of a note from Jani to Tove providing a reminder not to forget him this weekend:

<note>

<to>Tove</to>

<from>Jani</from>

<heading>Reminder</heading>

<body>Don’t forget me this weekend!</body>

</note>

JSON

JSON is a lightweight, self-describing data-interchange format which is quickly gaining popularity due to its simple serialization into a data structure representation. JSON is built on two structures: a collection of key:value pairs (dictionary, hash table) and an ordered list of values (array, vector, list, sequence). The { } bracket pair is a representation of an object, with its representation described as a set of key:value pairs.  The [ ] brackets signify an array of objects, each object separated by a comma delimiter. The following is the JSON representation of the note which we created an XML representation of in the previous section:

{

note:{

to:’Tove’,

from:’Jani’,

heading:’Reminder’,

body:’Don’t forget me this weekend!’

}

}

Web service frameworks

A number of web service frameworks have been created over the past ten years to simplify the development of web services and web applications. Here are some details for three particular web service frameworks which are popular in today’s web service development:

Ruby on Rails

Ruby on Rails is an open-source, Ruby-based web application and web service framework intended to be used to develop web applications and web services rapidly. The Ruby on Rails framework is arguably one of the most popular framework used by developers of today’s modern web applications and web services, praised for its “convention over configuration” philosophy which allows rapid development of web applications and web services through code generation tools and sensible default configurations. Documentation and code examples are plentiful and of high quality.

Restlet

Restlet is an open-source, Java-based web application and web service framework which supports development of both web service client and server applications. Restlet provides no code generation tools and mild amounts of configuration must be done prior to successfully running a web service reachable at a given ip address and port. Documentation and code examples for the Restlet framework are minimal, resulting in greater difficulty for a developer to learn how to use the framework.

Play!

Play! is another Java-based web application and web service framework that seems to have more documentation and code examples compared to the Restlet community. Play! is heavily inspired by the Ruby on Rails framework, with the “convention over configuration” philosophy implemented to simplify the development of web services.

Web service resources

programmableweb.com – A human-readable, searchable and categorized registry of web services which are available on the web today for consumption.

Amazon web services – A free web service hosting service.

Google App Engine – Another free web service hosting service.

References

http://www.w3.org/TR/ws-arch/#whatis
http://www.modrails.com/documentation/Architectural%20overview.html#typical_web_applications
http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration#History
Richardson, Leonard; Ruby, Sam (2007). RESTful Web services. O’Reilly Media.