Welcome!

Java Authors: Andreas Grabner, Liz McMillan, Tim Hinds, Elizabeth White, Cloud Ventures

Related Topics: Java, AJAX & REA

Java: Article

Why Can't Java EE Be More AJAX-Like?

"SOA Is Bigger than Java," Contends Brandon Werner, Decrying Both the "Sun Monarchy and JCP Worship"

"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."

Asked by JDJ News Desk about the "Think AJAX" part of Werner's blog posting, King's response was as follows:
"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."
It all goes to show that the new year, 2006, will be as lively a year for Java as any for a while. Hold on to your hat!

More Stories By Jeremy Geelan

Jeremy Geelan is Chairman & CEO of the 21st Century Internet Group, Inc. and an Executive Academy Member of the International Academy of Digital Arts & Sciences. Formerly he was President & COO at Cloud Expo, Inc. and Conference Chair of the worldwide Cloud Expo series. He appears regularly at conferences and trade shows, speaking to technology audiences across six continents. You can follow him on twitter: @jg21.

Comments (9) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
JDJ News Desk 10/31/06 01:58:54 PM EST

'SOA is bigger than Java,' says Brandon Werner, 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, 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.'

SYS-CON Australia News Desk 10/30/06 08:59:45 AM EST

'SOA is bigger than Java,' says Brandon Werner, 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, 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.'

Vishal 10/02/06 08:22:15 PM EDT

I have replied in detail to recent chit chat in blogosphere about how EJB 3.0 and JEE should evolve.
EJB 3.0 and JBoss SEAM is a start to save JEE
Please feel free to provide feedback.

Vishal

Sreenath V 10/01/06 02:07:43 PM EDT

Dear All,
The Author is immature and i believe he has no experience in Enterprise development. He thinks internet application is all about AJAX. There are lots of other enterprise internet based application that really doesn't need AJAX based web applications, B2B uses webservices, EAI to communicate b/w application via internet...

Dear Author, please stop this kind of blog and be constructive rather than Destructive in your blogs. If this hurts you, i am sorry but you need to be constructive.

Regards,
Sreenath.V

Lambda Hacker 11 10/01/06 01:28:08 PM EDT

public Class KnowItAllJavaWeenie implements
EnterpriseBullShitInterface, TooManyAcronymsInterface,
PatternKnowitallInterface,
ArchitectsAreWaySmarterThanYouInterface,
ThinksJavaIsCoolInterface {
// there's nothing really to this implementation
}

Augusto 10/01/06 12:32:59 AM EDT

"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."

No, you need to go back to CS 101.

Only morons are thinking about implementing a >>> "faster bubble sort" <<< ! The statement pretty much speaks for itself and actually means you not only have to be thinking about "concrete technologies" but you have to go back and learn basic algorithms and fundamental CS principles before thinking about simple patterns and be buzzword compliant.

j j 09/27/06 06:29:52 PM EDT

'SOA is bigger than Java,' says Brandon Werner, 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, 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.'

Dan Toraason 01/09/06 12:14:43 PM EST

After actually reading the article, I see that it is not about AJAX at all :)

But it is a change in thinking. I tend to agree that we should be less concerned about specific technologies (such as Hibernate), but should be more concerned with choosing and using the correct patterns correctly. That is really what software architecture is about and where its benefits come from, not from technology selections. I also agree, that to get the best benefit and reusablity and interoperability, we, and the industry, need to be looking at standards that provide uniform ways to implement the correct patterns. If I get it at all, that is what J2EE was always about. It's just that instead of waiting for J2EE to evolve as a standard (that's micro-evolution, not macro-evolution, just to be clear), anxious developers have built "competing" technology that will likely find its way into the standard JEE stack, it's just a matter of time. Standards necessarily take time to solidify.

So the question is not J2EE OR AJAX, its how to do AJAX with J2EE in a standard way. Or J2EE with Hibernate-like persistence. Or J2EE with Lightweight containers (ala Spring).

Don Babcock 01/04/06 01:35:21 PM EST

I believe that Brandon is correct in asserting that "SOA is bigger than Java." I've been in this business for over 30 years now and I've seen languages come and go in the mainstream but the problems remain pretty much the same year after year. The real progress will be made as we focus on that layer of abstraction. In that respect, recognition of patterns in the problem space and the development of best practice approaches will yield the best fruit. As much as I love Java, I do not expect it to last much longer than FORTRAN, C, COBOL, C++, Smalltalk, and many other languages which have all had their time on center stage. The various "frameworks" are all steps in moving us toward what will come after. If I could see clearly what that was, I could be the next Bill Gates (g). But it's clear that convergence on standards is key to real progress. Imagine how awkward it would be if one part of the country used different electrical standards than another (i.e. something other than 60Hz 120VAC.) It's bad enough having to have both metric and SAE tooling in my tool chest. As much as science fiction technologies seem to become science fact, I've wondered about the standards that Scotty (Star Trek) would have enjoyed. He never seemed to have a problem adapting the circuits in the food replicators to fix the phasers just in the nick of time. No Token Ring vs Ethernet for him - no VHS vs Betamax. Hibernate, AJAX, et al are approaches that will make their contributions and then we'll move on. There was a time when we all wrote out our own data stores. In the 80's RDB's and SQL largely relieved us of that burden just as word processing technology did away with the old SCM typewriter for all intents and purposes. It's hard to imagine an architecture that would abstract us from the tedium of the same old coding to the same degree that SQL and RDB's relieved us from read and writes to filesystems but it seems to be coming. These all seem to be steps in that direction. I can't wait.