![]() |
|
![]() |
The YourCo Web site contains an example that uses enterprise beans to update and access persistent data in the employee leave banks. Employees can check the balance (how many days they have) in their vacation, sick and personal leave banks, and they can also transfer days between the banks. To see the enterprise beans in action at YourCo:
To find out more, see these topics: Why use enterprise beans Using the enterprise beans to manage the transactions simplifies your job while ensuring the integrity of the data during a transfer. As a web developer, you just need to invoke the enterprise beans (in this case they are invoked from servlets) and the enterprise beans handle the more complex processing for you: they ready the data store, read and write the data, and commit it when and if the transaction is assured to be complete. In the event of a network or system problem, you do not have to worry that one account would be debited and the other not be credited. And, it easy for the developer who creates the enterprise bean to make it into a transaction. The hard work is done by the EJB environment. If you have already looked at the Account, Transfer, and Increment sample enterprise beans, some of this will be familiar. To build this application we used the Account and Transfer samples as a starting point, made a few changes, and then added function with a few more beans. The leave banks use four enterprise beans in total, all created with IBM VisualAge for Java Enterprise Edition. They include three entity beans with container-managed persistence (CMP) and one session bean. Leave.jar contains an entity enterprise bean that was based on the Account EJB sample. This bean keeps track of days instead of money. The bean contains data for these columns in a database table: ID, TYPE, and BALANCE. We use the integers 1, 2 and 3 to indicate the leave bank type - for vacation, sick, or personal leave Access.jar contains a session enterprise bean that was based on the Transfer EJB sample. It has a getBalance() method to return the number of days instead of money. It has a transferDays() method which is similar to transferFunds() in the Transfer enterprise bean, but this new method also keeps an audit trail of all transfers by adding a new row in the History enterprise bean. And, it includes a new getHistory() method that accesses the History bean and returns a list of all the transfers for a specific ID between one leave bank TYPE and another. History.jar contains a new entity enterprise bean for the transfer history information. It maintains the data for these columns in a database: ID, FROMTYPE, TOTYPE, AMOUNT, THEDATE and THETIME. It also has an AUDITNUMBER that is the unique key for each row in the database table. Audit.jar contains an entity enterprise bean that was based on the Increment EJB sample. It is accessed by the transferDays() method of the Access bean to get a unique number to identify the new transaction row in the History bean. If you are going to adapt these enterprise beans for your own applications, these details will be of interest. Although we based the Leave enterprise bean on the Account sample, we changed the way we created the key. The Account bean has a single column, ACCOUNTID, used as the key, and the Leave bean has two columns, ID and TYPE, that jointly form the key. This allows days to be transferred between two different TYPEs for the same ID but prohibits them to be transferred between two different IDs. In this application, this means you can transfer from one of your banks to another, but not to another employee's banks. For this to work properly, the ID must be a multiple of 10. For example, 10, 20, 100, 110, 1300 are all valid IDs but 1, 27, 33 are not. The values of TYPE must be single digits between 0 and 9, inclusive. This is because the compound key must be a unique hashcode value, calculated by adding the value of ID to TYPE. Therefore, a hashcode of 22 is clearly ID 20 with TYPE 2, and not ID 18 with TYPE 4, or ID 19 with TYPE 3. If you do not follow these rules, the result is unpredictable.
|