Web Services: SOAP vs.

REST
<author name> (Student number: <number>) November 17, 2006

Abstract It is unanimously believed that Web services will move the Web to its next level by facilitating application to application interaction over the Internet. However, there is no consensus on how Web services should be implemented. Software vendors promote involved tool-chains that are based on SOAP, a W3C standard, as the ideal technology, while a few, but vocal practitioners claim that a simpler approach, called REST, is often more appropriate. In this paper, we investigate the fundamental underpinnings of SOAP and REST. Furthermore, we discuss the applicability of SOAP and REST in different domains.

Introduction

To realize the full potential of the nowadays ubiquitous infrastructure of the Web, it is necessary to extend the scope of the Web beyond human-oriented browsing to include application to application interactions, which are enabled by programmatic interfaces. These programmatic interfaces are referred to as Web services [44]. How these programmatic interfaces should be realized is a matter for, sometimes heated, debates [17]: the debate of SOAP versus REST. SOAP, a W3C standard, which is backed by all majors vendors (including BEA Systems, IBM, Microsoft, and SUN), allows the exchange of information between peers in a decentralized, distributed environment. Moreover, a huge and growing number of protocols [47] enhance SOAP with advanced features such as reliability, security, and transaction support; or standardize application-oriented procedures for complex interactions among businesses. REST, in contrast, is neither a standard nor is it promoted by any vendor. REST, which stands for Representational State Transfer, has been rst described in Roy Fieldings PhD thesis as an architectural style for distributed hypermedia systems [13, p. 4]. Fielding, co-founder of the Apache HTTP Server project and one principal author of the Hypertext Transfer Protocol [14], attributes the ability of the Web to sustain its exponential growth to the principles of the REST architectural style [15]. Hence, it is enticing to apply the same principles to building Web services.

2
2.1

Representational State Transfer (REST)

REST as an Architectural Style

Strictly speaking, REST refers to the architectural style that is described by Fieldings PhD thesis [13]. However, the term is also loosely used to differentiate Web services with sophisticated, SOAP-based programming interfaces from Web services that simply utilize HTTP and XML (or an equivalent

technology) to provide their programming interface; in this sense, the term REST is used [46] even if those Web services do not fully adhere to the architectural style dened by Fielding. In the following, we will use the term REST according to the denition given in Fieldings PhD thesis: REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. [13, p. 75] The architectural principles dened by REST have been used by Fielding [15] to guide the design and evolution of the Hypertext Transfer Protocol (HTTP) [14] and Uniform Resource Identiers (URI) [2] . Moreover, those principles have become an important part of the general architecture of Web [22]. The principles of the REST architectural style consists of [13, section 5.1]: a layered, stateless client/server design with caching of requests; a uniform interface between components; and optionally: code-on-demand support. To illustrate above principles and some of their implications that are mentioned in [13, chapter 3 and 5], we describe them in the context of Web applications. Layered, stateless client/server design and caching Web applications are partitioned in a client component and a server component where the server component provides services to the client component. The client component, for example, could be a Web browser and the server component a Java Servlet running in a Web server, which communicates with the client over the stateless HTTP protocol. REST principles mandate that the server is stateless. Therefore, the server cannot hold any session state, and client requests necessarily contain all information needed to understand a request in isolation; hence, a request can be understood without referring to earlier requests. Furthermore, the servers stateless design simplies its implementation and improves server scalability because the server can release resources after each request. REST allows to insert additional layers between client and server in form of intermediary components, which relay messages and may provide additional services. As a constraint, layers are visible only to their immediate neighbours, thus layers behind the immediate neighbours of a component remain hidden to the component. Consequently, layers are decoupled from each other, and the exibility to deploy and evolve components is increased. Reverse-proxy servers are an example of an intermediary component. A reverse-proxy server can be installed in front of a cluster of Web servers to provide load-balancing or to the secure communication to the client by SSL encryption. Furthermore, intermediary components may cache the result of requests if staleness of data is not an issue. Thus by placing a caching component near the client, the latency perceived by the client can be vastly reduced. An example of a caching component is a (caching) Web proxy. Uniform interface Fielding emphasizes that a uniform interface between components is the key principle that differentiates REST from other network-based architectures. To attain a uniform interface, REST denes

