Figure 18-2 takes a closer look at the access paths between the clients, enterprise beans, and database tables. As you can see, the end-user clients (Web and J2EE application clients) access only the session beans. Within the enterprise bean tier, the session beans are clients of the entity beans. On the back end of the application, the entity beans access the database tables that store the entity states.
Figure 18-2 Enterprise Beans in the Duke's Bank Application
The source code for these enterprise beans is in the
The Duke's Bank application has three session beans:
Txstands for a business transaction, such as transferring funds.) These session beans provide a client's view of the application's business logic. Hidden from the clients are the server-side routines that implement the business logic, access databases, manage relationships, and perform error checking.
The business methods of the
AccountControllerEJBsession bean perform tasks that fall into the following categories: creating and removing entity beans, managing the account-customer relationship, and getting the account information.
The following methods create and remove entity beans:
These methods of the
AccountControllerEJBsession bean call the
removemethods of the
AccountEJBentity bean. The
removeAccountmethods throw application exceptions to indicate invalid method arguments. The
createAccountmethod throws an
IllegalAccountTypeExceptionif the type argument is neither
Money Market. The
createAccountmethod also verifies that the specified customer exists by invoking the
findByPrimaryKeymethod of the
CustomerEJBentity bean. If the result of this verification is
createAccountmethod throws a
The following methods manage the account-customer relationship:
CustomerEJBentity beans have a many-to-many relationship. A bank account may be jointly held by more than one customer, and a customer may have multiple accounts. Because the entity beans use bean-managed persistence, there are several ways to manage this relationship. For more information, see Mapping Table Relationships for Bean-Managed Persistence.
In the Duke's Bank application, the
removeCustomerFromAccountmethods of the
AccountControllerEJBsession bean manage the account-customer relationship. The
addCustomerToAccountmethod, for example, starts by verifying that the customer exists. To create the relationship, the
addCustomerToAccountmethod inserts a row into the
customer_account_xrefdatabase table. In this cross-reference table, each row contains the
accountIdof the related entities. To remove a relationship, the
removeCustomerFromAccountmethod deletes a row from the
customer_account_xreftable. If a client calls the
removeAccountmethod, then all rows for the specified
accountIdare removed from the
The following methods get the account information:
AccountControllerEJBsession bean has two
getAccountsOfCustomermethod returns all of the accounts of a given customer by invoking the
findByCustomermethod of the
AccountEJBentity bean. Instead of implementing a
getmethod for every instance variable, the
getDetailsmethod that returns an object (
AccountDetails) that encapsulates the entire state of an
AccountEJBbean. Because it can invoke a single method to retrieve the entire state, the client avoids the overhead associated with multiple remote calls.
Because it is the
AccountControllerEJBbean that manages the customer-account relationship,
CustomerControllerEJBis the simpler of these two session beans. A client creates a
CustomerEJBentity bean by invoking the
createCustomermethod of the
CustomerControllerEJBsession bean. To remove a customer, the client calls the
removeCustomermethod, which not only invokes the
CustomerEJB, but also deletes from the
customer_account_xreftable all rows that identify the customer.
CustomerControllerEJBsession bean has two methods that return multiple customers:
getCustomersOfLastName. These methods call the corresponding finder methods--
TxControllerEJBsession bean handles bank transactions. In addition to its
TxControllerEJBbean has several methods that change the balances of the bank accounts:
These methods access an
AccountEJBentity bean to verify the account type and to set the new balance. The
depositmethods are for non-credit accounts, whereas the
makePaymentmethods are for credit accounts. If the
typemethod argument does not match the account, these methods throw an
IllegalAccountTypeException. If a withdrawal were to result in a negative balance, then the
withdrawmethod throws an
InsufficientFundsException. If a credit charge attempts to exceed the account's credit line, the
makeChargemethod throws an
transferFundsmethod also checks the account type and new balance; if necessary, it throws the same exceptions as the
transferFundsmethod subtracts from the balance of one
AccountEJBinstance and adds the same amount to another instance. Because both of these steps must complete, the
transferFundsmethod has a
Requiredtransaction attribute. If either step fails, the entire operation is rolled back and the balances remain unchanged.
For each business entity represented in our simple bank, the Duke's Bank application has a matching entity bean:
The purpose of these beans is to provide an object view of these database tables:
tx. For each column in a table, the corresponding entity bean has an instance variable. Because they use bean-managed persistence, the entity beans contain the SQL statements that access the tables. For example, the
createmethod of the
CustomerEJBentity bean calls the SQL
Unlike the session beans, the entity beans do not validate method parameters (except for the primary key parameter of
ejbCreate). During the design phase, we decided that the session beans would check the parameters and throw the application exceptions, such as
IllegalAccountTypeException. Consequently, if some other application were to include these entity beans, its session beans would also have to validate the method parameters.
The EJB JAR files include several helper classes that are used by the enterprise beans. The source code for these classes is in the
j2eetutorial/bank/src/com/sun/ebank/utilsubdirectory. Table 18-1 briefly describes the helper classes.
Table 18-1 Helper Classes for the Application's Enterprise Beans Class Name
Encapsulates the state of an
AccountEJBinstance. Returned by the
Defines the strings that are the logical names in the calls of the
lookupmethod. (For example:
EJBGetterclass references these strings.
Encapsulates the state of a
CustomerEJBinstance. Returned by the
Provides methods that generate the next primary keys (for example,
Has simple methods for printing a debugging message from an enterprise bean. These messages appear on the stdout of the J2EE server if it's run with the
Contains validation methods:
Has methods that locate (by invoking
lookup) and return home interfaces (for example,
Encapsulates the state of a
TxEJBinstance. Returned by the
A database table of the Duke's Bank application may be categorized by its purpose: representing business entities and holding the next primary key.
Tables Representing Business Entities
Figure 18-3 shows relationships between the database tables. The
accounttables have a many-to-many relationship: A customer may have several bank accounts, and each account may be owned by more than one customer. This many-to-many relationship is implemented by the cross reference table named
txtables have a one-to-many relationship: A bank account may have many transactions, but each transaction refers to a single account.
Figure 18-3 makes use of several abbreviations. PK stands for primary key, the value that uniquely identifies a row in a table. FK is an abbreviation for foreign key, which is the primary key of the related table. Tx is short for transaction, such as a deposit or withdrawal.
Figure 18-3 Database Tables in the Duke's Bank Application
Tables That Hold the Next Primary Key
These tables have the following names:
Each of these tables has a single column named
id. The value of
idis the next primary key that is passed to the
createmethod of an entity bean. For example, before it creates a new
AccountEJBentity bean, the
AccountControllerEJBsession bean must obtain a unique key by invoking the
getNextAccountIdmethod of the
getNextAccountIdmethod reads the
next_account_idtable, increments the
idvalue in the table, and then returns the
Protecting the Enterprise Beans
In the J2EE platform, you can protect an enterprise bean by specifying the security roles that can access its methods (see EJB-Tier Security). In the Duke's Bank application, two roles are defined--
BankAdmin--because two categories of operations are defined by the enterprise beans.
A user in the
BankAdminrole is allowed to perform administrative functions: creating or removing an account, adding a customer to or removing a customer from an account, setting a credit line, and setting an initial balance. A user in the
BankCustomerrole is allowed to deposit, withdraw, transfer funds, make charges and payments, and list the account's transactions. Notice that there is no overlap in functions that users in either role can perform.
Access to these functions was restricted to the appropriate role by setting method permissions on selected methods of the
TxControllerEJBenterprise beans. For example, by allowing only users in the
BankAdminrole to access the
createAccountmethod in the
AccountControllerEJBenterprise bean, you have denied users in the
BankCustomerrole or any other role permission to create bank accounts. To see the method permissions that have been set, in
TxControllerEJBenterprise beans in the tree view. For each bean, select the Security tab and examine the method permissions.