Sun ONE Application Server 7 Migrating and Redeploying Server Applications Guide |
Module AiBank Application specification
The sample application we defined is called 'iBank' and 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).
For packaging and deployment of application components, standard J2EE methods are used, and include definition of deployment descriptors, and packaging of application components within 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 packaging 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 packaging methods will be useful in pointing out any differences between Sun ONE Application Server 6.0/6.5 and Sun ONE Application Server 7, and any issues arising thereof.
Tools used for the development of the application
Sun ONE Studio Enterprise Edition for Java, Release 4.0
As Sun ONE Application Server 7 supports both the EJB 1.0 and EJB 1.1 standard, the other EJBs in the iBank application (2 session EJBs and the BMP entity bean) were developed with Sun ONE Studio for Java, and then packaged and deployed in Sun ONE Application Server 7 using the supplied Application Assembly Tool. This approach enabled us to test usage of a third-party IDE for developing 1.1 EJBs in Sun ONE Application Server 7. Moreover, the approach also gave us the chance to experiment with migrating 1.1 EJBs developed for Sun ONE Application Server 6.5 to Sun ONE Application Server 7.
The Sun ONE Studio for Java development environment was also used to migrate EJB components in the iBank application to Sun ONE Application Server (code adapted from EJB 1.0 standard to EJB 1.1, O/R mapping for CMP entity beans, configuration of deployment properties and packaging of the application's different modules).
Oracle 8i 8.1.6
The database was developed with Oracle 8i (version 8.1.6) and the JDBC driver used to access the database was the thin Oracle driver (type 4).
Database schema
- The 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 no., and also holds the no. 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 no., 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.
These business rules are illustrated in the entity-relationship diagram below:
Figure 1    Database Schema
The database model translates as the 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 logic
High-level view of application navigation
Detailed application logic
- Login Process
- View / edit details
- Account summary and Transaction history
- Fund Transfer
- Interest Calculation
Application Components
- Data 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 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 issues
While many of application design choices made are certainly debatable especially in a "real-world" context, care was taken to ensure that these choices enabled 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 one can 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, the white paper specifically looks at the following technologies:
Servlets
- iBank includes a number of servlets, that enable us to detect potential issues with:
- The use of generic functionality of the Servlet API.
- Storage/retrieval of attributes in the HTTP session and HTTP request.
- Retrieval of servlet context initialisation parameters.
- Page redirection.
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 ShowTransactionHistory.jsp.
Error pages for JSP exception handling: the Error.jsp page is the application error redirection page.
JDBC
The iBank application accesses a database via a connection pool and data source, both programmatically (BMP entity bean, BankTeller session bean, custom tag library) and declaratively (with the CMP entity beans).
Enterprise Java Beans
iBank uses a variety of Enterprise Java Beans:
Entity beans:
Bean-managed persistance ("Customer" bean): that allows us to test:
JNDI lookup of initial context
pooled data source access via JDBC
definition of a BMP custom finder ("findByCustUsername()")
Container-managed persistence ("Account" and "Branch" beans): that allow us to test:
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:
Stateful session beans: BankTeller allows us to test:
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 Packaging