The W3C has issued Web Services Description (WSDL) 2.0 as a W3C Candidate Recommendation, where the specification is designated as ready for implementation. At this point, the spec is tested for implementability and the interoperability of implementations.

The Core Spec, Adjuncts and Primer are all available from the W3C's site.

As such, the call for implementations has been posted to identify those with an interest in partcipating in this implementation and interop testing process.

Well, just glancing over the example in the Primer, it looks a lot better.

it's just great the W3C keeps piling the WSDL gold onto the internet. Now with WSDL2, it will be even more spectacular. With WSDL2, you can slice, you can dice, you can bake an apple pie and still have room for icecream. WSDL2, how did the world ever live without it :)

peter

Ok, so we now have another version of WSDL, one that may be marginally less awful to read or write than WSDL1.1. Which is a good thing. If there is one thing that SOAP stack teams are more scared of than machine-generated WSDL in a bugrep, its handwritten stuff, usually because the author doesn't understand all the byzantine quirks of WSDL. The team ends up debugging the WSDL before closing the bugrep as invalid.

But, its still WSDL. Its still not as minimal or elegant as the proposed SSDL alternative.

And, if other WS-* specs are anything to go by, it wont come with anything resembling a formal test suite. Instead the spec will be a piece of a paper and some XSD documents, and every SOAP team is left to misunderstand the bit of paper differently. Which effectivley guarantees that interop is doomed from the outset, because there is no set of tests to say whether a particular stack is compliant. Instead all you have are plugfests and recrimination.

What is it about test-driven development that the W3C, OASIS and other standards bodies don't believe in?
-steve

Its still not as minimal or elegant as the proposed SSDL alternative.

If it isn't widely accepted, it can be the greatest ever and it won't matter. The best solution isn't always the winner e.g. most computer users have Windows as their OS.

Its still not as minimal or elegant as the proposed SSDL alternative.

If it isn't widely accepted, it can be the greatest ever and it won't matter. The best solution isn't always the winner e.g. most computer users have Windows as their OS.

Maybe, but I know that the next thing I do with XML will use RelaxNG. It may not be as widely used as XSD, but it wont cause me as much pain.

The big barrier is tool support. Maybe I should add SSDL support to Axis2. That will be low down on my todo list there, after "proper fault handing"

Maybe I should add SSDL support to Axis2. That will be low down on my todo list there, after "proper fault handing"

That's a start but if my partner doesn't use SSDL, I can't use it. Since we have many partners and I can guarantee some don't use SSDL, I can't use it. Our vendor doesn't support it anyway but if it did, I still couldn't use it.

That's the thing with standards. If the standard isn't standard, it isn't really a standard.

While we're on the subject of WSDL, does anyone have any tips for WSDL versioning? I just came across Amazon.com's approach (http://www.amazon.com/gp/aws/sdk/main.html/104-0557955-5608706?s=AWSEcommerceService&v=2005-10-05&p=ApiReference/ServiceVersioningArticle) for WSDL versioning, but I was wondering if anyone had any other approaches? Is it usually best to create a whole new WSDL for each version change of the service in order to not break existing users of the service? I would think this may be a better approach since one can't assume that all web service stacks will be able to safely ignore new elements/operations of the WSDL, correct?

Thanks!
Ryan

While we're on the subject of WSDL, does anyone have any tips for WSDL versioning? I just came across Amazon.com's approach (http://www.amazon.com/gp/aws/sdk/main.html/104-0557955-5608706?s=AWSEcommerceService&v=2005-10-05&p=ApiReference/ServiceVersioningArticle) for WSDL versioning, but I was wondering if anyone had any other approaches? Is it usually best to create a whole new WSDL for each version change of the service in order to not break existing users of the service? I would think this may be a better approach since one can't assume that all web service stacks will be able to safely ignore new elements/operations of the WSDL, correct?Thanks!Ryan

Yes. Deploying a new WSDL is usually the best approach for preserving compatibility with existing clients. However, as I blogged here, it takes some work to support multiple service implementations. The same is true if a client has to work with multiple service versions. Careful schema design avoiding incomatible changes usually helps though.

Subbu

[The] spec will be a piece of a paper and some XSD documents... there is no set of tests to say whether a particular stack is compliant.

The W3C Recommendation Track Process requires that any specification be accompanied by a test suite and at least two (2) interoperable implementations, in order for it to become a W3C Proposed Recommendation, the next step toward being published as a W3C Recommendation.

To this end, the WSDL 2.0 Working Group has also invited implementers to test heir implementations against, and contribute to, the small but growing WSDL 2.0 Test Suite. An interoperability event will be held as the implementations and test suite mature, which will be open to all WSDL 2.0 implementers.

On the other hand, the OASIS standards do not have such requirements, and thus are subject to the sort of intrigue you've outlined in your post.

WSDL 2 is much more OO than WSDL 1 was!

- An interface definition (akin to IDL) can be easily shared for different transports and endpoints. A big complaint of WSDL-1 not being OO was that services were singletons. In WSDL-2 services can have instances, which makes replication easy, which helps things such as smart stubs, QoS, and UDDI-like stuff. This is great for autonomic computing and computational grids. Actually, this WSDL enhancement I think came from the grid community, GGF, with lots of help from IBM. Somehow this might relate to WS-Addressing or WS-Discovery.

- Interface inheritance and multiple inheritance.

- Predifined interaction patterns, including pub/sub.

- Infoset based, component model, tighter SOAP integration, blah blah blah...

For more details see:
http://www.idealliance.org/papers/dx_xmle04/slides/moreau.pdf

<P>For those new to WSDL 2.0: What, in brief, is new in this spec?</P>

• Reusability: Through inheritance, a WSDL 2.0&nbsp;interface may inherit from one or more other interfaces
• Extensibility: WSDL 2.0 can use:
• Open content model (from WSDL 1.1) - mix XML into WSDL from other namespaces, @wsdl:required attribute indicates whether it must be understood
• Message Exchange Patterns (MEPs): defines a pattern of interaction between agents&nbsp;
• Features and Properties (F&amp;Ps): describes requirements and semantics provided by extensions
• Safe Operations: Requester agent requires no obligation beyond invoking the operation (analogous to HTTP GET)
• Complete HTTP/1.1 support
• SOAP 1.2 Binding

Are their any WSDL 2.0 implementations avaialble?

Regards,
Naresh