JNDI

Java Naming and Naming Interface if part of Java SE:

  1. Standard API to interact with naming and directory services
  2. Provide the ability to look up things in a “registry”
  3. Used in enterprise solutions to locate resources such as EJBs, JMS queues or Web Services

JNDI resources are organized in tree structure:

  1. Analogues to the folder structure of a computer’s file system
  2. Supports events, lookups, and complex searching against structure

App->JNDI->JNDI IMPL->DS

Finding EJB with JNDI uses four key concepts:

  1. Context
  2. Initial context
  3. Path & Name
  4. Search

Simple JNDI lookup:

[code language=”java”]
String jndiPath = com.development.tutorials.ejb3.RemoteCalculator;

try{

calculator = (RemoteCalculator) c.lookup(jndiPath);

}
[/code]

Problems with JNDI
1. Keep track of JNDI path
2. Bean name

Accessing Session Beans

After we implemented the session beans, we should be able to access it.

EJB interactions:

A client for and EJB can be:

  1. Java EE Application Client
  2. Java EE component (JSP,Servlet,JSF,EJB)
  3. Any java object
  4. Java application

Client finds a proxy to interact with an EJB using:

  1. Java naming and directory interfaces(JDNI)
  2. Dependency Injection(used most of the time)

Steps for interacting with with and EJB(3-step plan)

  1. Declare the reference for the EJB interface
  2. Get the EJB “instance”
    1. using JNDI for remote clients or legacy EJBs
    2. using DI for local clients or application clients
  3. Invoke methods on the interface

 

Session Bean Implementations

To implement the local stateless bean

  1. import javax.ejb.Stateless;
  2. add the annotation above the class: @Stateless  to see what is the difference between beans check my Choosing and developing a Session Bean

To implement the remote statelful bean

  1. import javax.ejb.Statelful;
  2. add the annotation above the class: @Stateful

To implement the local singleton bean

  1. import javax.ejb.LocalBean;
  2. import javax.ejb.Singleton;
  3. add the annotation above the class:
    1. @LocalBean
    2. @Singleton

Every session bean has:

  1. Business interface
  2. Implementation class
  3. Deployment descriptor information

Enum

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

constant

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

creating a singleton

 

 

 

 

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.

XML:

uses ejb-jar.xml or server specific file.

Annotations:

more annotations is better

Note

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.