four constraints: [...] identication of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. [13, p. 82]. We discuss these principles in the following: Any kind of information that is offered by a REST interface is represented as a resource. Each resource is addressable by a (global) resource identier. Furthermore, a resource need not refer to a physical resource, but it can also represent an abstract concept which, for example, refers to different physical resources over time such as the latest version of a document. Components manipulate resources by applying a generic set of operations on the representation of a resource. Representations consist of data (that is, a sequence of bytes) and meta data. If a resource has multiple representations such as a document that is available in multiple formats, the server delivers the representation that best ts the client component. Exchanged messages must be self-descriptive. Self-descriptive means that a message can be processed without referring to previous messages or to data that is transferred outside of the message (for example, data contained only in the underlying transport protocol). Finally, REST applications use hypermedia to change application state: A client accesses resources by their representation, which may contain links to (representations of) other resources. By following those links, the application state is transferred from one state to the next. In other words, application state is transferred by following links from one representation to another representation: hence, the name Representational State Transfer. In the context of a Web application, aforementioned constraints can be illustrated as follows: Every resource of the Web application is addressable by a Uniform Resource Identier (URI) [2]. By issuing a URI together with a (generic) HTTP method, for example GET or POST, a client obtains the resources representation or manipulates a resource. For instance, a client could send the server an HTTP GET request to retrieve a journal article as an HTML document and an HTTP POST request to add a comment to the article. Furthermore, the HTML document that represents the article could contain a list of links to other articles; by following one of those links, the client moves to another state. Code-on-demand Code-on-demand support allows adding functionality to clients as needed; hence, the amount of functionality that must be hard-wired in each client can be reduced. This style can be implemented, for example by the inclusion of ECMAScript or Java applets in a Web page. It is, however, an optional constraint of REST because code-on-demand support is not always feasible. For instance, downloading Java applets may be prevented for security reasons at organizational boundaries by rewalls.

2.2

REST Web Services

REST does not prescribe how Web services should be implemented: In Fieldings PhD thesis [13], REST is merely considered as an architectural style that optimizes the characteristics of Internet-scale, distributed hypermedia systems. Yet, numerous articles on the Web [18, 20, 28, 31] provide guidelines for building Web services with REST. To illustrate the REST approach to Web services, we present a conversation between a service consumer and a simple on-line ight booking system that provides a REST-compliant Web service.

Example of a REST Web service In this example, the service consumer of a ight booking system searches for a ight, books a ight, modies the previously made booking, and nally cancels the booking. To search for ights, the service consumer sends an HTTP GET request where the search criteria are supplied as a query string. The actual HTTP request is shown below:
GET /flights?departure=London&arrival=Berlin&date=2006-11-13 HTTP/1.1 Host: www.flyhigh.com The server replies to the HTTP request with a list of matching ights, which is represented by an XML document. The response could be in any format; however, XML is usually preferred as it is a wide-spread format for representing information in human and machine readable manner. HTTP/1.1 200 OK <?xml version="1.0"?> <flight_list xmlns:xlink="http://www.w3.org/1999/xlink"> <flight no="47" time="12:30" xlink:href="http://www.flyhigh.com/flights/47"/> <flight no="64" time="19:30" xlink:href="http://www.flyhigh.com/flights/64"/> </flight_list> The service consumer could follow a link in response to retrieve further details of a ight. However, we assume that the service consumer directly creates a new booking. To create a new booking the service consumer sends a POST request to www.flyhigh.com/bookings that carries the ight number and the name of the customer in the request body: POST /bookings HTTP/1.1 Host: www.flyhigh.com <?xml version="1.0"?> <booking> <flightno>47</flightno> <customer>John Do</customer> </booking> The server adds the booking to the systems database and returns the URI of the created resource. Assuming that the URI of the created booking is www.flyhigh.com/booking/2043, the service consumer sends the following PUT request to the server in order to correct the spelling of the customer name. PUT /bookings/2043 HTTP/1.1 Host: www.flyhigh.com <?xml version="1.0"?> <updated_elements> <new_content select="/booking/customer[0]"> <customer>John Doe</customer> </new_content> </updated_elements> Updating resources with REST can be tricky as the expressiveness of a PUT request by itself is limited. Replacing the complete booking with the body of the PUT request is a simple approach; however, it requires that the service consumer is able to construct a complete representation of the resource. In general, this constraint is unacceptable considering that some elements of a representation may be hidden from the service consumer, or that, the service consumer does not keep track of some elements (for example, the service consumer may consider the ight number an irrelevant implementation detail).

