The creation of a session EJB consists of two steps:

These steps have been made easier through the use of annotations.

In this example we will use the @Stateless annotation. Create a Java EE application called SalutationApplication . The application should have both a SalutationApplication-ejb and a SalutationApplication-war module. Add the following Stateless session bean to a package called packt and name the bean Salutation.

In this EJB we will add two simple business methods which return different types of greetings.

package packt;
import javax.ejb.Stateless;

@Stateless
public class Salutation {
  public String getFormalSalutation(String name) {
    return "Dear " + name;
  }
  public String getInformalSalutation(String name) {
    return "Hi " + name;
  }
}

The process of creating a stateless session EJB involved defining a class to support the desired functionality of the bean and using the @Stateless annotation to specify the class as a stateless session EJB. In order to use the @Stateless annotation we needed to use an import statement.

The two class methods took a string as an argument and returned the string prefixed with either a formal or informal greeting.

Annotation is at the heart of the EJB declaration. Annotations are embedded in the application's source code and allow further processing of the source code either:

An annotation can be applied to many different program elements including but not limited to classes, methods, parameters, fields, and packages. In essence, annotations are used to provide metadata about an element. Metadata is usually defined as data about data. We may have a program element, such as a method, requiring in some circumstances additional information about how it is used.

For example, we might want a particular method to correctly override a base class method. The @Override annotation does exactly this. This annotation is useful should we accidentally mistype the method name and fail to actually override the annotation. We may think we are overriding it but we are not. If we use the @Override annotation and fail to actually override the method a syntax error is issued by the compiler.

The @Stateless annotation provides information to configure the environment and treat the class as an EJB. The annotation is used at runtime and has attributes affecting its visibility. In particular, the mappedName attribute is used in the generation of the bean's JNDI name.

@Stateless(mappedName="salutationBean")
public class Salutation {

The bean can now be referenced in certain contexts using the name: salutationBean. An alias can also be defined for an EJB in the project's ejb-jar.xml file.

Session beans are not limited to a stateless form. The use of the @Stateful annotation declares a bean to be stateful. This means field variables can maintain their values as a user interacts with the application over a period of time called a session. In addition, session beans frequently interact with entities to persist data to a database.

A session bean can also have a local, remote and no-interface client view. The interface used determines the intent and scope of the bean. The no-interface view is new to EJB 3.1. This approach allows the developer to use EJB without having to declare a business interface. In later recipes we will see how these aspects of session beans are used.

The next recipe illustrates how we can use the session bean in other parts of our application.

The essential steps to access a session EJB using dependency injection include:

First we need a session bean. To keep things simple, we will use the Salutation session EJB developed in the previous recipe. We will add our servlet to the SalutationApplication.

We will be developing a HyperText Transfer Protocol (HTTP) based servlet named SalutationServlet. This servlet will use the Salutation EJB's methods and display their return value. Create a package in the WAR module called servlet. Add the servlet to this package.

The servlet consists of a class declaration and three methods:

The servlet begins with the @WebServlet annotation then declares an instance of the Servlet EJB and uses it in the processRequest method.

package servlet;
import javax.ejb.EJB;
import packt.Salutation;

@WebServlet(urlPatterns = {"/SalutationServlet"})
public class SalutationServlet extends HttpServlet {
  @EJB
  private Salutation salutation;

  protected void processRequest(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
      response.setContentType("text/html;charset=UTF-8");
      PrintWriter out = response.getWriter();
      try {
        out.println("<html>");
        out.println("<head>");
        out.println("<title>Servlet SalutationServlet</title>");
        out.println("</head>");
        out.println("<body>");
        out.println("<h1>" + salutation.getFormalSalutation("Sherlock Holmes") + "</h1>");
        out.println("</body>");
        out.println("</html>");
      } finally {
      out.flush();
      out.close();
    }

  }

  @Override
  protected void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
      processRequest(request, response);
  }

  @Override
  protected void doPost(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
      processRequest(request, response);
    }
}

Enter the URL as shown in the following screenshot into a browser. When executed, the salutation Dear Sherlock Holmes will be displayed in the browser.

To provide a reference to an EJB in a servlet we used the @EJB annotation to inject the bean. However, before we could use the annotation two import statements were required. The first one was for the annotation and the second one is for the Salutation EJB.

import javax.ejb.EJB;
import packt.Salutation;

The declaration of the servlet began with @WebServlet annotation. The @WebServlet is a class level annotation marking the class as an HTTP servlet. The urlPatterns parameter specifies the URL pattern which maps to this servlet. This pattern is important because this is how a user of the servlet is able to locate it on the server.

