Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Make an EJB from any Java class with Java Reflection

Make any single-tier Java application into an enterprise application

By Tony Loton, JavaWorld.com, 12/15/00

Every EJB application server allows you to install an EJB if you provide a bean implementation, remote interface, and a home interface but, in most cases, you have to write them yourself. That is unavoidable and worth the effort for brand-new EJBs. But what if you have an existing class that performs the tasks you want your Enterprise Bean to do? Wouldn't it be nice to say, "Make me an EJB that does that?" Taking the idea further, what if you use those classes within existing applications? Wouldn't it be nice if the applications could be modified easily to use your new EJBs without having to manually replace every class instantiation with a JNDI lookup followed by a HomeInterface.create()?

The idea first occurred to me near the end of 1999, while working with the ObjectSpace Voyager Application Server, and I have subsequently applied the idea with Oracle Application Server. Next, I will turn my attention to the J2EE reference implementation.

What's the big idea?

For any EJB that you wish to install in an application server, you must supply three Java classes: a bean implementation (for example, BankBean.java), a home interface (for example, BankHome.java) and a remote interface (for example, BankRemote.java). The bean implementation provides the functionality, the home interface allows you to lookup and create new bean instances, and the remote interface allows you to communicate with the bean. That is all shown for an EJB called BankBean in Figure 1.

Figure 1. BankBean implementation, home interface, and remote interface

So for a new EJB, you need three Java classes, each of which must adhere to the EJB specification. For just one new EJB, creating three classes -- all EJB compliant -- might not be so bad. But if you're creating lots of EJBs -- perhaps from functionality you've already coded into existing classes -- a more automated solution would be beneficial.

The basis of my idea is, therefore, to produce an EJBWizard utility that will take any given Java class and generate all of the additional support classes that will allow it to be used remotely as an EJB. I have set myself the additional requirement that the original class should be left unchanged. That will allow the class to be used locally as it is now and will enable functional changes to be made more easily in the future. That means that the bean implementation that I will generate will be a wrapper, which delegates method calls to the original class, instead of a modified version of the class itself. You will see what that looks like in Figure 2.

Figure 2. BankBean implementation delegating to Bank

Thus, existing applications will be completely unaffected in their use of the original class, whereas new applications that will use the class' EJB version will now have to use JNDI to look up the home interface and then call create() on the home interface to access an EJB instance through the remote interface. To make it easier to write new client applications and to facilitate the conversion of existing applications to use the distributed versions of their classes, I will add a client-side factory that hides the details of the JNDI lookup and creation via the home interface, as seen in Figure 3.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.