Java Enterprise Edition

Recent articles:

Popular archives:

Inheritance vs composition (1998)
J2EE object caching frameworks (2004)
XFire: Easy and simple Web services (2006)

Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can, or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing heavily in Java's future as a platform for platforms

Also see:

Discuss: Tim Bray on 'What Sun Should Do'

Featured Whitepapers

Build, deploy, and test EJB components in just a few seconds

OpenEJB simplifies Enterprise JavaBeans development

By Nader Aeinehchi, JavaWorld.com, 06/13/05

Print
Email
Feedback
Resources
Discuss

Digg
Reddit
SlashDot
Stumble
del.icio.us
Technorati
dzone

The Enterprise JavaBeans development cycle—build, deploy, and test—is time consuming, partly because EJB components run inside an EJB container, which, in turn, depends on various resources like datasources and a JNDI (Java Naming and Directory Interface) provider. The traditional development cycle can vary anywhere from a few minutes to 30 minutes, depending on your application's complexity, the number of beans, and the EJB container's features. Some EJB containers provide hot-deployment such that any change in the application results in an automatic redeployment. Based on my experience, hot-deployment does not always function properly as a cache cleaner—server restart and redeployment is often needed.

Another challenge with EJB development is using the EJB container's debugger tool. Since the test and the container system run in different JVMs, you must set up a remote debugging environment, which itself may become complex.

Unit testing (with JUnit) EJB components is also not easy. Firstly, the beans must be deployed to the container, which itself is time-consuming. Secondly, you have two options with JUnit tests that are both complex and time-consuming:

The tests run within the container, which requires the tests to be deployed to the container
The tests run in different JVMs and act as a client against a remote EJB container

To address the above challenges, the J2EE community has come up with several good solutions to shorten the EJB development cycle. However, many challenges remain, mostly because of the numerous technologies (EJB, Servlet/JavaServer Pages, Java Message Service, and Java Database Connectivity) a J2EE application relies on. In addition, many competing and complementary solutions are available, and it's difficult to know which one to choose.

As for EJB development, there are varying solutions. One solution is to test the application when it is deployed to an EJB container. Another solution is to test the application on a simulated (mock) EJB container. In the latter solution, when other EJB components or resources (e.g., a datasource) are needed, an external EJB container is called. Nevertheless, these solutions have their complexities and shortcomings.

In this article, I introduce you to a combination of tools that significantly simplify and shorten the EJB development cycle. To give you an idea of the time saved, only three seconds pass from the time some code has changed until the time the test results appear on the screen, using a laptop with a 2.2 GHz Mobile Intel Pentium 4 Processor.

This article is based on my experience with an on-going development project. The project consists of roughly 300 Java classes and 10 EJB components. Throughout the article, I refer to the tools used in the project: XStream, OpenEJB, Eclipse, and Oracle OC4J.

Macroscopic view

Instead of running your test inside a container, run the container inside your test. In this article, we use a lightweight embeddable EJB container inside our tests, as shown in Figure 1.