Contract-First or Code-First Design - Part 1

While in London for a conference, Ted Neward ran into Adrian Trenaman, a fellow Web services geek who’s been working with Web services for some years now, including having written several training courses on several different Java WS-* implementations. Naturally, their conversation swung from the usual “How are you enjoying the conference?” small talk to the more interesting - and heated - discussion of building Web services in general. Fortunately, unknown to either of them, a small digital recorder was capturing their conversation, and in an exclusive, highly-sensitive deal involving no fewer than three countries and two intelligence agencies whose name we’re not even allowed to think about, much less disclose, the transcript of that conversation is now being made public through TheServerSide Interoperability Blog.

[Editor’s note: At this point, both had consumed several beverages of questionably moral character - readers unaccustomed to raucous debate are forewarned.]

Adrian: So I heard you gave a talk on Java/.NET interop…

Ted: Yep. Adrian: … and that you said something along the lines of “WSDL sucks eggs”.

Ted: (Laughs) I think my actual words were something along the lines of “Learning WSDL is an exercise best reserved for the residents of the Fifth Circle of Hell” or something like that.

Adrian: You’re not a fan of contract-first?

Ted: You are?

Adrian: It’s not that bad.

Ted: Dude, them’s fightin’ words!

Adrian: (Laughter) Seriously, you don’t care for WSDL?

Ted: Nope. But you’re welcome to try to convince me otherwise, if you want.

Adrian: Well, it just seems to me that learning WSDL and XSD can go a long way in improving the quality of the Web services experience.

Ted: OK, opening arguments. Begin.

Adrian: (Laughter) OK, here goes. I used to think that WSDL was pretty ugly; it is certainly verbose and largely non-intuitive to the beginner. When I started with web services using XMLBus in 2001, the support for code-first programming was hugely attractive: you could take a Java class, run a simple “java-to-WSDL” utility, and an appropriate WSDL contract was generated. Today similar approaches exist for JAX-RPC toolkits like Axis, and JAX-WS toolkits, such as Celtix. These approaches allow developers to swiftly web-service-enable their existing code, with little or no need for WSDL design, and seem hugely attractive. Why would a developer want to venture into the “Fifth Circle of Hell” when they just don’t have to? I think the answer to this lies in the context of the service being designed. If this a tactical, short-lived service, then the code-first approach may be appropriate. However, if this service is to be long-lived within an enterprise, and engineered for reuse, then you may want to consider the following reasons to adopt a WSDL first approach.

Ted: Well, you’re not saying anything I don’t disagree with so far: context always matters, no matter the technology. And frankly, I’m not advocating the “code-first” approach, either; I believe in something hybridized between the two, sort of a “code-first/contract-aware” approach. But why in Heaven’s name would you sign developers up to write 50 lines of obtuse XML that can’t be verified until runtime just to specify a contract that can be more succinctly expressed in four lines of Java or C#? Adrian: Four reasons.

Ted: Cool. You put ‘em up, I’ll knock ‘em down, one at a time.

Adrian: You’ll TRY, you mean. (Laughter) (Editor’s note: There is a pause here in the conversation as the waitress brings more beer and our agent surreptitiously turns up the microphone gain on the recorder cleverly disguised as a floral arrangement on the table.)

Read Part 2