IBM Submission for the W3C Workshop on Web of Services for Enterprise Computing

Version 0.1 (DRAFT for W3C Enterprise Workshop)

January 9, 2007

Authors: Christopher Ferris, Senior Technical Staff Member; Kelvin Lawrence, Distinguished Engineer, CTO; Tony Storey, IBM Fellow

Acknowledgements: Chris Brealey, Stefan Hepper, Noah Mendelsohn, Mark Phillips, Luciano Resende, Arthur Ryman, Thomas Schaeck

Introduction
Support for REST in SOAP and WSDL
Bringing the Two Worlds Together
Conclusion
References

Introduction

RepresentationalStateTransfer (REST) is the architectural model of the World Wide Web. REST does not itself define the technical building blocks of the Web, such as Uniform Resource Identifiers (URIs), the HTTP protocol, or various media types. Rather, it provides guidelines for the development and use of such technologies in a manner designed to provide the necessary scalability and flexibility for a distributed system of global proportions, such as the World Wide Web. For example, while the Web allows for resources to be named with URIs, REST specifies that every interesting resource should have its own URI name. Every such resource is thus directly “on the Web”, and can be accessed from browsers, cell phones, server applications, etc. can be bookmarked, linked from emails, and so on.

REST is an area of strategic interest for several reasons. First of all, by studying REST, one can learn how to build more effective applications for use on the Web. Secondly, the term “REST” has been used by many within the industry as a metaphor for applications that use Plain Old XML (POX) over HTTP. Such usage has been positioned by some as preferable to the use of SOAP-based Web services, in part, because POX/HTTP is perceived as being easy to program with little or no tooling, as more flexible, and as offering Web-scale integration. As a result, “REST” (more specifically, POX/HTTP) is now seen by some as a competitor to SOAP-based Web services, particularly for the many applications that have modest requirements for security, transactions, portability across transport protocols, and other sophisticated features. Finally, the emergence of so-called AJAX [AJAX] applications, which leverage easy access to Web-based data and graphics to create highly interactive browser-based applications in which data is combined in very flexible ways, has sparked a renewed interest in REST because its architectural constraints can simplify the design of such applications.

However, the apparent perception that REST- and SOAP-based Web services are in competition with one another is unfortunate. In fact, recent versions of SOAP and WSDL have been specifically designed to facilitate RESTful implementations of Web services. Our vision is of a single scalable stack, offering the best of the Web in simple scenarios, and scaling gracefully with the addition of optional extensions when more robust quality of service features are required. Unfortunately, most implementations of Web services today are not implemented in a manner that promotes RESTful usage of Web services. Most Web services IDE environments do not, by default, provide the developer with an option to generate REST style Web services at present (e.g. deploying an endpoint that can be accessed via HTTP GET). Accordingly, users perceive the technologies as being competitive alternatives, and in many cases they are choosing REST style Web services (i.e. POX/HTTP). Publicly available information sources, such as Yahoo!, Google and Amazon, support both models, and they report that up to 85% of users are opting for REST style interfaces.

Web Services are a foundational architecture for both SOA and for IBM's distributed computing products. They bring tremendous value to our customers in circumstances that the Web alone can't directly address. The Web has proven the value of an open, interconnected, worldwide system for information sharing and integration. The question is: when to use one and when to use the other. In fact, our central thesis is that there are important opportunities for synergy.

This paper explains in more detail our view of why REST is important, and it discusses the opportunities that REST presents for SOA. We conclude that REST is important, that the W3C should facilitate, and the Web services community should adopt, an approach that unifies REST and Web services into a single distributed programming model. In short, we believe that the industry must put the “Web” back into “Web services”.

Support for REST in SOAP and WSDL

The initial versions of SOAP and WSDL, SOAP 1.1 and WSDL 1.1, which are both W3C Member Submissions that were submitted by IBM, Microsoft and a host of others, are not aligned with REST (see below), which is a major contributing factor to the current rift between REST proponents and those who advocate the so-called WS-* stack. The new versions, SOAP 1.2 and WSDL 2.0, which are both W3C Recommendation Track specifications, have benefited from input from the Web Architecture community and are as a result more aligned with REST. The adoption of SOAP 1.2 and WSDL 2.0, together with meaningful support for the appropriate features of these specifications in middleware and tools, could result in a unification of the REST and WS-* communities.

SOAP 1.1 and WSDL 1.1

