I got a lot of heat for stating that the way to save Java EE was to focus on architecture and not concrete JCP implementations. Although my metaphor regarding AJAX was over-represented in the press, I still believe that we shouldn’t be so concerned about using non-JCP technology in implementing Java EE architecture.
As I stated a few weeks ago:
If I am an enterprise developer, and the architect has done his job of abstracting DAO and dependent objects from the Business Objects, I can quickly plug and play from Spring to EJB 3.0 quickly. That was the whole point of DAO patterns in the EJB 1.x and early EJB 2.x days; so that when this mythical time came when CMP EJBs were fast and ready for wide deployment we could just implement that, clean the overrides and slice off the DAO / JDBC side… Why was it acceptable to do this during the J2EE 1.4 days with EJBs, but is sacrilegious to do so now to allow for Spring vs. EJB 3.0 plug-and-play? How does it not help JEE principles to write Adapter patterns to do this anymore than it did to abstract the dependent objects from DAO or to incorporate XML web service processing in our Business Delegate patterns using the Delegate Adapter Strategy?
I got knocked by Gavin pretty hard on talking down EJB 3.0, but I can’t help but think that now that his technology has been integrated in to the JCP (i.e. he won) he has become a little bit of a cheer leader for all things JCP. I wonder what he would think of Jerome Louvel’s Restlet project, a implementation of Roy T. Fielding’s excellent doctorial thesis on the REST architecture style.
The Servlet API has grown significantly over the last few years, with the addition of JSP, JSF and web service consuming all being stapled on top of the common API. Essentially, anything that has to do with HTTP travels through servlets. Although extremely simple and flexible at the base level, which has allowed for so much to be implemented on top of it, it has begun to show it’s age in its general philosophy towards persistence and mapping of sessions. Restlet is a replacement for the Servlet API and provides a lot of advantages over Servlets in HTTP communication, particularly for web services. Why has Restlet generated so much attention lately? Simply put, once again someone has decided to throw off the shackles of JCP-implied restrictions and write a solution that does not have to be crippled by the problems of the previous architecture (NIO blocking, session persistence). As we move in to thinking about SOA and the speed to which we can access and process web services from the ESB, Restlets might have appeared at just the right time.
What Spring and Hibernate did to EJB 2.x and J2EE in general, Restlet promises to do to the Servlet API.
This could mean more than just a replacement of course, but an eventual adoption and approval by the JCP. Just like Hibernate and Spring did to EJB persistence and Dependency Injection (killing my favorite asexual pattern, the Singleton), even a change in mind-set or “what is possible” could impact the next round of JCP submissions. In fact, This may already be happening as we speak.
This addition of Restlet to the Java EE open source landscape confirms what I have stated about programming to the problem domain using JEE best practices instead of just writing to the JCP specification. Those Jave EE architects who model the problem with an open mind when picking the best technologies for their next start-up or super-go-fast project will be the winners and push Java as a platform forward, particularly in SOA implementations where Java does not have the web service speed advantage.
As Gavin pointed out in his response to me, developers in Fortune 500 companies won’t be using Restlets, but then again they didn’t use Hibernate or Spring either. Although it is certain that these larger companies will always write to the vendor-pitched JCP standards, I believe that this is a demonstration of a weakness, not a strength. After all, what disruptive new way of doing something did any established company introduce? Why do they always kick themselves and try to catch up, when the obvious answer all along is that you don’t change things unless you are willing to take risks in technology?
Restlets, and its implications on the performance and flexibility of web services, is such a risk that could yield huge rewards. Unfortunately, the next Google (or maybe Google itself) will be the ones that deliver on this reward, while IBM and Sun will be demonstrating their Servlet tied technologies to Fortune 500 companies that will gawk at the idea of using such slow communication to and from their new SOA inspired Enterprise Service Bus.
But hey, at least it’s JCP approved and backwards compatible.
If anyone needs any more examples of how behind Microsoft is in its core businesses 
