Chapter 5 Migrating iBank Application

Chapter 5
Migrating iBank Application - Walkthrough

This chapter describes the process for migrating the main components of a typical J2EE application from Sun ONE Application Server 6.0 and 6.5 to Sun Java System Application Server 7 2004Q2. This chapter highlights the problems posed during the migration of each type of component and suggests practical solutions to overcome such problems.

For this migration process, the J2EE application presented is called iBank and is based on the actual migration of the iBank application from the Sun ONE Application Server 6.0 and 6.5 versions to Sun Java System Application Server 7 2004Q2. iBank simulates an online banking service and covers all of the aspects traditionally associated with a J2EE application.

The sensitive points of the J2EE specification covered by the iBank application are summarized below:

Servlets, especially with redirection to JSP pages (model-view-controller architecture)

JSP pages, especially with static and dynamic inclusion of pages

JSP custom tag libraries

Creation and management of HTTP sessions

Database access through the JDBC API

Enterprise JavaBeans: Stateful and Stateless session beans, CMP and BMP entity beans

Assembly and deployment in line with the standard packaging methods of the J2EE application

The iBank application is presented in detail in Appendix A, "iBank Application Specification."



Note	The sample application, iBank, is not a clustered application - because of which this chapter does not discuss about the migration issues related to clustered applications.

Preparing for Migrating the iBank Application

Before you start with the migration process learn about the differences in the deployment descriptors. For detailed information, see Migrating Deployment Descriptors.

Choosing the Target

If your applications support failover capabilities, you must choose the migration target server as Sun Java System Application Server 7 2004Q2, Enterprise Edition. The persistence type ha is the persistence type supported for production environments that require failover capabilities in Sun Java System Application Server 7 2004Q2, Enterprise Edition. For more details on enabling failover capabilities to your migrated applications, see the Sun Java System Application Server Administration Guide.

If your applications do not use the high availability features, you may choose to migrate your applications to Sun Java System Application Server 7 2004Q2, Standard Edition.

After choosing the target server, install the server on your migration environment. For step-by-step instructions to install the software, see the Sun Java System Application Server Installation Guide.

If you are using Sun Java System Migration Tool to migrate the components, you must install the tool. The Sun Java System Migration Tool can be downloaded from the following location:

http://www.sun.com/migration

For information on how to use the tool, see the Sun Java System Migration Tool online help.

Development Environment

The iBank application in Sun ONE Application Server 6.5 is developed using the Sun ONE Application Server 6.5 and Sun ONE Studio. Sun ONE Application Server 6.5 supports the following features:

Load-balancing of applications across server instances

Failover of server instances nodes

Identifying the Components of the iBank Application

Extract the application, which is in a zip format in a local directory.

The source for the iBank application (iBank65.zip) can be found at the migration site http://www.sun.com/migration/sunonetools.html. Unzipping the file iBank65.zip would create the following directory structure:

iBank
/docroot
/session
/entity
/misc

/docroot contains HTML, JSP’s and Image files in its root. It also contains the source files for servlets and EJBs in the sub-folder WEB-INF\classes following the package structure com.sun.bank.*. A war file is generated through the contents of this directory.

/session contains the source code for the session beans following the package structure com.sun.bank.ejb.session. This directory forms the EJB module for the session beans.

/entity contains the entity beans following the package structure com.sun.bank.ejb.entity. This directory would form the EJB module for entity beans.

/misc contain the sql scripts for the database setup.

Setup the Schema

Setup the schema for iBank application by executing the sql scripts provided in the /misc folder. These scripts are for oracle database. These scripts creates user, creates tables and insert data into the tables. Execute the scripts in the following order:

01_iBank_CreateUser.sql

02_iBank_CreateTables.sql

03_iBank_InsertData.sql

Manual Migration of iBank Application

The manual migration does not require any major changes in the source code as Sun Java System Application Server 7 2004Q2 supports CMP 1.1. However, manual migration of the application would require a few changes to be made in the following aspects:

Web Application Changes

Migrating iBank from Sun ONE Application server 6.0/6.5 to Sun Java System Application Server 7 2004Q2 would not require any changes in the web application part of the iBank application. Delete the ias-web.xml file from the source directory, as there is no information in this file that can go inside its counterpart in the Sun Java System Application Server 7 2004Q2 deployment descriptor, the sun-web.xml file. The web.xml requires no changes.