@WebServlet(urlPatterns = {"/SalutationServlet"})
public class SalutationServlet extends HttpServlet {

The salutation variable was declared as a field of the servlet. The @EJB annotation immediately preceded the variable declaration and effected dependency injection. This allows the EJB container to support the EJB.

   @EJB
   private Salutation salutation;

HTTP Servlets typically respond to doGet and doPost HTTP commands. The doGet and doPost methods are invoked depending on whether a GET or POST HTTP command is issued. In this example, both of these methods called the processRequest method using the common servlet logic in the processRequest method.

The processRequest method used standard servlet code to generate the HTML response sent back to the browser. Of particular interest to us was the use of the salutation object. The getFormalSalutation method was invoked and its return value was sent forward to the browser.

...
out.println("<h1>" + salutation.getFormalSalutation("Sherlock Holmes") + "</h1>");
...

The next recipe illustrates the use of JNDI to access an EJB.

To use JNDI in a client:

Familiarize yourself with the Salutation session bean and its two methods as developed in the Creating a Simple Session EJB recipe. We will also modify the SalutationServlet from the second recipe to use JNDI instead of DI.

A portable JNDI name syntax has been added to EJB 3.1. We will use this syntax as it makes the use of JNDI less dependent on the deployment server.

The modification of the SalutationServlet involves removing the @EJB annotation and adding code to perform the JNDI look up. This code is placed immediately before the servlet's try block.

...
  Context context = null;
  try {
    context = new InitialContext();
    salutation = (Salutation) context.lookup("java:global/SalutationApplication/SalutationApplication-ejb/Salutation");
  } catch (Exception e) {
      e.printStackTrace();
  }
...

In order to initialize and assign an instance of the bean to the salutation variable, the bean needed to be looked up using an object implementing the Context interface. The Context interface provided the information necessary to locate the server and to create a reference to a Salutation object. First, we needed to create an InitialContext object. This class implemented the Context interface. Exceptions resulting from the creation of the InitialContext object and the subsequent lookup method were caught.

Once the Context has been established, the Context object's lookup method was invoked and a reference to the Salutation EJB was provided. The lookup method used a portable JNDI name to identify the EJB. In this case, a global name was used.

The syntax starts with one of three different prefixes. In this example the prefix was java:global specifying a global name. Following the prefix is a series of names separated by forward slashes. The first name was the name of the application, SalutationApplication. The second name was the name of the JAR file where the bean is held, SalutationApplication-ejb. The name of the bean was the last name. Names are automatically generated for EJBs.

Prior to EJB 3.1, a JNDI name was server-specific and limited the portability of EJBS. With EJB 3.1 this problem goes away and we can create more portable and maintainable applications.

There are two features of JNDI needing further scrutiny.

java:global[/<app-name>]/<module-name>/<bean-name>

java:module/<bean-name>

java:app[/<module-name>]/<bean-name>

java:global/app1/module1/bean1

java:module/bean1

public class Salutation implements 
  SalutationLocalInterface, 
  SalutationRemoteInterface {

  }

java:global[/<app-name>]/<module-name>/Salutation/ SalutationLocalInterface
java:global[/<app-name>]/<module-name>/Salutation/ SalutationRemoteInterface

The creation of an MDB involves three tasks:

Our MDB, which is called SalutationMessageBean, will simply log each time a salutation message is processed.

Open the SalutationApplication and add the SalutationMessageBean to the SalutationApplication-ejb module and the packt package.

@MessageDriven(mappedName = "jms/SalutationQueue", activationConfig =  {
    @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")
    })
public class SalutationMessageBean implements MessageListener {

  public SalutationMessageBean() {
  }