The problem could be solved by breaking up the resource such that the service consumer is able to provide complete representations. This solution, however, complicates the service interface; moreover, if elements of n resources should be updated, n PUT requests must be issued. To avoid those drawbacks, we recommend to describe the modications in a particular message type and issue this message as a PUT request. Recognizing the particular message type, the service implementation can apply the modications to the resources representation. In the previously shown PUT request, the <updated_elements> element indicates that only parts of the booking should be updated. The parts that should be updated are determined by an XPath expression. Hence, this approach allows generically to update any resource that is represented as an XML-document. When the server receives the PUT request, it updates the customers name in systems database and indicates the successful update by replying with status 204 (No Content) (No Content indicates that the HTTP response has no message body). Finally, to cancel the previously modied booking, the service consumer sends a DELETE request to www.flyhigh.com/booking/2043). The server responds by deleting the booking from the systems database and replies with status 204 (No Content) to signal the successful deletion of the booking.

Key traits of REST Web services

The previous example illustrates three key traits of REST-compliant Web services: resource-oriented, stateless interaction; manipulation of resources by a set of generic operations; and simplicity by leveraging existing Web standards. REST Web services are inherently resource-oriented: every entity instance that can be retrieved or manipulated is represented by a resource. Moreover, resources are not hidden from service consumers. Resources are identied by Uniform Resource Identiers (URI), which allow service consumers to address each resource. Additionally, a URI implies the state of a service consumer. Because service providers do not maintain state of service consumers, the state of a service consumer can be restored by simply applying a previously saved URI. Service consumers manipulate resources by a set of generic operations consisting of the four HTTP methods: POST, GET, PUT, and DELETE. These operations are often equated with the Create, Read, Update, and Delete (CRUD) functions that manipulate records in database systems. The meaning of GET (=read) and DELETE (=delete) is obvious, the meaning of POST (=create) and PUT (=update), however, is more subtle as both HTTP methods can create or update resources. The crucial difference between the two methods is that PUT requests must be idempotent (that means sideeffects must not occur as a request is processed more than one time) while POST requests are non-idempotent [14]. Thus, a PUT request may create a previously non-existing resource, but if the same request is issued again, the existing resource must be replaced with the content of the PUT request. The POST method, in contrast, allows to add new resources with each repeated request. Finally, complying with the semantical constraints for HTTP methods as dened in the HTTP specication allows network elements to handle caching and partial network failures intelligently. REST Web services not only comply with Web standards and the Webs general architecture [45], they make deliberate use of existing Web technologies. For example, REST Web services make use of HTTP methods, HTTP status codes (to signal success or failure of the service provider), HTTP access authentication (to authenticate service consumers), TLS/SSL (to ensure condentiality and integrity of representations), XML (to represent information) and so forth. In summary, REST Web services utilize the existing infrastructure of the Web to gain simplicity and efciency.

Limitations of the REST Approach to Web Services

From a practical point of view, the biggest drawback of REST is that it is not even close of becoming a standard for building Web services. Furthermore, REST completely relies on existing Web standards, which, however, were originally designed for interactive web applications and thus lack more advanced features, such as reliable communication or support for distributed transactions; however, these features are, in some cases, indispensable for automated, batch-oriented systems.

Furthermore, REST provides no formal means to specify REST interfaces, which makes it difcult for tools to semi-automatically interact with REST Web services or to generate stub code for accessing REST Web services. Finally, the restriction that the service interface must expressed in terms of resources and a limited set of operations (POST, GET, PUT, and DELETE) bears some drawbacks. First, it is difcult to express the interfaces of activity-oriented applications because an activity-oriented view does not match with the resource-oriented design of REST [36]. Furthermore, the resource-oriented design of REST interfaces implies that REST Web services expose a plethora of resources by URIs. We expect that managing those URIs proves difcult for rich interfaces. Finally, the expressiveness of the PUT request by itself is not sufcient for updating resources as show by our sample application on page 4.

3
3.1

SOAP
SOAP/WSDL

