Basing your application on EJBs means moving as much of the business logic into separate objects as possible. In EJB, these objects come in two different flavors:
Entity beans are objects that map to a relational database. Each instance of an entity bean typically corresponds to a single row in a database table. Each instance variable corresponds to a single column in the database table. We normally need to define a table in our database to correspond to our entity bean, but the EJB container writes and executes SELECT, INSERT, UPDATE and DELETE queries according to our needs.
Session beans perform actions, by themselves or by using one or more entity beans. Session beans normally have no state of their own, which makes them more efficient than entity beans. However, there are times when it might help to keep some state around within a session bean. For this reason, EJB offers the stateful session bean, whose state is kept around between invocations.
If we were to create an on-line forum using EJBs, we probably would have to define entity beans (and the corresponding tables) for users, threads and postings. We also would have to define session beans that support adding, modifying and deleting each of these types of entity beans and for retrieving entire threads and individual postings.
JBoss is a Java application server that makes it possible to create and deploy multitier J2EE applications. JBoss doesn't pretend to handle the application side of things; for that, you will need to use Jakarta-Tomcat or another servlet container. But JBoss does provide the back-end features, such as a directory service and messaging service, as well as the EJB container.
Installing JBoss is extremely easy, assuming that you already have installed the JDK. Sun provides a copy of the JDK in RPM format, which you can download from java.sun.com. You also will need to download and install the Ant utility, a Java program meant to replace the venerable UNIX make program. If you are familiar with make and XML, you will find Ant's build.xml format as shown in Listing 1 [available at ftp.linuxjournal.com/pub/lj/listings/issue92/5497.tgz] to be relatively straightforward.
Once you have installed the JDK and Ant, installing JBoss is a cinch. I downloaded the binary code from <j href=“http://boss.org” target=“_blank”>boss.org, opting for the integrated JBoss and Jakarta-Tomcat support. The file comes as a zip archive, meaning that you'll need the Info-Zip utilities (which come with all Linux distributions that I've used) to unpack them.
When unpacked, the JBoss-Jakarta distribution contains two subdirectories, appropriately named jboss and tomcat. Set the JBOSS_DIST environment variable to point to the jboss directory, so that various JBoss-related utilities and features will be able to find the appropriate files.
At this point, you can start the JBoss server with the following two commands:
cd $JBOSS_DIST/bin sh run.sh
By default, JBoss logs quite a bit of information to the terminal window.
Our first EJB will be Calculator, a stateless session bean whose multiply() method takes two integers and returns their product. After writing Calculator and its necessary EJB interfaces, we will see how we can use it from within a standalone Java program.
Writing a simple Calculator class with a multiply method normally would not be very difficult. We would create the file Calculator.java and define a method with the following signature:
public int multiply (int num1, int num2)
EJB allows us to find and invoke our Calculator bean remotely, which means that we must write several classes that make it possible to find Calculator. In the end, our application will manipulate a remote reference to the actual Calculator bean, rather than the object itself. Writing a session bean thus involves writing one Java class and two interfaces.
The Java class is the bean class itself, which performs the actual work. The bean class doesn't know that it has been invoked by an object on another computer; it can learn about its environment by querying its “context” but normally doesn't need to do that very much. The bean class typically is called the EJB's simple name, with the word Bean attached. The bean class for our Calculator EJB is thus CalculatorBean, defined in the file CalculatorBean.java. The bean class must implement either the SessionBean or EntityBean interface, depending on what type of bean it is.
The first interface is the remote interface, which allows the application to locate and get a reference to the Calculator EJB. The remote interface traditionally is given a simple name, such as Calculator and thus is defined in the file Calculator.java. The remote interface should define a method for each public method in the bean class. The remote interface must extend the EJBObject class.
The second interface is the home interface, which allows the EJB container to create, locate, destroy and otherwise manage an Enterprise JavaBean. The home interface is traditionally given the same name as the remote interface, with the word Home attached. The name of our EJB's home interface is thus CalculatorHome, which we define in the file CalculatorHome.java. The home interface must extend the EJBHome class.
One of the nice things about EJB is that your classes can rely on the default EJB behavior much of the time. This might not be the most efficient way to go about things, but it allows us to focus on writing the functional part of our code, allowing the EJB container to handle almost all of the infrastructure.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Client-Side Performance
- Tibbo Technology's Tibbo Project System
- Sony Settles in Linux Battle
- Peppermint 7 Released
- Libarchive Security Flaw Discovered
- July 2016 Issue of Linux Journal
- The Giant Zero, Part 0.x
- Maru OS Brings Debian to Your Phone
- Profiles and RC Files
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide