Let's talk about exceptions ...
How do you handle exceptions? Do you think upfront about the type of exceptions that you want to catch or do you just let the outside world handle it?

-- Jeroen van Bergen in JW Blogs

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Brewing entity Enterprise JavaBeans

Harness the power of entity beans

By Sandip H. Mandera, JavaWorld.com, 09/01/00

Enterprise JavaBeans (EJB) represents a fundamental change in the world of enterprise software. The EJB specification provides the software development community with the component model, maintains interoperability between EJB and non-EJB applications (including non-Java-based applications like CORBA), and features straightforward programming. The power of EJB resides in the fact that it saves a developer the pain of developing a homegrown infrastructure.

This article will focus on the design and development of container-managed entity beans. I will begin with a brief summary of the changes introduced in EJB Specification 1.1 and follow it with a brief tour of session beans before I delve fully into a discussion of entity beans (the fun part).

Improved recipe

EJB Specification 1.1 tightened some of the issues that were loosely defined by Sun Microsystems in version 1.0. These are the changes/modifications, as defined by EJB Specification 1.1:

  1. Mandatory entity-bean support for container providers.
  2. Improved support for EJB environment management, which means the bean provider must specify the bean's entire environment using entries in a JNDI context.
  3. Clear lines of separation between the roles and responsibilities of the bean provider and that of the application assembler.
  4. Removed support of deployment descriptor features that described the deployer's output. Also, the deployment descriptor is specified in XML.
  5. JDK 1.2 caused the EJB container vendors to change their runtime libraries with the Java class java.security.Identity to java.security.Principal interface.
  6. The package name of the javax.jts interface has changed to javax.transaction. Also, modifications were made in the thrown exceptions.
  7. All finder methods must throw the FinderException.
  8. ejbCreate() requires a different value. Instead of void(), ejbCreate() returns the primary key class reference.


As a component developer, you must understand what each bean flavor provides its clients. EJB Specification 1.1 supports both session and entity beans. Before we brew the beans, let's taste each flavor.

Taste session beans

Before tasting the session beans, we must first understand their main ingredient: their sessions. A session represents a conversation instance. And like any conversation, a session exists for a limited period of time. It ends when the thread connecting the conversation dies.

A session bean is a logical extension of the conversation instance, but resides on the server. For its entire life, a session bean exists in the container, which manages security, concurrency, etc. Also, the client view of a session bean does not depend upon location. A session bean presents the same set of APIs to its client, which can be another EJB, a Java applet, a Java application, a Java servlet, or a CORBA client. Whether the client runs in the same Java VM as the session bean is immaterial.

Unlike entity beans (which I will discuss later), session beans do not advertise their identities. Thus, session beans appear to be anonymous to the client. Because of this, when EJBObject.getPrimaryKey() and EjbHome.remove(Object primaryKey) methods are invoked on session beans, you obtain java.rmi.RemoteException. This means component developers should not provide finder methods when writing session beans.

Resources