Introduction
The Simple Object Access Protocol (SOAP) provides an XML-based messaging framework to exchange data between peers in a decentralized, distributed environment. SOAP Version 1.1 became widely known in 2000 when the W3C published it as a W3C Note [5]. In 2003, SOAP Version 1.2 [42], an updated version which incorporates modications that make SOAP more compatible to the general architecture of the Web [23], became a W3C Recommendation. However, SOAP Version 1.1 has remained the most widely adopted version as indicated by the pending inclusion of SOAP Version 1.2 in the interoperability specications [48] of WS-I, an industry organization that fosters Web services interoperability. While SOAP denes a general framework for message exchange, it is not sufcient for building Web services. A complementary specication, the Web Services Description Language (WSDL) [9], is needed to describe precisely the interface of Web services. Don Box, an originators of SOAP, once pointed out that SOAP would not make sense without WSDL (or some equivalent specication) [4]. A practitioner report from the nance industry [49] conrms this view. Unsurprisingly, the term SOAP often implies SOAP plus WSDL. In this paper, the term SOAP generally implies usage of SOAP Version 1.1 with WSDL Version 1.1.

Basics of SOAP
SOAP Version 1.1 denes [5]: the general structure for packaging payload data; rules for representing data types that are commonly found in programming languages as XML; conventions for modeling Remote Procedure Calls (RPC) as XML-based messages; and a binding that species how SOAP messages should be exchanged over HTTP. A soap message is a well-formed XML document. As shown in Figure 1, a SOAP message consists of an envelope element, zero or more header elements, and a body element, which encloses the payload data. These elements make up the general structure of SOAP messages. Header elements carry data that may be processed by SOAP intermediaries, that is, applications that reside along the message path between the initial sender and the ultimate receiver of a message. For example, a SOAP intermediary could encrypt the payload of the SOAP message and add a header that informs the receiver of the used encryption algorithm. To facilitate the exchange of data between applications, SOAP Version 1.1 denes rules for representing data types that are commonly found in programming languages as XML (simple types, compound types, and arrays). However, because XML is a verbose data format, SOAP Version 1.2 substitutes XML by the XML Info Set [43], an abstract data set for XML documents allowing for more efcient, binary representations. Aforementioned rules describe how to build messages that applications exchange in order to interact. Besides this message-oriented style, SOAP also supports an RPC-oriented style by providing conventions for mapping a function and its parameters to a message, and exchanging this message to effect a Remote Procedure Call(RPC).

Figure 1: Structure of a SOAP message.

Messages may be exchanged over any communication protocol; however, HTTP is the only protocol for which SOAP denes a binding. A binding species how the communication protocol should be employed to exchange messages. SOAP Version 1.1 always transfers messages by the HTTP POST method even if a request is free of side-effects. Because HTTP intermediaries must assume that POST requests, may have sideeffects, HTTP intermediaries are unable to cache SOAP requests. To better accommodate for the needs of HTTP intermediaries, SOAP Version 1.2 introduces the SOAP Web Method Feature [41, section 6.4 and 7], which allows using the HTTP GET method for side-effect free requests. This feature is, however, limited as the request of a HTTP GET method cannot carry a SOAP message; therefore, the specication only denes the response to a request but not the request itself. Furthermore, the usage of the HTTP PUT and DELETE methods are not specied by SOAP. Above parts of the SOAP specication are described abstractly and orthogonally to allow for independent evolution of each part. Moreover, the SOAP specication allows implementors to substitute those parts by other means where appropriate. The only mandatory part of the SOAP specication is the part that species the general structure for packaging payload data as SOAP messages (that is, the SOAP envelope).

Basics of WSDL
The Web Service Description Language (WSDL) [9] is a de-facto standard for describing service interfaces in XML. To describe a service interface, the provided operations and the messages that are associated with those operations are detailed in a WSDL document. The elements of a WSDL document are described in Table 1. The Types, Message, Operation, and Port Type elements describe the logical properties of a service interface by specifying the set of operations and the structure of the messages that may be exchanged between a service consumer and a service provider when operations are invoked. The deployment details of a service are indicated by the Binding, Port, and Service element. Deployment details are, for example, the URL of the service and the wire format of messages. The wire format of messages is determined by the binding of service. The WSDL specication provides bindings for various protocols including SOAP. A WSDL document describes the syntactic properties of a Web service interface in a machine-readable manner, which allows tools to generate code for Web service invokation. In particular, WSDL allows tools (such Apache Axis, or Suns JAX-RPC implementation) to map operations of a Web service to methods in object-oriented programming languages.

