Future of EJBs: Tools Are Finally Catching Up

Enterprise JavaBeans have been around for a while now, but are still considered by many to be difficult and cumberson to program with. When new technologies like EJB jump onto the scene, it sometimes takes awhile for them to actually become easy to use. After some dust settles, we often end up with best practices, patterns, and tools. We are currently at version 2.0 of the EJB spec, but how far have we actually come?


Enterprise JavaBeans have been around for a while now, but are still considered by many to be difficult and cumberson to program with. When new technologies like EJB jump onto the scene, it sometimes takes awhile for them to actually become easy to use. After some dust settles, we often end up with best practices, patterns, and tools. We are currently at version 2.0 of the EJB spec, but how far have we actually come?

This article will address the maturity of EJB from our perspective as EJB developers, including:

  1. What development tasks do we have to do (but shouldn't need to!)

  2. Do IDEs help?

  3. What other tools are out there?

What tasks do we have to do

When you first start with EJBs you quickly learn the steps that you need to go through, to create and deploy a bean:

  • Create a Home Interface (local and/or remote), Component Interface (local and/or remote), a Bean class, and maybe a Primary key

  • Compile those Java source files

  • Create XML deployment descriptors (ejb-jar.xml, vendor specific: weblogic-ejb-jar.xml, ejb-inprise.xml, etc)

  • Package the code and deployment descriptors into a jar file

  • Maybe: Run a vendor specific command to build the stubs and skeletons. This doesn't seem to happen as much anymore, as the servers do that for you

In the beginning, you learn how to create the source code for the interfaces. You work out which interfaces to extend, and the type of method signatures that you need to place in them. You make the mistake of thinking that the bean class will implement the Remote interface, but after some reading, you work out the methods that you need to create in the bean and finish it all up.

Then you get to work on the deployment descriptors. It all seems simple for a minimal session bean. You move on to work on an Entity bean and make the mistake of mixing up <prim-key-class> and <primkey-field>. You curse as you forget which one has the hyphen, and have to go look it up. That is a small thing though; overall, it is still easy to setup the XML descriptor right? Wrong.

It is a real pain to configure the method permissions and transactions on beans. There is no way you want to touch that by hand, but that is nothing compared to working with relationships in EJB 2.0 CMP. Holy cow, the simplest relationship becomes a mess of XML. If the simplest example is so hard to read, imagine what it looks like when you have real world relationships all over the shop!

I do not want to look at XML. I do not want to manually edit XML. The XML deployment descriptors should be for computers to see, and not for humans to work with directly.

Do IDEs help?

Have you used the latest IDEs recently? In the past, I have often found that IDEs have gotten in the way, and are buggy when it comes to EJB support. However, the newest batch seem to be getting better and better.

In my last project, I decided to use JBuilder 5 Enterprise, aiming to get as most as I could out of the platform. I had a really good experience. Here are the tasks that I used the IDE for:

  • Generate as much of the EJBs as possible

  • Development with an EJB server

  • Package the EJB (including deployment descriptors)

Step One: Generate as much of the EJBs as possible

Firstly, I went through the session beans that I wanted to use. JBuilder automatically generated a Home, Remote, and a Bean class for me. This is a good thing. I think that the interfaces should be built from the code where possible, and if I am doing something 'strange' I can go in and tweak it. Ideally, a tool would allow me to say 'Put this in the Remote interface', or maybe 'Don't put this in the Remote interface' and then I would never have to touch it.

Secondly, I used the Entity Bean Data Modeler to build all of the Entities that I needed. After pointing to the database, I could create beans mapping to any of the tables, and all of the code, and deployment descriptors were built for me. Another great time saver. This tool was good for simple beans, but nowhere near as good as tools such as Thought Inc.'s Cocobase and WebGain TOPLink. As a developer, I love being able to tell a tool how I want to model my data, and have it create the code for me' this is the way it should be! With Cocobase I can decide to create BMP beans, or CMP, all within a nice visual interface. I am dragging and dropping my visual data model, able to map to fields in a table, or even to stored procedures. These tools save a lot of time, and allow me to refactor my code easily.

Step Two: Development with an EJB server

One feature that I loved, was being able to have an EJB server running within JBuilder. For quick debugging this was fantastic, as I could right click on my EJB group and say 'Run'. JBuilder would automatically go out and compile code that had changed, and deploy it into an EJB container (BEA WebLogic, IBM WebSphere, and of course Borland AppServer). Add to this the distributing debugging support, and you will greatly hasten your EJB development. Why would I want to write custom scripts (or ant build.xml files) that compile my code, package it as a jar file, and then do the deployment into a running development server?

Step Three: Package the EJB (including deployment descriptors)

I never saw XML (well I did take a peak at the source). The group of EJBs can be packaged how you want, and a deployment descriptor editor really helps you out. I can't mistype things in my deployment descriptor, as options are drop down menus. When I create an EJB Reference I am shown the EJBs that I could create an <ejb-link> too. These things are nice, but you see a greater power when you go into the method permissions and transaction attribute areas of the tool. Now a monkey could setup the correct permissions, whereas you would have to be delicate if working with the raw XML tags. When I build my project the result is a nice jar file, with all of my classes, and deployment descriptors that do the right thing.

Thank you. IDEs are finally here to help us. I have been talking about JBuilder, but there are many other great IDEs out there. I am personally a great fan of TogetherSoft's Control Center product (the entire suite in fact). I like TogetherJ because the model is always in your view. At a philosophical level, I think it is good for developers to be viewing and working with the model. This view is NOT just for architects. The only issues with these products are their lifecycles. They often seem to be behind the times, and maybe don't support the latest and greatest (e.g. some not supporting EJB 2.0). As EJB becomes increasingly mature, it will stabilize, and these problems will fade away.

What other tools are out there?

More and more tools are coming forth. One tool that I really like is EJBGen (http://www.beust.com/cedric/ejbgen/). This is a command line utility that takes a bean class that has special JavaDoc tags, and will build your interfaces, other classes (such as Value Objects, Primary Key), and XML descriptors for the beans. As a developer, I am just working in one file, the bean class itself. There is something clean and simple about having the 'unit' of the bean being just one file. There is a similar tool called XDoclet (http://sourceforge.net/projects/xdoclet/), which has been extended to work with all J2EE pieces, not just EJB. This allows you to generate your descriptors for Web Application, and application.xml files. XDoclet also supports many vendor specific descriptors, unlike the BEA WebLogic focused EJBGen.

On the GUI front, there is a tool called EJBCreator that generates source code skeletons for EJB 2.0 beans, value objects, primary keys, ejb-jar.xml files and even Ant build files. MiddleGen (http://boss.bekk.no/boss/middlegen/) is a GUI wrapper around EJBGen and XDoclet.


As the EJB specification, and server implementations mature, we are finally seeing the growth of tools. We do not want to be mucking around in XML descriptors; we want GUIs and command line tools to hide these ugly angle brackets from us. Check out some of the great applications that I talked about, and if you feel adventurous, join in with the open source ones. If you know of any other good ones, post that information to TheServerSide! A lot of these tools are young, and need to get a lot better. Maybe one day we will be up to the level that Smalltalk was at years ago?

Dion Almaer is Senior Enterprise Educator at The Middleware Company; he provides its clients with architecture consulting and training in requirements gathering, architecting and modeling their e-commerce applications (with UML), and implementation with EJB/J2EE based application servers (primarily BEA WebLogic). Dion also has significant experience with higher-level E-commerce infrastructure such as BEA's Commerce Server, Personalization and Portal Server, ATG's Dynamo, and Inference's kCommerce. You can reach him at dion@middleware-company.com

Dig Deeper on EJB specification

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.