Simon Fell > Its just code > Contract First

Sanjiva (of Axis / WSo2 fame) responds to my two ids post with a post called Salesforce Web service API is crappy .. so blame the tools, unfortuantly Sanjiva in this case doesn't know what he's talking about.

• This particular API that I was discussing (the Partner API) has no OO object model (to use Sanjiva's term), sure I never explicitly called out that i was talking about the partner API, but the clues are there. See for yourself, here's a copy of the WSDL I was talking about - partner.wsdl. (If you have a salesforce.com login, you can find this under setup -> integrate -> AppExchange API -> Partner WSDL).
• We do contract first, and the entire contents of the partner WSDL are authored by hand, not a single thing is generated from code (ok, actually the statusCode and exceptionCode enum's are generated from code, the rest is done by hand). I've never seen a tool that would be able to generate that WSDL from a bunch of classes.
• Did you even read the post, or just see the "tools are crap" and go on tilt ?
• I'll write a schema for that 2nd message and even put up a dummy endpoint that'll return it, but you get to try out a bunch of mainline WS tools and report your results.

Sanjiva goes on to say Note that if you had indeed done it right then there'd be no issue with changing tools for dealing with the contract. The contract is sacred and that's the only thing that matters- what my tool does is between me and my tool.. Well, the contract is sacred, and hasn't changed, yet I've burnt a lot of time trying to make sure that it's still usable with tools like Indigo and Axis2. What you really mean, is that the contract is sacred as long as I use the subset of XSD that the tools like (except that different tools like different subsets, and different vendors change their minds over what the right subset is).

BYW, last time i looked XSD has no object model, it has extensions & restictions, which some tools choose to map (with varying degree's of success) to their languages OO model, but that doesn't make XSD OO.

Finally, if you want to try out the Web Service's for yourself and see what all the fuss is about, go ahead and signup for a free developer account.

Update: Steve correctly points out that my tool rants are based on tool used as a caller of the salesforce.com API (where we have to worry about the gauntlet of mainstreeam and not so mainstream soap stacks, we are living the WS dream with clients using .NET, Java, Perl, Python, PHP, Ruby, Javascript and others to call our service), not rants about the tools we use internally to build the service.