WSDL Element Types Message Operation

Table 1: Elements of a WSDL document. Description

Logical service interface:

Port Type

Types is a container element where the data types that occur in the WSDL are dened as XML Schema types. A message consists of list of named parts; the parts structure is specied by a type that is declared in the Types element. Similar to methods in programming languages, operations dene the actions that a Web service can perform. The Operation element species what messages are send to and received from a Web service when the operation is invoked. Similar to modules in programming languages, a port type groups a set of related operations.
Mechanics of the service interface:

Binding

Port Service

A binding species the protocol for invoking the operations of a specic port type (module). For example, a binding could declare that operations are invoked in a document-oriented style according to SOAP Version 1.1. A port denes an endpoint to a port type by adding an address, for example a URL, to a binding. A service groups a set of related ports. In other words, it groups a set of concrete implementations of a port type (module).

3.2

The Web Service Stack

SOAP enables communication among Web services, and WSDL provides the means to describe formally Web services. These standards form the foundation of Web services; a further standard, Universal Description, Discovery, and Integration (UDDI), which is published by the OASIS consortium, is also considered to be essential to Web services [11]. UDDI allows to set up public Web services directories, which allow service providers to publish their Web services. Service consumers can discover Web services; retrieve their interface description in the WSDL format; and nally invoke the Web services. This process is illustrated by Figure 2.

Figure 2: Web services roles, operations and artifacts. Source: [26, p. 7]

In addition to the Web service core protocols (SOAP, WSDL, and UDDI), a whole stack of protocols has been proposed in order to extend the realm of Web services [7, 40, 47]. Figure 3 shows a logical view of the Web service stack. The layers of the Web service stack address issues such as security, reliable messaging, transaction support, and business process orchestration. Additionally, researchers are currently working on the concept of semantic Web services [12, 21], which will (hopefully) allow autonomous agents to interact intelligently with Web services.

Figure 3: Web services stack. Source: [35, p. 2]

3.3

Limitations of the SOAP Approach to Web Services

SOAP and WSDL do not depend on any other standard except for the XML Infoset, as they make no assumptions about the implementations of Web services. Moreover, other standards can customize SOAP/WSDL and add further services. Hence, SOAP/WSDL seems to have limitless potential. However, the extensibility of SOAP/WSDL also makes these technologies inherently complex and provokes a proliferation of overlapping extensions. The perception that SOAP Web services suffer from too many standards and bear too much complexity is wide-spread [27, 35, 38, 40]. Referring to SOAP Web services, Mockford reported: For some, the apparent lack of stability and coherence in the specications even raises the question of the real long-term viability and value of the technology. [29, p. 1] Finally, in terms of performance, SOAP cannot compete [25] with efcient middleware technologies such as CORBA; hence, SOAP is less suitable for high performance, distributed applications.

Applicability of SOAP Web Services and REST Web Services

Practical differences
For building simple Web services, the greatest practical difference between SOAP and REST is the level of toolkit-support and backing by vendors and standardization bodies. Very few tools exists for REST; however, this is not necessarily a weakness as existing tools are deemed sufcient [28]. In contrast, building SOAP Web services sans tool-support is impractical because WSDL documents are meant to be processed by software tools rather than humans [6, p. 7] and because writing code to construct SOAP messages would be tedious and error prone. Anderson [1] reports that one architect of the SOAP specication admitted to him that it was the objective of SOAPs sponsor to ensure that SOAP becomes so complex that it can only be understood and modied by tools. Unsurprisingly, a great number of Open-source and commercial tools [37] are offered to develop SOAPbased Web services. However, whether tools can counter SOAPs innate complexity is debatable. Dealing with the complexities of Web services remains a challenge for implementors. To build software solutions that are

based on Web services, software developers not only need a general understanding of a plethora of technologies, they also need to know their intricacies [39]. We believe that differences between SOAP and REST stem from the fact that they target different, though overlapping domains.

