WSDL 2.0 FAQ

Since WSDL 2.0 announced CR, I've received a rather continuous stream of questions regarding it, which is a very encouraging sign: Web Service users are apparently interested in WSDL 2.0 and want to understand what's involved in using it.

As these have become FAQ posited to me, I've started listing them here with my responses in order to disseminate the information as best as possble. :-)

WSDL 2.0 FAQ 1.0

1) Does the change to a single interface per service impose an unreasonable constraint that doesn't correlate to real world services?

No, because there are a number of reasonable approaches to indicating a relationship between services. These include:

• Declare multiple interfaces in the same wsdl:description element.
• Declare multiple interfaces in the same wsdl:targetNamespace.
• Add an extension to WSDL 2.0 that links together all services that are related in this way.
• Declare them in completely separate WSDL 2.0 documents, but use the same endpoint address for both.
• Use inheritance to combine the customer interface and management interface into a single, larger wsdl:interface.

Also, a service is best defined through descriptions and/or definitions of the *interactions* between real world resources, such as choreographies or orchestrations.

2) It seems the working group was divided on this issue. What was the reasoning behind the final decision?

The decision was reached the basis of the model of services based on a flexible definition of a resource:

A resource offers one or more interfaces, where an interface consists of a collection of operations. Each interface may be accessed by one or more endpoints, where an endpoint represents a binding of that interface to a particular protocol, and each endpoint has an IRI. A "service", thus, is a collection of endpoints bound to the same interface and therefore the same resource. Services themselves can be grouped by IRIs.

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. 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.

Choreographies and/or orchestrations address this in offering one or more interfaces to consumers, some of which may be callback interfaces, and expecting zero or more services to be made available to them, including some by the consumers themselves. With the level of existing work on such higher-level descriptions, a majority of the Working Group didn’t see the point behind attempting to shoehorn this sort of rich description into a resource description language.

3) WSDL 2.0 changed the data model, so is it true that all the tooling people had to compile previous WSDL won't work anymore? How is it being addressed?

WSDL 2.0 presents a model for describing resources, rather than the data that is actually being exchanged. 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. WSDL 2.0 includes a specification for SOAP 1.1 binding, providing backwards compatible support at the transport level, it 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.

4) How is interoperability between WSDL 1.1, 1.2, and 2.0 being addressed?

WSDL 1.2 *is* WSDL 2.0. The version was renamed from 1.2 to 2.0 given the substantial differences from 1.1. So I take it that what you’re really asking is how interoperability between WSDL 1.1 and 2.0 is addressed.

WSDL is a resource description language. As such, interoperability between services/resources only has practical significance in terms of how they interact. Thus, the real question is how WSDL 2.0 interoperates with languages that describe and define such interactions, since any actual information exchange is handled by the transport layer and not by the service/resource description. WSDL can describe what parties in an exchange can expect, but the onus is on

1. The resources to provide responses compatible with what is expected by the requestor per the description,
2. The framework/toolkit hosting the resource to provide the associated functionality, and
3. The description/definition/implementation of the interaction between resources to support them.

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.

To me this points to a larger question at which I’ve already hinted – should users look to WSDL to describe interactions between resources? My answer to that is a resounding no – 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.

So, really, 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.

5) How will the change to a component model affect a scripting language writer, who doesn't necessarily understand OO concepts?

Actually, the new model is more self-consistent and thus 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. 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 actually simplify the task of scripting, offsetting any possible overhead of learning OO concepts.

In WSDL 2.0, you have to first process documents into a component model, then process the component model. It’s at least a two-pass process. Although essentially all WSDL 1.1 toolkits practically made you do something of the sort, the capacity for import and include make this a bit more complicated. In the end, the script writer really won’t see any real difference. Who really feels the impact are the tooling developers, who would support the use of WSDL in scripting languages.

I think the real question for those using scripting languages is “Do they want a WSDL, or a schema at all?” xsi:type and other message annotations are probably more interesting than a static description for binding on the fly....

6) What are people going to like best about 2.0?

Without doubt, for the majority, it’s the component model. It makes it so much easier to describe services and reuse those descriptions. These simplifications have extended to the SOAP and HTML bindings to WSDL, as well as the capability to writing other bindings.

As someone working to define the choreography of web services, what really appeals to me is the formalisation of Message Exchange Patterns, and the power afforded to describe QoS by Features & Properties.