Brandon Werner

Archive for the ‘JPA’ Category

End of EJB Gaining Momentum?

Thursday, February 9th, 2006

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.

Quickly: Conversation on EJB3 continued, Mac Love, Wordpress 2.0

Friday, December 30th, 2005

Good conversation between Gavin King (inventor of Hibernate & EJB3 spec) and myself regarding my article on Java Lobby. He takes me to task on arguing to leave JBoss and JEE more open to disruptive technologies like Hibernate was.

Also, I’ve been busy moving all my code and environment over to my new iMac G5 I got myself for Christmas. I have been using Powerbooks for two years now since a lot of my work takes me all over and I needed a powerful system to follow me. However, considering it might be nice to have a dedicated desktop system to use when at home, I decided an iMac G5 was just enough of an investment to last me till the Intel chip switch (investing in a PowerMac at this point without seeing the Intel benchmarks would be a lot of money invested in an old platform). The Apple Store at Kenwood Towne Center did give me an (unintentional?)free upgrade that I didn’t want by giving me the iMac G5 with the wireless keyboard and mouse ($89 extra at Apple Store online). Unfortunately, I didn’t want this option because I was looking forward to getting the Mighty Mouse included for the right mouse click. Yes, I know they are generally bad and I do have a two button MS mouse, but I at least wanted to give it a go. I’m not certain if they were out of Might Mouse iMacs or if it was a packaging error (the employee scanned the box, the additional cost was not there).

If anyone doesn’t know about Apple’s excellent online service yet, .Mac, it is truly an incredible synchronization technology that is woefully missing on the Microsoft platform despite their attempts to do something like it in MSN. I moved all of my important documents, keynote presentations and code projects I wanted to be transparent across my Powerbook and iMac on to my Apple provided 2 GIG iDisk and told both to synchronize but keep a local copy (for speed). Also, .Mac synchronizes all of your calendar entries, address book entries, email, bookmarks, keychains (passwords and forms for the web and drive shares) and other system settings between the Powerbook and the iMac seamlessly. If you code on the iMac for two days, add lots of code to the project, and then open your Powerbook.. there is your code on the Powerbook. Same with an appointment you add to your Powerbook during a meeting, as soon as you go home and log in to your iMac.. there it is.

I knew it did this in theory but I had never before used it to keep everything in sync. It works wonderfully. (Both Mac OSX 10.4 Tiger, your mileage may vary).

It is a platform in itself, with the latest .Mac SDK 2.0 (Developer Preview 2) just released, which allows third party providers to write to this sync technology. Transmit, a great graphical FTP application, uses this SDK so that your list of FTP sites (and username / passwords) are updated between your computers - directly in the application - so that as soon as you launch Transmit the new FTP sites you may have added on your Powerbook now appear on your iMac. NetNewsWire also uses this to keep your RSS feeds synchronized across Macs, even keeping track of which articles you’ve read and which you have not. It’s not hard to imagine the other great applications using this technology.

Also, IntelliJ Idea on the Macintosh platform is a joy, although people should be wary of Apple’s latest J2SE 5.0 Release 4 Developer Preview 3 that appeared on the developer site two weeks ago, it seems to have some Swing bugs on redraw. I’d stick with the Apple J2SE 5.0 Release 3 for now.

Finally, I upgraded the site to Wordpress 2.0 two days ago. If you didn’t notice, it’s because it took 5 minutes (plus about 30 minutes to re-apply my stylesheet and code modifications I made to the old site). Wordpress has made the upgrade very easy, but for a 2.0 release the feature-set has not been added to greatly. However, a lot of the changes are under the hood and the site does appear faster. It even includes the AJAX goodies all web apps must have these days, but they are mostly just visual candy. For instance, when you delete an item the list fades to red and then disappears. Wooooo. Ahhhhh. Pretty!

The best things are to come in the future to be certain, when the plug-in developers begin working with the new 2.0 API. However, if you are holding off on upgrading to Wordpress 2.0 on downtime concerns, it’s not really an issue.

How to Save JEE, And It’s Not EJB 3.0

Tuesday, December 27th, 2005

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.