WSDL was one of the four standards on which Web services were originally built though it always drew some heat that it wasn't up to snuff for loose coupling. While a better version has long been desired, attempts to update it have also met with stern criticism.
Version 2.0 of WSDL (Web Services Description Language) differs substantially from previous releases, with a new component model, interface inheritance and other changes designed to reduce complexity. Critics, however, argue it has added complexity and abandoned the notion of backwards compatibility in the process.
WSDL 2.0 right now is making its way through the Candidate Recommendation phase at the W3C, with interoperability testing expected to begin by or before mid-Q2. It represents a contract for a Web service, specifying the message formats, transport protocols, locations, etc. WSDL 2.0 is the culmination of nearly four years of work by the W3C's Web Services Description Working Group. Originally it was to be called WSDL 1.2, but was renamed from 1.2 to 2.0 because it turned into more of a forklift upgrade.
One of the major differences is the component model, which "makes it so much easier to describe services and reuse those descriptions," said Charlton Barreto, a member of the Web Services Description Working Group and a senior computer scientist at Adobe Systems Inc.. "These simplifications have extended to the SOAP and HTML bindings to WSDL, as well as the capability to writing other bindings." Also, he said, "fault handling is greatly improved because of the component model."
Another key enhancement, Barreto said, is Features & Properties (F&P). With F&P, "you have a richer choice in the ability to describe quality of services [QoS] for Web services. We now have two mechanisms we support for QoS: Features & Properties and WS-Policy [which has yet to enter a standards body]. Both encourage extensibility of the specification."
In addition, he said, "Message Exchanges Patterns was a huge improvement." Message Exchange Patterns model the typical exchange between roles from the provider perspective. "It encourages the implementation of more complex patterns. We've gone beyond the standard for protocols used in WSDL 1.1 and have been able to define message exchange patterns that address reliability of input or output."
The changes will impact those writing WSDL implementations, however. "The fact that they changed the data model is my biggest concern," said Anne Thomas Manes, vice president and research director at Burton Group in Midvale, Utah. "It forces us to learn something different. All the tooling you had to compile the old WSDL will not work anymore."
People will have to migrate to WSDL 2.0 tooling, Baretto said. "The new component model changes the object model used to represent WSDL in implementation languages such as Java, C#, C++, etc. As such, people will have to migrate to WSDL 2.0 tooling to generate implementation code," he said. "WSDL 2.0 includes a specification for SOAP 1.1 binding, providing backwards-compatible support at the transport level, transparent to users. In short, migrating one's existing WSDL 1.1 implementations to WSDL 2.0 will likely involve either regenerating stubs or changing interfaces in a choreography or orchestration, but nothing more."
Another concern Manes has is the complexity of the component model, particularly for those using scripting languages. "If I'm a scripting language writer, I don't understand a lot of these object-oriented concepts," she said.
In response, Barreto said the component model is more self-consistent and easier to understand. "WSDL 1.1 itself embodied a number of OO concepts, yet with various compromises which weren't necessarily accessible to those familiar or unfamiliar with OO," he said. "With the component model, WSDL 2.0 has addressed the inconsistencies experienced in 1.1 and greatly simplifies the use of WSDL. WSDL 2.0 ease-of-use improvements simplify the task of scripting, offsetting any possible overhead of learning OO concepts."
Also new to WSDL 2.0 is the concept of interface inheritance. According to Manes, this "imposes an unreasonable constraint that doesn't correlate to real world services. There are valid reasons for multiple interfaces for services and it makes it easier for tooling." She said the working group was not unanimous on this issue.
"A majority of the Working Group saw the benefits afforded by this approach – the simplicity of the model, the simplifications it extends to bindings and the clarification of the role of WSDL," Barreto said. "Even though there still are a number of WSDL users who feel that some means of stitching disparate interfaces together is a requirement, this approach confuses the use of WSDL in a manner that persists today. The role of WSDL is not to define service composition, but resources."
Another concern Manes raised was the move from WSDL 1.1 to 2.0. "With WSDL's new data model, it will be highly disruptive."
Addressing that issue, Barreto said, "One can represent the same resources in WSDL 1.1 or WSDL 2.0. It is up to the technology which describes, defines and/or implements interactions between resources to support the use of resource descriptions in either WSDL 1.1 or 2.0."
The larger issue, he said, is that users should not look to WSDL to describe interactions between resources. "WSDL should only describe how to interact with a resource. We have robust ways to describe interactions between resources which interoperate with WSDL 2.0."
He continued, "We need to ask how can the various Web Services specs that are used to connect systems and businesses interoperate with WSDL 2.0. A considerable number of the emerging Web Service specs have already addressed this. Beyond support in these individual efforts for WSDL 2.0 (as well as 1.1), this will be a matter for WS-I to address in an updated profile."