What Makes Up An EJB?

An EJB has two client interfaces that a client uses to create and use an EJB:

• Component interface (remote or local)—The component interface specifies the business methods that the clients of the object can invoke.

• Home interface—The home interface defines EJB life cycle methods, such as a method to create and retrieve a reference to the bean object.

The client uses both of these interfaces when invoking a method on a bean.

Figure 1-4 Events in a Stateless Session Bean

Description of the illustration overview4.gif

Figure 1-4 demonstrates a stateless session bean and corresponds to the following steps:

1. The client, which can be a standalone Java client, servlet, JSP, or an applet, retrieves the home interface of the bean—normally through JNDI.

2. The client invokes the create method on the home interface reference (home object). This creates the bean instance and returns a reference to the component interface (remote or local interface) of the bean.

3. The client invokes a method defined in the component interface (remote or local interface), which delegates the method call to the corresponding method in the bean instance (through a stub).

4. The client can destroy the bean instance by invoking the remove method that is defined in the component interface (remote or local interface). Some beans, such as stateless session beans, cannot call the remove method. In this case, the container removes the bean.

For an example of a stateless session bean implementation, see "Developing Session Beans".

When developing an EJB, you create the following four major components:

• the home interface

• the component interface (remote or local interface)

• the implementation of the bean

• a deployment descriptor for each EJB

  Component	Description
  The home interface	Specifies the interface to an object that the container itself implements: the home object. The home interface contains the life cycle methods, such as the create() methods that specify how a bean is created.
  The component interface (remote or local)	Specifies the business methods that you implement in the bean. The bean must also implement additional container service methods. The EJB container invokes these methods at different times in the life cycle of a bean.
  The bean implementation	Contains the Java code that implements the methods defined in the home interface (life cycle methods), component interface (business methods), and the required container methods (container callback functions).
  The deployment descriptor	Specifies attributes of the bean for deployment. These designate configuration specifics, such as environment, interface names, transactional support, type of EJB, and persistence information.

  
  

Development issues for your EJBs are discussed in the following sections:

• Interfaces for Bean Implementation is Based on Bean Type

• Parameter Passing Conventions for Your EJBs

• How to Handle Returned Parameter Objects

Interfaces for Bean Implementation is Based on Bean Type

Your bean implements the methods within either the SessionBean, EntityBean, or MessageDrivenBean interface. The implementation contains logic for lifecycle methods defined in the home interface, business methods defined in the component interface (remote or local), and container callback functions defined in the SessionBean, EntityBean, or MessageDrivenBean interface.

See the following chapters for details on each bean type:

• Chapter 3, "Implementing Session Beans"

• Chapter 4, "Entity Beans"

• Chapter 9, "Message-Driven Beans"

Parameter Passing Conventions for Your EJBs

When you implement an EJB or write the client code that calls EJB methods, you must be aware of the parameter-passing conventions used with EJBs.

A parameter that you pass to a bean method—or a return value from a bean method—can be any Java type that is serializable. Java primitive types, such as int, double, are serializable. Any non-remote object that implements the java.io.Serializable interface can be passed. A non-remote object that is passed as a parameter to a bean or returned from a bean is passed by value, not by reference. So, for example, if you call a bean method as follows:

public class theNumber {
  int x;
}
...
bean.method1(theNumber);

then method1() in the bean receives a copy of theNumber. If the bean changes the value of theNumber object on the server, this change is not reflected back to the client, because of pass-by-value semantics.

If the non-remote object is complex—such as a class containing several fields—only the non-static and non-transient fields are copied.

When passing a remote object as a parameter, the stub for the remote object is passed. A remote object passed as a parameter must extend remote interfaces.

The next section demonstrates parameter passing to a bean, and remote objects as return values.

How to Handle Returned Parameter Objects

The EmployeeBean getEmployee method returns an EmpRecord object, so this object must be defined somewhere in the application. In this example, an EmpRecord class is included in the same package as the EJB interfaces.

The class is declared as public and must implement the java.io.Serializable interface so that it can be passed back to the client by value, as a serialized remote object. The declaration is as follows:

package employee;

public class EmpRecord implements java.io.Serializable {
  public String ename;
  public int empno;
  public double sal;
}

Note: The java.io.Serializable interface specifies no methods; it just indicates that the class is serializable. Therefore, there is no need to implement extra methods in the EmpRecord class.