Contract-First XML Web Service Design is No Panacea
Dare Obasanjo has had a lot of good comments lately on the whole REST/Web Services thing, and here he argues against claims that writing the interface definition first (the "contract") is the key to getting Web services right. I first heard this thinking that WSDL-first is the magic from Tony Hong years ago at one of the old SOAP interoperability derbies. I'd figured this was actually written into the WS stone tablets somewhere.
Dare dwells on the mismatch between WXS schema types and programming platforms, and gets at topics I discussed in "XML class warfare" and "The worry about program wizards" [both Application Development Trends], as well as other outlets. I think the mismatch alone isn't a problem: all modeling involves approximation. The problem is that people want it all to work without leaving the safety of their wizards, and I'm sorry for managers who don't like the smell of engineers, but all modeling also requires expertise. Wizards save some time cosmetically in the cheapest phase of development (implementation) just to charge very usurious interest on that savings throughout all the other phases. Customer problems such as Dare mentions are classic surfeit of the poisoned Kool-Aid, dating back to the 4GL heyday.
Model-first is still the key to solving such problems, I think. WXS and WSDL are too low-level to qualify. The model uses a specification language that expresses the solution in terms that are both formal, and close to the conception of the problem space. That takes collaboration between the subject matter experts and modeling experts during analysis and high-level design. It then requires further effort from a modeling expert to define the mappings between the model and artifacts of th eprogramming environment such as IDL, WSDL and WXS during the low-level design, which flows into implementation. No need for waterfalls or analysis-paralysis: these can all be rapid, iterative steps. But you can't just make a magic leap to low-level problem solving and expect not to pay the penalty in maintenance. This is the oldest advice in software engineering. It's amazing how few pay it the slightest attention.