Why people don't do WSDL-first?

Question

I'm currently making a presentation that deals with web services.

We created our service using WSDL+XSD-first approach, in which we first created (with the aid of tools) the XSD schema and WSDL and then compiled both to .NET and Java classes for interoperation.

I want to justify why we used this approach. I mentioned that it's more OOP-compliant (first define interface, then implementation, not vice versa) and that you have more control over interoperability constraints. Also, you can define namespaces explicitly and help reuse XSDs across applications

On the contrary, today, still many people prefer implementing the code in their IDE and generate WSDL from there. The question is, why?

Answer 1

I disagree - I think it has to do with expressing a contract, not development ease.

And I think the WSDL should be generated from the .xsd.

The Spring web service page has a nice discussion about "contract first" web services. Read it and see what you think.

Answer 2

Both styles of development have advantages and disadvantages but I don't think contract last is used more just because it's easier and quicker on the newbies, as you say, but mainly because as tools and frameworks evolved, the WSDL quickly moved into what's cataloged as plumbing code, quote:

[...] the behind-the-scenes low-level code that bridges between the application and lower layers. The coding of that stuff is often fairly dull and repetitive, but it's required to make the system work.

Nobody wants to write boring, repetitive code, especially when there are plenty of tools and frameworks to do it for you. If you don't even have to understand SOAP, WSDL or XSD that's even better for some... or should I say "magic"... but that's a different discussion :).

Answer 3

Not sure if my self-answer is the only answer but that's what I know

Because it's easier and quicker for newbie developers

Simply people don't all like learning new languages, but they prefer using the ones they master, no matter if their product won't work with a client from another platform

Answer 4

When I create webservices (we mostly use JBoss which has a nice built in webservices system) I always define the interactions first in a general sense, but not in XML, I don't particularly like writing the XML myself. It's an ugly, verbose language. So what I do is I map out my responses and parameters as Java objects, then annotate them appropriately, and then once I deploy the application I magically have a webservice without ever having to write XML. WSDLs and XSDs are kind of verbose and what JBoss generates for me isn't any better than what I used to have to write myself, and arguably it saves a lot of time. You don't necessarily have to implement the service at that point, just the response and input data structures. And then you can take that wsdl that it generates for you and use whatever tool you want to generate the objects the client needs.

Answer 5

There are some good reasons always to do Contract-First when it comes to wsdl.

The simple answer as to why people don't, is because it's less effort to simply have Visual Studio, or Apache CXF, or what ever implementation of Web Services you're using generating one for you.

It's easy up front, but down the road it can get messy.

Portability

One of them is you rely on the wsdl being generated being something that can be consumed by many different sources. Typically the wsdl's generated by either Visual Studio or Apache CXF will generate issues.

Sun's implementation of SOAP tends to generate wsdl's that contain "parameter" as the part name of messages, even though that causes an error when Visual Studio tries to consume a service as a web reference. Visual Studio's implementation also has known quirks that have to be hand tuned by those consuming their services in some situations.

In fact both Java and C# offer ways to override the auto-generated wsdl with a hand tuned one.

Stability

Contract-Last means your code generates the contract. This also means that it gets harder to avoid changing the API by mistake. If, on the other hand, you generate the WSDL yourself (it isn't hard) and you write the XSD (that isn't hard either - and in my opinion is easier to get right than JAXB classes in Java), then you enforce the contract. It is explicit when the contract changes.

Versioning

Since in Contract-First it is explicit when you change the contract, you can then version it in the namespace, and that means it becomes very clear when different versions are sent. Legacy clients can thereby be prevented from attempted to consume new messages which can be useful if you've made breaking updates.

This can save many man hours.