Contracts first, WSDL hurts

There been a flurry of activity around the whole SalesForce API thing (linked summary here) going on about "Contract first", XSD, and WSDL. Some of the key quotes:

Steve Loughran: "Me, I blame WSDL and XSD."
Sanjiva Weerawarana: "Middleware vendors who claim that taking some customer's old object oriented code and auto generating services is a good thing should be shot."
Arjen Poutsma: "I don’t like writing WSDLs. I think they force a wrong model. Unfortunately, they are the standard."

One of the things that I think important in software is separation of concerns. Separating the contract from the internals of the service (like its domain model) is paramount in that respect.

The service's contract is made up the logical message types (not necessarily XML) it "owns". There are certain kinds of messages that a service may send or receive but that it doesn't own. For instance, a service may receive messages published by a different service notifying it about important events. Also, a service will communicate with another service requesting it to perform some action by sending it a message. In both these cases, the message types being sent are not part of the first service's contract.

So, why does WSDL dictate that services need to expose operations in order to receive messages they don't own? These message types are not owned by the service and, as such, will have different versioning behaviors than message types owned by the service. So why on earth should they be bundled in the same WSDL file? Even if they're in separate WSDL files, and on separate endpoints, the semantics of these "operations" are totally different. I wouldn't want just anyone to be able to send a message to those endpoints - only the service to which I've subscribed should be sending me those messages.

But there's policy to manage that, right? Unless, of course, the service decides to switch the location where it sends messages from - which is its perrogative. But then we can write custom policies to handle that, right? Unless we didn't know that the service changed its sending policy - which we shouldn't know, autonomy and all that.

But, but, but...

WSDL hurts. Its a crappy standard. But, like Arjen said, "they are the standard." The thing is, WSDL doesn't add anything of value beyond basic XML once you set out to build loosely coupled systems. Loose coupling is, first and foremost, an architectural goal. Its a pity that an implementation detail like WSDL gets in the way. There are alternatives, like REST, but they have their faults too. The point being, if you're XML based, you'll be interoperable. The tools may not necessarily work well with it, but after the first 90% of the work they do automagically for you, you still have the other 90% to do by hand anyway. So doing 100% by hand is really only a 10% increase :)

Posted by Udi Dahan at 03:06 PM  Permalink