However, generically speaking, if there is some information inside the web.xml that needs to be mapped to the Server specific resources, then a declaration in sun-web.xml will be required. For example, if the web.xml file had declared a javax.sql.Datasource type resource reference, it is mandatory to map it to the JNDI name of the actual DataSource on the Sever, inside the sun-web.xml.

You need to create the new sun-web.xml. The process of creating Sun Java System Application Server specific deployment descriptor sun-web.xml is outlined below:

Create a new XML file which has the following DOCTYPE definition on top:

'http://www.sun.com/software/sunone/appserver/dtds/sun-web-app_2_3-1.dtd'>

Save this file as sun-web.xml.

The root tag of this XML file, as evident from the DOCTYPE definition, is sun-web. In the DTD, this element is defined as follows:

<!ELEMENT sun-web-app (security-role-mapping*, servlet*, session-config?, resource-env-ref*, resource-ref*, ejb-ref*, cache?, class-loader?, jsp-config?, locale-charset-info?, property*)>

From the above declaration it is clear that all tags are optional. Thus, a default sun-web.xml would look something like:

<!DOCTYPE sun-web-app SYSTEM "http://www.sun.com/software/sunone/appserver/dtds/sun-web-app_2_3-1.dtd">

</sun-web-app>

To declare any resource references, use the following element declaration:

<!ELEMENT resource-ref (res-ref-name, jndi-name, default-resource-principal?)> where the sub elements are:

<!ELEMENT res-ref-name (#PCDATA)>
<!ELEMENT default-resource-principal (name, password)>
<!ELEMENT jndi-name (#PCDATA)>

In case of iBank application sun-web.xml must contain the following resource-reference declarations:

<sun-web-app>

<resource-ref>

<res-ref-name>jdbc/IBank</res-ref-name>

<jndi-name>jdbc/IBank</jndi-name>

<default-resource-principal>

<name>ibank_user</name>

<password>ibank_user</password>

</default-resource-principal>

</resource-ref>

</sun-web-app>

EJB Changes

Migrating iBank from Sun ONE Application Server 6.5 to Sun Java System Application Server 7 2004Q2 does not require any changes in the EJB code.

Session Beans:

In ejb-jar.xml: The <!DOCTYPE definition should be modified to point to the latest DTD url in case of ejb-jar.xml. This new definition should look like this:

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN'
'http://java.sun.com/dtd/ejb-jar_2_0-1.dtd'>

The ias-ejb-jar.xml in Sun ONE Application server 6.5 has been replaced by sun-ejb-jar.xml in Sun Java System Application server 7 2004Q2. Since the DTDs for these two XML files are radically different, you need to create the new sun-ejb-jar.xml by extracting relevant information from the ejb-jar.xml and ias-ejb-jar.xml. The process of creating the ejb-jar.xml file is outlined below:

Create a new XML file which has the following DOCTYPE definition on top:

<!DOCTYPE sun-ejb-jar PUBLIC ’-//Sun Microsystems, Inc.//DTD Sun ONE Application Server 7.1 EJB 2.0//EN’ ’http://www.sun.com/software/sunone/appserver/dtds/sun-ejb-jar_2_0-1.dtd’>

Save this file as “sun-ejb-jar.xml”, along with the modified ejb-jar.xml.

The root tag of this XML file, as evident from the DOCTYPE definition, is sun-ejb-jar. In the DTD, this element is defined as

<!ELEMENT sun-ejb-jar (security-role-mapping*,enterprise-beans)>

The security-role-mapping tag is meant for mapping the security roles declared in the ejb-jar.xml. Since there is no security declared in the ejb-jar.xml file of the iBank application, you can skip the declaration of this tag. Focus on the enterprise-beans tag. Right now, the sun-ejb-jar.xml file should have the following contents:

<sun-ejb-jar>

<enterprise-beans>

</enterprise-beans>

</sun-ejb-jar>

NOTE: The header part of the document, namely the XML declaration and DOCTYPE definition, are not included here for brevity.

The enterprise-beans element is defined in the DTD as follows:

<!ELEMENT enterprise-beans (name?, unique-id?, ejb*, pm-descriptors?, cmp-resource?)>

The optional name element should contain the canonical name of the <enterprise-beans>. You may give it some name.

The <unique-id> element is used by the Sun Java System Application Server and is inserted by the Application Server automatically at the time of application deployment.

The EJB element tag is the most important tag. This element describes the runtime bindings for a single EJB. It is defined in the DTD as follows:

<!ELEMENT ejb (ejb-name, jndi-name?, ejb-ref*, resource-ref*, resource-env-ref*, pass-by-reference?, cmp?, principal?, mdb-connection-factory?, jms-durable-subscription-name?, jms-max-messages-load?, ior-security-config?, is-read-only-bean?, refresh-period-in-seconds?, commit-option?, gen-classes?, bean-pool?, bean-cache?)>

In the sample, the ejb element will contain the ejb-name element. The ejb-name element will contain the canonical name of the EJB. This name should be the same as declared inside the ejb-name element of the ejb-jar.xml for that EJB. It will also contain the jndi-name of the EJB. One of the differences between Sun ONE Application Server 6.5 and Sun Java System Application Server 7 2004Q2 is the flexibility of the latter in providing freedom to the bean developer to have different ejb-name and jndi-name of an EJB. In Sun ONE Application Server 6.5, the jndi name of an EJB by default was ejb/<ejb-name>.

To allow smooth migration, keep the jndi-names of the EJB and all other resources to be same as they were on Sun ONE Application Server 6.5. Hence, declare the ejb-name of all the EJBs’ to be ejb/<ejb-name>.

Using the logic described above, the sun-ejb-jar.xml now should have the following contents:

<sun-ejb-jar>

<enterprise-beans>

<ejb>

<ejb-name>BankTeller</ejb-name>

<jndi-name>ejb/BankTeller</jndi-name>

</ejb>

<ejb>

<ejb-name>InterestCalculator</ejb-name>

<jndi-name>ejb/InterestCalculator</jndi-name>

</ejb>

</enterprise-beans>

</sun-ejb-jar>

For each <ejb-ref> element inside the ejb-jar.xml, there should be a corresponding <ejb-ref> element inside the sun-ejb-jar.xml. The <ejb-ref> element inside the ejb-jar.xml is used to declare all the EJBs referenced from inside the bean class of that EJB. While the bean class code will reference the EJB by using its <ejb-ref-name>, this <ejb-ref-name> has to be mapped to the actual <jndi-name> of the bean on the Application Server. Hence, this serves as a mechanism to add a layer of abstraction between the name referenced by the EJB implementation and the actual JNDI name of the bean.

Using the logic explained above, consider examining the BankTeller EJB. In the ejb-jar.xml, there are two <ejb-ref> declarations inside this EJB. The first one is for the Customer EJB (an entity bean in the Entity Bean module). As explained in Step 3 above, the JNDI names of all EJBs must be kept as ejb/<ejb-name>, and add this declaration inside the sun-ejb-jar.xml

<sun-ejb-jar>

<enterprise-beans>

<ejb>

<ejb-name>BankTeller</ejb-name>
<jnndi-name>ejb/BankTeller</jndi-name>

<ejb-ref>

<ejb-ref-name>Customer</ejb-ref-name>
<jndi-name>ejb/Customer</jndi-name

</ejb-ref>

</ejb>

<ejb>

<ejb-name>InterestCalculator</ejb-name>
<jndi-name>ejb/InterestCalculator</jndi-name>

</ejb>

</enterprise-beans>

</sun-ejb-jar>

Similarly, add a similar <ejb-ref> tag for Account EJB. Since the InterestCalculator bean does not have a <ejb-ref> tag inside the ejb-jar.xml, it is not required inside the sun-ejb-jar.xml also. Now, the sun-ejb-jar.xml has the following contents:

<sun-ejb-jar>

<enterprise-beans>

<ejb>

<ejb-name>BankTeller</ejb-name>
<jndi-name>ejb/BankTeller</jndi-name>

<ejb-ref>

<ejb-ref-name>Customer</ejb-ref-name>
<jndi-name>ejb/Customer</jndi-name>

</ejb-ref>

<ejb-ref>

<ejb-ref-name>Account</ejb-ref-name>
<jndi-name>ejb/Account</jndi-name>

</ejb-ref>

</ejb>

<ejb>

<ejb-name>InterestCalculator</ejb-name>
<jndi-name>ejb/InterestCalculator</jndi-name>

</ejb>

</enterprise-beans>

</sun-ejb-jar>

The ejb element would contain element pass-by-reference <!ELEMENT pass-by-reference (#PCData).

pass-by-reference elements control the use of Pass by Reference semantics. The EJB specification requires pass by value, which will be the default mode of operation. This can be set to true for non-compliant operation and possibly higher performance. It can apply to all the enclosed EJB modules. Allowed values are true and false. Default value is false.

The ejb element also has an element named <bean-cache>.

<!ELEMENT bean-cache (max-cache-size?, is-cache-overflow-allowed?, cache-idle-timeout-in-seconds?, removal-timeout-in-seconds?, victim-selection-policy?)>

This element is used only for the stateful session beans and the entity beans. In the iBank application, only BankTeller session bean will have this entry.

In this tag, max-cache-size defines the maximum number of beans in the cache. cache-idle-timeout-in-seconds specifies the maximum time that a stateful session bean or entity bean is allowed to be idle in the cache. After this time, the bean is passivated to backup store. This is a hint to the server. Default value for cache-idle-timeout-in-seconds is 10 minutes.

The amount of time that the bean remains passivated (i.e. idle in the backup store) is controlled by removal-timeout-in-seconds parameter. Note that if a bean was not accessed beyond removal-timeout-in-seconds, then it will be removed from the backup store and hence will not be accessible to the client. The Default value for removal-timeout-in-seconds is 60min.

With the above entries, sun-ejb-jar.xml should look like this:

<sun-ejb-jar>

<enterprise-beans>

<ejb>

<ejb-name>BankTeller</ejb-name>

<jndi-name>ejb/BankTeller</jndi-name>

<ejb-ref>

<ejb-ref-name>Customer</ejb-ref-name>

<jndi-name>ejb/Customer</jndi-name>

</ejb-ref>

<ejb-ref>

<ejb-ref-name>Account</ejb-ref-name>

<jndi-name>ejb/Account</jndi-name>

</ejb-ref>

<pass-by-reference>false</pass-by-reference>

<bean-cache>

<cache-idle-timeout-in-seconds>

</cache-idle-timeout-in-seconds>

<removal-timeout-in-seconds>

</removal-timeout-in-seconds>

</bean-cache>

</ejb>

<ejb>

<ejb-name>InterestCalculator</ejb-name>

<jndi-name>ejb/InterestCalculator</jndi-name>

<pass-by-reference>false</pass-by-reference>

</ejb>

</enterprise-beans>

</sun-ejb-jar>

The element used only for defining the stateless session bean and the message-driven bean pool is the <bean-pool>.

<!ELEMENT bean-pool (steady-pool-size?, resize-quantity?, max-pool-size?, pool-idle-timeout-in-seconds?, max-wait-time-in-millis?)>

steady-pool-size specified the initial and minimum number of beans that must be maintained in the pool.

resize-quantity specifies the number of beans to be created or deleted when the pool is being serviced by the pool manager.

max-pool-size specifies the maximum pool size. Valid values are from 0 to MAX_INTEGER.

max-pool-size spiffiest the maximum pool size.

pool-idle-timeout-in-seconds specifies the maximum time that a stateless session bean or message-driven bean is allowed to be idle in the pool.

Finally the sun-ejb-jar.xml will have the following contents:

<sun-ejb-jar>

<enterprise-beans>

<ejb>

<ejb-name>BankTeller</ejb-name>

<jndi-name>ejb/BankTeller</jndi-name>

<ejb-ref>

<ejb-ref-name>Customer</ejb-ref-name>

<jndi-name>ejb/Customer</jndi-name>

</ejb-ref>

<ejb-ref>

<ejb-ref-name>Account</ejb-ref-name>

<jndi-name>ejb/Account</jndi-name>

</ejb-ref>

<pass-by-reference>false</pass-by-reference>

<bean-cache>

<cache-idle-timeout-in-seconds>

</cache-idle-timeout-in-seconds>

<removal-timeout-in-seconds>

</removal-timeout-in-seconds>

</bean-cache>

</ejb>

<ejb>

<ejb-name>InterestCalculator</ejb-name>

<jndi-name>ejb/InterestCalculator</jndi-name>

<pass-by-reference>false</pass-by-reference>

<bean-pool>

<pool-idle-timeout-in-seconds>

</pool-idle-timeout-in-seconds>

</bean-pool>

</ejb>

</enterprise-beans>

</sun-ejb-jar>

Entity Beans:

In ejb-jar.xml: The <!DOCTYPE definition should be modified to point to the latest DTD url in case of ejb-jar.xml. This new definition should look like this:

<!DOCTYPE sun-ejb-jar PUBLIC ’-//Sun Microsystems, Inc.//DTD Sun ONE Application Server 7.1 EJB 2.0//EN’ ’http://www.sun.com/software/sunone/appserver/dtds/sun-ejb-jar_2_0-1.dt d’>

Insert <cmp-version> tag with value 1.1 for all CMPs beans in ejb-jar.xml.

Entry for entity bean would look like:

<description>Account CMP entity bean</description>

<ejb-name>Account</ejb-name>

<home>com.sun.bank.ejb.entity.AccountHome</home>

<remote>com.sun.bank.ejb.entity.Account</remote>

<ejb-class>com.sun.bank.ejb.entity.AccountEJB</ejb-class>

<persistence-type>Container</persistence-type>

<prim-key-class>

com.sun.bank.ejb.entity.AccountPK

</prim-key-class>

<reentrant>False</reentrant>

<cmp-version>1.x</cmp-version>

<cmp-field>

<field-name>branchCode</field-name></cmp-field>

<cmp-field>

<field-name>accTypeId</field-name></cmp-field>

<cmp-field>

<field-name>accBalance</field-name></cmp-field>

<cmp-field>

<field-name>custNo</field-name></cmp-field>

<cmp-field>

<field-name>accNo</field-name></cmp-field>

</entity>

Similarly, all the CMP beans would have this entry.

Similar to Session Beans, the ias-ejb-jar.xml in Sun ONE Application Server 6.5 has been replaced by sun-ejb-jar.xml in Sun Java System Application Server 7 2004Q2. Since the DTDs for these two XML files are radically different, you need to create the new sun-ejb-jar.xml by extracting relevant information from the ejb-jar.xml and ias-ejb-jar.xml. The process of creating the sun-ejb-jar.xml is outlined below:

Create a new XML file which has the following DOCTYPE definition on top:

<!DOCTYPE sun-ejb-jar PUBLIC ’-//Sun Microsystems, Inc.//DTD Sun ONE Application Server 7.1 EJB 2.0//EN’ ’http://www.sun.com/software/sunone/appserver/dtds/sun-ejb-jar_2_0-1.dtd’>

Save this file as “sun-ejb-jar.xml”, along with the modified ejb-jar.xml.

The root tag of this XML file, as evident from the DOCTYPE definition, is sun-ejb-jar. In the DTD, this element is defined as

<!ELEMENT sun-ejb-jar (security-role-mapping*, enterprise-beans) >

The security-role-mapping tag is meant for mapping the security roles declared in the ejb-jar.xml. As in the iBank application, there is no security declared in the ejb-jar.xml file, skip the declaration of security-role-mapping optional tag and focus on the enterprise-beans tag. The sun-ejb-jar.xml file should have the following contents.

<sun-ejb-jar>

<enterprise-beans> </enterprise-beans>

</sun-ejb-jar>

NOTE: The header part of the document, namely the XML declaration and DOCTYPE definition are not included here for brevity.

The <enterprise-beans> element is defined in the DTD as follows:

<!ELEMENT enterprise-beans (name?, unique-id?, ejb*, pm-descriptors?, cmp-resource?)>

The optional name element should contain the canonical name of the <enterprise-beans>. You may give it some name.

The <unique-id> element is used by Sun Java System Application Server and is inserted by the Application Server automatically at the time of application deployment.

The ejb element describes the runtime bindings for a single EJB. It is defined in the DTD as follows:

In this case, the ejb element will contain the ejb-name element. The ejb-name element will contain the canonical name of the EJB. This name should be the same as declared inside the ejb-name element of the ejb-jar.xml for that EJB. It will also contain the jndi-name of the EJB. One of the differences between Sun ONE Application Server 6.5 and Sun Java System Application Server 7 2004Q2 is the flexibility of the latter in providing freedom to the bean developer to have different ejb-name and jndi-name of an EJB. In Sun ONE Application Server 6.5, the JNDI name of an EJB by default was ejb/<ejb-name>.

To allow smooth migration, keep the jndi-names of the EJB and all other resources to be same as they were on Sun ONE Application Server 6.5. Declare the ejb-name of all the ejbs’ to be ejb/<ejb-name>.

Using the logic described above, the sun-ejb-jar.xml now should have the following entries:

<sun-ejb-jar>

<enterprise-beans>

<ejb>

<ejb-name> Account</ejb-name>

<jndi-name> ejb/Account</jndi-name>

</ejb>

other ejb’s

</enterprise-beans>

</sun-ejb-jar>

The ejb element contains the element pass-by-reference <!ELEMENT pass-by-reference (#PCData).

pass-by-reference elements control the use of Pass by Reference semantics. EJB specification requires pass by value, which will be the default mode of operation. This can be set to true for non-compliant operation and possibly higher performance. It can apply to all the enclosed EJB modules. Allowed values are true and false. Default value is false.

In case of CMP entity beans, element cmp is declared, which describes runtime information for a CMP EntityBean object for EJB1.1 and EJB2.0 beans.

<!ELEMENT cmp (mapping-properties?, is-one-one-cmp?, one-one-finders?)>

The mapping-properties tag contains the location of the persistence vendor specific O/R mapping file. is-one-one-cmp field is used to identify CMP 1.1 with old descriptors. This contains the boolean true if it is CMP 1.1. one-one-finders contains the finders for CMP 1.1.

This root element <finder> contains the finder for CMP 1.1 with a method-name and query parameters.

<!ELEMENT finder (method-name, query-params?, query-filter?, query-variables?)>

Element method-name contains the method name for the query field. Element query-params contains the query parameters for CMP 1.1 finder.

query-filter is an optional element which contains the query filter for CMP 1.1 finder.

After making the above entries in iBank, sun-ejb-jar.xml would look like the following:

<sun-ejb-jar>

<enterprise-beans>

<ejb>

<ejb-name> Account</ejb-name>

<jndi-name> ejb/Account</jndi-name>

<pass-by-reference>false</pass-by-reference>

<cmp>

<mapping-properties>

META-INF/sun-cmp-mappings.xml

</mapping-properties>

<is-one-one-cmp>true</is-one-one-cmp>

<one-one-finders>

<method-name>

findOrderedAccountsForCustomer

</method-name>

<query-params>int custNo</query-params>

<query-filter>

custNo == custNo

</query-filter>

</finder>

</one-one-finders>

</cmp>

</ejb>

other ejb’s

</enterprise-beans>

</sun-ejb-jar>

Account is the only entity bean having a finder other than primary key. Hence the finder entry shown above would only be in the case of Account bean.

The <!ELEMENT commit-option (#PCDATA)> specifies option for committing.

The <ejb> element also has an element <bean-cache>.

<!ELEMENT bean-cache (max-cache-size?, is-cache-overflow-allowed?, cache-idle-timeout-in-seconds?, removal-timeout-in-seconds?, victim-selection-policy?)>

This element is used only for stateful session beans and entity beans. In this tag, max-cache-size defines the maximum number of beans in the cache. cache-idle-timeout-in-seconds specifies the maximum time that a stateful session bean or an entity bean is allowed to be idle in the cache. After this time, the bean is passivated to backup store. This is a hint to the server. Default value for cache-idle-timeout-in-seconds is 10 minutes.

The amount of time that the bean remains passivated (i.e. idle in the backup store) is controlled by removal-timeout-in-seconds parameter. Note that if a bean was not accessed beyond removal-timeout-in-seconds, then it will be removed from the backup store and hence will not be accessible to the client. The Default value for removal-timeout-in-seconds is 60 min.

With the above entries, sun-ejb-jar.xml should look like this:

<sun-ejb-jar>

<enterprise-beans>

<ejb>

<ejb-name> Account</ejb-name>
<jndi-name> ejb/Account</jndi-name>
<pass-by-reference>false</pass-by-reference>

<cmp>

<mapping-properties>

META-INF/sun-cmp-mappings.xml

</mapping-properties>

<is-one-one-cmp>true</is-one-one-cmp>

<one-one-finders>

<method-name>

findOrderedAccountsForCustomer

</method-name>

<query-params>int custNo</query-params>

<query-filter>

custNo == custNo

</query-filter>

</finder>

</one-one-finders>

</cmp>

<commit-option>C</commit-option>

<bean-cache>

<max-cache-size>60</max-cache-size>
<cache-idle-timeout-in-seconds>0</cache-idle-timeout-in-seconds>

</bean-cache>

</ejb>

other ejb’s

</enterprise-beans>

</sun-ejb-jar>

In <!ELEMENT enterprise-beans (name?, unique-id?, ejb*, pm-descriptors?, cmp-resource?)>

Element <pm-descriptors> would be as follows:

<!ELEMENT pm-descriptors (pm-descriptor+, pm-inuse)>

Persistence Manager descriptors contain one or more pm-descriptors, but only one of them must be in use at any given time.

<pm-descriptor> describes the properties for the persistence manager associated with entity bean. pm-identifier element describes the vendor who provided the PM implementation. pm-version further specifies which version of PM vendor product to be used. pm-config specifies the vendor specific config file to be used. pm-class-generator specifies the vendor specific concrete class generator. This is the name of the class specific to a vendor. pm-mapping-factory specifies the vendor specific mapping factory. This is the name of the class specific to a vendor. pm-insue specifies whether this particular PM must be used or not.

The element <cmp-resource> contains the database to be used for storing CMP beans in an ejb-jar.

<!ELEMENT cmp-resource (jndi-name, default-resource-principal?)>

The element jndi-name specifies the JNDI name string. Element default-resource-principal has element name and password to be used when none are specified while accessing a resource.

<!ELEMENT default-resource-principal ( name, password)>

Finally sun-ejb-jar.xml should contain the following:

<sun-ejb-jar>

<enterprise-beans>

<ejb>

<ejb-name> Account</ejb-name>

<jndi-name> ejb/Account</jndi-name>

<pass-by-reference>false</pass-by-reference>

<cmp>

<mapping-properties>

META-INF/sun-cmp-mappings.xml

</mapping-properties>

<is-one-one-cmp>true</is-one-one-cmp>

<one-one-finders>

<method-name>

findOrderedAccountsForCustomer

</method-name>

<query-params>int custNo</query-params>

<query-filter>

custNo == custNo

</query-filter>

</finder>

</one-one-finders>

</cmp>

<commit-option>C</commit-option>

<bean-cache>

<max-cache-size>60</max-cache-size>

<cache-idle-timeout-in-seconds>

</cache-idle-timeout-in-seconds>

</bean-cache>

</ejb>

other ejb’s

<pm-descriptors>

<pm-descriptor>

<pm-identifier>IPLANET</pm-identifier>

<pm-version>1.0</pm-version>

<pm-class-generator>

com.iplanet.ias.persistence.

internal.ejb.ejbc.JDOCodeGenerator

</pm-class-generator>

<pm-mapping-factory>

com.iplanet.ias.cmp.NullFactory

</pm-mapping-factory>

</pm-descriptor>

<pm-inuse>

<pm-identifier>IPLANET</pm-identifier>

<pm-version>1.0</pm-version></pm-inuse>

</pm-descriptors>

<cmp-resource>

<jndi-name>jdo/pmf</jndi-name>

</cmp-resource>

</enterprise-beans>

</sun-ejb-jar>

Generate dbschema by using the capture-schema utility in Sun Java System Application Server 7 2004Q2 installation’s bin directory. Execute capture-schema.bat file stored in the \bin directory and specify the valid inputs for the database URL, username, password, and specify the tables for which schema has to be generated. By default, schema has to be generated for all the tables used by the application. In case of iBank, there are six tables for which schema has to be generated. Name this schema file as myschema.dbschema. The tables used in iBank are:

ACCOUNT

ACCOUNT_TYPE

BRANCH

CUSTOMER

TRANSACTION_HISTORY

TRANSACTION_TYPE

Store the file myschema.dbschema above the META-INF folder for the entity beans.

In <ejb-name>-ias-cmp.xml: Replace all the <ejb-name>-ias-cmp.xml files in Sun ONE Application Server 6.0/6.5 with one sun-cmp-mappings.xml file. This file maps (at least one) set of beans to tables and columns in a specific dbschema. Since the DTDs for this two XML files are radically different, You need to actually create a new file following the steps given below:

Create a new XML file which has the following DOCTYPE definition on top:

<!DOCTYPE sun-cmp-mappings PUBLIC ’-//Sun Microsystems, Inc.//DTD Sun ONE Application Server 7.0 OR Mapping //EN’ ’http://www.sun.com/software/sunone/appserver/dtds/sun-cmp_mapping_1_0.dtd’>

Save this file as “sun-cmp-mappings.xml”.

The root tag of this XML file, as evident from the DOCTYPE definition, is sun-cmp-mappings. In the DTD, this element is defined as follows:

<!ELEMENT sun-cmp-mappings ( sun-cmp-mapping+ ) >

Element sun-cmp-mapping would be :

<!ELEMENT sun-cmp-mapping ( schema, entity-mapping+) >

Here element schema is the path name to the schema file.

A CMP bean has a name, a primary table, one or more fields, zero or more relationships, and zero or more secondary tables, plus flags for consistency checking. Element entity-mapping has the following elements:

<!ELEMENT entity-mapping (ejb-name, table-name, cmp-field-mapping+, cmr-field-mapping*, secondary-table*, consistency?)>

Element ejb-name is the EJB name from standard ejb-jar DTD. Element table-name is the name of the database table. A cmp-field-mapping has a field, one or more columns that it maps to cmr-field mapping. A cmr field has a name and one or more column pairs that define the relationship. Element secondary-table is for secondary table used. In case of iBank, no secondary table is used.

After making the changes described above, the sun-cmp-mappings.xml file with entries for Account entity bean should look like the following:

<sun-cmp-mapping>

<schema>mySchema</schema>

<entity-mapping>

<ejb-name>Account</ejb-name>

<table-name>ACCOUNT</table-name>

<cmp-field-mapping>

<field-name>custNo</field-name>

<column-name>CUST_NO</column-name>

</cmp-field-mapping>

<cmp-field-mapping>

<field-name>branchCode</field-name>

<column-name>BRANCH_CODE</column-name>

</cmp-field-mapping>

<cmp-field-mapping>

<field-name>accTypeId</field-name>

<column-name>ACCTYPE_ID</column-name>

</cmp-field-mapping>

<cmp-field-mapping>

<field-name>accNo</field-name>

<column-name>ACC_NO</column-name>

</cmp-field-mapping>

<cmp-field-mapping>

<field-name>accBalance</field-name>

<column-name>ACC_BALANCE</column-name>

</cmp-field-mapping>

</entity-mapping>

</sun-cmp-mapping>

NOTE: The header part of the document, namely the XML declaration and DOCTYPE definition are not included here for brevity.

Entries for all the CMP entity beans have to be made.

Assembling Application for Deployment

Sun Java System Application Server 7 2004Q2 primarily supports the J2EE model wherein applications are packaged in the form of an enterprise archive (EAR) file (extension .ear). The application is further subdivided into a collection of J2EE modules, packaged into Java archives (JAR, extension .jar) for EJBs and web archives (WAR, extension .war) for servlets and JSPs.

All the JSPs and Servlets should be packaged into WAR file, all EJBs into the JAR file and finally the WAR and the JAR file together with the deployment descriptors in to the EAR file. This EAR file is a deployable component.

Deploying iBank application on Sun Java System Application Server 7 2004Q2 using the asadmin utility

The last stage is to deploy the application on an instance of Sun Java System Application Server 7 2004Q2. The process for deploying an application is described below:

The Sun Java System Application Server 7 2004Q2 asadmin includes a help section on deployment that is accessible from the Help menu.

The command line utility asadmin can be invoked by executing asadmin.bat file in Windows and asadmin file in Solaris Operating Environment that is stored in Sun Java System Application Server 7 2004Q2 installation's bin directory. i.e., Install_dir/AppServer7/appserv/bin.

At asadmin prompt, the command for deployment would be:

asadmin> deploy -u username -w password -H hostname -p adminport [--type application|ejb|web|client|connector] [--contextroot contextroot] [--force=true] [--name component-name] [--upload=true] [--instance instancename] filepath

Restart the server instance and then test the application on the browser by typing the url ‘http://<machine_name>:<port_number>/IBank’. Test by giving one of the available user name and password. This should show the main menu page of the iBank application.

Previous Contents Index Next

Previous Contents Index Next
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Migrating and Redeploying Server Applications Guide