Web Services: SOAP vs. REST
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.
1 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 re- ferred 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 pro- cedures 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 first described in Roy Fielding’s PhD thesis as an “architec- tural 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 Representational State Transfer (REST)
2.1 REST as an Architectural Style Strictly speaking, REST refers to the architectural style that is described by Fielding’s 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
1 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 defined by Fielding. In the following, we will use the term REST according to the definition given in Fielding’s PhD thesis:
REST provides a set of architectural constraints that, when applied as a whole, em- phasizes scalability of component interactions, generality of interfaces, independent de- ployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. [13, p. 75]
The architectural principles defined by REST have been used by Fielding [15] to guide the design and evolution of the Hypertext Transfer Protocol (HTTP) [14] and Uniform Resource Identifiers (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 isola- tion; hence, a request can be understood without referring to earlier requests. Furthermore, the server’s stateless design simplifies 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 compo- nents, 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 flex- ibility 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 toprovideload-balancingortothesecurecommunicationtotheclientbySSLencryption. 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 differen- tiates REST from other network-based architectures. To attain a uniform interface, REST defines
2 four constraints: “[...] identification 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 identifier. 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 fits the client component. Exchanged messages must be self-descriptive. Self-descriptive means that a message can be pro- cessed 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 re- sources 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 Identifier (URI) [2]. By issuing a URI together with a (generic) HTTP method, for example GET or POST, a client obtains the resource’s 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 func- tionality 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, download- ing Java applets may be prevented for security reasons at organizational boundaries by firewalls.
2.2 REST Web Services REST does not prescribe how Web services should be implemented: In Fielding’s 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 flight booking system that provides a REST-compliant Web service.
3 Example of a REST Web service In this example, the service consumer of a flight booking system searches for a flight, books a flight, modifies the previously made booking, and finally cancels the booking. To search for flights, 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 flights, which is represented by an XML doc- ument. 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
The service consumer could follow a link in response to retrieve further details of a flight. 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 flight number and the name of the customer in the request body: POST /bookings HTTP/1.1 Host: www.flyhigh.com
The server adds the booking to the system’s 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
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 flight number an irrelevant implementation detail).
4 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 modifications in a particular message type and issue this message as a PUT request. Recog- nizing the particular message type, the service implementation can apply the modifications to the resource’s representation. In the previously shown PUT request, the
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 manip- ulated is represented by a resource. Moreover, resources are not hidden from service consumers. Resources are identified by Uniform Resource Identifiers (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 meth- ods: 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 side- effects 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 defined in the HTTP specification allows network elements to handle caching and partial network failures intelligently. REST Web services not only comply with Web standards and the Web’s general architecture [45], they make deliberate use of existing Web technologies. For example, REST Web services make use of HTTP meth- ods, HTTP status codes (to signal success or failure of the service provider), HTTP access authentication (to authenticate service consumers), TLS/SSL (to ensure confidentiality 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 efficiency.
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.
5 Furthermore, REST provides no formal means to specify REST interfaces, which makes it difficult 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 difficult 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 difficult for rich interfaces. Finally, the expressiveness of the PUT request by itself is not sufficient for updating resources as show by our sample application on page 4.
3 SOAP 3.1 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 modifications that make SOAP more compatible to the general architecture of the Web [23], be- came 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 specifications [48] of WS-I, an industry organization that fosters Web services interoperability. While SOAP defines a general framework for message exchange, it is not sufficient for building Web services. A complementary specification, 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 specification) [4]. A practitioner report from the finance industry [49] confirms 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 defines [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 specifies 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 defines 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 efficient, binary representations. Aforementioned rules describe how to build messages that applications exchange in order to interact. Be- sides 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).
6 Figure 1: Structure of a SOAP message.
Messages may be exchanged over any communication protocol; however, HTTP is the only protocol for which SOAP defines a binding. A binding specifies 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 side- effects, 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 specification only defines the response to a request but not the request itself. Furthermore, the usage of the HTTP PUT and DELETE methods are not specified by SOAP. Above parts of the SOAP specification are described abstractly and orthogonally to allow for independent evolution of each part. Moreover, the SOAP specification allows implementors to substitute those parts by other means where appropriate. The only mandatory part of the SOAP specification is the part that specifies 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 in- terface 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 specification 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 Sun’s JAX-RPC implementation) to map operations of a Web service to methods in object-oriented programming languages.
7 Table 1: Elements of a WSDL document. WSDL Element Description Logical service interface: Types Types is a container element where the data types that occur in the WSDL are defined as XML Schema types. Message A message consists of list of named parts; the part’s structure is specified by a type that is declared in the Types element. Operation Similar to methods in programming languages, operations define the actions that a Web service can perform. The Operation element specifies what messages are send to and received from a Web service when the operation is invoked. Port Type Similar to modules in programming languages, a port type groups a set of related operations. Mechanics of the service interface: Binding A binding specifies the protocol for invoking the operations of a spe- cific port type (module). For example, a binding could declare that op- erations are invoked in a document-oriented style according to SOAP Version 1.1. Port A port defines an endpoint to a port type by adding an address, for ex- ample a URL, to a binding. Service 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 finally invoke the Web services. This process is illustrated by Figure 2.
Figure 2: Web services roles, operations and artifacts. Source: [26, p. 7]
8 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 assump- tions 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 pro- vokes 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 specifications 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 efficient middleware technologies such as CORBA; hence, SOAP is less suitable for high performance, distributed applications.
4 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 sufficient [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 specification admitted to him that it was the objective of SOAP’s sponsor to ensure that SOAP becomes so complex that it can only be understood and modified by tools. Unsurprisingly, a great number of Open-source and commercial tools [37] are offered to develop SOAP- based Web services. However, whether tools can counter SOAP’s innate complexity is debatable. Dealing with the complexities of Web services remains a challenge for implementors. To build software solutions that are
9 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 demon- strates 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]. SOAP’s 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]. Specifically, 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 satisfies the demands of e-commerce applications very well. However, REST is less suited for sophisticated B2B interactions that involve multi-step business trans- actions 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-to- end 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 trans- actions, 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, REST’s strengths, Internet-scalability and simplicity, are less important for EAI solutions than for Web applications. In particular, the steep learning-curve to master SOAP’s 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, 32–34]. 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.
5 Related Work
In [16], Fielding describes the abstract model of the World Wide Web’s 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 secu- rity model. Web-calculus allows, for example, confidentiality by URL obfusication.
6 Conclusion
In this paper, we illustrated the fundamentals of REST and SOAP. We clarified 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 specification 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 REST’s 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 application- level 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 identifiers (URI): Generic syntax. Tech- nical 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 architec- ture and its specifications, 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):26–34, 2001. ISSN 1520-9202.
[9] Erik Christensen, Francisco Curbera, Greg Meredith, and Sanjiva Weerawarana. Web services de- scription 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 Weer- awarana. Unraveling the web services web: An introduction to SOAP, WSDL, and UDDI. IEEE Internet Computing, 6(2):86–93, 2002.
[12] N. J. Davies, D. Fensel, and M. Richardson. The future of web services. BT Technology Journal, 22(1): 118–130, 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 407–416, 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):115–150, 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 1–18. 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 proto- col 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 428–437. IEEE Computer Society, 2004.
[25] Christopher Kohlhoff, Ben Boyd Rd, Neutral Bay, and Robert Steele. Evaluating SOAP for high per- formance business applications: Real-time trading systems. In the 12th World Wide Web Conference (alternate track), pages 872–880, April 01 2003.
[26] Heather Kreger. Web services conceptual architecture, 2001. URL www.ibm.com/software/ solutions/webservices/pdf/WSCA.pdf.
[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):19–26, 2004.
[30] Tim O’Reilly. 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): 18–24, 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 93–94, 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. URL http://www.soaprpc.com/ws_ implementations.html.
[38] Pal Takacsi-Nagy. Illuminating the dark side of web services — BEA’s 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):31–50, 2004. ISSN 1532-060X.
[40] Steve Vinoski. WS-nonexistent standards. IEEE Internet Computing, 8(6):94–96, 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 profile version 1.2. Technical report, 2006. URL http://www.ws-i.org/Profiles/BasicProfile-1.2.html. Working Group Draft 2006- 10-03.
[49] Olaf Zimmermann, Sven Milinski, Michael Craes, and Frank Oellermann. Second generation web services-oriented architecture in production in the finance industry. In OOPSLA ’04: Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, pages 283–289, 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 program- ming, systems, languages, and applications, pages 301–312, 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 choreogra- phy standards - the case of REST vs. SOAP. Decision Support Systems, 40(1):9–29, 2005.
14