Web Services: SOAP vs. REST

Web Services: SOAP vs. REST(Studentnumber: )November 17, 2006AbstractIt is unanimously believed that Web services will move the Web to its next level by facilitatingapplication to application interaction over the Internet. However, there is no consensus on howWeb services should be implemented. Software vendors promote involved tool-chains that arebased on SOAP, a W3C standard, as the ideal technology, while a few, but vocal practitionersclaim 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 IntroductionTo realize the full potential of the nowadays ubiquitous infrastructure of the Web, it is necessary toextend the scope of the Web beyond human-oriented browsing to include application to applicationinteractions, which are enabled by programmatic interfaces. These programmatic interfaces are referredto 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, distributedenvironment. Moreover, a huge and growing number of protocols [47] enhance SOAP with advancedfeatures such as reliability, security, and transaction support; or standardize application-oriented proceduresfor complex interactions among businesses.REST, in contrast, is neither a standard nor is it promoted by any vendor. REST, which stands forRepresentational State Transfer, has been first described in Roy Fielding’s PhD thesis as an “architecturalstyle for distributed hypermedia systems” [13, p. 4]. Fielding, co-founder of the Apache HTTPServer project and one principal author of the Hypertext Transfer Protocol [14], attributes the abilityof 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 StyleStrictly 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-basedprogramming interfaces from Web services that simply utilize HTTP and XML (or an equivalent1

technology) to provide their programming interface; in this sense, the term REST is used [46] even ifthose 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, emphasizesscalability of component interactions, generality of interfaces, independent deploymentof 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 andevolution 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 3and 5], we describe them in the context of Web applications.Layered, stateless client/server design and cachingWeb applications are partitioned in a client component and a server component where the servercomponent provides services to the client component. The client component, for example, could be aWeb browser and the server component a Java Servlet running in a Web server, which communicateswith the client over the stateless HTTP protocol.REST principles mandate that the server is stateless. Therefore, the server cannot hold any sessionstate, 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 server’sstateless design simplifies its implementation and improves server scalability because the server canrelease 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 visibleonly to their immediate neighbours, thus layers behind the immediate neighbours of a componentremain hidden to the component. Consequently, layers are decoupled from each other, and the flexibilityto deploy and evolve components is increased. Reverse-proxy servers are an example of anintermediary component. A reverse-proxy server can be installed in front of a cluster of Web serverstoprovideload-balancingortothesecure communication to the client by SSL encryption.Furthermore, intermediary components may cache the result of requests if staleness of data is notan issue. Thus by placing a caching component near the client, the latency perceived by the client canbe vastly reduced. An example of a caching component is a (caching) Web proxy.Uniform interfaceFielding emphasizes that a uniform interface between components is the key principle that differentiatesREST from other network-based architectures. To attain a uniform interface, REST defines2

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 RESTinterface 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 abstractconcept which, for example, refers to different physical resources over time such as the latest versionof a document.Components manipulate resources by applying a generic set of operations on the representationof a resource. Representations consist of data (that is, a sequence of bytes) and meta data. If aresource has multiple representations such as a document that is available in multiple formats, theserver delivers the representation that best fits the client component.Exchanged messages must be self-descriptive. Self-descriptive means that a message can be processedwithout referring to previous messages or to data that is transferred outside of the message (forexample, data contained only in the underlying transport protocol).Finally, REST applications use hypermedia to change application state: A client accesses resourcesby their representation, which may contain links to (representations of) other resources. Byfollowing 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]. Byissuing a URI together with a (generic) HTTP method, for example GET or POST, a client obtainsthe resource’s representation or manipulates a resource. For instance, a client could send the server anHTTP GET request to retrieve a journal article as an HTML document and an HTTP POST requestto add a comment to the article. Furthermore, the HTML document that represents the article couldcontain a list of links to other articles; by following one of those links, the client moves to anotherstate.Code-on-demandCode-on-demand support allows adding functionality to clients as needed; hence, the amount of functionalitythat must be “hard-wired” in each client can be reduced. This style can be implemented, forexample by the inclusion of ECMAScript or Java applets in a Web page. It is, however, an optionalconstraint of REST because code-on-demand support is not always feasible. For instance, downloadingJava applets may be prevented for security reasons at organizational boundaries by firewalls.2.2 REST Web ServicesREST 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 guidelinesfor building Web services with REST. To illustrate the REST approach to Web services, we present aconversation between a service consumer and a simple on-line flight booking system that provides aREST-compliant Web service.3

