I was reading an article the other day about REST, Rails, Java, Ruby and SOAP. The author mentionned something about programmers trying to solve complex problems with complex solutions. While I think writing simple solutions to complex problems would be great, I think people tends to underestimate complex problem's... hmm... complexity.

Simple APIs and framework are great when writing a tutorial or an article for a magasine, but it's only when you get to use it to solve a complex real problem that you will know if it is as good as you thought. Real-life problems are not "designed" to fit any programming paradigms. There is all sorts of exceptions, special cases and weird rules to follow. When you face one of those, the quality of a framework is not simplicity but flexibility. And sometime, simple frameworks are not that flexible.

If an API or a framework is not flexible enough, you will end-up having to do many hacks in order to achieve your goals. I consider every hack a flaw in the design of an application. If you need to do a hack to perform a specific task, the application was not designed properly. Sometime it's faster to perform the hack than to refactor the application to a better design. And it works for a while. But the more hacks you put into place, the higher your design debt is. If you never return to your code to fix the hacks and implement a proper design, the application is likely to become extremely hard to maintain after a few years.

Here's another example of simple vs. complex where, in my opinion, complex wins. SOAP vs. XML-RPC. Both are used to solve the same problem; remote procedure calls. (I know, you could do more than just remote procedure calls with those technologies but in general, that's what they are used for.) One is fairly simple (XML-RPC) while the other (SOAP) is much more complex. Given a simple and a complex option, why on Earth would you pick the complex one? Because of all the benefits of the complex API.

SOAP messages are defined in a document called the Web Service Definition Language (WSDL for short.) XML-RPC messages are defined... in the head of the designer. Yes, writing the WSDL document can sometime be a pain, especially the first time you do it or when you want to get a prototype going to show to you manager. You have to explicitly dictate what the messages are, what parameters and objects are optionnal, what values are accepted, etc. No question here, SOAP is more complex than XML-RPC. In XML-RPC, every elements that makes a message is part of a pre-defined vocabulary of XML elements. It's highly flexible and you can pretty much create free-form messages.

Sure, you could write a document describing the protocol between the XML-RPC client and server, but you assume the person who is going to be designing the client will read and understand the document. WSDL is, by definition, non-ambiguous. Somebody want to write a new client application for you server? Give him a copy of the WSDL file and, most of the time, you don't have to add more details.

One of the other advantages of SOAP is that there are many toolkits that will take a WSDL file and generate stubs and skeletons for you. Tools like gSOAP and Axis lets you do SOAP without actually worrying about it. Knowing everything they need from the WSDL, they can generate a bunch of code for you and handle all of the XML input and output for you.

So next time you hear somebody complaining about a framework or an API being too complex, give it serious look anyway. You might just end-up spending twice as much time doing hacks around a simpler API's... simplicity... in order to achieve your goals.

Tags Technorati : programming | soap | gsoap | xmlrpc | rest | java | ruby