|Home > Documentation > Sample applications > EJB sample application|
Enterprise Java Beans has been one of the corner stones of the J2EE specification. As a J2EE 1.5 certified application server, Apache Geronimo supports EJB's extensively with the help of OpenEJB EJB Container. 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. In this article, you will see how an initial database application is extended and used for both local and remotely referred application clients for an Enterprise Java Beans back end. The application uses the built-in Apache Derby as its database. Use this article to learn how to simplify your enterprise application development process.
Banking application has two types of application clients namely "Banking Remote Application" and "Banking Web Application". Each of these clients demonstrate how to refer Enterprise Java Beans in remote and local interfaces respectively. Both these clients are referring a common business layer which has been implemented with the help of Session and Entity Beans. Stateless Session Beans are acting as the business service interface between business entities and application clients. All the business entities of the application layer are implemented with Entity Beans.
After reading this article you should be able get the best out of EJB features of Geronimo, such as defining Enterprise Java Beans, managing relations between them and refer EJB's via differents kind of clients.
This article is organized in to following sections.
EJB implementation may vary from one vendor to another.The following are the main list of features Apache Geronimo supports as a J2EE container.
As mentioned above the Banking application supports two types of business application clients.The overview of each client is given below.
Both of these clients use a common business service layer. Behind that business service layer, there are three common business entities that appear in the banking application domain Account, Customer and ExchangeRate. Each Customer can have more than one Account while an Account can only be owned by one Customer. ExchangeRate represents a rate value given by the bank relative to the USD for a particular currency.
The Banking application consists of the following list of packages and classes.
Finally, the banking application will be deployed as an EAR to the application server. The overview of the structural content of the EAR file is given in the following example.
First, we will look at how the business service layer of the application has been implemented with the help of EJBs.
Corresponding openejb-jar.xml defines Geronimo specific features of EJBs. Since we will deploy the database pool along with the application, there is no need to provide a dependency to an existing database pool.
persistence.xml defines a persistence unit which is used by an EntityManagerFactory in order to talk to BankDB through the BankPool configuration. The name that is given to this <persistent-unit> will be used when trying to reference it via an annotation in the EJB. By setting the SynchronizeMappings property it will not overwrite what is already in the database. So this is important to have when you do not want your data to be deleted. The jta-data-source and non-jta-data-source should point to the same thing.
web.xml does not do anything special here. It just enumerates the servlets present in the web-app and maps the url-pattern for each of them.
geronimo-web.xml is the Geronimo specific deployment plan. As usual, it specifies the module's information and context-root. So in order to visit the web-app the root url will be http://localhost:8080/Bank.
BankPool.xml provides the connection information for a database on Geronimo. In this case we are using Geronimo's built-in Derby database. The dependency for it should actually be org.apache.geronimo.configs/system-database//car. It has caused me problems when trying to use anything different. The following database pool plan is generated from the console. The only change I made to it was the dependency to make it point to the system-database where the derby engine is running. This db pool will be deployed with the EAR application.
geronimo-application.xml tells the application that there is a database pool that needs to be deployed as well. The db pool is defined in BankPool.xml and the driver that is needs in order to be deployed is the tranql-connector-ra-1.3.rar file--these two files will reside on the top level layer of the resultant EAR file.
The sample database that is being used to demonstrate this application is inbuilt Derby database. The name of the sample database is BankDB and it consists of three tables, CUSTOMER ,ACCOUNT and EXCHANGE_RATE. The fields for each of these tables are described below.
customerId (PRIMARY KEY)
accountNumber (PRIMARY KEY)
rateId (PRIMARY KEY)
The CUSTOMER table stores the data related to the customers. It stores only the identification number and and the name. ACCOUNT table has a unique account number for identification. Account type and balance are the other information stored. Account.customerId is a foriegn key to the Customer table which is the owner of the Account. EXCHANGERATE table has a primary key of rateId for an identification. Each record of EXCHANGERATE has currency name and rate paid by the bank.
The tools used for developing and building the Banking applications are:
Apache Derby, an Apache DB subproject, is a relational database implemented in Java. Its footprint is so small you can easily embed it in any Java-based solution. In addition to its embedded framework, Derby supports a more familiar client/server framework with the Derby Network Server.
Maven is a popular open source build tool for enterprise Java projects, designed to take much of the hard work out of the build process. Maven uses a declarative approach, where the project structure and contents are described, rather than the task-based approach used in Ant or in traditional make files, for example. This helps enforce company-wide development standards and reduces the time needed to write and maintain build scripts. The declarative, lifecycle-based approach used by Maven 1 is, for many, a radical departure from more traditional build techniques, and Maven 2 goes even further in this regard. Maven 2 can be download from the following URL:
Download the bank application from the following link:
After decompressing the given file, the bank directory will be created.
You can checkout the source code of this sample from SVN:
Configuration of the application consists of creating the database and defining the connection pool to access it.
After starting Apache Geronimo log into the console and follow the given steps to create the BankDB.
Use a command prompt to navigate into the bank directory and just give mvn install site command to build. It will create the bank-ear-2.0-SNAPSHOT.ear under the bank folder. Now, you are ready to deploy bank application in the Geronimo Application server.
Deploying sample application is pretty straight forward as we are going to use the Geronimo Console.
To test the sample web application open a browser and type http://localhost:8080/Bank. It will forward you to the index page of banking application which has direct links to the view customer and exchange rate information. To view the list of account information of each customer, provide a relavant customer id in the DB. Exchange rate page will display list of all currencies in the exchange rate table. (Note that 'Bank' is case-sensitive)
This article has shown you how to use the EJB features of the Apache Geronimo. It has provided step-by-step instructions to build an application, deploy and run it to elaborate those features.
Following are some of the highlights of the article.