SOAP 1.1 and WSDL 1.1 are not REST friendly. SOAP 1.1 [SOAP11] is in contradiction with the REST principle of Uniform Interface which states that Web resources should support a standard set of HTTP verbs, i.e. GET, POST, PUT, DELETE, etc. The use of HTTP GET [W3C-GET] is recommended for safe, idempotent operations; its use for unsafe operations is prohibited. Web developers appreciate the convenience of GET-based operations which can be invoked using a simple URI. Indeed, a single URI is sufficient to provide access for browsing, for Google crawling, for AJAXapplications, and potentially for SOAP based Web services. For operations that retrieve information from a server without changing server state, GET-based operations can have significant performance advantages since the results can be cached. Since the SOAP 1.1 specification only formally defined the use of POST, there is scant support for the use of the HTTP GET operation in most Web services offerings which makes these offerings unusable for REST-based Web services.

WSDL 1.1 [WSDL11] also has mismatches with REST. WSDL 1.1 makes an attempt to describe REST style Web services by providing binding extensions for HTTP GET and HTTP POST but these are unfortunately deficient. The HTTP GET binding supported URI accessibility, i.e. the input parameters of an operation can be mapped to the URI. However, these bindings have to be applied to every operation in an interface (i.e. a portType). The inability to specify either GET or POST on a per-operation basis means that a logical interface would have to be partitioned into two physical interfaces for the purpose of accurately binding to GET or POST. Instead, HTTP GET and HTTP POST are treated as two equivalent ways of binding an interface.

WSDL 1.1 also fails to support REST URI accessibility for SOAP through its requirement of specifying fixed endpoint URIs (i.e. a <port>) for services. In contrast, REST is based on the assumption that each important resource is assigned its own URI. In practice, these resources are created and destroyed dynamically. For example, in REST, one would model individual flight reservations as resources. Requests to query and update those reservations would be directed to the URI of the reservation. Reservation endpoints could not therefore be published in static WSDL 1.1 documents. Instead, the resource URI is typically returned in response messages of other operations. WSDL 1.1 lacks the ability to describe this type of situation.

In summary, SOAP 1.1 and WSDL 1.1 combined with the tooling in IDEs and runtimes that provided initial support for SOAP and WSDL effectively discouraged the application of the REST architectural style to SOAP based Web services. REST style Web services have emerged as a more Web-friendly alternative to SOAP based Web services.

SOAP 1.2 and WSDL 2.0

When the SOAP 1.1 and WSDL 1.1 W3C Notes entered the W3C Recommendation Track, members of the Web Architecture community sought to remedy the conflicts with REST.

The first notable improvement in SOAP 1.2 is that HTTP GET is supported for requesting a SOAP response. This addition makes it possible to use SOAP in REST style Web services.

WSDL 2.0 also improves the ability to describe REST style Web services. The WSDL 2.0 HTTP binding permits assigning verbs (GET, POST, etc.) on a per-operation basis. Furthermore, WSDL 2.0 defines a new extension attribute that can be used to mark an operation as safe, with the recommendation that safe operations be bound to an HTTP GET request.

Finally, WSDL 2.0 defines two additional extensions that can be used to annotate message schemas and the respective messages they describe that contain references to Web services. This permits the description of dynamically created Web services. For an example of how WSDL 2.0 can describe REST style Web services, with or without SOAP, refer to section 5.3 “Describing Web Service Messages That Refer to Other Web Services” of the WSDL2.0 Primer [WSDL20-Part0].

Endpoint Reference (EPR) v URI

Web Services Resource Transfer (WS-RT) provides Web services with a means of interacting with individual resources behind a service façade that exposed a common interface for the resources. WS-Event Notification provides Web services with publish-subscribe capabilities.

Both of these two emerging standards use WS-Addressing endpoint references (EPR)s to identify resources. In the context of WS-Resource Transfer and WS-Event Notification, the EPR references a resource that has state, much as a URI does a Web resource. Using WS-Resource Transfer, that state can be created, retrieved, updated or deleted, in a manner similar to the REST architectural style, using a uniform interface (CREATE, GET, PUT, DELETE). With WS-Event Notification, the EPR is used to identify a subscription and the consuming endpoints involved.

On the surface, this design would appear to be RESTful. However, because the resource references are EPRs and not simply URIs, there is only limited synergy between the resources in WS-* space and Web space because there is no canonical mapping of an EPR to a URI that could be retrieved using an HTTP GET.

The other potential problem with EPRs as relates to REST is that an EPR is not considered to be an identifier. Unlike the case with URIs, there is no defined means of performing EPR comparison. Given two EPRs, there is no generic way in which one can assert that they are the same.

