|Home > Documentation > Reference > Samples > Sample applications > bank - EJB sample application|
This sample applications includes an ejb module with a stateless session bean, jpa entity beans, a web client, and a very simple command line non-javaee client. There are no security features.
There are three jpa entities Account, Customer and ExchangeRate. They are not set up to demonstrate any entity relationships.
todo: rewrite to use jpa entity relationships
The jpa entities rely on the datsources defined in the SamplesDatasource plugin.
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.
There is no need for an openejb plan.
persistence.xml defines a persistence unit which is used by an EntityManagerFactory in order to talk to SampleDatabase through the SampleDatasource configuration. The name that is given to this <persistent-unit> will be used when referencing it via an annotation in the EJB. The <jta-data-source> and <non-jta-data-source> MUST NOT point to the same thing.
web.xml lists the servlets and url-patterns.
No web plan is needed.
The geronimo plan plan.xml contains the db initialization gbean that runs a script to create tables and populate them. If you leave this out openjpa will create or update the structure of the tables on first access. The unprocessed version of this plan is at bank-jetty/src/main/plan/plan.xml. The processed version shown here with plugin name and all dependencies filled in can be found at bank-jetty/target/resources/META-INF/plan.xml after building the project.
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.
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)
The bank command line client does a JNDI lookup to the remote interface. Later, the list of ExchangeRate is obtained and printed out on the screen.
Please note that "BankManagerFacadeBeanRemote" is used here as the look up name instead of "BankManagerFacadeRemote". Otherwise, you'll get an error like this -
javax.naming.NameNotFoundException: /BankManagerFacadeRemote does not exist in the system. Check that the app was successfully deployed.
To test the command line client first determine a useable (although excessive classpath) by running
If you are using windows platform, you need to replace the ":" separator that separates the classpath jars with the ";" separator. Also, if you use the default maven 2 home, you need to replace "c:\documents and settings" with "c:\docume~1".
then in bank-client run