THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Overview
A typical J2EE application may contain Enterprise JavaBeans or EJBs. These beans contain the application's business logic and live business data. Although it is possible to use standard Java objects to contain your business logic and business data, using EJBs addresses many of the issues of using simple Java objects, such as scalability, lifecycle management and state management.
This document discusses one type of EJB, the Session EJB. This type of EJB is useful for mapping business process flow (or equivalent application concepts). There are two types of Session EJB, stateless and stateful.
EJBs hold conversations with clients. A conversation is basically an interaction between the EJB and the client and these interactions are composed of method calls by the clients to the EJBs. Stateful session beans retain state on behalf of a client. This means that if the state of the bean changes during a client's method call, this state is retained for subsequent calls by the same client. A stateless session bean on the other hand retains no conversational state from method to method. In other words, it is expected to hold its conversational state for only a single method call.
This article is organized in the following sections:
- Session Beans implementation analysis
- Sample application
- The JBoss environment
- The Geronimo environment
- Step-by-step migration
- Summary
Session Beans implementation analysis
EJB implementation may vary from one vendor to another. The purpose of this section is to provide a session bean specific feature-to-feature comparison between JBoss and Apache Geronimo so you can clearly identify the differences and plan accordingly before migration.
Sample application
This sample application shows how session beans are used and deployed in a container. There are two clients, one for stateless session beans and another for stateful session beans. Both client applications use the same database which contains a table that stores loan application details. An entity bean is used to connect to and operate on the loan details table. A session bean is then used by the client application to get specific details from the database using the entity bean. The first client creates a stateless session bean and displays a list of denied loan applications via a method defined in that EJB. The second client creates a stateful session bean and adds loan applications to the database.
The following figure illustrates the application flow:
Application Beans
The session bean sample application consists of the following packages:
- com.ibm.demo.entity
- CustomerBean - contains the methods that connect to the database and operations to manipulate the data.
- CustomerHomeRemote - the remote interface for the EJB.
- CustomerHomeRemote - EJBHome Interface.
- com.ibm.demo.session.stateful
- StatefulLoanManagerBean - it has the submitLoanApplication() method that saves new customer loan applications to the database as well as the getSubmitCount() method that returns the number of loans submitted; since this bean is a stateful session bean, it can remember connection details from a session so the loan application submit count is retained for every call to the submitLoanApplication() method.
- StatefulLoanManagerRemote - the remote interface for the EJB.
- StatefulLoanManagerHomeRemote - EJBHome Interface.
- com.ibm.demo.session.stateless
- LoanManagerBean -it has the deniedLoans() method that is used to get a list of all customers whose loan applications are denied based on the condition that their Annual Salary to Loan Amount ratio is less than 0.1
- LoanManagerRemote - the remote interface for the EJB.
- LoanManagerHomeRemote - EJBHome Interface.