How to Save JEE, And It’s Not EJB 3.0
I write for a few journals and as I have been talking with editors about story outlines, articles and ideas going forward in 2006, I’ve noticed a huge push in talking up EJB 3.0. In fact, one “highly placed” editor told me flat out:
“Nothing about Hibernate or Spring, EJB 3.0 is coming out, people need to start writing to the standards now.”
Wow. As a person well versed in enterprise architecture and development, 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 JEE is to survive as a platform, we have to stop teaching JEE as a set of JCP blessed related technologies, often complicated, as implemented in the Glassfish reference implementation, may Sun (Ra?) be praised. I believe that the best way to move on to the JEE 5 era and eliminate all the weeping and nashing 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.
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?
When I create UML models or look at others and see lots of Business Object patterns and DAO patterns and Domain Stores in their neat little component architectures, I see JEE Proper: isolation, coarse grained objects, security & independence. Now, what does it matter of company A decides to implement their business logic by plugging a EJB 3.0 embedded in to their JBoss app server, or use Spring embedded in the JBoss application server? If I am a web developer or application developer using a sea of Business Delegates to access the core services of an enterprise application, how does that affect me? 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 webservice processing in our Business Delegate patterns using the Delegate Adapter Strategy?
Some people contend that the whole reason for following only JCP blessed and Sun approved JEE components is that the tools to develop these applications and the application servers that run these applications MUST have one standard to code and test to. However, if JBoss has proven anything, it’s that multiple JEE technologies can be housed in one application server and even made available to the container without compromising or affecting JCP-blessed JEE technologies. In fact, as we have seen, JBoss and Oracle both use their own persisting technologies (Hibernate and TopLink) to implement EJB 3.0. Spring can run inside JBoss, and a lot of enterprise deployers now strip much of the JEE JCP technologies right out of their JBoss configuration to increase speed and improve reliability.
Further, on the tools side, the explosion of Hibernate mappers and Spring helpers for Eclipse, Netbeans and IntelliJ shows us that developers are more than capable in this day and age to add tools that can automate JEE technologies that are not JCP blessed. In a world where our IDEs are platforms in themselves, the flexibility of creating plug-ins to manage complexity in new JEE technologies should not cause anyone to worry about productivity.
I believe that if we are to save the JEE stack, and keep it innovative, we have to allow for non-JCP or even pre-JCP technologies in JEE, and to embrace them as much as possible. Think of what EJB 3.0 or JEE 5 would be like if Hibernate and Spring never existed? Do we really want to now step on the fingers of these programmers and point towards EJB 3.0 as the one true way?
What if we just understood JEE the way it should be understood, as a collection of best practices and server-side solutions, and let the community loose to invent awesome technologies to continue to solve how these technologies in JEE can be better implemented? As this latest JEE upset has shown, we can’t predict what amazing and interesting things are out there from the incredible Java community, and to isolate them from JEE and politically push only JCP technologies in the stack ensures not just the end of JEE for the big guys, but a possible end to all the great work that has been done in JEE engineering regarding software development, the software development process (RuP, Iteration) and development patterns. JEE is much too important to all of us Java developers to abandon it or kill it with inflexible “picks” of technologies to go in the stack.
JEE is about persistence, high availability, scalability, coarse grained objects, best practices and rapid development of enterprise quality code that can be organized and managed by teams and companies through business processes and refactored or scaled by keeping best practices in mind. As we have seen in the past, JEE can deliver on this, even if Sun throws things like the EJB 2.x spec in its way. Let’s keep the innovation going, let’s not return to the days of old.
Java deserves better.
December 27th, 2005 at 11:47 am
Amen to that.
This was one of the most refreshing posts I have read in a long time.
December 27th, 2005 at 2:30 pm
So how do I encourage consultants from big four insulting firms from evangelizing J2EE? After all, much of the “strategy” within enterprises is created by tem…
http://duckdown.blogspot.com/
January 12th, 2006 at 11:44 am
> Think AJAX. AJAX is not a set of any one company’s technologies,
OMG!!! Ajax started as a Microsoft technology. Than, if I’m not mistaken, the XmlHttpRequest became a pseudo-standard (in that sense, the ref implementation is the MS ActiveX object). People became aware of it mostly thanks to Google Mail and Google Map started to use it. So that’s why, asking “Why can’t JEE be more AJAX like?” doesn’t make any sense, I think. And as a technology and in principle AJAX is tiny compared to Java EE. How can you believe that anything that big can be this successful without a standardization and cooperation effort from various implementors? Look at what happened to Java Applets! Just because browsers couldn’t produce compliant JVM, the whole technology faded away. Because AJAX is not bigger than a fruit fly that it doesn’t suffer such a problem.
September 30th, 2006 at 10:18 pm
Very timely view point. In order to understand AJAX and it’s trajectory/locus we need to refer to Clayton Christensen and his insights on Disruptive Technologies.
a) Established technologies keep on adding more features and they leave out a lot of folks
b) Simple, sometimes crude/less featured technologies start the low end disruption. These good-enough technologies slowly find acceptance in the low end markets (read less functionalities)
c) The higher end “heavy” technologies would never realize that they are being disrupted (Yagiz’s post is one example, calls it fruit fly !) and eventually they will be replaced by the low end technologies, which by that time would have achieved the feature set that everybody needs, not the bloated set that the original technologies had.
d) What Brandon is saying is that the J2EE realize that it could be disrupted and take actions to change it’s trejectory
October 1st, 2006 at 8:07 pm
October 1st, 2006 at 8:09 pm
Coulen’t get this discussion out of mind and had a few mor thoughts on this very excellent topic posted in my blog …http://doubleclix.wordpress.com/2006/10/02/ajax-java-beans/
October 2nd, 2006 at 12:49 am
Which journal do you write for? I will ensure I not pollute my minds with those and clean them out of my library as soon as I can.
You probably haven’t done any Ajax before. Not that I’m pro EJB, but comparing Java EE and AJAX concluding AJAX is easier and better is plain crap. Yes I’ve done AJAX lots of it. In fact most of my work is focused on RIA right now. It can be done very beautifully when you know what you are doing, but the fact is that there is no real standard and many sets of best practises and some are even contradicting with each other.
The fact that I can do Ajax well doesn’t mean every one can…with almost every system out there with a different AJAX approach, I have to retrain people for every project and understand 10-20 variations of AJAX architecture. Already people are complaining about too many different solutions in JEE and now some amature is trying to say the AJAX situation is better.
Whether EJB is a step forward or backward is subjective and only time will tell, but comparing the AJAX world that is 10 times worst (even EJB 2.* is better and that is quite bad already)…..that just went too far.
October 2nd, 2006 at 9:41 am
Hi Brandon,
I have replied in detals to this post at my blog.
EJB 3.0 and JBoss SEAM is a start to save JEE
Please feel free to provide feedback.
Vishal
October 5th, 2006 at 12:00 pm
February 2nd, 2007 at 7:54 am
I don’t understand why you’re blamed for bringing in AJAX as another example. As with Spring/Hibernate it’s a technology that came up, because the JCP guys didn’t do their job right. Why don’t we get what AJAX delivers with Servlet/JSP or even JSF technologies? Meanwhile, in AJAX we can recognize what’s going on with Spring/EJB 3. It is integrated with JSF.
Further reading:
http://blog.rainer.eschen.name/2006/11/15/successful-software-architects-ignore-standards/
April 13th, 2007 at 11:16 am
I adopted use of Spring early (because of the unnecessary complexity of J2EE) and have been working with JEE 5 from the very beginning. JEE has come along way and is way easier to work with then Spring, unless you like programming in XML. I think that anyone that says different hasn’t really used JEE 5.
For example,
Dependency Injection in JEE 5
@EJB
private Something something;
In Spring you have create some XML beans, make sure to configure the right files to make sure the right beans get loaded, etc. Sounds a lot like deployment descriptors in J2EE. Actually it is much better than J2EE, but JEE is taking the next step.
June 19th, 2008 at 8:28 pm
[...] It is shocking that some people would actually recommend “Java EE to be more Ajax-like”. Java Developer’s Journal reports in story “Why Can’t Java EE Be More Ajax-like“?) that Cincinnati-based Brandon Werner’s blogged: [...]