Enterprise Java Beans: Stateless Session Bean worksheet
Introduction:
There are three different types of Enterprise Java Bean, Session Beans (stateless and stateful), Entity Beans (with Container Managed Persistence and Bean Managed Persistence) and Message Driven Beans. All are distributed object technologies that are part of J2EE ( Java 2 Enterprise Edition) API and run in an Application Server. The Application Server provides services such as instance pooling, session management, transaction management, persistence and object to database synchronization. The programmer can use these services without any extra programming as long as she follows the conventions and rules defined in the J2EE specification. In this session you will modify and deploy a Stateless Session Bean using the JBOSS Application Server. These are simple distributed objects that allow users to make remote procedure calls but do not maintain any state between calls. The Application Server maintains a pool of instances ready for use. If a particular Bean is in a lot of demand the Application Server will increase the number of instances in the pool. If there are not many clients requesting a particular Bean the Application Server reduces the number of instances in the pool, saving resources. As you will see the programmer doesn’t have to do any extra programming to take advantage of this load balancing service.
1. Install JBOSS Application Server:
copy installation directory to local machine:
cd /tmp
mkdir jboss
cp -r /opt/jboss/3.2.2RC4 /tmp/jboss
Start up JBOSS server:
cd /tmp/jboss/3.2.2RC4/bin
sh run.sh > server.log &
check server is starting up ok
tail –f server.log
JBOSS will take a couple of minutes to start up so be patient. At the end you will see something like:
14:02:39,936 INFO [URLDeploymentScanner] Started
14:02:40,371 INFO [MainDeployer] Deployed package: file:/tmp/jboss/3.2.2RC4/server/default/conf/jboss-service.xml
14:02:40,384 INFO [Server] JBoss (MX MicroKernel) [3.2.2RC4 (build: CVSTag=JBoss_3_2_2_RC4 date=200309172341)] Started in 3m:4s:719ms
You can shutdown the server as follows (not now though !):
cd /tmp/jboss/3.2.2RC4/bin
shutdown.sh -S
2. Deploy an EJB to check server is working:
copy EJB jar archive to deployment directory
cp /cs/research/sse/home1/rigel/ucacwxe/public_html/lectures/Z23-04-05/statelessBean/hello.jar /tmp/jboss/3.2.2RC4/server/default/deploy
You should see the following in the server.log:
14:19:58,729 INFO [EJBDeployer] Deployed: file:/tmp/jboss/3.2.2RC4/server/default/deploy/hello.jar
14:19:58,999 INFO [MainDeployer] Deployed package: file:/tmp/jboss/3.2.2RC4/server/default/deploy/hello.jar
Now make new directories called “ejbclient” and “ejbserver” in your home directory
cd ~
mkdir ejbclient
copy client source and class files to test HelloBean:
cp -r /cs/research/sse/home1/rigel/ucacwxe/public_html/lectures/Z23-04-05/statelessBean/HelloClient/ ~/ejbclient/
copy server source and class files to local dir
cp -r /cs/research/sse/home1/rigel/ucacwxe/public_html/lectures/Z23-04-05/statelessBean/HelloWorld/ ~/ejbserver
Now try out the client:
cd ~/ejbclient/HelloClient
runClient.sh
If all goes well you should see the following:
ucacbjb@chaiwan% runClient.sh
Hello, World!
3. Understanding the HelloWorld example:
Go to the server source code dir
cd ~/ejbserver/HelloWorld
Look at the interface for the Bean in “Hello.java”. This defines the remote interface of business methods for the Stateless Session Bean.
Look at the”HelloHome.java” interface. This defines the interface for the management of the Bean. At a minimum you must define at least one “create” method that returns an instance of the remote interface.
Now look at HelloBean.java. You’ll see a number of methods such as “ejbActivate” that all EJB’s must implement, although most of them do nothing. These are methods that are called by the EJB Container (the part of the App Server that manages Beans) at various stages in the Bean’s lifecycle. You can put code in these methods if you want something to happen just before or just after the Container changes the state of the Bean. It is important to understand that these methods are only called by the EJB Container, not by the Bean’s clients. When and why the EJB Container calls these methods depends on the type of Bean. For an Stateful Seesion Bean the ejbPassivate() method is called just before the EJB Container decides to remove a Bean instance’s state from memory and persist it to a database. For a Stateless Session Bean only the ejbCreate() and ejbRemove() methods are called as a Bean instance moves in an out of the method ready pool.
Notice that the ejbCreate() method matches the corresponding create method in the Home interface. Finally we implement the helloWorld() method defined in the remote interface. You can think of the Bean class as implementing the methods defined in the Home and Remote interface, although enforcement of this relationship is only done by the EJB Container. A standard java compiler will not notice if you fail to implement one of the interface methods. You’ll probably get an error at deployment or runtime instead.
The naming conventions used here are significant. Whatever you call the remote interface will determine what the Home and Bean class are called. So if your Remote interface is called MyHello, then the Home interface will be called MyHelloHome and the Bean class will be called MyHelloBean.
4. Change the HelloWorld Bean:
Change the HelloWorld Bean so that the helloWorld method takes a String argument as a parameter and prints this message.
4.1 Compiling modified code. To compile you need to add the jar archive that contains the EJB API classes such as EJBException, EJBHome etc. These classes are in the javax.jar archive which you will find in the directory:
/cs/research/sse/home1/rigel/ucacwxe/public_html/lectures/Z23-04-05/statelessBean/
Probably the easiest thing is to copy the jar to directory where you are working on you code and add it to the classpath:
javac –cp ./javax.jar *.java
4.2 Archiving the Bean
When you deploy an EJB to an app server you have to package your class files along with a couple of files called deployment descriptors into a jar archive. The structure of the archive should be as follows:
myejb.jar
|
|---META-INF
| |
| |---ejb-jar.xml
| |---jboss.xml
|
|---HelloWorld
| |
| |---Hello.class
| |---HelloBean.class
| |---HelloHome.class
The ejb-jar.xml is a standard J2EE deployment descriptor that any EJB must have. It defines amoung other things the logical name for the Bean, class mappings to the Home, Remote and Bean components of the Bean, and whether the Bean is stateful or stateless.
The jboss.xml is a deployment descriptor that is unique to this particular Application Server (JBOSS). Not everything needed to deploy a Bean is defined in the J2EE specification so each J2EE vendor have their own extensions and deployment files. The jboss.xml file maps the “HelloBean” to a JNDI name that the client can use to find the Bean.
You can simply copy the whole META_INF directory containing example deployment descriptors to your server code directory:
cd ~/ejbserver
cp –r /cs/research/sse/home1/rigel/ucacwxe/public_html/lectures/Z23-04-05/statelessBean/META-INF.
Now you can archive the HelloWorld (containing your class files) and the META-INF dir containing your deployment descriptors into a jar archive:
jar –cvf hello.jar HelloWorld META-INF
4.3 Deploy your new bean
With the modified classes in the jar archive you can “hot deploy” to the running app server simply by copying the jar file into the jboss deployment dir:
cp hello.jar /tmp/jboss/3.2.2RC4/server/default/deploy
4.4 Change client:
You will also need to modify your client to call the helloWorld() method with a String parameter. Remember to include the javax.jar archive in the classpath.
Find out more:
The classic introduction for EJB’s is:
“Enterprise JavaBeans”, by Richard Monson-Haefel, published O’Reilly, 2000, ISBN 1-56592-869-5