Developing Entity Beans

1. Set up a data source to a database.

2. Develop a primary key class.

A primary key is a unique identifier of a Java object that doesn’t necessarily have to relate directly (or at all) to a primary key of a database table. It isn’t always necessary to write a primary key class because it is possible to use Java objects defined in the entity bean class such as Strings or Integers as primary keys. Primitive types such as int can be used only if properly wrapped by Java objects.

A primary key class is defined inside of the deployment descriptor. Although an entity bean class can define a unique class as its primary key, it is possible for multiple entity beans to use the same primary key class. If two entity objects have the same home instance and the same primary key, they are considered to be identical.

3. Develop the Entity Bean Class.

This is where the bulk of the business get/set logic goes.

4. Define the Home or Local Home Interface.

The home interface should extend the EJBLocalHome interface in cases where the client will be calling the entity bean from inside the same EJB container, such as servlet-based database applications. If the client will be calling the entity bean from outside the EJB container, the home interface should extend the EJBHome interface.

5. Define the Local or Remote Interface.

Methods of choice are exposed to clients in either the local or remote interface. The local interface extends the EJBLocalObject interface, whereas the remote interface extends the EJBObject interface.

6. Define a Deployment Descriptor

The primary key class can be extended from any base class. In order to be a valid RMI/IIOP type, the primary key must implement the Serializable interface. A hashCode() method and an equals() method must be implemented in order for the EJB container to manage primary keys. These methods are necessary for the container to determine whether particular instances are the same.

7. Deploy using Container-Provided Tools

Benefits of using container-managed persistence include:

• Database independence: The container, not the Bean Writer, maintains database access code to most popular databases.
• Container-specific features: Features such as full text search are available for use by the Bean Writer.

Drawbacks to use of container-managed persistence include:

• Only container-supported algorithms for persistence can be used.
• Portability to other EJB containers can be lost.
• The developer has no access to the view and cannot modify the actual code.

8. Create a Client Application

A client application can be either remote or local. A remote client can be another bean either in the same or different EJB container, a Java program, or a non-Java program. A local client must run inside of the same JVM as the entity bean.

To create a Web application that contains one or more JSP pages

1. Create a directory structure for the application that conforms to the format required for the Web application. The directory structure should look somewhat like the following:

+ document root directory – holds .jsp, .html, .js files

|

|------- “WEB-INF” - holds web.xml, .tlds (taglib descriptors)

|

|--------- “classes” - holds servlet, bean, or tag classes

(with subdirectories for packages)

|

|--------- “lib” - contains JARS of servlets, JavaBeans, and other

utility classes that are part of the application.

|

|--------- any other directories you like (e.g. for images, etc.)

2. Write your JSP pages and save them in the root directory.
3. Create any Java servlets, JavaBeans components, or other supporting Java classes and compile them. If you don’t want these files to be exposed n the URL space of the application, save them under the WEB-INF\classes directory or package them into JAR files and save the JAR files in the WEB-INF\lib directory.
4. From a command prompt, switch to the root directory and type: jar –cf <your appname>.war
5. Take the generated .war file and install it on your app server (this step is app server-specific).

The life cycle of Enterprise JavaBeans

1. The client locates the bean’s home using the JNDI services in the application server.
2. The JNDI service returns a reference to the client’s Home interface.
3. The client uses its Home interface to call home.create(). In response to this call, the Home object creates an EJBObject. A new instance of the code in the bean class is also instantiated by the newInstance() method.
4. The new instance of the bean class is given a session context. This instantiation is now called a Session Bean.
5. The Home object gives the client’s Remote interface a reference to the EJBObject in the container.
6. The client’s Remote interface can now invoke methods on the EJBObject in the container. This EJBObject then passes these method calls to the Session Bean.
7. The session bean returns a resultset to the EJBObject, which in turn returns it to the client’s Remote interface.

Guideline: Use of stateful versus stateless session beans

Stateful session beans should be considered when any of the following conditions are true:

• The session bean needs to maintain data in its member variables across method invocations.
• The state of the session bean must be initialized when the session bean is instantiated.
• The session bean needs to maintain information about the client across multiple method invocations.
• The session bean is servicing an interactive client whose individual presence needs to be known to the EJB container or applications server.

Stateless session beans may be considered when either of the following conditions are true:

• The session bean does not need to maintain any data in its member variables across method invocations.
• The session bean provides a service that is not client specific.

Personal roles or EJB development

The J2EE standard describes roles for developers who must perform the different types of tasks necessary to create and deploy a J2EE/EJB application. Some of these roles are:

• Entity Bean Developer
• Bean Writer
• Application Assembler
• Bean Deployer

Deploying the application

J2EE applications and components are packaged in a standard way, defined by the J2EE specs. First, create the .war file (as described above). Put all your EJBs inside a .jar file and then both these into a J2EE application file (.ear). Deploying the .ear file is specific to the applications server you are using.

For WebShere, instructions can be found at:

http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/was/060702_basic_deployment.html