Brandon Werner

Last month I wrote an article called “How To Save J2EE, And It’s Not EJB 3.0” that sparked a lot of controversy and a public spat with Gavin King (inventor of Hibernate and spec lead of EJB 3.0).

I argued that Java on the enterprise should be moved forward as a set of patterns and best practices, not just a set of JCP approved technologies. In other words, before you had an entire architecture (J2EE) and your designs at the application level had to conform to the architecture of the blessed JCP specification.

Or, in the words of a Jewish proverb, “You cannot break the law, you can only break yourself against the law.”

Well, it turns out that you can also change the law. That’s what I argued in my article, stating that people might not want to get wrapped up in EJB 3.0 propaganda and instead continue to use Hibernate and Spring, as well as push for new technologies that can be applied in a JEE context.

In other words, architecture becomes less important, and design extremely important as businesses develop applications that are more agile and service oriented. Most important, they can customize their JEE space to their business needs, not import the whole elephant just because you want the trunk.
A direct out-growth of that idea is a new article at O’Reilly’s OnJava called “J2EE Without the Application Server” by Guy Pardon, which gives good examples of practical design strategies for non-ejb J2EE development.

That is why I am very excited about JBoss going forward, and very nervous about hearing Oracle was looking to buy them. JBoss might be the way all application servers will look in the future, a pluggable framework of services (some JCP, some not) that offer to annotate a container with functionaity but is light-weight and flexable. You pick the architecture pieces, then design.

I’m sorry Sun, but I think the EJB ship has sailed. It was a good idea that never worked, at least not as transparently as the idea of “JavaBeans that persist state” would suggest.

Soon, ServiceLocator will be replaced by Dependency Injection (also known as Inversion of Control) type annotations in EJB 3. However, as these annotations won’t be available to helper classes like current JNDI lookups are, the ServiceLocator singleton might still be around even after EJB 3’s release, to the dislike of many Singleton haters.

There are some caveats to IoC in EJB3:

1. They are not be available to non-ejb programmers or in helper classes
2. Those who use Composite Entity patterns in their JEE architecture will not have JNDI look-ups available to them in their Dependent Objects and must aquire all their resources from the EJB itself.
3. Those who use Session Facades and Business Delegate patterns for more than EJB lookups will have to continue to rely on JNDI lookups and ServiceLocator.
4. The way IoC is implemented in EJB3 leaves a lot to be desired (not just POJOs with XML files like Spring)
5. This means that those who prefer (or are mandated) to use light-weight web frameworks and code for small to medium web applications will be stuck with JNDI look-ups and ServiceLocator(s) for some time to come.

Therefore, this article seeks to help people who want an honest comparison between the two methods of operation, about where we got where we are today, and how migrating from JDK 1.4.2 to JDK 1.5 might change their ServiceLocator pattern to reflect Java 5 Generics, since ServiceLocator makes heavy use of Collections API to cache JNDI lookups for services.

Do to formatting issues in Internet Explorer regarding all the code samples I used, it’s best if you just read this article on JavaLobby instead: ServiceLocator Pattern: Does EJB 3 Really Kill It Off?.

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.