However it is interesting to see how it is still relevant even a few years later when new frameworks are around.
The two common paradigms for building a web service are code-first and contract-first. The former means you start writing your c#/java/whatever service code and generate the contract (wsdl) from it. The latter means you first create the wsdl (either manually or using some tool) and then create the service code from it.
So with code-first you write this:
And this is auto generated for you:
While in contract-first you write the wsdl (possibly using a tool) and the code is generated.
Pros for code-first:
Pros for contract first:
Code first is the de-facto "default setting" in almost all frameworks - most tutorials and documentation use it. So contract-first is much more interesting from a "let's write an interesting post" POV.
In the next series of posts I'll write on the contract-first approach using several frameworks.
My opinion on the matter is that it does not really matter. Contract-first is important from the interoperability perspective, but most frameworks do not support all wsdl/schema artifacts. So ignoring the code you'll find yourself working with a perfectly interoperable wsdl that no framework can consume. For example xsd:union is not supported in .Net and xsd:choice isn't in Axis2 1.3. Contract without an implementation is useless.
On the other hand, code-first also requires you to look in the generated wsdl and verify it is interoperable. A service that can't be consumed is also useless.
So code-first or contract-first? Whatever, you'll need to do both anyway.