The problem could be solved by breaking up the resource such that the service consumer is able to providecomplete representations. This solution, however, complicates the service interface; moreover, if elements ofn resources should be updated, n PUT requests must be issued. To avoid those drawbacks, we recommendto describe the modifications in a particular message type and issue this message as a PUT request. Recognizingthe particular message type, the service implementation can apply the modifications to the resource’srepresentation.In the previously shown PUT request, the element indicates that only parts of thebooking 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 customer’s name in system’s database and indicatesthe successful update by replying with status 204 (No Content) (’No Content’ indicates that the HTTPresponse has no message body).Finally, to cancel the previously modified booking, the service consumer sends a DELETE request towww.flyhigh.com/booking/2043). The server responds by deleting the booking from the system’s databaseand replies with status 204 (No Content) to signal the successful deletion of the booking.Key traits of REST Web servicesThe previous example illustrates three key traits of REST-compliant Web services: resource-oriented, statelessinteraction; manipulation of resources by a set of generic operations; and simplicity by leveraging existing Webstandards.REST Web services are inherently resource-oriented: every entity instance that can be retrieved or manipulatedis represented by a resource. Moreover, resources are not hidden from service consumers. Resourcesare 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 ofservice 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) andDELETE (=delete) is obvious, the meaning of POST (=create) and PUT (=update), however, is more subtle asboth HTTP methods can create or update resources.The crucial difference between the two methods is that PUT requests must be idempotent (that means sideeffectsmust 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 constraintsfor HTTP methods as defined in the HTTP specification allows network elements to handle caching and partialnetwork failures intelligently.REST Web services not only comply with Web standards and the Web’s general architecture [45], theymake 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 (toauthenticate service consumers), TLS/SSL (to ensure confidentiality and integrity of representations), XML (torepresent information) and so forth. In summary, REST Web services utilize the existing infrastructure of theWeb to gain simplicity and efficiency.Limitations of the REST Approach to Web ServicesFrom a practical point of view, the biggest drawback of REST is that it is not even close of becoming a standardfor 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 reliablecommunication or support for distributed transactions; however, these features are, in some cases, indispensablefor automated, batch-oriented systems.5

Furthermore, REST provides no formal means to specify REST interfaces, which makes it difficult fortools to semi-automatically interact with REST Web services or to generate stub code for accessing REST Webservices.Finally, the restriction that the service interface must expressed in terms of resources and a limited set ofoperations (POST, GET, PUT, and DELETE) bears some drawbacks. First, it is difficult to express the interfacesof activity-oriented applications because an activity-oriented view does not match with the resource-orienteddesign of REST [36]. Furthermore, the resource-oriented design of REST interfaces implies that REST Webservices expose a plethora of resources by URIs. We expect that managing those URIs proves difficult for richinterfaces. Finally, the expressiveness of the PUT request by itself is not sufficient for updating resources asshow by our sample application on page 4.3 SOAP3.1 SOAP/WSDLIntroductionThe Simple Object Access Protocol (SOAP) provides an XML-based messaging framework to exchange databetween peers in a decentralized, distributed environment. SOAP Version 1.1 became widely known in 2000when the W3C published it as a W3C Note [5]. In 2003, SOAP Version 1.2 [42], an updated version whichincorporates modifications that make SOAP more compatible to the general architecture of the Web [23], becamea W3C Recommendation. However, SOAP Version 1.1 has remained the most widely adopted version asindicated by the pending inclusion of SOAP Version 1.2 in the interoperability specifications [48] of WS-I, anindustry organization that fosters Web services interoperability.While SOAP defines a general framework for message exchange, it is not sufficient for building Webservices. A complementary specification, the Web Services Description Language (WSDL) [9], is needed todescribe precisely the interface of Web services. Don Box, an originators of SOAP, once pointed out that SOAPwould not make sense without WSDL (or some equivalent specification) [4]. A practitioner report from thefinance industry [49] confirms this view. Unsurprisingly, the term SOAP often implies SOAP plus WSDL. Inthis paper, the term SOAP generally implies usage of SOAP Version 1.1 with WSDL Version 1.1.Basics of SOAPSOAP Version 1.1 defines [5]: the general structure for packaging payload data; rules for representing data typesthat are commonly found in programming languages as XML; conventions for modeling Remote ProcedureCalls (RPC) as XML-based messages; and a binding that specifies how SOAP messages should be exchangedover HTTP.A soap message is a well-formed XML document. As shown in Figure 1, a SOAP message consists of anenvelope element, zero or more header elements, and a body element, which encloses the payload data. Theseelements make up the general structure of SOAP messages.Header elements carry data that may be processed by SOAP intermediaries, that is, applications that residealong the message path between the initial sender and the ultimate receiver of a message. For example, a SOAPintermediary could encrypt the payload of the SOAP message and add a header that informs the receiver of theused encryption algorithm.To facilitate the exchange of data between applications, SOAP Version 1.1 defines rules for representingdata types that are commonly found in programming languages as XML (simple types, compound types, andarrays). However, because XML is a verbose data format, SOAP Version 1.2 substitutes XML by the XML InfoSet [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. Besidesthis message-oriented style, SOAP also supports an RPC-oriented style by providing conventions formapping a function and its parameters to a message, and exchanging this message to effect a Remote ProcedureCall(RPC).6

Figure 1: Structure of a SOAP message.Messages may be exchanged over any communication protocol; however, HTTP is the only protocol forwhich SOAP defines a binding. A binding specifies how the communication protocol should be employedto exchange messages. SOAP Version 1.1 always transfers messages by the HTTP POST method even if arequest 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 ofHTTP 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 asthe request of a HTTP GET method cannot carry a SOAP message; therefore, the specification only defines theresponse to a request but not the request itself. Furthermore, the usage of the HTTP PUT and DELETE methodsare not specified by SOAP.Above parts of the SOAP specification are described abstractly and orthogonally to allow for independentevolution of each part. Moreover, the SOAP specification allows implementors to substitute those parts byother means where appropriate. The only mandatory part of the SOAP specification is the part that specifies thegeneral structure for packaging payload data as SOAP messages (that is, the SOAP envelope).Basics of WSDLThe Web Service Description Language (WSDL) [9] is a de-facto standard for describing service interfaces inXML. To describe a service interface, the provided operations and the messages that are associated with thoseoperations 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 interfaceby specifying the set of operations and the structure of the messages that may be exchanged betweena service consumer and a service provider when operations are invoked. The deployment details of a serviceare indicated by the Binding, Port, and Service element. Deployment details are, for example, the URL of theservice 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-readablemanner, 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 inobject-oriented programming languages.7

WSDL ElementTypesMessageOperationPort TypeBindingPortServiceTable 1: Elements of a WSDL document.DescriptionLogical service interface:Types is a container element where the data types that occur in theWSDL are defined as XML Schema types.A message consists of list of named parts; the part’s structure is specifiedby a type that is declared in the Types element.Similar to methods in programming languages, operations define theactions that a Web service can perform. The Operation element specifieswhat messages are send to and received from a Web service when theoperation is invoked.Similar to modules in programming languages, a port type groups a setof related operations.Mechanics of the service interface:A binding specifies the protocol for invoking the operations of a specificport type (module). For example, a binding could declare that operationsare invoked in a document-oriented style according to SOAPVersion 1.1.A port defines an endpoint to a port type by adding an address, for examplea URL, to a binding.A service groups a set of related ports. In other words, it groups a set ofconcrete implementations of a port type (module).3.2 The Web Service StackSOAP enables communication among Web services, and WSDL provides the means to describe formally Webservices. 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 beessential to Web services [11].UDDI allows to set up public Web services directories, which allow service providers to publish their Webservices. 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 hasbeen proposed in order to extend the realm of Web services [7, 40, 47]. Figure 3 shows a logical view of theWeb 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 onthe concept of semantic Web services [12, 21], which will (hopefully) allow autonomous agents to interactintelligently with Web services.Figure 3: Web services stack. Source: [35, p. 2]3.3 Limitations of the SOAP Approach to Web ServicesSOAP and WSDL do not depend on any other standard except for the XML Infoset, as they make no assumptionsabout the implementations of Web services. Moreover, other standards can customize SOAP/WSDL andadd further services. Hence, SOAP/WSDL seems to have limitless potential.However, the extensibility of SOAP/WSDL also makes these technologies inherently complex and provokesa proliferation of overlapping extensions. The perception that SOAP Web services suffer from too manystandards 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 thequestion 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 suchas CORBA; hence, SOAP is less suitable for high performance, distributed applications.4 Applicability of SOAP Web Services and REST Web ServicesPractical differencesFor building simple Web services, the greatest practical difference between SOAP and REST is the level oftoolkit-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 SOAPWeb services sans tool-support is impractical because WSDL documents are meant to be processed by softwaretools rather than humans [6, p. 7] and because writing code to construct SOAP messages would be tediousand error prone. Anderson [1] reports that one architect of the SOAP specification admitted to him that it wasthe objective of SOAP’s sponsor to ensure that SOAP becomes so complex that it can only be understood andmodified by tools.Unsurprisingly, a great number of Open-source and commercial tools [37] are offered to develop SOAPbasedWeb services. However, whether tools can counter SOAP’s innate complexity is debatable. Dealing withthe complexities of Web services remains a challenge for implementors. To build software solutions that are9

ased 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, thoughoverlapping domains.ApplicabilityREST is intended for Internet-scale, hypermedia systems. Hence, REST is not designed to 1) abstract fromexisting technologies; 2) provide rich object-oriented interfaces; or, 3) reduce the application developmenteffort. 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 demonstratespotential for sophisticated Business-to-Business (B2B) interactions [50], and it has proved its value as atechnology for Enterprise Application Integration (EAI) [8, 39, 49]. SOAP’s broad scope inherently increasesits 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 betweennon-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. RESTWeb services can draw from a large share of (Web) developers because REST is easy to understand and canbe used with any development tool alike. Hence, REST satisfies the demands of e-commerce applications verywell.However, REST is less suited for sophisticated B2B interactions that involve multi-step business transactionsbetween cooperating yet untrusting parties. REST provides no standards to coordinate long-runningmulti-step transactions between trading partners; indeed, it even lacks the technical foundations to establishsuch standards because it only provides point-to-point communication over HTTP, but does not enable end-toendconnectivity over multiple hops, which may employ different transfer protocols. Hence, REST is limited.setof 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, andmaximum platform-independence; 3) maintainability due to encapsulation (in form of object-orientation); and4) rapid development by tools facilitating the development process. These demands are clearly not meet byREST. Moreover, REST’s strengths, Internet-scalability and simplicity, are less important for EAI solutionsthan for Web applications. In particular, the steep learning-curve to master SOAP’s complex tool-set hardlydiminishes 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 introductionof 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 ofSOAP Web services.5 Related WorkIn [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 forbuilding Web services.[24] presents ARRESTED as an extension of REST. ARRESTED includes additional features, for exampleasynchronous 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 causestandards proliferation. Furthermore, they examine the technical difference of SOAP and REST in the contextof Business-to-Business interactions. In contrast, we have assessed the technical differences of SOAP andREST 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 SOAPand 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 securitymodel. Web-calculus allows, for example, confidentiality by URL obfusication.6 ConclusionIn this paper, we illustrated the fundamentals of REST and SOAP. We clarified the term REST in the meaningof an architectural style and in the meaning of a simple approach for building Web services using HTTP andXML. Furthermore, we explained SOAP in terms of a specification for message exchange, but we argued thatSOAP 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 appropriatefor 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 applicationlevelprotocols provided by the Web service stack. Finally, we argued that SOAP is most suited for EnterpriseApplication 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. Technicalreport, 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 FrystykNielsen, 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. URLwww.csc.fi/molbio/opetus/embrace/presentations/WS/Compendium.pdf.[7] Luis Felipe Cabrera, Christopher Kurt, and Don Box. An introduction to the web services architectureand 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 descriptionlanguage (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 InternetComputing, 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 WebServices (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 protocolstack, 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) architecturalstyle 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 performancebusiness 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 valueand technical challenges of adopting web services. J. Softw. Maint. Evol., 16(1-2):31–50, 2004. ISSN1532-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 webservices-oriented architecture in production in the finance industry. In OOPSLA ’04: Companion tothe 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, andapplications, 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 architectureand 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 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 choreographystandards - the case of REST vs. SOAP. Decision Support Systems, 40(1):9–29, 2005.14