(Note : I’ve posted this a while back on my personal blog …. But since then i’ve been working on a more general post on Software Architecture and Company Strategy for TIE, I thought this would also belong here as a good background …)

Service Oriented Architecture is the new mantra to ease integration between heterogeneous systems in the enterprise.

Lately, I have been having questions about this approach and this post comes out from different experiences. One being reading Vincent thoughts on the topic.

The other being this excellent and lively presentation by Jim Webb and Martin “architecture guru” Fowler : SOA without ESB. The last was the presentation from Didier Girard during the excellent Université du SI conference in Paris back in early july. The bottom line of both presentations being : the web works. The Web is resources that are easily accessible.

Using Web Services for different systems integration within the Enterprise should be easy. We should have resources easily searchable and accessible. Hence these questions about how relevant Service Oriented Architecture stands as it is implemented today.

SOA the new J2EE (read bloated) solution ?

Are architecture astronauts taking over again ? Discussing the topic with Vincent it just occured to me that SOA was just like the next EJB around. This type of magical thing which is supposed to help “allowing individuals and businesses to focus on what they do best”. Eventually we end up with only one successful project out of 5.

I remember this serverside symposium back in 2003. (wasn’t there though, I was just reading the coverage). That was a cornerstone : Rod Johnson introduced Spring, Gavin King Hibernate and Bruce Tate presented his Bitter EJB book.

For the first time in Java hostory, J2EE myths were started to be analysed in an objective manner :

J2EE Myths and why they are dangerous :

• There are no simple problems
• Database portability is always required
• It’s ok to defer application server choice
• Distrust relational databases
• J2EE developers always know best
• J2EE allows developers to forget about low-level issues
• Achieve scalability through distributing objects (Stateless SesssionBeans with remote interfaces)
• J2EE = EJB

EJB was also the target :

Bruce looked at one of the classic anti-patterns: the “Golden Hammer”. This is the temptation to use this new tool you’ve acquired to solve every problem. EJB has become the modern “Golden Hammer”. Often, this is because people want to put this relatively new, hot technology on their resume.

Scott Ambler reminded that 65 to 80% of J2EE projects were failure and he contributed to make Agile methodologies popular with his Agile Modeling book.

We know how it ended up : Spring became the new J2EE (over industry standards), Hibernate became the standard for J2EE ORM mapping (again over industry standard JDO), Bruce Tate flew From Java to Ruby, Agile methodologies took off, Floyd Marinescu left java-centric serverside (which he had created) to set up infoq, more hybrid technology wise (Java but also Ruby, Rails, .Net) and topic wise (development, architecture but also agile, SOA, etc …).

SOA Vs Agile

I do like this definition of Agile methodologies by Mike Cottmeyer and V. Lee Henson in their essay The Agile business Analyst :

Agile is focussed on driving towards simplicity versus rather than creating systems that manage complexity

The most successful experience I had with Web Services was with a mere XML-RPC standard : Remote Procedure call in XML format over HTTP. This helped us build very quickly a Web Services Layer around a core of services and have all type of technologies (Ruby, PHP, Python, Java) using these services.

My 2 cents on the success of this solution : XML-RPC standard description is one page long. Compare with SOAP’s which is the SOA industry standard agreed on by all the industry big cats and the de facto protocol used in enterprise applications : 20 pages or so of abstraction to please all stakeholders : a pain in the neck for developers and for Agile development.

Gimme a REST

Back to Didier Girard, Martin Fowler and Jim Webb presentations : the future of SOA will be based on the same receipts that make the web the ubiquitous technology the net quickly became. Web is an infinite set of open resources, and the most appropriate architecture for web services should be based on this paradigm.

Besides, the internet has drastically changed the balance of forces in IT world decision making. As Martin Fowler reports it :

Tim Bray contended that the key decisions on technology are made by the programming community. (…) The reason we have so much bloatware in IT is because IT purchasing decisions are usually made on golf courses by people who have lost meaningful contact with the realities of software development.

My bet : in the same way that open source community naturally adopted standards such as Spring, Hibernate, and, to some further extents, RubyOnRails over bloated industry standards (EJB2, JDO and J2E Web Apps respectively), REST should emerge as the natural SOA standard over SOAP.

REpresentational State Transfer aligns Web Services CRUD possibilities to HTTP CRUD support : GET (Read), POST (Create, Update, Delete), PUT (Update), DELETE (Delete) and bring Web Services back to the web : a set of searchable and accessible resources.

I hope this will help saving Web Services from bloatware and help us aligning technology with the business goal.

Like

Unlike