Applicability
REST is intended for Internet-scale, hypermedia systems. Hence, REST is not designed to 1) abstract from existing technologies; 2) provide rich object-oriented interfaces; or, 3) reduce the application development effort. Consequently, REST is most appealing for Web applications. SOAP, in contrast, seems to be less popular for large-scale e-commerce applications [30]. Rather, it demonstrates potential for sophisticated Business-to-Business (B2B) interactions [50], and it has proved its value as a technology for Enterprise Application Integration (EAI) [8, 39, 49]. SOAPs broad scope inherently increases its complexity as SOAP must account for varied environments with different requirements. E-commerce and B2B applications are distinguished from EAI applications in that transactions are between non-trusted parties, which are performed over high-latency networks and occur less frequently [3]. Specically, e-commerce applications demand scalability and low-barrier of entry in order to attain a large user-base. REST Web services can draw from a large share of (Web) developers because REST is easy to understand and can be used with any development tool alike. Hence, REST satises the demands of e-commerce applications very well. However, REST is less suited for sophisticated B2B interactions that involve multi-step business transactions between cooperating yet untrusting parties. REST provides no standards to coordinate long-running multi-step transactions between trading partners; indeed, it even lacks the technical foundations to establish such standards because it only provides point-to-point communication over HTTP, but does not enable end-toend connectivity over multiple hops, which may employ different transfer protocols. Hence, REST is limited.set of the Web service stack that is build on top of SOAP. Evidently, SOAP is most appropriate for EAI applications, which typically demand: 1) support for transactions, reliably, and asynchronous communication; 2) longevity by standards backup, vendor backup, and maximum platform-independence; 3) maintainability due to encapsulation (in form of object-orientation); and 4) rapid development by tools facilitating the development process. These demands are clearly not meet by REST. Moreover, RESTs strengths, Internet-scalability and simplicity, are less important for EAI solutions than for Web applications. In particular, the steep learning-curve to master SOAPs complex tool-set hardly diminishes its viability as long as the long-term goals of EAI solutions are realized. Finally, SOAP and REST are not considered to be mutually exclusive [19, 3234]. With the introduction of the SOAP Web Method Feature in version 1.2, REST principles can be applied to SOAP Web services . However, it remains to be seen when (or if) SOAP toolkits will allow for a more REST style implementation of SOAP Web services.

Related Work

In [16], Fielding describes the abstract model of the World Wide Webs architecture and the principles of REST, which he developed earlier in his PhD thesis. Interestingly, the paper does not propose REST as a solution for building Web services. [24] presents ARRESTED as an extension of REST. ARRESTED includes additional features, for example asynchronous events and message routing, to accommodate to the needs of decentralized environments. [51] investigates the driving forces that effect standards adoption and the social dimensions that cause standards proliferation. Furthermore, they examine the technical difference of SOAP and REST in the context of Business-to-Business interactions. In contrast, we have assessed the technical differences of SOAP and REST with a focus on the lowest layer of the Web services stack. [32] explains, from the viewpoint of a REST proponent, the philosophical differences between the SOAP and REST approach to Web services. Furthermore, the paper analyses the technical merits of SOAP and REST.

10

[10] presents web-calculus, a generic messaging model that enhances REST with a capability-based security model. Web-calculus allows, for example, condentiality by URL obfusication.

Conclusion

In this paper, we illustrated the fundamentals of REST and SOAP. We claried the term REST in the meaning of an architectural style and in the meaning of a simple approach for building Web services using HTTP and XML. Furthermore, we explained SOAP in terms of a specication for message exchange, but we argued that SOAP commonly implies SOAP plus WSDL or even the whole stack of Web service protocols. We showed that RESTs key strengths, Internet scalability and simplicity, makes it particularly appropriate for e-commerce applications. For Business to business scenarios, REST is suitable if those scenarios are simple. Solutions for involved scenarios mandate the use of SOAP because those solutions demand the applicationlevel protocols provided by the Web service stack. Finally, we argued that SOAP is most suited for Enterprise Application Integration (EAI).

