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.
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.
Bridges not walls
Thanks a lot for the great summary. I think you picked out most of the highlights. One thing I'd like to add is to mention that the workshop included several discussions on how to best combine REST and SOAP based approaches to Web services. One of the more interesting to me is described Noah Mendelsohn's paper, which he presented on behalf of the W3C Technical Architecture Group (the group that also wrote the Web Architecture document).
Noah's recommendation was to consider modeling Web resources both as a simple Web resource and also as a more complex resource using WSDL. The example he uses is printer management, in which the simple operations such as GET status and POST a file to be printed are handled using straightforward Web operations, while more complicated management operations are handled using WSDL defined operations, such as clear print queue, set printer defaults, set printer security, etc.
Re: Bridges not walls
Considering the TAG document, I was puzzled even when I read it -- it seems to me that it makes a very unconvincing case for not sticking with REST.
But even I am tiring of the REST/WS debate, and I hope future efforts wil focus on constructive improvements ...
Re: Bridges not walls
I think all the points you may be looking for were raised during the discussion. Have a check of the minutes when you get a chance.
It was not a debate about REST vs SOAP, although I think some of the attendees might have wished it to be.
It was chartered to examine enterprise IT requirements and evaluate how well the Web of Services was meeting them. We looked at both WS-* and REST in the context of enterprise IT requirements, based on the assumption that there would be considerable benefit from standardizing IT environments.
The report is attempting to capture the results rather than indicate agreement or disagreement. Nor was it necessarily a goal to gain agreement that one approach was better than another.
Presenters said that they were getting value out of both appoaches. In the case of Yahoo the same presenter said this - Yahoo is currently using both REST and SOAP based Web services successfully. The presenters may have tended to favor REST but once again this was not the real question.
As usual the debate cannot be settled in the abstract. It always depends on what you are doing, what problem you're trying to solve.
As you may know I made sure to invite and encourage participation from REST folks. In the end I believe everyone acknowledged that there are pros and cons to each approach - again, depending on your requirements.
The report has just tried to capture that as well as we could, and I hope through the Workshop and its report we can help move the discussion toward more positive ground.
Re: Bridges not walls
Re: Bridges not walls
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015