February 27th and 28th, Bedford, MA.
Author: Peter Lacey
(Mr. Lacey is an employee of the Burton Group. This position paper reflects Mr. Lacey's individual position, and is not the position of his employer.)
The stated mission of the World Wide Web Consortium is To lead the World
Wide Web to its full potential by developing protocols and guidelines that
ensure long-term growth for the Web.
The purpose of this workshop is
to answer the question "can the Web fulfill industry and business
requirements." My position is that the goal of this workshop is at odds
with the mission of the W3C. The W3C should be focusing on technologies
that are universally applicable. Any benefit that the enterprise may
derive from the efforts of the W3C is purely ancillary.
It is well within the W3C's scope to address the need for a "web of services" as such services can be both created and consumed outside of enterprise boundaries. When originally envisioned SOAP web services were expected to address this need, and as such were worthy of the W3C's attention. However, very early on it was apparent to many that SOAP web services were not "of the Web," but instead were simply that latest incarnation of enterprise middleware, and thus only applicable within the enterprise. In the ensuing years the trivial number of SOAP web services that have been exposed to business partners and general consumers, has proven out this position. In fact, the use of web services within the enterprise is also extremely modest, but that is besides the point.
In contrast, there has been a Web-based technology at hand at long as the Web itself has been. It is a technology that achieves true Web scalability. A technology that allows a service to provide both information and (importantly for a web) hyperlinks to related information. A technology that is equally applicable within and without the enterprise.. I am, of course, referring to the Web itself, and in particular to a description of Web-based distributed computing known as REST.
REST is subtle, that fact that HTTP can be used to create a web of services is not immediately obvious to many. Over the years, though, as the failure of SOAP web services becomes more and more apparent, and awareness and use of REST and REST-like services has increased, interest in REST has grown. Even so, the use of the one technology that can provide for a web of services is not what it could be. Furthermore, much misinformation surrounds this technology. The principal reasons for this state of affairs are:
Awareness of REST among developers is limited. Because enterprise developers are not well versed in (or possibly even aware of) REST principles, they continue to struggle with SOAP as the technology of choice for exposing services on the network. Consequently, few web services are made available to the world at large, and even fewer REST-styled services. It is also true, but outside the scope of the W3C, that a terrific number of dollars and man hours is being poured down the SOAP web services drain.
Documented REST design patterns and best practices are extremely limited and not consolidated. Similarly, example code is also scarce. Also, much of what is in place today for enabling and securing the human-centric web makes truly RESTful systems difficult to produce. For example, security infrastructure that allows only HTTP GETs and POSTs, support in HTML forms for only GETs and POSTs, HTTP libraries and servers that are built around session-enabled applications rather than stateless resources.
Additionally, standardization efforts surrounding HTTP and REST-styled systems have stalled. Standards that might prove useful for addressing alternate messaging patterns, providing generally useful media types, and addressing certain limitations in HTTP that inhibit the full potential of a RESTful architecture.
REST is currently suitable for addressing a broad swath of use cases in the realm of distributed computing. It is not suited to addressing all possible use cases, nor should it be. REST need only address the use case inherent in the Web: machine to machine communication that accounts for things such as network latency, evolvability, simplicity, heterogeneity, and hypermedia. The use case of addressing needs particular to the enterprise are not in scope. Nothing in the W3C's efforts for fostering a web of services should be limited to the typical integration challenges of the enterprise or reimplementing enterprise middleware. Should W3C efforts also prove useful for addressing some subset of these issues, so much the better.
It is recommended that the W3C embark on effort to promote and foster REST-styled distributed systems. Such efforts should include evangelism and education. The W3C should compile best practices and create other documentation that enables developers to educate themselves and encourages consistency of design. The W3C should ascertain what gaps currently exist in the standard REST technology stack that can be addressed with additional standardization. The W3C should encourage the development of libraries, tools, and practices that foster the development of a web of services. Finally, the W3C should divorce itself from all efforts that further the technological needs of the enterprise at the expense of the world.