The recent debate (here, here, and here, amongst others) might lead you to believe there are two ways to design a web service: code-first and contract-first. A surface reading of the debate seems to indicate that you either write a bunch of classes and rely on the vendor to generate the XML (code-first) or write all your WSDL/XSD by hand (contract-first). This is utter crap.
Just like anything else, it all comes down to Splosky's Law. Roughly paraphrased, it reads, “There is no free lunch.“ You don't get to ignore the wire format, and you don't get to ignore the tools. Instead, you have to remember things like, “CLR value types don't work very well in the face of missing elements, but Java works differently.“ You, lucky coder, have to remember that you're writing a system in which the parts might look something like this:
Java <-> Axis <-> XML <-> HTTP <-> XML <-> System.Xml.Serialization <-> ASP.NET <-> C#
And that every layer has its own oddities and idiosyncrasies. If you can do that by writing a pile of classes, great. But you simply won't be able to guarantee success unless you know how those classes turn into XML. You might get lucky, but that's pretty much the same thing as saying, “Well, there was a threading bug, but I ran it again and it didn't happen, so it must not be a problem.“ Similarly, you can't just hurl an XSD at the world and expect that everyone will write code to consume the corresponding XML directly off the wire - they're going to use vendor toolkits for the simple economic reason that it's too expensive not to.
Note that I'm not putting words into the mouths of any of the participants in this debate. Many of them make the same points, although not, I think, in the same “camp neutral“ vein. My point is that you can claim to be either a “contract-first” or “code-first” person and still succeed. Which pretty much makes the distinction (and therefore that aspect of the debate) pointless.
No, call yourself whatever you want, but you still get to learn the stack from end-to-end. Programmers hate this because they spend their life building abstractions, and this flies right in the face of that. Vendors hate it to admit it because it means they can't sell toolkits that “take care of everything for you.” (Not that they don't try.) But at the end of the day, the universe doesn't care that we don't like it - it's still the case that abstractions leak, and knowledge is the only insurance.