Platforms like ESBs were built to solve the problem of interconnecting and integrating enterprise systems. The disconnect between how an ESB-based or RESTful solution approach the same problem can mostly be explained by the fact that they both evolved from very different starting points, and therefore have very different principals at their core. 

ESBs, having evolved from DCE-RPC, CORBA based RPC architectures, have always required static definition of non-uniform remote interfaces.  The modern WS-Deathstar-type ESBs are still based on this concept, with WSDL interface typically backed by statically compiled implementations (or if you are exotic XML based mediation languages).  The remote interface semantics can be augmented by a variety (cluster f&@k?) of ‘enterprisey’ features like transactions, routing and reliability defined by a collection of related specifications but it turns out that implementations based on some of those specifications do not interoperate or scale.  This is primarily a function of questionable specification development processes and over complexity.

In the end the non-uniform interfaces at the heart of these solutions tightly couple the clients and servers and this coupling is the underlying limiting factor on the adaptability and extensibility of these systems.  I still really struggle to find a successful real world internet-available IDL or WSDL based web service that has been used in a series of completely unexpected contexts (i.e. mashups) or that has evolved beyond more than one or two revisions without completely breaking backward compatibility for old clients.

In parallel the RESTful HTTP standard emerged and provided the platform for the Web that has scaled and adapted to truly global proportions.  This wasn’t an accident – the Web succeeded because of the RESTful principals upon it was built – stateless, client server, layered systems that support caching and of course the true use of Hypertext As The Engine Of Application State (thankfully now referable to as ‘the hypertext constraint‘).  To me HATEOAS is the most critical feature of RESTful solutions. It is the one feature that negates the need for non uniform interfaces and it is here where the two approaches diverge dramatically.  It also isn’t an easy concept to grasp for folks who are used to traditional RPC oriented systems. 

Regardless, the recent emergence of dynamic languages like Python and Ruby, and their respective web application frameworks, Django and Rails, is now making it economically efficient for anyone to produce RESTful web services that can scale and that are reusable.  Steve is just expressing his opinion that this approach works better.

Don’t get me wrong – the ESB approach has been proven to succeed and
scale but primarily in limited deployment environments and usually only when considerable resources are thrown at the solution.  To put it another way, the inherent limits in non-uniform interface based systems can be pushed through use of sophisticated tools and language bindings but this only be achievable when considerable resources are thrown at the solution.  I think this is what Steve is getting at – I don’t think Steve is saying ESBs are “bad”, just that they are not the best platform for building internet scale services/resources

(Hey, check it out, I didn’t mention SOA once!)

BTW, I’m reading The Future Of Ideas at the moment, hope to write more about that soon, but it does relate to the notion of control mentioned in Steve’s latest followup post.

Rails Hydra: Synthesizing an Application out of Multiple Rails Codebases (Craig R. McClanahan, Nick Sieger, Sun Microsystems)

Good talk on building services using several Rails applications, the Sun guys also got a chance to demo use of NetBeans 6 for Rails development (with some live demo debugging thrown in along with great audience participation!) Most of the demo centered around making it easier to develop DRY ActiveResource implementations. ActiveResource is almost definitely the right underpinnings for any RESTful service implementation but I think it still needs a bit more work around the edges.

Using a HAXOR Approach for Peace and Productivity (Tim Dysinger)

Good talk on how to manage interaction between designers and developers when developing Rails applications that use HTML, Ajax and XML Over REST. Quite high level (and if I’m honest, I was working away in the background so I couldn’t give it my full attention…)

Browser-based Testing of Massive Ajax-using Rails Applications with Selenium (Till Vollmer)
Good overview of using Selenium to test web applications from within the browser, covering use of Selenium IDE (browser based Javascript IDE), Selenium RC and the Selenium on Rails Plugin. Highlighted that Selenium struggles a bit with testing Ajax heavy web pages but it is possible with hand crafted scripts that use waitForVisible and/or waitForElementPresent events…

Functional JavaScript Development with Prototype (Ben Nolan)
Bit of an edge talk for the JavaScript fanatics but Ben presented well and it seemed well received by the audience…

Ruby on Rails leads you to the e-business (Quentin Tousart)
Mildly interesting talk on experiences gained in building two e-commerce websites using Rails.

Obscure Data Formats, Workflow, and Remote Synchronization (Chad Thatcher)
Another interesting case study on building a Rails front-end for a legacy data format (in this case the RISM format used by the British Library to catalog music manuscripts). Interesting use of composed_of in the Rails model objects to compensate for the fact that the underlying data was in hierarchical rather than relational form.

That’s about it, I met up with Sean Hanley from exoftware and David Rice . Mental note to self, get into RubyIreland…