Contract-First or Code-First Design - Part 2

Editor’s note: This is the second part of a continued series of transcriptions from a conversation secretly recorded in a bar in London between Ted Neward and Adrian Trenaman on the code-first/contract-first debate. Adrian was about to launch into the first of four reasons he prefers WSDL and contract-first when a waitress interrupted them to bring more drinks.

Ted: Ahh, good stuff. OK, you said you had four reasons you prefer the evils of WSDL to something else.

Adrian: (Laughter) Evils?

Ted: Toh-may-toh, toh-mah-toh.

Adrian: OK, first: Code-first interfaces may not be well suite for the demands of remote traffic. It’s generally accepted that not all procedures or methods should be made remote: if you’re going to take on the overhead of a network call then you should maximize the amount of data transmitted with each call. Current coding practices often lead to many fine grained methods (for example, get() and set() methods on Java beans) that are unsuitable for remote access. Early Java-to-WSDL tools generated WSDL on a class/interface level, not allowing you to distinguish between those methods you wanted to expose remotely through the WSDL contract and those you want to remain outside of the contract. Newer tooling using JAX-WS and .NET does allow you to specify remoting on a per-method basis, which alleviates this problem somewhat. However, this tooling relies on network-savvy developers and designers - are they always going to be around to make sure someone not so clued in starts adding poorly designed operations to the interface?

Ted: No argument on the substance of your argument: making a network traversal has to be considered one of the most expensive things a developer can force the machine to do. And I agree, lots of developers don’t realize that the cost of one network RPC call can be up to four or five orders of magnitude–

Adrian: Wait, is that ten thousand or a hundred thousand times? I forget.

Ted: Yeah, it’s hard for people to comprehend numbers that big, so I did the math once and tried to put it into real-world terms. If we consider a standard, non-remoted method call to be equivalent to your morning commute of twenty minutes, then a network call, Web service or otherwise, is roughly the same amount of time as what we’d need, using today’s technology, to go to Pluto, or roughly fourteen years.

Adrian: (Garbled response; detailed analysis suggests a reaction suspiciously like beer coming out of his nose.)

Ted: Yep. And to expect that “newbie” developers are going to have an appreciation for the costs of network calls is definitely a stretch. But here’s my point: What are those newbie developers doing designing remote interfaces in the first place? The same problem exists with CORBA, RMI, EJB, or any other remoting technology, not with Web services in of themselves. In fact, this is probably my biggest concern over POJO-based approaches being applied to communication technologies, that what’s good for POJOs isn’t good for distribution. What’s worse, the WSDL-based approach doesn’t help this at all, particularly given that a lot of devs are designing their WSDL services to be just as “chatty” as they’re going their RMI or EJB or .NET Remoting or any other RPC-based tools. That’s not an issue of technology, that’s an issue of education and experience.

(Editor’s note: At this point in the conversation, both launched into an extended discussion of the evils of clueless programmers and their tendencies to be shunted off into less dangerous places, such as Upper Management.).

Read Part 1 — Read Part 3