Sun Java System Application Server Platform Edition 8 Migrating and Redeploying Server Applications Guide |
Appendix A
iBank Application SpecificationThe iBank application is used as the migration sample. This application simulates a basic online banking service with the following functionality:
- log on to the online banking service
- view/edit personal details and branch details
- summary view of accounts showing cleared balances
- facility to drill down by account to view individual transaction history
- money transfer service, allowing online transfer of funds between accounts
- compound interest earnings projection over a number of years for a given principal and annual yield rate
The application is designed after the MVC (Model-View-Controller) model where:
- EJBs are used to define the business and data model components of the application
- Java Server Pages handle the presentation logic and represent the View.
- Servlets play the role of Controllers and handle application logic, taking charge of calling the business logic components and accessing business data via EJBs (the Model), and dispatching processed data for display to Java Server Pages (the View).
Standard J2EE methods are used for assembling and deploying the application components. This includes the definition of deployment descriptors and assembling the application components within the archive files:
- a WAR archive file for the Web application including HTML pages, images, Servlets, JSPs and custom tag libraries, and ancillary server-side Java classes.
- EJB-JAR archive files for the assembling of one or more EJBs, including deployment descriptor, bean class and interfaces, stub and skeleton classes, and other helper classes as required.
- an EAR archive file for the packaging of the enterprise application module that includes the Web application module and the EJB modules used by the application.
The use of standard J2EE assembling methods will be useful in pointing out any differences between Sun ONE Application Server 6.x/7.x and Sun Java System Application Server Platform Edition 8, and any issues arising thereof.
Database SchemaThe iBank database schema is derived from the following business rules:
- The iBank company has local branches in major cities.
- A Branch manages all customers within its regional area.
- A Customer has one or more accounts held at their regional branch.
- A customer Account is uniquely identified by the branch code and account number, and also holds the number of the customer to which it belongs. The current cleared balance available is also stored with the account.
- Accounts are of a particular Account Type that is used to distinguish between several kinds of accounts (checking account, savings account, etc.).
- Each Account Type stores a number of particulars that apply to all accounts of this type (regardless of branch or customer) such as interest rate and allowed overdraft limit.
- Every time a customer receives or pays money into/from one of their accounts, the transaction is recorded in a global transaction log, the Transaction History.
- The Transaction History stores details about individual transactions, such as the relevant branch code and account number, the date the transaction was posted (recorded), a code identifying the type of transaction and a complementary description of the particular transaction, and the amount for the transaction.
- Transaction types allow different types of transactions to be distinguished, such as cash deposit, credit card payment, fund transfer between accounts, and so on.
Figure A-1, the entity-relationship diagram shown below, illustrates these business rules.
Figure A-1 Database Schema
The database model translates as a series of table definitions below, where primary key columns are printed in bold type, while foreign key columns are shown in italics.
ACCOUNT_TYPE
ACCTYPE_ID
CHAR(3)
NOT NULL
3-letter account type code
ACCTYPE_DESC
VARCHAR(30)
NOT NULL
Account type description
ACCTYPE_INTERESTRATE
DECIMAL(4,2)
DEFAULT 0.0
Annual interest rate
TRANSACTION_TYPE
TRANSTYPE_ID
CHAR(4)
NOT NULL
A 4-letter transaction type code
TRANSTYPE_DESC
VARCHAR(40)
NOT NULL
Human-readable description of code
Application Navigation and LogicFigure A-2 provides a high-level view of application navigation.
Figure A-2 Application Navigation and Logic
Login Process
Figure A-3 shows the login process used in the iBank application.
Figure A-3 Login Process
View/Edit Details
Figure A-4 shows the view/edit details process used in the iBank application.
Figure A-4 View/Edit Details Process
Account Summary and Transaction History
Figure A-5 shows how the account summary and transaction history work in the iBank application.
Figure A-5 Account Summary and Transaction History
Fund Transfer
Figure A-6 shows how funds are transferred in the iBank application.
Figure A-6 Fund Transfer
Interest Calculation
Figure A-7 shows how interest is calculated in the iBank application.
Figure A-7 Interest Calculation
Application ComponentsData Components
Each table in the database schema is encapsulated as an entity bean:
All entity beans use container-managed persistence (CMP), except Customer, which uses bean-managed persistence (BMP).
Currently, the application only makes use of the Account, AccountType, Branch, and Customer beans.
Business Components
Business components of the application are encapsulated by session beans.
The BankTeller bean is a stateful session bean that encapsulates all interaction between the customer and the system. BankTeller is notably in charge of the following activities:
The InterestCalculator bean is a stateless session bean that encapsulates financial calculations. It is responsible for providing the compound interest projection calculations, through the projectEarnings() method.
Application Logic Components (Servlets)
Presentation Logic Components (JSP Pages)
Fitness of Design Choices with Regard to Potential Migration IssuesWhile many of application design choices made are certainly debatable especially in the “real-world” context, care was taken to ensure that these choices enable the sample application to encompass as many potential issues as possible as one would face in the process of migrating a typical J2EE application.
This section will go through the potential issues that you might face when migrating a J2EE application, and the corresponding component of iBank that was included to check for this issue during the migration process.
With respect to the selected migration areas to address, this section specifically looks at the following technologies:
Servlets
The iBank application includes a number of servlets, that enable us to detect potential issues with:
Java Server Pages
With respect to the JSP specification, the following aspects have been addressed:
- Use of JSP declarations, scriptlets, expressions, and comments
- Static includes (<%@ include file="…" %>): notably tested with the inclusion of the CheckSession.jsp file in every page)
- Dynamic includes (<jsp:include page=… />): this is catered for by the dynamic inclusion of Header.jsp in every page
- Use of custom tag libraries: a custom tag library is used in the file ShowTransactionHistory.jsp
- Error pages for JSP exception handling: the Error.jsp page is the application error redirection page
JDBC
Enterprise Java Beans
The iBank application uses a variety of Enterprise Java Beans.
Entity Beans
Bean-managed persistence (Customer bean): allows us to test the following:
Container-managed persistence ("Account" and "Branch" beans): allow us to test the following:
- Object/Relational mapping with the development tool and within the deployment descriptor
- Use of composite primary keys (Account)
- Definition of custom CMP finders (with the "Account" bean, and its findOrderedAccountsForCustomer() method). This is the occasion to look at differences in declaring the query logic in the deployment descriptor, and also to have a complex example returning a collection of objects.
Session Beans
Stateless session beans: InterestCalculator allows us to test the following:
Stateful session beans: BankTeller allows us to test the following:
- Looking up various interfaces using JNDI and initial contexts
- Using JDBC to perform database queries
- Using various transactional attributes on bean methods
- Using container-demarcated transactions
- Maintaining conversational state between calls
- Business methods acting as front-ends to entity beans (e.g., the "getAccountSummary()" method)
Application Assembly
The iBank application is assembled by following the J2EE standard procedures. It contains the following components: