« How Not to Plan a Career in Software | Main | A Real eBay Architect Analyzes Part 3 »

Sunday, January 07, 2007


Mark Baker

"My IDL would allow me to leverage all HTTP operations"

Does ... not ... compute. Can you explain what you mean?

Dan Pritchett

All I was trying to say is that a service "invocation" should support binding to GET, POST, PUT, or DELETE. WSDL limits you to POST which as you well know means you can't express something as simple as an RSS feed. My goal would be that, while arguably unnecessary, the IDL could easily describe an RSS feed or WebDAV.

Bill de hOra

"I have spent the past few weeks thinking about how such an IDL might look"

The state of the art for interface semantics beyond natural language is RFC2119. And mustIgnore. I'm not joking.

No argument from me re the WSDL. Don't deploy on it unless you have to for partnering reasons.


Maybe SSDL can be your alternative language (http://www.ssdl.org/)?


Having an easy-to-read-and-write-by-humans IDL that is similar to RelaxNG is more than welcome!

Using RelaxNG's Compact syntax and RelaxNG itself as the schema language, as well as being able to express bindings for HTTP (including all its methods and headers) and other protocols would be totally awesome. You'd have me onboard as a vivid fan at least!

John "Z-Bo" Zabroski

Sounds like WHISKY syndrome: "Why isn't someone koding yet?"

I'm just a college student, so tell me, what happens when your team of engineers change the model as they code? Once you are done with specification (the WSDL), is all of this roundtrip engineering being updated throughout the design and testing of your conceptual construct?

sergei anikin

Dan, I think, there are two problems, you exposed in your post:
a) Implementations incompatibility, we really can't do much about it.
b) Luck of proper language editor, here I can propose you to look at MPS, product being in the concept phase by our beloved Idea IntelliJ developers(JetBrains). Their idea is, that it is not enough to have language defined and translation implemented, you need a reasonably good editor to be effective in the language usage. This was the case for Java, before IntelliJ arrived, it is the case you are discussing in this article.


Dear driveawedge (can't find your name), I agree with you that WSDL is hard to author and that tools are often bad. But some of your issues seam mislead:

The IDL should be a common langauge, and as such it does not have to talk about java.util.Map or unsigned long long. Instead, WSDL chooses XML (and I haven't seen you complain about it) and XML Schema (but WSDL can easily cope with RelaxNG, too). IIRC, RelaxNG also uses XML Schema datatypes because they seem to be a good set of data types for XML data. Mapping of that into languages, if desired, is out of scope for this W3C effort.

You may want to have a look at W3C XML Schema patters for data binding at http://www.w3.org/2002/ws/databinding/ - they are trying to document commonly supported patterns in XML Schema, and they you may restrict yourself to that for interoperability.

WSDL 2 also aims to give you good support for binding to HTTP operations.

Perhaps all that's missing in WSDL is just the human-readable syntax, a la RelaxNG compact? Care to propose it?

BTW, make the comment window bigger, please.

Dan Pritchett

You missed my point on type bindings. I understand that WSDL is language neutral and relies on XML bindings. My point is that if you suggest developers express interfaces in a native language, you expose them to the possibilities of picking types that are not terribly neutral. Thus the argument for having an IDL that is understandable by people.

David Chazin

Yes, WSDL is hard to read. It need to be approached like a foreign language, which means it will take time. Even worse is that most of the tooling stinks so you are almost forced to have to hand tamp it to get it to work properly if you are dealing with multiple target environments and languages. Also errors are really hard to track down. Part of the problem is that multiple xml namespaces have to be used everywhere, which makes the xml part of the processing much more complicated and harder to understand.
Another issue is expectations. I expected that using wsdl should be easy. Actually it is quite difficult and nuanced to understand and use and has a very steep learning curve.
The good news is that once you "get it" you can read it and crank out services as fast you think you should have been able to when you first started.


Maybe WADL will do better :-)

Joe Schlebotnick

WSDLs are easy. Thy are a W3C specification. I have had my hands tied and STILL managed to use other WSDLs with only cat-ing a file through telnet to port 80 and capturing the results in yet another file.

If I can do this without tools, imagine what you can do with .NET or whatever.

The comments to this entry are closed.