John Burkhardt "If I have nothing to say, my lips are sealed" - Talking Heads
Saturday, May 18, 2002
The search for high level wsdl editing/generating tools continues:
CapeClear has a wsdl editor. Omniopera has a wsdl editor with some wizards to generate wsdl. SilverStream has one as part of their eXtend product. I'm guessing this is big bucks. There are others.. but as part of huge enterprise platforms.
Anyone have any experience with these things? Searching around I found that this quest has been discussed quite a bit in the past.. ok, so I'm bit late to the wsdl party..
9:19:37 AM
After contemplating writing my own wsdl editor for about 30 seconds, I remembered meeting some folks from XML Spy (and I -gasp- clicked their ad on xml.com) They have an intriguing product that they are calling the world's first Soap debugger. The only bit I could find on wsdl is: "XML Spy includes full support for WSDL, SOAP and Web Services in the XML Spy 4.3 Suite product." Does this work? Is it useful?
8:56:48 AM
Rich Salz published an interesting article outlining some of his frustrations with wsdl.
The most widespread tools take an existing Java class or COM object and then generate a WSDL definition. This is backwards and half-assed. It's backwards because -- as we should have learned with earlier infrastructures -- the right thing to do is write the interface first. It's half-assed because while everybody's generating interfaces, nobody is capable of automatically consuming them.
I'm not a Java programmer. I could never get into it. But I've done tons of COM. I do write the interface first, and in fact, using the MS SOAP Toolkit, I can write my idl, build a type library and then use that to generate wsdl. None of these steps have anything to do with implementation. Of course, I then have to have my way with the wsdl file, but its a good starting point anyway...
I would love cleaner, more customizable wsdl generation tool. Maybe its time to write one!
As we'll see, message definitions are where we get the first hints that WSDL exceeds the 80/20 rule of flexibility and complexity.
I have to say, I kind of agree with his frustrations when trying to fully grock this stuff. Is it uneccesarily complex? I've taken it on blind faith that a lot of the complexity is neccesary because we want to maintain future extensibility and not get tied into one implementation.
