Web Services Protocols

Abstract

The aim of the Web Service protocols is to provide a means of describing data and behavior in a machine-processable way. Web Services use XML to describe metadata for discovery purposes and to define behaviour, and in general presume that XML documents will be the payload of the messages exchanged. These XML documents are not typically descriptions of resources in the sense that the Web exchanges resource representations, but rather encoded data that can trigger operations and responses from remote hosts. As such, Web Services are akin to distributed object technologies. Indeed, SOAP originally stood for Simple Object Access Protocol and early versions influenced the XML Remote Procedure Call (XML-RPC) specification [195].

This affinity with distributed object approaches, as well as the way in which Web Services use the Web, has meant they have had their detractors, as the quote above demonstrates. The debate between the Web Services community and the Web community led to the so-called SOAP versus REST war that raged from 2002 until roughly 2007 with no outright victor. Currently, in 2008, a mood of sometimes resigned acceptance has fallen on the debate with many authors suggesting that both approaches are suitable for different kinds of systems, in terms of scale, heterogeneity and underlying purpose. Those with reservations about Web Services technologies argue that they go against the grain of the Web, because they do not use its existing infrastructure, such as URIs for identifying resources, and HTTP for modelling behaviour. Instead, SOAP and WSDL define their requirements from scratch and merely use Web technology to expose and transfer these formats. Furthermore, during the period in which a plethora of Web Services specifications were being developed (see Section 16.4 for some of the most salient), many argued that the quantity and their complexity would lead to unmanageable and brittle systems. At the core, this debate was about differences in architectural approaches, in particular between object-orientation, service-orientation and resource-orientation. The abstractions underpinning these architectures and the relationships between them are described in Section 8.4.