Java Tutorial - Java Scipt : Session Bean Tests and Sample Code

Java Tutorial - Java Scipt :

Session Bean Tests and Sample Code


Stateless session beans are the best starting point for developing scalable components containing business logic. They are extremely useful and relatively easy to code. In this section, we show you how to develop a trivial “Hello World” type of stateless session bean EJB and use a JSP page to interact with it. There will be quite a few classes, so it is probably easiest to organize everything in a new directory. First, let’s create our core EJB class. This actually implements the business methods (just a simple “Hello” in this case).
Here’s the code for GreeterBean.java  package test.ejb;

import javax.ejb.*;
import java.util.*;
import java.rmi.*;
public class GreeterBean implements SessionBean
{
private String msLastGreeted = null;
private SessionContext moContext;
// --- Standard EJB life cycle stuff ---
public void ejbActivate() {}
public void ejbCreate() {}
public void ejbRemove() {}
public void ejbPassivate() {}
public void setSessionContext( SessionContext oContext )
{
moContext = oContext;
}
// --- Our “business” methods ---
public String sayHello( String sName )
{
String s = “Hello “ + sName + “! “;
if( msLastGreeted != null )
{
s = s + “I just saw “ + msLastGreeted + “.”;
}
msLastGreeted = sName;
return s;
}
// -- This method is only exposed via the local interface, so this
// -- is effectively hidden from the scope of remote clients.
public String getLastGreeted()
{
return msLastGreeted;
}
}

Now, let’s save that file under test\ejb\GreeterBean.java and take a look at the various EJB interface classes.
The home interface is used to create our bean. We’ve kept it very minimal.
Here’s the code for GreeterHome.java:

package test.interfaces;
public interface GreeterHome
extends javax.ejb.EJBHome
{
public test.interfaces.Greeter create()
throws javax.ejb.CreateException, java.rmi.RemoteException;
}

The local home interface looks quite similar. It’s basically the same as the home interface minus the remote exception and extending a different base interface.
Here’s the code for GreeterHomeLocal.java:

package test.interfaces;
public interface GreeterLocalHome
extends javax.ejb.EJBLocalHome
{
public test.interfaces.GreeterLocal create()
throws javax.ejb.CreateException;
}

Now, let’s look at the interface classes that tell an EJB client what methods are available. We’ll look at Greeter.java, the remote interface, first:

package test.interfaces;
public interface Greeter
extends javax.ejb.EJBObject
{
public String sayHello( String name ) throws
java.rmi.RemoteException;
}

In the local interface version, we’re going to expose an additional method that we didn’t want remote clients to access. Remote and local interfaces are used as tools to manage scope and method visibility. In a real-world application, this can be used to hide tightly coupled code behind the local interface. Compared with the remote interface version, the general form for the local interface is the same, except that it extends EJBLocalObject rather than EJBObject and the methods don’t throw remote exceptions.
Here’s the code for GreeterLocal.java:

package test.interfaces;
public interface GreeterLocal
extends javax.ejb.EJBLocalObject
{
public String sayHello( String name );
public String getLastGreeted();
}

The differences are very minimal as far as the interfaces go. There are five different files, yet they don’t really hold a lot of different information. This is part of the grunt work that can and should be automated by tools such as
XDoclet, which can generate these interface files from a single source file. To see XDoclet in action, skip ahead to the section on CMP beans. Let’s try compiling the files. Be sure that the files are saved under the correct
directory, as indicated by their package. We’re going to separate the commands for compiling the interfaces and the EJB because the client often needs the interface files. Unless the interface changes, we should use the same compiled class files for compatibility reasons. If the interface files are recompiled, they will need to be updated in the client as well. The command for compiling the interfaces on Windows is as follows:

javac -classpath .;%JBOSS_HOME%\client\jboss-j2ee.jar
test\interfaces\Greeter.java test\interfaces\GreeterLocal.java
test\interfaces\GreeterHome.java test\interfaces\GreeterLocalHome.java

And for the EJB:

javac -classpath .;%JBOSS_HOME%\client\jboss-j2ee.jar test\ejb\GreeterBean.java

On Linux, the command for compiling the interfaces as follows:

javac -classpath .:$JBOSS_HOME/client/jboss-j2ee.jar
test/interfaces/Greeter.java test/interfaces/GreeterLocal.java
test/interfaces/GreeterHome.java test/interfaces/GreeterLocalHome.java

And the Linux command for compiling the EJB is:

javac -classpath .:$JBOSS_HOME/client/jboss-j2ee.jar test/ejb/GreeterBean.java

The files should be all compiled and ready to be packaged into a .jar file for the EJB, along with the descriptor files that we are about to write. If the compilation failed, be sure to check that the JDK is in your path and that the environment variable for JBOSS_HOME is set properly. The last step before we package up our stateless session bean EJB is to write some descriptor files. These tell the EJB container about the EJB we’ve created. You need to place these files under the META-INF subdirectory. First, we need to write a J2EE standard descriptor file for the EJB. This is the ejb-jar.xml file and it should look like this: