Brandon Werner

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.

Another very sought after and often Googled code block from my Fatima (JavaPress) project on Java.net is how to use Apache’s XML-RPC to ping update services for blogs, podcasting, email, ect. Many services like Technorati and BlogSpot use XML pinging, and many people get led astray by using Sun’s XML-RPC library which only uses SOAP.

You must use Apache’s XML-RPC. Why? Since SUN Microsystem’s API(s) insist on using SOAP as the transmission protocol but integrators wish to have XML sent instead, you have to use the xmlrpc-1.2 code from the Apache Foundation. Technorati and others don’t accept a SOAP envelope obviously.

So, here is a ping service for you. Just download Apache’s XML-RPC and call the class.

Do to formatting issues in Internet Explorer, I can no longer include the code in this post. You may download it from the Fatima project on Java.net directly or view it in JavaLobby.

Many people have asked how I implemented RSS in Fatima (JavaPress) on Java.net since the object model for Sun’s Rome API is a little.. dense, and suited more for abstract aggrigation in your applications like Technorati. However, Rome is extremely powerful and offers lots of transformation and organization of your RSS feeds (no matter if you generate them or you grab them). Well, below is a general class that implements everything you would need to start generating your own RSS feeds using the ROME API, and for everyone that wants to get started quick this example should help you out.

doSyndication() is where you’ll want to focus your attention.

NOTE: This generates both regular RSS and shows you how to generate RSS with the embed tag for Podcasts!

Do to formatting issues in Internet Explorer, I can no longer show the code in this entry. You may download it from the Fatima project on Java.net directly or view it at JavaLobby.