  @Override
  public void onMessage(Message message) {
    try {
      String name = message.getStringProperty("name");
      Logger.getLogger("SalutationLog").log(Level.INFO,
        "Salutation processed", "");
    } catch (JMSException e) {
        throw new RuntimeException(e);
      }
  }

}

The next recipe will demonstrate the use of this MDB.

The @MessageDriven annotation is more complex than most annotations but understanding it is by no means insurmountable. The annotation has five possible attributes. For our SalutationMessageBean we used only two of them, mappedName and activationConfig.

The mappedName attribute is the simplest one. It is a vendor-specific name and maps the MDB to a JMS queue. When a message appears in the queue, it is sent to the MDB's onMessage method. We used the name jms/SalutationQueue. This is the name configured by the server and represents the queue we want to use. Most servers provide a way of creating and naming JMS resources, such as a queue.

mappedName = "jms/SalutationQueue",

The activationConfig attribute is concerned with how the MDB works in its environment. This can include issues such as how messages are acknowledged and the type of destination used. We addressed these two issues in our MDB. Nested within the @MessageDriven annotation were two @ActivationConfigProperty annotations. These were used to specify the acknowledgement mode and the destination type.

The @ActivationConfigProperty annotation has a propertyName attribute and a propertyValue attribute. These are used together to specify the name and value of a property. For our MDB the acknowledgement mode was set to "Auto-acknowledge" and the destination type was the javax.jms.Queue interface.

@MessageDriven(mappedName = "jms/SalutationQueue", activationConfig =  {
    @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")
    })

When a message arrives at the message queue it is sent to the onMessage method of the MDB. This method has a single parameter, a javax.jms.Message object. Depending on the type of message sent, various methods can be applied against this object to return information needed by the bean. In the earlier code sequence, the value of a name property was returned and used as part of the logging operation.

There is a lot more to MDBs than what we have seen here. But let's not spoil the fun; many useful MDB recipes are found in Chapter 3, Message-Driven Beans.

The next recipe shows how to send a message to this MDB.

The process consists of two steps:

Review the SalutationApplication project as developed in the Accessing a session bean using dependency injection recipe. We will be modifying the SalutationServlet.

Start by adding declarations for a queue factory and a message queue as instance variables in the SalutationServlet.

  @Resource(mappedName = "jms/SalutationQueueFactory")
  private QueueConnectionFactory queueConnectionFactory;
  @Resource(mappedName = "jms/SalutationQueue")
  private Queue queue;

Next, we need to add code to send the message. This code is placed in front of the servlet's try block. This code can be used regardless of whether the salutation object is instantiated using DI or JNDI. In this code we will create a connection to a server-based queue. Once we have a connection we create a session which serves to facilitate communication. The session creates a message producer which sends the message. And of course, we need to handle exceptions.

This might sound kind of involved but don't worry; most of the individual steps are simple.

  try {
    String message = "Salutation generated";

    Connection connection = queueConnectionFactory.createConnection();
    Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
    MessageProducer messageProducer = (MessageProducer) session.createProducer(queue);
    TextMessage textMessage = session.createTextMessage();
    textMessage.setText(message);
    messageProducer.send(textMessage);
    Logger.getLogger("SalutationLog").log(Level.WARNING,
      "Message sent successfully", "Message sent successfully2");
  } catch (JMSException ex) {
      Logger.getLogger("SalutationLog").log(Level.WARNING,"JMSException in SalutationServlet", "JMSException in SalutationServlet");
    }

First, we needed to create a connection to the queue. This step used a connection factory. As you are probably aware, the software factory pattern is used to, among other things, hide the details of how an object is created.

In addition to a connection factory, a destination queue was created. Most IDEs will assist in the creation of these resources. However, it may be necessary to use the server's administration console to create these resources. The connection factory was created by the server, GlassFish in this case, with the name jms/SalutationQueueFactory which is of type QueueConnectionFactory. The @Resource annotation was used to inject it into the servlet.

  
  @Resource(mappedName = "jms/SalutationQueueFactory")
  private QueueConnectionFactory queueConnectionFactory;

The queue is of type javax.jms.Queue and used the name jms/SalutationQueue as defined within the server. The @Resource annotation was used again to inject this resource.

 
  Resource(mappedName = "jms/SalutationQueue")
  private Queue queue;

A try block was needed to catch and handle any JMS exception thrown. Within the try block a message string was defined. This string was sent to the queue. Next, the QueueConnectionFactory object is used to create a QueueConnection. The QueueConnection represents a connection between two point-to-point JMS elements. Any exceptions were handled in the catch block.

  try {
    String message = "Salutation generated";
    Connection connection = queueConnectionFactory.createConnection();
...
  } catch (JMSException ex) {
      Logger.getLogger("SalutationLog").log(Level.WARNING,"JMSException in SalutationServlet", "JMSException in SalutationServlet");
    } 

The next step created a Session object used for sending and receiving messages. The Connection object's createSession method uses two parameters. The first one indicates that the session is part of a transaction. The second argument specifies the type of acknowledgment to be made. Using Session.AUTO_ACKNOWLEDGE meant the session automatically acknowledged the receipt of the message.

Session session = connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);

The Session object was used to create a MessageProducer. The MessageProducer object was used later in this code sequence to send a message to the destination queue. The queue was used as the argument in the createProducer method.

  MessageProducer messageProducer = (MessageProducer)
    session.createProducer(queue);

Next, a TextMessage was created using the createTextMessage method. A TextMessage is one of several interfaces derived from the Message interface. These JMS interfaces represent different types of messages used within JMS. The setText method assigned a string to be sent.

TextMessage textMessage = session.createTextMessage();
textMessage.setText(message);

The messageProducer then sent the message.

messageProducer.send(textMessage);

The output was displayed in the log file used by the SalutationMessageBean.

INFO: Salutation processed

The previous recipe explains the MDB used in this recipe.

To create a web service:

Creating the EJB and web service are both straightforward.

Create a new web application called TODService . Within the application we will create a web service and a stateless EJB. Next, create the singleton EJB in a package called ejb . Add an EJB called TimeOfDay using the @Singleton annotation.

package ejb;

import java.text.SimpleDateFormat;
import java.util.Calendar;
import javax.ejb.Singleton;

@Singleton
public class TimeOfDay {

  private static final String DATE_TIME = "yyyy-MM-dd HH:mm:ss";

  public String timeOfDay() {
    Calendar calendar = Calendar.getInstance();
    SimpleDateFormat simpleDateFormat = new SimpleDateFormat(DATE_TIME);
    return simpleDateFormat.format(calendar.getTime());
  }
}

The next step is to create the Web Service. The JAX-WS Web Service is defined using the @WebService annotation. We will use the @EJB annotation to inject the TimeOfDay EJB and then create a single @WebMethod , called timeOfDay .

package service;

import ejb.TimeOfDay;
import javax.ejb.EJB;
import javax.jws.WebMethod;
import javax.jws.WebService;

@WebService
public class Time {
  @EJB
  private TimeOfDay timeOfDay;

  @WebMethod(operationName = "timeOfDay")
  public String timeOfDay() {
    return timeOfDay.timeOfDay();
  }

}

The easiest way to demonstrate service is to use the testing service available as part of the server. Enter the following URL into a browser to observe the behavior of the service:

http://Localhost:8080/Todservice/Timeservice?Tester

The following screenshot shows the TimeService Web Service Tester. This page is automatically generated and provides a way of testing web services. Since this type of application uses the SOAP protocol to invoke a service, the service tester provides an easier to use graphical technique to test the service. Without this capability the developer would have to develop a more convoluted SOAP message.

Click on the timeOfDay button. The following screenshot displays the string returned. The SOAP request and response used for the service are not shown in the screenshot but can be seen in the window by scrolling down.

The TimeOfDay class used a single method, called timeOfDay, which returns a string representing the time. To support the formatting of the string we created another string, DATE_TIME to hold the string's format pattern. This pattern was used with the format method to yield a properly formatted return string.

    private static final String DATE_TIME = "yyyy-MM-dd HH:mm:ss";

The timeOfDay method obtained an instance of the Calendar class. Its getTime method was used to get the current day and time. The SimpleDateFormat class along with the format method were used to format the string. The string is then returned.

The @WebService annotation identifies as a web service provided by the application. This is followed by the class declaration. The TimeOfDay object was injected using the @EJB annotation. Notice that we used the no-interface view of the TimeOfDay EJB. That is, there was no explicit interface defined for the EJB.

The method immediately following the @WebMethod annotation is available for use by the client. The operationName attribute specified the method name as seen by the client.

The timeOfDay method is simple enough. It used the timeOfDay method of the TimeOfDay object.

Notice the URL used to test the application TODService contains the context root of the application.

http://localhost:8080/TODService/TimeService?Tester

This value is configured in the application's sun-web.xml file.

...
<sun-web-app error-url="">
<context-root>/TODService</context-root>
...
</sun-web-app>

To create a JAX-RS application we need to:

The use of annotations makes both of these steps easy to do.

Create a new Web Service called RESTApplication. In this application we will be adding two stateless session beans: TipSessionBean and TipOfTheDay.

Next, create a packt package for the two stateless EJBs. Follow this by creating a stateless session bean, TipSessionBean, to support an application returning a random tip of the day message. Next, we will create the Web Service to access and use the bean.

The TipSessionBean is straight forward. The EJB uses an array of strings to hold the tips. The getTip method randomly returns a tip from the array.

package packt;
import javax.ejb.Stateless;

@Stateless
public class TipSessionBean {
  private final static String tips[] = {
    "I hear and I forget. I see and I remember. I do and I understand", "Study the past if you would define the future", " Life is simple, it's just not easy."};

  public String getTip() {
    return tips[(int)(Math.random()*tips.length)];
  }

}

Now let's turn our attention to the RESTful application. A stateless session bean, called TipOfTheDay, is used to represent the service.

@Path("tipoftheday")
@Stateless
public class TipOfTheDay {
  @EJB
  TipSessionBean tips;

  @GET
  @Produces("text/html")
  public String processGet() {
    return getTip();
  }

  @POST
  @Produces("text/html")
  public String processPost() {
    return getTip();
  }

  private String getTip() {
    return tips.getTip();
  }

}

The service can be tested using an IDE tester or by typing the URL of the service into a browser as illustrated in the following screenshot:

At the heart of the TipSessionBean is the getTip method. This method used the Math class' random method to return a double number greater than or equal to 0.0 but is less than 1.0. The return value was multiplied by the length of the array, three in this case. This returned a number between 0 and 2.999997. The result was cast to an integer (between 0 and 2 inclusive) and then used to select the tip.

  public String getTip() {
    return tips[(int)(Math.random()*tips.length)];
  }

In the TipOfTheDay class, the @Path annotation used a string to specify the name of the service. This name is part of the URL used by a client. The class itself used the @EJB annotation to inject the TipSessionBean for the field tips.

The @GET annotation configured the processGet method as the method to use when a HTTP GET request is made. The @Produces annotation specified the type of output as text/html. While we did not actually generate any HTML tags, we could if needed.

Most web applications will support both the GET and POST operations. However, from a Java EE perspective there is little difference between them. This allows us to create one method which handles both requests in the same way.

The processGet method calls a private getTip method of the service. A third method, processPost, was added to POST requests and also called the servlet's getTip method. The getTip method then used the Tip's object to return a tip.

The service can be tested using an IDE tester or typing in the URL of the service into a browser.

The actual URL is dependent on the configuration of the application. Consider the URL:

http://localhost:8080/RESTApplication/resources/tipoftheday

The context path for the application is http://localhost:8080/RESTApplication where RESTApplication is the name of the project. The relative URL is /resources as specified in the @ApplicationPath annotation discussed next. The last part, tipoftheday, is specified in the @Path annotation.

When a RESTLess application is created in an IDE such as NetBeans, an ApplicationConfig class is automatically generated. You may be prompted to choose between various options. Normally, the default option will suffice.

This class, shown below, defines the components used in the application and supplies any metadata needed for the application. The ApplicationConfig used for the tip of the day application uses the @ApplicationPath annotation to specify the base URI for all of the resources of the application. Notice that annotations can also be written prefixed with the package name as we sometimes do with Java classes.

package org.netbeans.rest.application.config;

@javax.ws.rs.ApplicationPath("resources")
public class ApplicationConfig extends javax.ws.rs.core.Application {
}

Notice in this example the application path is given as resources. This is why the URL used to test the application uses this string in front of the resource name.

Accessing an EJB from an applet uses three steps:

The remote interface determines which methods are available to the Applet.

Create two different applications. The first application will be called CapitalApplication, packaged as EJB-JAR, and contains an EJB called CapitalBean. It possesses a method which, when passed the name of a country, returns its capital. The second is a stand-alone JApplet application which uses the CapitalBean.

For this recipe, we will create three classes:

EJBs used outside of a Java EE application normally need to implement a remote interface. This interface specifies the methods available to a client. The CapitalBean EJB implements CapitalBeanRemote interface. This interface has a single method called getCapital.

package packt;
import javax.ejb.Remote;

@Remote
public interface CapitalBeanRemote {
  public String getCapital(String state);
}

The CapitalBean implements the getCapital method using a HashMap initialized with countries and their capitals.

@Stateless
public class CapitalBean implements CapitalBeanRemote {
  private HashMap<String, String> capitals = new HashMap<String, String>();

  public CapitalBean() {
    capitals.put("United Kingdom", "London");
    capitals.put("Japan", "Tokyo");
    capitals.put("India", "New Delhi");
  }

  @Override
  public String getCapital(String country) {
    return capitals.get(country);
  }
}

Create a separate application called CapitalApplet. Add a JApplet called EJBApplet. The applet includes a JButton that when pressed will populate a JTextField with the capital of Japan.

The applet as shown below includes the following methods:

When setting up the project add libraries for the CapitalApplication (CapitalApplication.jar) and for the server (appserv-rt.jar). These files can be added using the properties tab of the CapitalApplet.

Most IDEs provide a way of executing an applet without actually creating an HTML page for the applet. Use the IDE to execute the EJBApplet. The applet will appear as shown in the following screenshot.

The CapitalBean EJB used a HashMap to maintain a list of countries and their capitals. This HashMap was initialized in the constructor. The getCapital method was passed the name of the country and returned the corresponding capital name.

In a HashMap, the first string represents a key (which for us is the name of a country), and a value (which is the country's capital). The put method adds the pair to the HashMap. The get method returns a value based on a key.

The applet InitialContext object bears further explanation. When the applet is created there are at least two JAR files placed on the application's classpath: the CapitalBean EJB JAR and an appserv-rt.jar file.

The EJB JAR contains the class declarations needed for the references to the EJB to be used correctly within the applet. Without this file, the compiler will be unable to know whether we are using the CapitalBean correctly.

The appserv-rt.jar file contains a manifest.mf file. This file contains the information needed to configure the client side of JNDI enabling it to successfully locate a resource and return a reference to it. In our case, the client side was our applet. Unless this JNDI information is configured properly, the InitialContext object may not be constructed correctly. This often results in an annoying naming exception message.

The declarations for the JApplet consisted of a JButton and a JTextField. The init method used a standard Swing technique of creating a thread which works gracefully with the AWTEvent thread to call the initComponents method. The initComponents method created a simple user interface. The invokeButton used an anonymous inner class to call the invokeEJB method when the button is selected.

The invokeEJB method is the interesting part of the applet. An InitialContext object was created and used with a global JNDI name to locate and return a reference to the CapitalBean EJB.

It is sometimes useful to examine the applet JNDI context in more detail. The InitialContext object's getEnvironment method returns a Hashtable we can use to list the environmental properties.

The Hashtable consists of key/value pairs which we can iterate through using an Enumeration object. The keys method of the Hashtable returns the Enumeration.

  Hashtable table = context.getEnvironment();
  Enumeration<String> enumeration = table.keys();
  while (enumeration.hasMoreElements()) {
    String key = enumeration.nextElement();
    System.out.println(key + " - " + table.get(key));
  }

One possible list may include the following properties and values:

java.naming.factory.initial - com.sun.enterprise.naming.impl.SerialInitContextFactory
java.naming.factory.url.pkgs - com.sun.enterprise.naming
java.naming.factory.state - com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl

The Accessing the session bean using JNDI recipe, discusses the use of JNDI in more detail.

To use an EJB from a JSP client:

JNDI is required because JSP does not support DI.

Create a Java EE application called JSPExample. It should contain both a JSPExample-ejb and a JSPExample-war module. In the JSPExample-ejb module, we will create a remote session bean called ConstantsBean with methods returning common math constants. We will place it in the packt package. The JSPExample-war module has an index.jsp from which we will invoke the EJB.

The ConstantsBean is a remote stateless session bean. The bean extends a remote interface, ConstantsBeanRemote, which defines the methods of the bean. These methods include getPI and getGoldenRatio both returning a double value.

@Remote
public interface ConstantsBeanRemote {
  public double getPI();
  public double getGoldenRatio();
}

The ConstantsBean implements this interface and is declared as a stateless session bean. The methods return the Math class PI constant and in the case of the golden ratio the actual golden ratio value.

@Stateless
public class ConstantsBean implements ConstantsBeanRemote {

  public double getPI() {
    return Math.PI;
  }

  public double getGoldenRatio() {
    return 1.6180339887;
  }
}

Create an index.jsp page in the JSPExample-war module. Next, modify the page to invoke and display the result of the EJB's methods.

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

<%@ page import="packt.ConstantsBeanRemote" %>
<%@ page import="javax.naming.InitialContext" %>
<%@ page import="javax.naming.Context" %>
<html>
<head><title>Constants</title></head>
<body>
<%!
ConstantsBeanRemote constantsBean;
%>
<%
Context context = null;
try {
  context = new InitialContext();
  constantsBean = (ConstantsBeanRemote) context.lookup("java:global/JSPExample/JSPExample-ejb/ConstantsBean");
}
catch(Exception e) {
  e.printStackTrace();
}
%><p>
<h1>Constants</h1>
PI: <%= constantsBean.getPI() %><br>
Golden Rule: <%= constantsBean.getGoldenRatio() %>
</body>
</html>

Execute the application. Its output should be similar to the following screenshot:

The ConstantsBean is straight forward; however, the index.jsp page requires more explanation. It invoked and displayed the result of the EJB's methods.

There are three sections of the JSP page referencing and using the bean. The first section declared the reference variable constantsBean.

<%!
ConstantsBeanRemote constantsBean;
%>

The second created the initial context and returned a reference to the bean. Notice the global JNDI name was used to locate the bean.

<%
Context context = null;
try {
  context = new InitialContext();
  constantsBean = (ConstantsBeanRemote) context.lookup(
    "java:global/JSPExample/JSPExample-ejb/ConstantsBean");
}
catch(Exception e) {
  e.printStackTrace();
}
%>

The last section used both methods of the ConstantsBean.

<h1>Constants</h1>
PI: <%= constantsBean.getPI() %><br>
Golden Rule: <%= constantsBean.getGoldenRatio() %>

The Accessing the session bean using JND I recipe, discusses the use of JNDI in more detail.

To access an EJB from a JSF page:

In this example we will also package the beans in the .war file to demonstrate this new feature of EJB 3.1. Packaging in .war file makes it easier to access EJBs from a web page.

Create a Java EE application called JSFExample and include only the JSFExample-war module. Be sure to enable contexts and dependency injection when creating the Java EE application. If you don't, you cannot use DI.

We will reuse the ConstantsBean from the JSPExample application detailed in the Accessing an EJB from JSP recipe in this chapter. Create a new package called packt and recreate the ConstantsBean inside of it. However, do not implement the ConstantsBeanRemote interface. Add the following annotation after the @Stateless annotation in the Constantsbean class. This will make the EJB visible to the JSF client.

@Named("constants")

Next, create a JSF managed bean called ConstantsManagedBean. This class will use DI to create and use the ConstantsBean.

@ManagedBean
public class ConstantsManagedBean {

  @EJB
  ConstantsBean constants;
  public ConstantsManagedBean() {
  }

  public double getGoldenRatio() {
    return constants.getGoldenRatio();
  }

  public double getPI() {
    return constants.getPI();
  }

}

To demonstrate the use of both the EJB and the JSF-managed bean, create a JSF page titled index.xhtml.

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
  xmlns:h="http://java.sun.com/jsf/html"
  xmlns:f="http://java.sun.com/jsf/core">
  <h:head>
    <title>Constants</title>
  </h:head>
  <h:body>
    <f:view>
      <h:form>
        <h:outputLabel for="name">
          <h:panelGrid columns="1">
            <h:outputText value="Managed Bean Length: #{constantsManagedBean.PI}" />
            <h:outputText value="Managed Bean Status: #{constantsManagedBean.goldenRatio}" />
            <h:outputText value="EJB Bean Length: #{constants.PI}" />
            <h:outputText value="EJB Bean Status: #{constants.goldenRatio}" />
          </h:panelGrid>
        </h:outputLabel>
      </h:form>
    </f:view>

  </h:body>
</html>

Execute the application. The following screenshot illustrates its output.

The ConstantsBean was explained in the previous Accessing an EJB from JSP recipe. The JSF managed bean, ConstantsManagedBean, was declared as such using the @ManagedBean annotation. DI was used to create and use the ConstantsBean. The managed bean has two methods, getGoldenRatio and getPI, which called the corresponding methods of the ConstantsBean.

The JSF page used both the ConstantsBean directly and the managed bean with h:outputText elements. As a developer you can choose to use either technique though the managed bean approach is no longer necessary.

<h:outputText value=
  "Managed Bean Length: #{constantsManagedBean.PI}" />
<h:outputText value=
  "Managed Bean Status: #{constantsManagedBean.goldenRatio}" />
<h:outputText value="EJB Bean Length: #{constants.PI}" />
<h:outputText value=
  "EJB Bean Status: #{constants.goldenRatio}" />

To use this approach we need:

We will be using the CapitalApplication developed in the Accessing an EJB from an Applet recipe found in this chapter. This recipe uses a CapitalBean to return the name of the capital given a state. Make sure the server and this application are executing before testing the Java application.

The EJB used here is the CapitalBean. Create a Java SE application using an IDE of your choice. It does not have to be the same one you used to develop the CapitalApplication. In the main method add:

  try {
    InitialContext context = new InitialContext();
    String name = "java:global/CapitalApplication/CapitalBean";
    CapitalBeanRemote bean = (CapitalBeanRemote)context.lookup(name);
    System.out.println(bean.getCapital("India"));
  } 
  catch(javax.naming.NoInitialContextException e) {
    e.printStackTrace();
  }
  catch (NamingException e) {
    e.printStackTrace();
  }

Make sure the application's classpath contains .jar files for the CapitalBean and the appserv-rt.jar file.

When executed, the output should appear as:

New Delhi

The application JAR file was needed to resolve the class names and the appserv-rt.jar file was needed so JNDI could function properly. This file provided the necessary information for JNDI to locate the server and look up the name correctly.

The Accessing the session bean using JNDI recipe provides more detail on the use of JNDI.

Create a standard Java SE application with the following main method.

public class Main {

  public static void main(String[] args) {
    try {
      Map properties = new HashMap();
      properties.put(EJBContainer.MODULES, new java.io.File("E:\\Packt\\Projects\\CapitalApplication\\build\\classes"));
      properties.put(EJBContainer.APP_NAME,"CapitalApplication");
      EJBContainer ejbC = EJBContainer.createEJBContainer(properties);
      Context context = ejbC.getContext();
      String name = "java:global/CapitalApplication/CapitalBean";
      CapitalBeanRemote bean = (CapitalBeanRemote)context.lookup(name);
      System.out.println(bean.getCapital("Japan"));

    } catch (NamingException e) {
        e.printStackTrace();
      }
  }

}

The Java SE application requires a few JAR files be included in its classpath. These include:

Use the property window of the application to add these files before executing the application.

We declared a Map variable called properties and assigned to it a new HashMap. The variable was used to initialize the EJBContainer. This container has a property, MODULES, specifying the modules to be used by the container. The Map object's put method was used to assign the location of the directory containing the CapitalApplication's classes.

The EJBContainer.APP_NAME field was used to specify the name of the application. Next, the EJBContainer class's static method, createEJBContainer, was called with the properties variable as an argument. The createEJBContainer method returns an EJBContainer object. This class's getContext method was used to get a Context object. The Context object represents the environment needed to find and use the CapitalBean.

Next, a portable JNDI name for CapitalBean was used as an argument to the lookup method. This returned an effective reference to the CapitalBean.

The bean variable was used to invoke the getCapital method and to display the results. The last step caught any exceptions thrown.

The output should appear as:

Tokyo

The previous Accessing an EJB from a Java Application using JNDI recipe, provides an alternative technique for accessing EJBs.

The Salutation bean developed in the first recipe will be modified. First, we start to modify the bean by adding a SessionContext object. The easiest way of obtaining a SessionContext object is to use dependency injection. In order to inject a SessionContext object we will need to use the @Resource annotation. Both the annotation and the SessionContext declaration require imports.

import javax.annotation.Resource;
import javax.ejb.SessionContext;

Next we add the @Resource annotation and declare our SessionContext variable context as a field of the class.

@Stateless
public class Salutation {
...
  @Resource
  private SessionContext context;
...

Next, create a getContextInformation method returning a string. We can use the StringBuilder class to build a string containing context information. There are several SessionContext methods available. The result of these methods is appended to contextInformation variable.

  public String getContextInformation() {
    StringBuilder contextInformation = new StringBuilder();
    contextInformation.append(context.toString() + "<br/>");
    try {
      contextInformation.append(context.getInvokedBusinessInterface().toString() + "<br/>");
    } catch (IllegalStateException e) {
      contextInformation.append(e);
      }
    return contextInformation.toString();
  }

The simplest way to demonstrate the use of the method is to modify the SalutationServlet. Add the getContextInformation method call after the statement where the getFormalGreeting method is used.

  out.println("<h1>" + salutation.getFormalSalutation("Sherlock Holmes") + "</h1>");
  out.println("<h2>" + salutation.getContextInformation() + "</h2>");

Execute the servlet using the URL http://localhost:8080/SalutationApplication-war/SalutationServlet as illustrated in the following screenshot:

The stateless session bean, as we used it, limits the amount of useful context information available. In the example, we only displayed a string to represent the SessionContext object and the business interface used by the client, neither of which are terribly exciting. Since the Salutation EJB used a no-interface view, we get back the class name. An EJB not implementing an interface is said to have a no-interface view.

The EJBContext is the super class for SessionContext. It possesses methods common to the three sub-interfaces of the EBJContext interface:

Always choose the corresponding context interface for the EJB or entity in use. The EJBContext can be obtained using either dependency inject or JNDI. We have already seen how dependency injection can be used. If we need to use JNDI instead, we need to follow the standard JNDI look up process:

Notice the structure of the JNDI look up string, java:comp/EJBContext. It is different from the previous JNDI names we have seen. The java:comp prefix is used to allow applications to expose their components. In this case, it specifies the standard name for a SessionContext.