Featured White Papers

• What Developers Want: The End of Application Redeploys

Sponsored Links

• Career opportunities at Harman- Careers That’ll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Brewing entity Enterprise JavaBeans

Harness the power of entity beans

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

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.