The second day here at Qcon London was more compelling than the first, from my point of view. There were several themes (I am just talking about what I personally attended).
The first was Java’s mid-life crisis and the reform of the JCP, which I will make the subject of a separate post.
The second was how the BBC runs its web site and its coming “tech refresh”, which was covered in a late “birds of a feather” session (which turned into a drink at the bar). I’ll come back to this later, after I’ve attended the BBC’s further session today.
The third was REST. Stefan Tilkov led a track on SOA, REST and the Web. Now, the general theme of this (following on from the Fowler/Webber session the day before on the shortcomings of the Enterprise Bus) is that SOAP and WSDL and WS-* have failed to deliver and that REST is fundamentally a better approach to designing distributed inter-application systems. What’s wrong with WS-*, SOAP and WSDL? Too many standards; too complex; too brittle; too incompatible; too few free and open source implementations; leaky abstractions; hijacked by middleware vendors who have an interest in keeping technology arcane and expensive.
By contrast REST is being embraced for all sorts of reasons, ranging from purist arguments about the value of resource-based computing where everything has an URI, to pragmatic arguments along the lines of “it works, I can use it, I understand it.” However, if you poke at some of the solutions which are described as REST, it turns out that some are more RESTful than others – using HTTP as a transport for POX (plain old XML) is not necessarily REST.
I’m still learning about this stuff; but I have no doubt of the value of REST. It fits particularly well with certain types of application. It is ideal for Internet mash-ups, for example. It is a natural fit with the Web. It builds on an infrastructure which is mature, proven and scalable.
Still, I have some scepticism about the rush to REST. I recall the early days of SOAP, when it was still meant to be the “Simple Object Access Protocol”, and at the time some of the claims being made for SOAP were not dissimilar to those now being made for REST (and yes, I know you can use SOAP and REST together). Specifically, it was intended to be a simple, loosely-coupled alternative to the brittle, highly complex, tightly-coupled, arcane, vendor-hijacked technologies such as CORBA and DCOM.
Someone yesterday – I think it was Jim Webber – remarked that middleware vendors are eyeing up REST; we can expect them to introduce products that will supposedly bring resilience, security, manageability, governance, scalability, and other good things; but which will also bring baggage that may sully the REST dream.
We may be having this conversation again in ten years as we discuss what-comes-after-REST.
Even if this is the case, I expect that Agile themes like YAGNI (You aren’t going to need it); appropriate planning and appropriate flexibility; communication and team dynamics; breaking hard problems into smaller, easier parts; testability; accountability – these will endure.