Of course, this is not an inherent limitation of WS-RF, WS-Transfer or WS-Resource Transfer, because HTTP cookies can also be used to implement a similar design pattern that is inconsistent with REST architectural style principles. The key here would be to limit use of these technologies such that only the address URI of the EPR is the identifier of the resource, in a manner that is consistent with REST.

Uniform Interface

Another aspect of SOAP-based Web services that is frequently noted in the context of discussions of the relative merits of REST versus Web services is that Web services do not impose a uniform interface constraint. Given an arbitrary EPR, unless that EPR supports the WS-Metadata Exchange interfaces, it would be difficult at best to determine how to access the service or resource referenced by that EPR. REST, on the other hand, does impose a uniform interface constraint. Given an arbitrary HTTP scheme URI, any recipient of that URI knows that it can perform an HTTP GET to retrieve a representation of that resource, and that they can create, update and delete that resource using the HTTP PUT, POST and DELETE methods.

With most Web services, the client is generated from the service’s published WSDL. With the exception of the likes of WS-Transfer (and WS-Resource Transfer), every service can expose a unique interface.

The uniform interface constraint permits new resources (or services) to be exposed to the Web such that every deployed client can immediately interact in at least a limited manner with that resource, without need of prior knowledge of that resource. Indeed, Web crawlers are an example of software that can only work if each resource exposes a generic resource: a crawler typically doesn't have any resource-specific information about the resources it's querying. Of course, to fully understand a representation that's returned, or to write code that exploits resource-specific characteristics, one does need some description of the resource. Thus, the debate between Web advocates and Web Services advocates is in part one of emphasis: when is there more value in building to a generic interface that all resources can support, and when is there greater value in artifacts such as WSDL, that facilitate the exploitation of particular resources?

The uniform interface lowers the barriers to entry of a new service significantly. On the day that Google released the Google Maps service, everyone on the planet with a browser could access that service, without the need to deploy or install new client software. At the same time, hundreds of other Web sites, such as Craig's list, were already providing other useful information such as real estate listings in a manner that could be easily accessed using the ubiquitously deployed HTTP Web infrastructure. Within days, new mashup applications that leveraged resources such as Craig's list, "mashing" them into Google Maps, and then republishing those mashed services at new URIs that could also be instantly consumed on a worldwide basis. This was achievable because the names of resources (URIs) could be easily shared, because the infrastructure (HTTP, caches, browser stacks, etc) needed to access those resources was already deployed on a worldwide basis, and because the REST interfaces to the data sources were easy to program in simple scripting languages.

Bringing the Two Worlds Together

Many enterprises have need of exposing services both to machine and human participants. Examples abound, such as the use case in which an OEM exposes its B2B supply-chain interfaces both as a SOAP-based Web services and as a Web forms-based interface for small and medium sized business partners that may have nothing more than a Web browser at their disposal with which to interact with their supply-chain partner. A concrete example of an industry standard that demonstrates this is RosettaNet, which has both a SOAP-based Web services interface as well as a Web forms based interface (RAE). Other industries have need of similar function, such as the automotive industry, that has need to interact with its supply-chain partners in Chinaor other emerging economies.

Healthcare is another industry that has need to expose services both as a SOAP-based Web services and as an HTTP forms-based interface to accommodate a broad range of large to small enterprises as well as individual users. HL7 is working on development of vocabularies that are used both within a SOAP-based Web services context as well as within a Web forms based context.

Clearly, each of these uses would benefit from the ability to deploy a common solution that can satisfy both the machine-to-machine and human interaction modes of access to a service through a single URI, rather than having to resort to deployment of two distinct solutions that share little in common.

Conclusion

It is clear that the REST architectural style has significant merit and is both important and relevant to SOA software offerings. While there has been an increasing influence of REST in some aspects of WS-* Web services, there is still much more that can and should be done to improve upon the potential synergies to restore the Web in Web services. Adoption of SOAP1.2 and WSDL2.0 in both vendor offerings and in deployed Web services will certainly help in this regard. However, it will be important that vendors implement the various extensions that pertain to REST, such as those described above.

As noted in the introduction, our vision is of a single scalable stack, offering the best of the Web in simple scenarios, and scaling gracefully to SOAP based Web services with the addition of optional extensions when more robust quality of service features are required. We believe that the right steps have been taken in the development of some of the more recent WS-* specifications to enable this vision to become reality.

While there are a number vendor and open source offerings that are already providing REST style integration capabilities, there are many more opportunities to integrate REST. We believe that REST should be both well supported, and fully exploited in SOA software offerings.