EJB Basics
To create an EJB, you’ll need to create at least two interfaces and one class. One of the interfaces defines the Bean’s business methods and is referred to as the remote interface. Business methods are those methods that you’ll use in client code to manipulate the Bean. For example, if you have methods to get or set variable values of the Bean, those methods will be defined in the remote interface. The other interface is called the home interface, and it is responsible for what is known as the Bean’s life cycle. The home interface defines methods to create, remove, and find Beans. These two interfaces and their methods are used by the client code to interact with the Bean itself.
The actual Bean class must have identical methods to those defined in the remote interface, and it must also have methods corresponding to some of the methods of the home interface. Client code doesn’t actually instantiate an object of the Bean class. (This may seem redundant or somewhat confusing, but it will become quite clear as you continue your EJB development efforts!) An optional class used only for entity Beans is called a primary key class, which is quite simple and provides access to a database record via a primary key.
There are basically two types of EJBs: session Beans and entity Beans. Session Beans can be categorized as either stateful or stateless and, as a rule, represent some sort of business logic. For example, if your Bean design called for an EJB that did nothing but calculate sales tax based on the geographical location of a customer, a session Bean would be a good candidate to perform that function. The two flavors of entity Beans are Bean- managed persistent Beans and container-managed persistent Beans, usually referred to as BMP Beans or CMP Beans, respectively. Entity Beans are typically used to represent database records. If you choose in your entity Bean to take care of the database
communication yourself using SQLj, JDBC, or the AS/400 Toolbox for Java’s record-level access classes, your Bean will be a BMP Bean. If you choose to have the EJB container take care of the communication between your entity Bean and a database, you will have created a CMP Bean.
Sophisticated Beans
A mention of CMP Beans usually brings the question, “How does an EJB container handle the database inserts, updates, and deletes for me?” The sophistication of EJB containers allows them to provide much more than a space for EJBs to run. As I mentioned, an EJB container can handle database operations in entity Beans. Virtually every container on the market today does so through the Java Database Connectivity (JDBC) driver of the database your CMP Bean will use. In the case of the AS/400, this means that if you want to get at the data in your AS/400 files, you’ll configure your EJB container to use the JDBC driver found in the AS/400 Toolbox for Java. Fields in a CMP Bean are then mapped to specific fields in a specific table in a specific database. Because the EJB 1.1 specification isn’t crystal clear on how these mappings are to be implemented, the method to perform the mappings is container-specific. The accompanying example details how to instruct your EJB container to make a particular CMP Bean aware of its corresponding database file.
In dealing with databases, EJB containers also provide client code with transaction management. The Java Transaction API is used by the container to give client code a high- level transaction service, thereby relieving the client code developer of worries about transaction management and coordination.
Security, Please
Another feature of EJB containers is their ability to perform security functions. The EJB
1.1 and the Servlets 2.2 specifications define standards and rules for containers to follow to accomplish the goal of cross-platform security. Until quite recently, security for any server- side Java application was platform-specific. In the case of the AS/400, this meant learning validation list APIs or using HTTP basic authentication for a user and then devising your own system of access.
EJB containers also manage resources, including database connections, threads, and Socket connections. Container support can allow multiple clients to access Beans, which frees the developer from worrying about how Beans are accessed or what happens when a Bean is on the receiving end of a deluge of client requests. The container does this by creating as many or as few instances of the Bean object as necessary within the container and by routing client requests to appropriate instances of the Bean. Fundamentally, however, the EJB container creates a distributed, networked application out of components (the interfaces and classes comprising a single EJB) that are written essentially as standalone objects. This, of course, is no small thing.
To recap the benefits of EJBs and EJB containers, the EJB model allows for developers to partition their efforts cleanly between session Beans and entity Beans. In using these Beans, the developer is freed from low-level database transaction knowledge. The developer will also be able to use cross-platform security and avoid coding to a platform-specific security API. The developer may choose to bypass coding database operations and have the container perform those tasks. The developer is thereby freed from the worry of threads or providing resources such as database connections. The developer is relieved of having to figure out how to handle multiple clients of the Bean. And, possibly most significant, the Bean developer is able to develop networked, distributed components without coding or knowing how those components will become networked and distributed. RPG developers can understand the importance of EJBs and EJB containers, as most of their benefits are similar to those that OS/400 provides for an RPG program. With all these advantages, it’s no wonder that EJB development is of great interest to business application developers.
Deploying the Bean
Rather than coding for many of these EJB features, they can be implemented by declaring them in what’s known as the deployment descriptor. Figure 1 (page 75) shows a portion of a required deployment descriptor of an EJB called ejb-jar.xml. As you can see by the file name, this is an XML file with tags to define the Bean, the Bean’s remote and home interfaces, primary key class (if any), and other descriptions to assist the EJB container in deploying the Bean. Note the example is of a CMP Bean corresponding to the familiar sample file of each AS/400, QIWS/QCUSTCDT. The deployment descriptor declares that the Bean’s persistence is managed by the container, and then it declares fields in the Bean that the container will have to map to the correct fields in the correct file. The ejb-jar.xml file can be quite lengthy and has many tags to use and remember. Typically, EJB containers come with tools to create these deployment descriptors. Even with these tools, however,
it’s a good idea to become familiar with the more common, required tags by going to Sun Microsystems’s EJB site at www.java.sun.com/products/ejb.
As I mentioned, a container that is EJB 1.1-compliant will offer support for CMP; in EJB 1.0-compliant containers, CMP support is only optional. However, there are no clear instructions for EJB containers on how to implement this functionality, and it is left to the container vendor to figure out how to do CMP support. In the case of JOnAS, CMP support comes in the form of another XML deployment descriptor called jonas-ejb-jar.xml, a portion of which is shown in Figure 2 (page 75). One of the functions of an EJB container that I mentioned is the capacity to manage resources, including database connections. In the jonas-ejb-jar.xml deployment descriptor, there is the Java Naming and Directory Interface (JNDI) name of the database connection resource called AS/400. Setup of this resource is included in the configuration files of the entire example, downloadable at www.midrangecomputing.com/mc. The table name is defined here (QCUSTCDT), and the CMP Bean’s fields are mapped to the actual physical file fields. Also, you can see declarations on how to implement what are known as finder methods. Finder methods are defined in the Bean’s home interface and are meant to put a wrapper around SQL SELECT statements. Container-specific deployment descriptors will vary slightly in their descriptions of Bean field to database field mappings and finder methods. The downloadable example is a simple CMP Bean with a client class that simply gets a reference to the EJB and performs a few methods on that Bean. Figure 3 shows the output.
Which Is Better? JOnAS and jBoss
I’d like to talk a bit about the two open source containers mentioned in the beginning of the article, JOnAS and jBoss. As open source products, both are freely available to download and use in production immediately. I’ll give you my take on both products based on my experience. Both are all-Java products, meaning that they can run on any machine that has a Java Virtual Machine (JVM). I’ll say more on this. Typically, the installation procedure for Java products, including these, is to simply download a .zip file and extract it to wherever you like on your disk. One of the first things to do is configure the container to create a data source for whatever database you’ll be using. For me, it was easier to configure an AS/400 data source for JOnAS than jBoss. Documentation for this procedure was clearer for JOnAS and the process was much more straightforward. Also, it was easier to configure a CMP Bean for use with JOnAS than with jBoss. Because all deployment descriptors in EJB 1.1 containers are XML files, it would make sense that one would be able to use a favorite XML editor to construct these files. With jBoss, however, it doesn’t seem to be enough that the deployment descriptors are both well-formed and valid. It appears to be hitand-miss as to whether jBoss will choke on deploying your EJBs, depending on whether you used its supplied deployment descriptor generator (EJX). For example, I was able to use the XML features in the integrated development environment (IDE) Forte (see “Is Developing Java Apps Your Forte?” MC, October 2000) to create my ejb-jar.xml file,
check and validate the XML, and have JOnAS recognize it. I could not get jBoss to recognize that deployment descriptor or the jBoss-specific CMP deployment descriptor, jaws.xml. jBoss’s mailbox is littered with messages from users complaining about the behavior of EJX and jBoss’ inability to consistently recognize deployment descriptors regardless of how they’re created. As I’m writing this, it appears that this particular nuisance will be with jBoss users for at least a while longer.
Despite its difficulties with creating data sources and deployment descriptors, I believe that jBoss is the superior of the two containers for a couple of key reasons. First is jBoss’s ability to hot-deploy a Bean. EJBs are packaged in JAR files; with jBoss, deployment of the JAR file is as simple as dropping the JAR file into a directory that jBoss constantly monitors for new Beans. This means no restarting the container when there are new Beans to deploy, an extremely significant feature for any production-quality software. Second, there has been significant work in this project to integrate Tomcat as tightly as possible. Tomcat is the open source/servlet JavaServer Page (JSP)/servlet container from the Apache Software Foundation, makers of the ever-popular Apache HTTP Server. Tomcat’s origins are in Sun’s reference implementation of its JSP/servlet specification. Sun handed over the code for that reference implementation to the Apache group, and Tomcat is the resulting production-quality JSP/servlet container. Both JOnAS and jBoss can receive security information (such as roles and users) from Tomcat, creating a seamless security environment for JSPs, servlets, and EJBs. Where jBoss shines, though, is not in the project’s work to run the two products within the same JVM, but in its focus on communication speed between the two.
Another great aspect of jBoss is that you don’t need to compile stubs and skeletons. If you’re familiar with Remote Method Invocation (RMI), you’ll know that RMI uses intermediary objects called stubs and skeletons to communicate across the network. JONAS comes with a tool called GenIC, which reads the classes and interfaces of your Beans, creates the source for classes required by JONAS (stubs and skeletons), and then compiles the source. The resulting class files must be packaged in the same JAR file as the Bean class files and then deployed. The reason for this step is that EJB uses some features of RMI to perform communication between objects across the network. In any case, not having to carry out this task when using jBoss is a definite plus.
Of course, the AS/400 has a JVM, and IBM has recently made version 1.3 available on the platform. Having said that, even with the help of other AS/400 professionals, I was unable to get either of these containers to run on IBM’s AS/400 JVM. After running these containers on Windows 98, Windows NT, Red Hat’s Linux, and even Sun’s Solaris, my suspicion turns to the AS/400 JVM. Without concrete proof, I’m unable to lambaste the AS/400 JVM, but I, along with MC senior technical editor Don Denoncourt, will be sure not to let this issue die, so as to deliver to the AS/400 community two production-quality open source EJB containers.
For most, EJBs on the AS/400 means WebSphere. WebSphere costs big bucks—about $7,500. For the sake of argument, take the worst-case scenario concerning running either JOnAS or jBoss: that they’ll never be able to run in the AS/400’s JVM. Spending a few grand on an Intel server running Linux that will be used only for Apache/Tomcat/jBoss-JOnAS would still be less costly than a copy of WebSphere. On top of that, you’d be able to take advantage of the latest Java 2 Enterprise Edition specifications, instead of waiting for WebSphere to bring itself up to still a couple versions behind the current specifications for JDBC, servlets, and JSPs. Download both JOnAS and jBoss, spend some time developing EJBs, and soon you’ll be ready to use them in production.
The JVM
REFERENCES AND RELATED MATERIALS
• jBoss Web site: www.jboss.org
• JOnAS Web site: www.evidian.com/jonas/index.htm
• Sun Microsystems’s EJB information page: www.java.sun.com/products/ejb
. . .
. . .
Figure 1: The ejb-jar.xml file has tags to assist the EJB container in deploying the Bean.
. . .
. . .
Figure 2: Use the XML deployment descriptor to provide CMP support in JOnAS.
CustomerHome.create() result:
J Doe 123 Main GR , MI 49525 Credit limit: 5000
CustomerHome.findByPrimaryKey() result:
G K Henning 4859 Elm Ave Dallas, TX 75217
CustomerHome.findByLastName() result:
G K Henning 4859 Elm Ave Dallas, TX 75217
CustomerHome.findByCreditLimit() result:
G K Henning 4859 Elm Ave Dallas, TX 75217
J A Johnson 3 Alpine Way Helen , GA 30545
W E Tyron 13 Myrtle Dr Hector, NY 14841
J S Alison 787 Lake Dr Isle , MN 56342
A N Thomas 3 Dove Circle Casper, WY 82609
M T Abraham 392 Mill St Isle , MN 56342
J Doe 123 Main GR , MI 49525
CustomerHome.findAllCustomers() result:
G K Henning 4859 Elm Ave Dallas, TX 75217
B D Jones 21B NW 135 St Clay , NY 13041
S S Vine PO Box 79 Broton, VT 5046
J A Johnson 3 Alpine Way Helen , GA 30545
W E Tyron 13 Myrtle Dr Hector, NY 14841
K L Stevens 208 Snow Pass Denver, CO 80226
J S Alison 787 Lake Dr Isle , MN 56342
J W Doe 59 Archer Rd Sutter, CA 95685
A N Thomas 3 Dove Circle Casper, WY 82609
F L Lee 5963 Oak St Hector, NY 14841
M T Abraham 392 Mill St Isle , MN 56342
J Doe 123 Main GR , MI 49525
Figure 3: The output of a simple CMP Bean shows data for a client class
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online