Aehso’s Output

I previously criticized a post by Dion Hinchliffe’s on WOA/Client but to be fair to Dion I have to compliment him on his latest post about the SOA world beginning to consider the Web-Oriented Architecture(WOA) in earnest.

Dion has continued to do some very deep thinking and about *OAs and this post reflects this effort – it should be immensely useful for anyone looking at how to evolve existing SOA systems over to a resource oriented architecture. I’m well past the ROA vs SOA debate (a ROA is a subset of SOA) but one lingering concern that I have about this and other discussions is this distinction between ROAs & WOAs.

I’m not quite sure that I can see a clear distinction between the two and I think having two TLAs for what may be the same underlying architecture type may be hindering understanding. Almost every core feature of WOA systems is derived from the underlying RESTful constraints. I’d imagine that if we could do away with one of these TLAs then the underlying concepts, and the differences from big-SOA, will become more accessible to all. (Note: I accept that there are non-RESTful anomalies out there mixed onto the www substrate but these edges always seem to fall by the wayside as the www has evolved.)

When I get chance I’ll try write up something more detailed on this but in the meantime if you have some clear examples of use cases where a WOA is a distinct superset of ROA then I’m sure they’d help my thinking.

aehso architecture, enterprise, rest, roa, soa, woa roa, soa, woa

Wonderful post (and followup) by Steve Vinoski, spawning lots of other discussions.  I should be surprised by some of the comments but… I’m not – I suspect agendas, pride and reputations may be at play.  Imho, and I stress humble opinion, his views are completely valid. Can enterprise architects disregard the architecture, constraints and protocols that helped the Web scale and adapt to be the global platform it is today?  If they want to build something that will adapt and scale then I also think the answer has to be No.

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.

aehso architecture, atom, django, enterprise, esb, internet, python, rails, rest, rss, ruby, sca, soa