Once upon a time shortly after 1998 (which is the birth year of XML) the true born King of the Web 2.0 was established and everybody seemed to like her. The talk is about the XML based SOAP Protocol which claimed to be the straightest and fastest highway leading to the ultimate control of the Web-Business. The architects all around the world celebrated the new unique and only right way of life over the wire which was entitled leading every developer and business application to acceptance and success. They also constructed promptly the simple and mighty name for that enterprise calling the holy approach SOA, the Service Oriented Architecture. In 2004 Don Box presented the four tenets creating the solid theoretical foundation for the idea. This buzzword promptly spread like bushfire. In order to prevent being called retarded everybody started referencing its own web-based solution to be SOA compliant. You remember? Even the simplest and ugliest (ASMX style) Web-Service, utilizing SOAP in one or another way, proclaimed “made in SOA”. Hundreds of books were written about SOA and of course the community was keen to use at least the “sticker” on the façade being SOA. The future of the web has been shaped and every effort was automatically banned working toward that predetermined crystal world. It was expected a huge worldwide catalog will be established with an endless number of service-offerings, the generic all comprehensive UDDI. Http was expected to play a humble and unnoticed role behind scenes of the glamorous SOAP-Envelops. The excited waiting for the announced revolution started.
The software machines and factories went on full power producing frameworks in order to empower everybody to be more and more SOA & UDDI compliant. At the beginning of this era the W3C started issuing quite nice recommendations which were still simple and understandable even for the novices. Later however the white XML shirts become stained. The spots started by something commonly puzzling, called the “Infoset” and the easy and friendly face of XML disappeared forever. No one was sure any more whether the things handled are still XML documents ore rather just XML-Infosets? The more advanced recommendations the W3C produced the more confusion and clouds settled on the WSDL/SOA based world.
The almighty frameworks (.NET) however supported developers quiet well and they were freed to fully understand the impacts and recommendations shaping the more-and-more complex SOAP-Envelops. It was only a short and delighted period where anybody with a little effort could write a real contract-first solution starting with the WSDL contract like many architects at that time suggested.
However the announced revolutions did not take place! The difficulties emerged as the more advanced recommendations (WS-*) prevented even the most experienced and the most determined to write contracts manually. At this time I doubt that there are more than a handful of them left who can still write WSDL contracts from scratch. This was the dagger of Brut being torn into Caesar’s heart. The complexity killed the idea and the uprising flight of the once lightweight and (overly) promising UDDI/WSDL elf started declining.
Don’t get me wrong! Those who are served by the frameworks can still write easily contract-first based solutions, although in a little bit different way. By using declarative attributes like DataContract, DataMember and many others the same can be achieved – but the result sometimes works out to be very scary . Did you ever look inside the frameworks produced wsdl-contract? Less blessed communities lacking the support of advanced frameworks started looking early enough for alternatives to escape the overwhelming standardization pressure and you know what? They succeeded.
It was one of my rare professional shocks when I learned, that except IBM and Microsoft there is a little support for the WSDL/SOAP-Only way of web based business. I also learned that a great number of new and successful web projects are based guess on what? Neither SOAP nor WSDL nor the four tenets of the SOA are applied but rather something called REST/JSON; the Representational State Transfer and the Java Script Object Notation. I experienced a professional’s shock on a conference learning, that up to now the SOA definition has to be understand in a more accommodating and lax way. Contracts, especially based on XSD or WSDL should be taken more flexible and definitely not imperatively. After long years of evangelizing the WSDL way, it was like a thunderbolt strike for me.
The formerly clear picture also was blurred by the emerging popularity of dynamic languages like Ruby or Python and further more. What I also have to understand, that based on those languages there makes a little sense creating fixed schemas as those languages operate beyond the borders of those type-systems which shaped the idea of the XSD/WSDL contracts.
Let me give you an example I learned experimenting with Python. Create a method signature having two input parameters (variables). In C# you would define a two parameter method let say int parametr1, and int paramter2 returning also an integer. If parameter1 = 5, and paramter2=3 then while adding them, the result will be without any great surprise an integer 8. In Python however (being dynamic) assigning parameter1=”John” and paramter2=3 makes also perfect sense and the operation will result returning three times concatenated “JohnJohnJohn”. In C# you would be forced to create some overloads in order to achieve the same flexibility which will lead to a code-explosion even for such simplest solution. Try to create for such “contract”, which is based on a dynamic language utilizing REST a valid WSDL! The Mission is (nearly) impossible? You are probably right.
The things I’m talking about are at this very time commonly well known. We know that the future of the Web will be co-shaped by AJAX, REST and JSON and formerly candidates established to rule the world have been dethroned. But be not too hasty! This of course does not mean at all, that they are dead. They are still very alive, and whenever you are in a desperate need creating a secure, state-full, reliable, smart and predictable behaving solution, you can and I even would suggest you have to use them. As Daniel Quinn was trying to convince us in his award winning book Ishmael; there is no one right way to live, so there is no one right way to work and architect in the Web 2.0. And this should be also an exclamation for future development. As soon someone will try to convince you about the only right way to do your business and your development task, just stand up and run-away. Whoever will try to do that, he or she will be desperately wrong. Do not trust one single word what they are saying! There are so many bright and right ways to do things as stars on the clear and moonless night sky.