References
[1] Tim Anderson. Ws-* vs the rest, 2006. [2] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform resource identiers (URI): Generic syntax. Technical report, 1998. URL http://www.ietf.org/rfc/rfc2396.txt. RFC 2396. [3] Tim Berners-Lee. Web architecture from 50,000 feet, 1998. URL http://www.w3.org/DesignIssues/ Architecture.html. [4] Don Box. A brief history of SOAP, 2001. URL http://webservices.xml.com/pub/a/ws/2001/04/ 04/soap.html. [5] Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Frystyk Nielsen, Satish Thatte, and Dave Winer. Simple object access protocol (SOAP) 1.1. Technical report, W3C, 2000. URL http://www.w3.org/TR/2000/NOTE-SOAP-20000508. W3C Note 08 May 2000. [6] Jan Christian Bryne, , and Anders Lanzen Computational Biology Unit. Web services tutorial, 2006. URL www.csc.fi/molbio/opetus/embrace/presentations/WS/Compendium.pdf. [7] Luis Felipe Cabrera, Christopher Kurt, and Don Box. An introduction to the web services architecture and its specications, 2004. URL http://msdn2.microsoft.com/en-us/library/ms996441(d= printer).aspx. [8] Timothy M. Chester. Cross-platform integration with XML and SOAP. IT Professional, 3(5):2634, 2001. ISSN 1520-9202. [9] Erik Christensen, Francisco Curbera, Greg Meredith, and Sanjiva Weerawarana. Web services description language (WSDL) 1.1. Technical report, 2001. URL http://www.w3.org/TR/2000/ NOTE-SOAP-20000508. W3C Note 15 March 2001. [10] Tyler Close. web-calculus, 2005. URL http://www.waterken.com/dev/Web/Calculus/. [11] Francisco Curbera, Matthew Duftler, Rania Khalaf, William Nagy, Nirmal Mukhi, and Sanjiva Weerawarana. Unraveling the web services web: An introduction to SOAP, WSDL, and UDDI. IEEE Internet Computing, 6(2):8693, 2002. [12] N. J. Davies, D. Fensel, and M. Richardson. The future of web services. BT Technology Journal, 22(1): 118130, 2004. ISSN 1358-3948.

11

[13] R. Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of Califormia, Irvine, USA, 2000. [14] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee. Hypertext transfer protocol HTTP/1.1. RFC 2068, Internet Engineering Task Force, January 1997. URL http://www.ietf.org/rfc/rfc2616. txt. [15] Roy T. Fielding and Richard N. Taylor. Principled design of the modern web architecture. In ICSE 00: Proceedings of the 22nd international conference on Software engineering, pages 407416, New York, NY, USA, 2000. ACM Press. ISBN 1-58113-206-9. [16] Roy T. Fielding and Richard N. Taylor. Principled design of the modern web architecture. ACM Trans. Inter. Tech., 2(2):115150, 2002. ISSN 1533-5399. [17] Greg Goth. Critics say web services need a REST. IEEE Distributed Systems Online, 5(12), 2004. [18] Joe Gregorio. How to create a REST protocol, 2004. URL http://www.xml.com/pub/a/2004/12/01/ restful-web.html. [19] Hugo Haas. Reconciling web services and REST services. In 2005 IEEE European Conference on Web Services (ECOWS 2005), 2005. URL http://www.w3.org/2005/Talks/1115-hh-k-ecows/. Keynote. [20] Hao He. Implementing REST web services: Best practices and guidelines, 2004. URL http://www. xml.com/pub/a/2004/08/11/rest.html. [21] Michael N. Huhns. Software agents: The future of web services. In Agent Technologies, Infrastructures, Tools, and Applications for E-Services, volume 2592 of Lecture Notes in Computer Science, pages 118. Springer, 2002. [22] Ian Jacobs and Norman Walsh. Architecture of the world wide web, volume one. W3C recommendation, W3C, 2004. URL http://www.w3.org/TR/2004/REC-webarch-20041215/. [23] Mario Jeckle and Erik Wilde. Identical principles, higher layers: Modeling web services as protocol stack, May 25 2004. URL http://citeseer.ist.psu.edu/658108.html;http://dret.net/ netdret/docs/wilde-xmleurope2004.pdf. [24] Rohit Khare and Richard N. Taylor. Extending the representational state transfer (REST) architectural style for decentralized systems. In ICSE, pages 428437. IEEE Computer Society, 2004. [25] Christopher Kohlhoff, Ben Boyd Rd, Neutral Bay, and Robert Steele. Evaluating SOAP for high performance business applications: Real-time trading systems. In the 12th World Wide Web Conference (alternate track), pages 872880, April 01 2003. [26] Heather Kreger. Web services conceptual architecture, 2001. solutions/webservices/pdf/WSCA.pdf. URL www.ibm.com/software/

