W3C Workshop on Web of Services Report

In February, the W3C organized a Workshop on the “Web of Services for Enterprise Computing”, chartered to explore the suitability of Web services and Web standards for meeting enterprise software requirements, and what, if anything, needs to be done to improve enterprise support. InfoQ covered the very interesting position papers back then; now, a report summarizing the results has been made available.

Quoting from the summary,

The workshop participants recommended, among other things, that W3C should:

• Ensure the stability of the Core platform of Web Services by maintaining its Web Services specifications through a Web Services Core Working Group
• Facilitate the common accessibility of resources by both Web and Web Service mechanisms
• Help users/vertical industries to specify needs, use cases, best practices guidelines, and architectural patterns for SOA

 

Some of the more interesting quotes include this one, conceding the perceived lack of success of the “Web of services”:

While the Web of documents has succeeded beyond anyone’s wildest imagination, in large part due to the widespread adoption of the standards on which it is based (HTML, HTTP, URI), the Web of services has not achieved equal success, particularly in the enterprise, where it potentially would have its greatest benefits.

But the WS side of things is addresses as well:

Services are being deployed on the Web without the help of SOAP Web services, but they are limited with respect to meeting comprehensive enterprise IT requirements, especially in the area of security.

As is the view that both the Web and the Web services approach have value:

[T]he discussion at the workshop indicated that various organizations are deriving value from both approaches to the problem (Web and WS-*), and in at least one case the same organization (Yahoo) said that they are employing both approaches successfully in different areas of the business.

One of the issues addressed multiple times was XML data binding. Paul Downey, who headed a working group (and whom we’ve talked to about this before), attended the workshop as well, and was happy that there was “much love for the data binding WG”, and the report supports this, but also acknowledges the problems:

The Data Binding Working Group at W3C was started to help with this problem. It is chaired by a user organization, but the WG has failed to achieve critical mass because of a lack of vendor participation. During the workshop, IBM said they did not join because Microsoft had not joined. Other vendors said that without IBM and Microsoft there it was difficult to justify the investment of time and effort on the WG. This is a clear example of the problem. Standards, especially enterprise software standards, are beneficial to the user, but vendors may sometimes have conflicting goals that inhibit market adoption.

In a blog posting shortly after the workshop, WSO2’s (and formerly Microsoft’s) Jonathan Marsh supports this view:

[O]ne of the major pain points in WS-* remains the poor support of XML Schema that is being addressed in the understaffed XML Schema Patterns for Databinding Working Group. A renewed effort to address this customer pain point is essential. I’m confident WSO2 can continue to participate and maybe even step up our work in this critical area, and I hope other vendors who wrongly dismissed the effort as irrelevant after Microsoft didn’t show up will reevaluate their positions.
The consequences of not doing so are to weaken confidence in the description side of WS-* that remains in my mind one of the primary advantages of WS-* over REST. If we can’t do a better job, I think REST and REST description languages such as WADL will gain momentum. That’s not a bad thing in itself, but some healthy competition will keep the architectures competing on their merits rather than their execution.

It’s interesting to see the perspective on the history of the Web and Web services:

Web services specifications include many concepts from the Web architecture and were originally designed to work well with Web technologies. However, the Web services specifications also included concepts and designs to work well with existing enterprise middleware technologies such as RPCs and MOMs, and the implementations of Web services have tended to gravitate toward those concepts and designs rather than toward the more Web friendly parts of the specifications. This is perhaps because implementations have in large part been done by the vendors of those existing technologies. […] Web applications, on the other hand, can be integrated with enterprise applications using raw XML and hand coding of the XML processing. This results in the ultimate loose coupling and provides the most benefit for portability and interoperability, but it places more of the burden for handling the abstraction onto the developer. This tends also to be more like the way the Web works. However, as the presenters from Yahoo noted, developers often object to the additional work involved in raw XML processing, and ask for code generation tools like those available from Web services vendors.

As one of the major challenges, the report points to interoperability:

As the WS-* stack grows and as efforts continue to increase the speed at which new specifications complete their associated standardization processes, the complexity of making everything work together across implementations becomes more daunting.

Also discusses was the issue of a description language for REST:

While it is also generally agreed that Web Services require a significant amount of description beyond what is contained in WSDL, it was also noted that while RESTful applications are termed “self describing,” these would also be well served by additional annotations. The discussion here noted the interest in WADL and the similar suggestion for a “REST DL.” In many cases, these both leverage externally generated metadata, ranging from English prose to structured or unstructured data to a more formal representation in RDF, but all referenced using URIs. URI-identified resources, including service descriptions, also provide a basis for defining orchestration/choreography activities. There is a great deal of interest in following work such as WADL to better understand what is to be accomplished and how rather than pursuing premature standardization.

There was also a number of other needs that were identified, Connectivity of legacy systems to the Web, Service description and support for discovery and versioning, Workflow, Intermediaries, and HTTP authentication.

The report’s conclusion:

During the workshop some of these very different characteristics were delineated that are involved in supporting and maintaining a set of technologies designed for use by a worldwide community of peers and those involved in maintaining a set of technologies for use in a hierarchical, strictly controlled corporate environment.
Inside and outside the firewall are often still two different worlds.

When we asked Gartner’s Nick Gall, who authored one of the more controversial position papers, for his opinion after the workshop, he answered:

I felt that the workshop discussions demonstrated a real desire to reduce the rift between the two “webs” (“http web” and “SOAP web”), but it also exposed the substantial amount of work that will require.