Ah, in my opinion this experiment works really well. I have already learned a lot from only three question posts. The old posts (and replies) are here:

OK, over to the question for today:

SOA-Q: WSDL rules or sucks?

Sometimes I get the feeling that many SOA-ers think that WSDL sucks, while at the same time others talk a lot about it as the holy grail. What's the current state?

Comments?

Update (some answers):

  • Arjen Poutsma wrote Re: SOA-Q: WSDL rules or sucks?

  • Mårten Gustafson wrote WSDL

  • Erik Johnson wrote:

    In the WS gold rush era (3 years back), WSDL was a toolkit sales rep's best friend. One utility generated all you need to hook up your code and the web. The (now) obvious problems have little to do with the WSDL spec itself. One thing that I think WSDL 1.0 did poorly was help separate the endpoint bindings - the URL - from the actual interface definition. If you're an ISV who delivers WSDLs to your customers you obviously don't want your internal dev machine names littering your product. The W3C explains how to separate the abstract interface from the physical bindings, but few people actually do it and some toolkits don't understand it when they see it. On the other hand, I have trouble blaming WSDL for problems with type systems (mapping XML Schema constructs to programming languages) and design choices (REST, MEST, RPC, whatever).

  • Jim Webber wrote:

    You probably already know about SSDL (http://ssdl.org). It's like WSDL should have been - SOAP centric and able to deal with arbitrary workflows and document exchanges.

    I definitely come down in the camp that sees WSDL as a disappointment more than something that sucks. It doesn't suck, it's just a very mediocre and complex toolkit for describing RPC in a protocol agnostic manner.