[27] Joe McKendrick. Web services standards: 60 and counting, 2006. URL http://blogs.zdnet.com/ service-oriented/?p=553. [28] Robert McMillan. A RESTful approach to web services, 2003. URL http://www.networkworld.com/ ee/2003/eerest.html?page=1. [29] K Mockford. Web services architecture. BT Technology Journal, 22(1):1926, 2004. [30] Tim OReilly. REST vs. SOAP at Amazon, 2003. URL http://www.oreillynet.com/lpt/wlg/3005. [31] Paul Prescod. REST and the real world, 2002. URL http://www.xml.com/pub/a/ws/2002/02/20/ rest.html.

12

[32] Paul Prescod. Roots of the REST/SOAP debate. In Extreme Markup Languages 2002, 2003. URL www.idealliance.org/papers/extreme/Proceedings/xslfo-pdf/2002/Prescod01/ EML2002Prescod01.pdf. [33] Sam Ruby. Rest + soap, 2002. URL http://radio.weblogs.com/0101679/stories/2002/07/20/ restSoap.html. [34] Xuan Shi. Sharing service semantics using SOAP-based and REST web services. IT Professional, 8(2): 1824, 2006. ISSN 1520-9202. [35] Flavio Oliveira Silva and Pedro Frosi Rosa. The quest for the web services stack: a fast trip. In ICWE 06: Proceedings of the 6th international conference on Web engineering, pages 9394, New York, NY, USA, 2006. ACM Press. ISBN 1-59593-352-2. [36] James Snel. Resource-oriented vs. activity-oriented web services, 2004. URL http://www-128.ibm. com/developerworks/library/ws-restvsoap/. [37] Soaprpc.com. Web service implementations, 2006. implementations.html. URL http://www.soaprpc.com/ws_

[38] Pal Takacsi-Nagy. Illuminating the dark side of web services BEAs view, 2003. [39] S. Tilley, J. Gerdes, T. Hamilton, S. Huang, H. Mueller, D. Smith, and K. Wong. On the business value and technical challenges of adopting web services. J. Softw. Maint. Evol., 16(1-2):3150, 2004. ISSN 1532-060X. [40] Steve Vinoski. WS-nonexistent standards. IEEE Internet Computing, 8(6):9496, 2004. [41] W3C. SOAP version 1.2 part 2: Adjuncts. Technical report, 2003. URL http://www.w3.org/TR/2003/ REC-soap12-part2-20030624/. W3C Recommendation 24 June 2003. [42] W3C. SOAP version 1.2 part 0: Primer. Technical report, 2003. URL http://www.w3.org/TR/2003/ REC-soap12-part0-20030624/. W3C Recommendation 24 June 2003. [43] W3C. XML information set (second edition). Technical report, 2004. URL http://www.w3.org/TR/ xml-infoset/. W3C Recommendation 4 February 2004. [44] W3C. Web services activity, 2006. URL http://www.w3.org/2002/ws/. [45] Norman Walsh and Ian Jacobs. Architecture of the world wide web, volume one. W3C recommendation, W3C, December 2004. http://www.w3.org/TR/2004/REC-webarch-20041215/. [46] Wikipedia. Representational state transfer Wikipedia, the free encyclopedia, 2006. URL http: //en.wikipedia.org/w/index.php?title=Representational_State_Transfer&direction= prev&oldid=86781002. [47] Lawrence Wilkes. The web services protocol stack, 2005. URL http://roadmap.cbdiforum.com/ reports/protocols/index.php. [48] The Web Services-Interoperability Organization (WS-I). WS-I basic prole version 1.2. Technical report, 2006. URL http://www.ws-i.org/Profiles/BasicProfile-1.2.html. Working Group Draft 200610-03. [49] Olaf Zimmermann, Sven Milinski, Michael Craes, and Frank Oellermann. Second generation web services-oriented architecture in production in the nance industry. In OOPSLA 04: Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, pages 283289, New York, NY, USA, 2004. ACM Press. ISBN 1-58113-833-4.

13

[50] Olaf Zimmermann, Vadim Doubrovski, Jonas Grundler, and Kerard Hogg. Service-oriented architecture and business process choreography in an order management scenario: rationale, concepts, lessons learned. In OOPSLA 05: Companion to the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pages 301312, New York, NY, USA, 2005. ACM Press. ISBN 1-59593-193-7. [51] Michael zur Muehlen, Jeffrey V. Nickerson, and Keith D. Swenson. Developing web services choreography standards - the case of REST vs. SOAP. Decision Support Systems, 40(1):929, 2005.

14