Developing a Session Bean

Class requirements are similar to JavaBeans:

  1. Must be a top level class
  2. Must be defined as public
  3. Can not be final or abstract
  4. Must have a public no-arguments constructor that takes no parameters
  5. Must not define the finalize method
  6. Must implement the methods of the business interface

Developing business interface

Similar to Java SE interfaces

  1. public interface SomeInterface

Annotated with client-access mode

  1. @Local – local(in context of application only)
    1. use import javax.ejb.Local;
    2. annotate with @Local
  2. @Remote – remote (inside and outside jar file)
    1. use import javax.ejb.Remote;
    2. annotate with @Remote



Enum serves as a type of fixed number(meaing limited to certain number) of constants and can be used at least for two things:


public enum Month {


This is much better than creating a bunch of integer constants.

creating a singleton

public enum Singleton {

   // init



Choosing and developing a Session Bean

Use a session bean if:

  1. Only one client has access to bean at any given time
  2. State of bean is not persistent
  3. Bean represent a web service

Use a Stateful Session bean if:

  1. Bean state represent client interaction
  2. Bean needs to hold client data across interactions
  3. Bean acts as a client mediator to other beans
  4. Need thread-safe interactions

Session Bean cardinality(taken from DevelopIntelligence)

bean cardinality.PNG

From the diagram, you can see that Stateless and Singleton beans looks very similar when it comes to Client-bean instances, except that in singleton all the clients access single object while in Stateless some objects are uses by clients and returned back to pool.

Developing a Session Bean

Steps to create a session bean:

  1. Define business logic interface
  2. Annotate the business interface
  3. Create the session bean, implementing the interface
  4. Annotate class defining type
  5. Compile, deploy and debug as discussed above

Dependency injection in EJB

After an EJB is instantiated inside the Java EE container, but before it is handed out to a client, the container may initialize property data on the instance according to rules defined for that enterprise bean. This feature is called dependency injection, an external provider initializes the properties of an object instance instead of by the class itself.

■Note Injection uses a “push” model to push data out to the bean, and it occurs regardless of whether the bean actually uses the data. If there is a chance that the data will not be used, the bean may elect to avoid incurring the cost of the resource derivation by performing a Java Naming and Directory Interface (JNDI) lookup in Java code to “pull” the
data, only if it is actually (or likely to be) used.

Common examples of dependency injection use in EJB are as follows:
• Injecting an EntityManager into a session bean for interacting with entities in a persistence unit
• Injecting a UserTransaction into a session bean that manages its transaction demarcation

Even though, the video below is for Spring framework, which is actually EJB’s alternative, it covers the Dependency Injection(DI) pretty well.

XML and Annotations in EJB

XML vs Annotations

A simple rule we follow is this: if we need to decouple our entity and bean classes from their EJB metadata, as when we want to use the same entity classes with two different entity inheritance strategies, we put our metadata in XML.

Otherwise, we stick with annotations. Don’t forget—you can always mix and match, relying on the firm policy that whenever metadata is specified for an element using both XML and annotations, the XML always wins. This allows any role (see the “EJB Roles” section later in the chapter) downstream of the bean developer to override metadata settings without having to update the Java source, since overrides can be applied exclusively to the XML descriptors.


uses ejb-jar.xml or server specific file.


more annotations is better


A more advanced strategy, which is also recommended, is to use annotations only when defining behavior of an enterprise bean or an entity that is truly integral to its definition, such as the relationship type of an entity relationship field, or the transactional requirements of a method on a session bean. Anything that could reasonably be overridden, such as the name of the table to which an entity maps, or the details of a value generator used for populating the primary key on an entity, would go in the XML descriptor, where it can be specified at deploy time by an application assembler, perhaps in consultation with a database administrator. While there is no harm in specifying default values using annotations in the Java source file, this approach recognizes the difference between firm metadata, which ought not to be modified, and loose metadata that may be freely modified without changing the behavior of the enterprise bean or entity.