"SOA is bigger than Java," says Brandon Werner (pictured), which is why BEA, IBM and the rest "aren't even submitting their SOA ideas to the JCP at all," he contends.

"In a world where we are moving to a SOA style of implementing business processes and modeling business needs into the architecture," Werner continues, "we must stop thinking in terms of concrete technology (faster bubble sort, smoother scrolling) and start thinking in terms of patterns and methodologies that best address the problem we are solving.

Cincinnati-based Werner's blogged observations bear the provocative title "How to Save JEE, And It’s Not EJB 3.0" and are spurred, he says, by his noticing what he discerns to be a concerted push by technical editors on "several journals" that he doesn't name (but which don't include Java Developer's Journal as he's not to date written for JDJ) to "talk up EJB 3.0" at the expense of frameworks like Hibernate and Spring.  

"As a person well versed in enterprise architecture and development," Werner declares, combatively, "I find this inevitable push to bury Hibernate and Spring as throwing a lot of very good tools down the drain in order to continue the Sun monarchy and JCP worship. However, from the enterprise viewpoint, it doesn’t matter if you use EJB 3.0, Spring or even Hibernate to eliminate the DAO issues in dependent objects of light-weight Composite Entity patterns, it’s all JEE to the architect."

"If Java EE is to survive as a platform," he continues, "we have to stop teaching JEE as a set of JCP blessed related technologies, often complicated, as implemented in the Glassfish reference implementation...I believe that the best way to move on to the JEE 5 era and eliminate all the weeping and gnashing of teeth that EJB 1.x and EJB 2.x introduced to developers is to teach JEE as a set of patterns and ideas, abstract from the actual implementations of various providers, and label them as best practices of the enterprise space."

Then Werner throws his bombshell: "Think AJAX."

"AJAX is not a set of any one company’s technologies, and there is not even a 'reference implementation' of it. You are free to use any backend you want, use any persistence you want, and even implement your own call-backs and improvements. The only thing AJAX is are a set of extremely important best practices and patterns developers use to create compelling web clients. Why can’t JEE be more AJAX like? Why do we have to politically migrate towards these reference JCP technologies when the actual, real JEE patterns don’t give a damn what you use?"

Werner reports in his blog that his comments already caused Gavin King (inventor of Hibernate & EJB3 spec) to take him to task on arguing to leave JBoss and JEE more open to disruptive technologies like Hibernate.  Posting his comment over at Javalobby, King counters that he doesn't see how his project is being "buried," as Werner claims.

"On the contrary," writes King (pictured below), "EJB3 gives us the opportunity to bring Hibernate and ORM technology to a much, much bigger group of people than was possible before. *You* might be lucky enough to be able to use whatever cool opensource technologies you can pick up off the street, but a lot of people are not that fortunate, and have to use stuff that is blessed by the standard."

King adds: 

"Before damning EJB3, actually take a look at the spec. Compare it to Hibernate. Look at the EntityManager API. Look at the transitive persistence model. Look at the query language. Where do you think those came from? (Yes, the APIs are not *exactly* the same as Hibernate - that is a natural and correct part of the specification process.)"

"Hibernate is not being buried," he continues, "rather, it is becoming the standard. To do that, we had to negotiate and work with other important stakeholders, especially Sun and Oracle. This is all Right and Good, and how it should be. More importantly, since the best practices in ORM are now well-documented in an actual formal spec, languages that come *after* Java will be able to look at the spec to understand how they should handle persistence. Just like Java learned remoting and managed transactions from the C++ community."

"AJAX exists because there is a standard for it: XmlHttpRequest. If you are really talking about AJAX frameworks, well, this is simply a sign of the immaturity of the whole space. In time successful solutions will emerge and eventually there might be a need to write standards. For now AJAX frameworks are all still basically experimental technology."