The motorcycle diaries of webservices

Software is a big grandpa pendulum clock. It oscillates between simplicity and complexity perpetually. Ideas and concepts that start off simple, rapidly become complex and eventually complex ideas are broken down into simple components and again these simple components evolve into complex creatures of their own. After all we evolved from a single cell into complex cell living beings, why blame the software for that?

Webservices necessitated from complex interaction between disparate systems (remember CORBA, JNI, DCOM, RPC, mainframe apis?). All those were dissolved into ‘simple’ wsdl based services, as long as client and server maintain the contract, everything was promised to be a simple hookup.

But it didnt end there. Generating wsdl clients either in Java or .NET were complex in its own terms. Java discovered its way, as usual, with hundreds of wsdl clients and xml jars (anyone still using xerces, xalan, sax4j directly?) – jaxb, jax-rs, jws, cxf and several more proprietary ones). .Net, was not a A-shot either: first asmx, then wcf and then several flavors of .net versions on top of that. Most of the time, its not a one-step process to call a WCF wsdl from a Java based client, there are always some surprises around the corner in terms of configurations. Its heartening to see nobody got it right the first time.

If you think about it, what was the necessity to generate classes from wsdl in order to send plain xml text data? The early xml apis described the xml in terms of hardcore hierarchy: root, nodes, parent, children, siblings, single. It could have been easily extended to represent a oh-so loveable joint-family: cousins, uncles, aunts, nephews and nieces:

public getAuntyNode() {
return currentNode.getParent().getFather().getSister().toNode();

public getDistantUncleNode() {
return currentNode.getParentNode().getMother().getSisterInLaw().getHusband().getSibling().toNode()

public getImMyOwnGrandpaNode() {

Such family friendly APIs would have thrilled developers who often work only after the family goes to sleep.

I am also starting to see that xml and xsd schemas are not an ideal way to describe data models. Describing a model in xsd using the semantics of xml itself is over complicated. On top of that extensions, simpleTypes, complexType – are way too tedious and garrulous. If you are exposed to C++/Ruby/Groovy world, you can visualize the models pretty quickly in terms of encapsulations, compositions and interfaces. In the xml world, I only see tags and attribute names. Lots and lots of them. The content is lost in the tag-tsunami.

While reviewing a project recently, where all our models are xsd based, data models extending from base xsds, and several simple, complex and xsd:any types, pretty soon I found them going above my head. Im not even thinking how xsds maintain versions of models and references.

Coming to actually using them in our Grails project, a colleague of mine tried to generate the client classes using jaxb (before trying a few other clients) and pretty soon found himself in a maze of conflicting classpaths from different generated wsdls. Jaxb generates classes for all the dependent xsds (obviously) and generating them for different wsdls (in the same project) ended up with several classpath issues.

Taking a break, we decided to ask a fundamental question: “Why do we have to worry about all the xml types in the Grails code, if all we need is to send a plain textual xml data?”.

Who cares what the model hierarchy of xsd is? Most of the time that model is useless to the Grails code, where typically the representation of model is different from the xsd models. All those xsd generated classes, objects, factories, abstract factories were required because the complex familial Java APIs were the only way to process xml (unless using StringBuffer and appending data manually).

Enter Groovy’s MarkupBuilder, it is much easier to build an xml than generating the client. So if we all care is to send data and generating that data itself is easier than generating clients, why bother at all with the later. And we switched to Grails wslite plugin, with which we are directly creating soap requests and sending it to server.

So thats how the pendulum switched back to its other position, back to creating hand made soaps. Eventually this may get complex too. But again, the important thing to remember is that the original complexity is not the same level of complexity of the broken down components. The “absolute complexity” remains unaltered and the “perceived complexity” depends on how lazy or smart we are.


2 Responses to The motorcycle diaries of webservices

  1. Keith Fail says:

    Hey Vasu,

    Great read. Thanks for writing this. These days I am differentiating between complexity and complicated. I think you use the idea’s interchangeable.

    The advantage of this distinction is that complexity means that two Agents (with free will) and other complex dynamic systems are inherently unable to be predicted. For example we can look at the results of evolution and explain a theory of how it seems to work, but we can never predict the complexity of the dynamics of an eco system. There are just too many agents who are interacting with one another.

    But much of software development falls into the domain of the complicated. In these cases it is possible to understand the effects by deeply studying and analyzing the components that make up the code and hardware.

    What do you think of this distinction. Would love to catch up some time. Give me a call if you have the time. 512-507-5464

    Keith Fail


  2. vasya10 says:

    Hey Keith,

    Nice hearing from you, its been a while ! Lets talk some time, sure.

    I alluded to that as “absolute vs perceived” complexity. I see “complicated” as the measure of “perceived complexity”. For eg, the weather models look simple for a weather-man, but for a layman the models are complicated, because his perception is not that deep. For an Unix administrator, piping commands to each other is simple, but for an end user it is “complicated”. But for the same admin, internal kernels are complicated, but not to the person who wrote the OS itself and so on. But the perceived complexity has to have a frame of reference, which is the “absolute complexity”. Without that, the interpretations will make no sense. For eg if someone says Ruby is simpler than Java, the reference is to the syntax (“perceived complexity”). Or someone could say Java is simpler than Ruby, where the reference is to type of programming (oop/procedural vs functional). But at the machine level code, they are all same (“absolute complexity”).


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: