September 19, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

EJB 3 Session Beans

  • December 22, 2006
  • By Raghu R. Kodali, Jonathan R. Wetherbee, and Peter Zadrozny
  • Send Email »
  • More Articles »

Exception Handling

The EJB 3 specification outlines two types of exceptions:

  • Application exceptions
  • System exceptions

Application exceptions are exceptions related to execution of business logic that the client should handle. For example, an application exception might be raised if the client application passes an invalid argument, such as the wrong credit card number.

System exceptions, on the other hand, are caused by system-level faults, such as Java Naming and Directory Interface (JNDI) errors, or failure to acquire a database connection. A system exception must be a subclass of a java.rmi.RemoteException, or a subclass of a java.lang.RuntimeException that is not an application exception.

From the EJB application point of view, application exceptions are done by writing application-specific exception classes that subclass the java.lang.Exception class.

In the case of a system exception, the application catches particular exceptions—such as a NamingException that results from a JNDI failure—and throws an EJBException. In this particular article, our examples aren't using any resources as such.

Client View for Session Beans

A session bean can be seen as a logical extension of a client program or application, where much of the logic and data processing for that application happens. A client application typically accesses the session object through the session bean's client view interfaces, which are the business interfaces that you're discussed in the earlier sections.

A client application that accesses session beans can be one of three types:

  • Remote: Remote clients run in a separate JVM from the session beans that they access, as shown in Figure 4. A remote client accesses a session bean through the bean's remote business interface. A remote client can be another EJB, a Java client program, or a Java servlet. Remote clients have location independence, meaning that they can use the same API as the clients running in the same JVM.
  • Local: Local clients run in the same JVM, as shown in Figure 3, and access the session bean through the local business interface. A local client can be another EJB, or a web application using Java Servlets, JavaServer Pages (JSP), or JavaServer Faces (JSF). Local clients are location dependent. Remote and local clients are compared in Table 1.
  • Web Services: You can publish stateless session beans as web services that can be invoked by Web Services clients.

Table 1. Considerations for Choosing Between Local and Remote Clients

Remote Local
Loose coupling between the bean and the client Lightweight access to a component
Location independence Location dependence
Expensive remote calls Must be colocated with the bean
Objects must be serialized Not required
Objects are passed by value Objects are passed by reference

In some cases, the session beans need to have both local and remote business interfaces to support different types of client applications. A client can obtain a session bean's business interface via dependency injection or JNDI lookup. Before invoking the methods in the session bean, the client needs to obtain a stub object of the bean via JNDI. Once the client has a handle to the stub object, it can call the business methods in the session bean. In the case of a stateless session bean, a new stub can be obtained on every invocation. In the case of a stateful session bean, the stub needs to be cached on the client side so that the container knows which instance of the bean to return on subsequent calls. Using dependency injection, you can obtain the business interface of the SearchFacade session bean with the following code:

@EJB SearchFacade searchFacade;

If the client accessing the session bean is remote, the client can use JNDI lookup once the context interface has been obtained with the right environment properties. Local clients can use JNDI lookup as well, but dependency injection results in simpler code. Listing 17 shows the SearchFacadeTest client program's JNDI code, which looks up the SearchFacade bean, invokes the wineSearch() business method, and prints out the returned list of wines.

Note If the remote client is a Java application or command-line program, an application client container can be used to invoke the session beans. Application client containers support dependency injection for remote clients.

Listing 17. SearchFacadeClient.java

package com.apress.ejb3.chapter02.client;

import com.apress.ejb3.chapter02.SearchFacade;
import java.util.List;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class SearchFacadeTest {
   public SearchFacadeTest() {
   }

   public static void main(String[] args) {
      SearchFacadeTest searchFacadeTest = new SearchFacadeTest();
      searchFacadeTest.doTest();
   }

   @EJB
   static SearchFacade searchFacade;

   void doTest(){
      InitialContext ic;

      try {
         ic = new InitialContext();
         System.out.println("SearchFacade Lookup");
         System.out.println("Searching wines");
         List winesList = searchFacade.wineSearch("Red");
         System.out.println("Printing wines list");
         for (String wine:(List<String>)winesList ){
            System.out.println(wine);
         }
      } catch (NamingException e) {
         e.printStackTrace();
      }
   }
}

Listing 18 shows the ShoppingCartTest client program, which looks up the stateful ShoppingCart session bean, calls the addWineItem() business method to add a wine to the shopping cart, calls the getCartItems() business method to get the items in the cart, and finally prints the list of wines in the shopping cart.

Listing 18. ShoppingCartTest.java

package com.apress.ejb3.chapter02.client;

import com.apress.ejb3.chapter02.ShoppingCart;

import java.util.ArrayList;

import java.util.List;

import javax.naming.InitialContext;
import javax.naming.NamingException;

public class ShoppingCartTest {
   public ShoppingCartTest() {
   }

   public static void main(String[] args) {
      ShoppingCartTest shoppingCartTest = new ShoppingCartTest();
      shoppingCartTest.doTest();
   }

@EJB
static ShoppingCart shoppingCart;

   void doTest(){
      InitialContext ic;

      try {
         ic = new InitialContext();
         System.out.println("ShoppingCart Lookup");
         System.out.println("Adding Wine Item");
         shoppingCart.addWineItem("Zinfandel");
         System.out.println("Printing Cart Items");
         ArrayList cartItems = shoppingCart.getCartItems();
         for (String wine:(List<String>)cartItems ){
            System.out.println(wine);
         }
      } catch (NamingException e) {
         e.printStackTrace();
      }
   }
}

Conclusion

This article has covered EJB 3 session bean details using a specific set of examples. You looked at the new and simplified EJB 3 model for developing session beans using standard Java language artifacts, such as Java classes and interfaces. You looked at session beans, and some typical use cases in which session beans can be used for developing applications. You discussed two different types of session beans (stateless and stateful), including the differences between them and some general use cases for each. You covered session bean usage in 2-tier and 3-tier application architectures. You discussed the usage of dependency injection in stateless and stateful beans. You considered ways to gain fine-grained control over application flow, including the use of callback methods and interceptors in stateless and stateful beans, as well as the use of annotations like @PostContruct and @PreDestroy.

About the Authors

Raghu R. Kodali is a consulting product manager and SOA evangelist for Oracle Application Server. He has worked in the software industry for over 10 years as a developer, consultant, and presales engineer in emerging technologies. He is responsible for J2EE features with expertise in SOA technologies like EJB, Web Services, and application development frameworks. Raghu has been the lead product manager for EJB design-time features in Oracle JDeveloper since the EJB 1.1 specification. His current area of focus is evangelizing service-oriented infrastructure and implementing service-oriented applications.

Jonathan Wetherbee is a consulting engineer and tech lead for EJB development tools on Oracle’s JDeveloper IDE. He has over 10 years of experience in development at Oracle, working on a variety of O/R mapping tools and holding responsibility for Oracle’s core EJB toolset since EJB 1.1.

Peter Zadrozny brings over 20 years of experience to StrongMail Systems, where he serves as chief technology officer. Peter joined StrongMail Systems from Oracle, where he was vice president and chief evangelist for Oracle Application Server. Previously, Peter served as chief technologist of BEA Systems for Europe, the Middle East, and Africa—a role he held since launching WebLogic’s operations in Europe in 1998. Prior to BEA, Peter held executive and technical positions in many countries around the world for companies such as Macromedia, McKesson, Electronic Data Systems, Petróleos de Venezuela, and Sun Microsystems, for whom he started operations in Mexico.

About the Book

Beginning EJB 3 Application Development: From Novice to Professional
By Raghu R. Kodali, Jonathan R. Wetherbee, and Peter Zadrozny



Published: September, 2006, Paperback: 512 pages
Published by APress Press
ISBN: 1590596714
Retail price: $44.99
This material is from Chapter 2 of the book.
Reprinted here with the publisher's permission.



Page 5 of 5



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel