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

Chapter 3
Migrating Applications to Sun Java System Application Server 7 2004Q2

This chapter describes the considerations and strategies that are needed when moving J2EE applications from Sun ONE Application Server 6, 6.5, and 7 to the Sun Java System Application Server 7 2004Q2 product line.

This chapter also describes specific migration tasks at the component level.

Note	You are encouraged to use the Migration Tool for Application Servers that automates the migration of J2EE components to Sun Java System Application Server. For more information on the Migration Guide, see section Sun Java System Migration Tool for Application Server of Appendix B, "Migration Resources."

The following topics are addressed:

About Sun ONE Application Server 6.0/6.5
Migration Issues From Sun ONE Application Server 6.x to Sun Java System Application Server 7 2004Q2
Migrating J2EE Components
Migrating Web Applications
Migrating Enterprise EJB Modules
Migrating Enterprise Applications
Migrating Proprietary Extensions
Migrating UIF

---

About Sun ONE Application Server 6.0/6.5

Sun ONE Application Server version 6.0 is a multi-platform application server based entirely on the J2EE 1.2 specification. Supported platforms include Windows NT and 2000, Solaris, AIX, and HP-UX.

In addition, Sun ONE Application Server 6.0 integrates with many Web servers through specific Web connector plug-ins that it ships with. These connectors enable it to be coupled with Sun ONE Web Server, Microsoft IIS, or Apache.

The Sun ONE Application Server 6.0/6.5 architecture is shown in the following figure:

Figure 3-1  Sun ONE Application Server 6.0/6.5 Architecture

As shown in the above figure, there are four internal servers, which are often called engines or processes. These processes are responsible for all the processing in the Sun ONE Application Server. The four internal servers of the Sun ONE Application Server 6.0/6.5 are:

Executive Server - provides most system services (some services are managed by the Administrative Server).

Administrative Server - provides system services for Sun ONE Application Server Administration and failure recovery.

Java Server - provides services to java applications.

C++ Server - components written in C++ are hosted in C++ server.

When a web server forwards requests to Sun ONE Application Server 6.0/6.5, the requests are first received by the Executive Server process (KXS). The KXS process forwards the request either to a Java Server process (KJS) or to a C++ Server process (KCS). A KJS process runs Java programming logic, whereas a KCS process runs C++ programming logic. Each KJS and KCS process maintains a specified number of threads and runs the programming logic to completion on those threads. The results are returned to the web server and sent on to the client browser.

---

Migration Issues From Sun ONE Application Server 6.x to Sun Java System Application Server 7 2004Q2

This section describes the issues that will arise while 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.

The migration issues described in this section are based on an actual migration that was performed for a J2EE application called iBank, a simulated online banking service, from Sun ONE Application Server 6.0 and 6.5 to Sun Java System Application Server 7 2004Q2. This application reflects all aspects that comprise a traditional J2EE application.

Use of the Sun Java System Migration Tool is highly recommended for migrating J2EE components without having to manually modify the code. The Migration Tool automates the task of migrating various J2EE Components to Sun Java System Application Server 7 2004Q2.

The iBank application covers the following features of the J2EE specification:

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.

---

Migrating J2EE Components

The following migration processes are described in this section:

Migrating JDBC Code
Migrating Java Server Pages and JSP Custom Tag Libraries
Migrating Servlets
Obtaining a Data Source from the JNDI Context
EJB Migration
EJB Changes Specific to Sun Java System Application Server

Migrating JDBC Code

With the JDBC API, there are two methods of database access:

Establishing Connections Through the DriverManager Interface

(JDBC 1.0 API), by loading a specific driver and providing a connection URL. This method is used by other Application Servers, such as IBM’s WebSphere 4.0

Using JDBC 2.0 Data Sources

The Data Source interface (JDBC 2.0 API) can be used via a configurable connection pool. According to J2EE 1.2, a data source is accessed through the JNDI naming service

Note	Sun Java System Application Server 7 2004Q2 does not support the Native Type 2 JDBC drivers bundled with Sun ONE Application Server 6.x. You must manually migrate code that uses the Type 2 drivers to use Third Party JDBC drivers.

Establishing Connections Through the DriverManager Interface

Although this means of accessing a database is not recommended, as it is obsolete and is not very effective, there may be some applications that still use this approach.

In this case, the access code will be similar to the following:

public static final String driver = "oracle.jdbc.driver.OracleDriver";

public static final String url = "jdbc:oracle:thin:tmb_user/tmb_user@iben:1521:tmbank";

Class.forName(driver).newInstance();

Properties props = new Properties();

props.setProperty("user", "tmb_user");

props.setProperty("password", "tmb_user");

Connection conn = DriverManager.getConnection(url, props);

This code can be fully ported from Sun ONE Application Server 6.0/6.5 to Sun Java System Application Server 7 2004Q2, as long as the Application Server is able to locate the classes needed to load the right JDBC driver. In order to make the required classes accessible to the application deployed in Sun Java System Application Server 7 2004Q2, you should:

Place the archive (JAR or ZIP) for the driver implementation in the /lib directory of the Sun Java System Application Server 7 2004Q2 installation directory.

Modify the CLASSPATH by setting the path for the driver through the GUI of the admin server. Click the server instance “server1” and then click the tab “JVM Settings” from the right pane. Now click the option Path Settings and add the path in the classpath suffix text entry box. Once you make the changes, click “Save” and then apply the new settings. Restart the server to modify the configuration file, server.xml.

Using JDBC 2.0 Data Sources

Using JDBC 2.0 data sources to access a database provides performance advantages such as transparent connection pooling, enhances productivity by simplifying code and implementation, and provides code portability.

Using a data source in an application requires an initial configuration phase followed by a registration of the data source in the JNDI naming context of the Application Server. Once the data source is registered, the application will easily be able to obtain a connection to the database by retrieving the corresponding DataSource object from the JNDI context. The actions are described in the following topics:

Configuring a Data Source
Looking Up the Data Source Via JNDI To Obtain a Connection

Configuring a Data Source

In Sun ONE Application Server 6.0 data sources and their corresponding JDBC drivers are configured from the server's graphic administration console. Connection pools are managed automatically by the application server, and the administration tool can be used to configure their properties. With integrated type 2 JDBC drivers, the connection pooling properties are defined on a per-driver basis, and common to all data sources using a given driver.

On the other hand, for third-party JDBC drivers, connection pool properties are defined on a per-data source basis. Third-party JDBC drivers can be configured either from the administration tool, or from a separate utility (db_setup.sh in Sun Solaris, and jdbcsetup in Windows NT/2000). Moreover, the command line utility iasdeploy can be used to configure a data source from an XML file describing its properties. These utilities are all located in the /bin/ sub-directory of the Sun Java System Application Server installation root directory.

In Sun Java System Application Server 7 2004Q2, data sources can be configured from the server's graphic administration console or through the command line utility asadmin. The command line utility asadmin can be invoked by executing asadmin file in Solaris, available in Application Server installation’s bin directory. At the asadmin prompt, use the following commands to create connection pool and JNDI resource.

The syntax for calling the asadmin utility to create a connection pool is as follows:

asadmin>create-jdbc-connection-pool -u username -w password -H hostname -p adminport [-s] [--instance instancename] --datasourceclassname classname [--steadypoolsize=8] [--maxpoolsize=32] [--maxwait=60000] [--poolresize=2] [--idletimeout=300] [--isconnectvalidatereq=false] [--validationmethod=auto-commit] [--validationtable tablename] [--failconnection=false] [--description text] [--property (name=value)[:name=value]*] connectionpoolid

For example:

asadmin>create-jdbc-connection-pool -u admin -w password -H cl1 -p 4848 –instance server1 --datasourceclassname oracle.jdbc.pool.OracleConnectionPoolDataSource --property (user-name=ibank_user):(password=ibank_user) oraclepool

Here JDBC connection pool ‘oraclepool’ for oracle database is created using database schema having the username ‘ibank_user’ and password ‘ibank_user’.

The syntax to create a JDBC resource is as follows:

asadmin>create-jdbc-resource -u username -w password -H hostname -p adminport [-s] [--instance instancename] --connectionpoolid id [--enabled=true] [--description text] [--property (name=value)[:name=value]*] jndiname

For example:

asadmin>create-jdbc-resource -u admin -w password -H cl1 -p 4848 --instance server1 --connectionpoolid oraclepool jdbc/IBANK

Here jdbc resource is created for the connection pool created above with the JNDI name ‘jdbc/IBANK’.

Here is the procedure to follow when registering a data source in Sun Java System Application Server 7 2004Q2 through graphical interface.

Register the data source classname
Place the archive (JAR or ZIP) for the data source class implementation in the /lib directory of the Sun Java System Application Server 7 2004Q2 installation directory.
Modify the CLASSPATH by setting the path for the driver through the GUI of the admin server. Click at the server instance “server1” and then click at tab “JVM Settings”, now click at path settings and add the path at the classpath suffix column. Once you make the changes save it and then apply these new settings. Restart the server, which would modify the configuration file, server.xml.
Register the data source

In Sun Java System Application Server 7 2004Q2, data sources and their corresponding JDBC drivers are configured from the server's graphic administration interface.

The left pane is a tree view of all items you can configure in the Sun Java System Application Server. Click on the item Connection pool at the left pane, the right pane would display the page associated with it where the relevant entries can be made.

Figure 3-2  Configuring Connection Pool through GUI

Similarly now click at the item Data source, right pane would show the entries required for data source setup.

Sun Java System Application Server 7 2004Q2 specific deployment descriptor sun-web.xml has to be modified accordingly.

For example if a new data source is configured for the iBank application, the sun-web.xml would have following entries.

<!DOCTYPE web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Web Application 2.3.1//EN' 'Http://localhost:8000/sun-web-app_2_3-1.dtd'>

<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>

Looking Up the Data Source Via JNDI To Obtain a Connection

To obtain a connection from a data source, the process is as follows:

Obtain an initial JNDI context
Obtain a reference to the data source by using a JNDI lookup
Obtain a connection using this reference
Obtaining the initial JNDI context

To guarantee portability between different environments, the code used to retrieve an InitialContext object (in a servlet, in a JSP page, or an EJB), should be simply, as follows:

InitialContext ctx = new InitialContext();

Obtaining a data source reference

To obtain a reference to a data source bound to the JNDI context, look up the data source's JNDI name from the initial context object. The object retrieved in this way should then be cast as a DataSource type object:

ds = (DataSource)ctx.lookup(JndiDataSourceName);

Obtaining the connection

This operation is very simple, and requires the following line of code:

conn = ds.getConnection();

Application Server 6.0/6.5, 7, and 7 2004Q2 all follow the above technique for obtaining a connection form data source. So to summarize migration does not require any modification to be made to the code.

Migrating Java Server Pages and JSP Custom Tag Libraries

Sun ONE Application Server 6.0/6.5 complies with the JSP 1.1 specification and Sun Java System Application Server 7 2004Q2 complies with the JSP 1.2 specification.

JSP 1.2 specification contains many new features as well as corrections and clarifications of areas that were not quite right in JSP 1.1 specification.

The most significant changes are:

JSP 1.2 is based on Servlet 2.3 and Java 2. JSP 1.2 applications will not run on platforms that only support JDK 1.1. JSP 1.2 is backward compatible with JSP 1.1, so JSP 1.1 application should run without any tweaking in a JSP 1.2 complaint container.
The definition of XML syntax for a JSP page has been finalized. So a JSP 1.2 complaint container must accept files in both JSP 1.1 format and the new XML format called as JSP document.
Tag libraries can make use of Servlet 2.3 event listeners.
A new type of validation has been added, for the tag libraries, which validates JSP pages.
New options for tag library distribution and deployment have been added.

These changes are basically enhancements and are not required to be made, while migrating JSP pages from JSP API 1.1 to 1.2.

Migrating JSP Custom Tag Libraries

When you are attempting to migrate applications that make use of custom tag library under Sun Java System Application Server 7 2004Q2 platform, following approaches can be envisaged:

The simplest approach is to try using the 6.x application custom tag library under Sun Java System Application Server 7 2004Q2 platform. There are several caveats to this:

First approach is to try redeveloping a custom tag library that would emulate the functionality provided by the server custom tags. Due to sheer amount of work that this approach entails, it is not recommended unless an application has huge dependency on the tag library.
Second approach is to rewrite pages in the application so that they may no longer use any functionality of the proprietary tag library. Obviously, this approach can involve a substantial investment, but is likely to be the most cost-effective solution for applications that have critical dependencies on the custom tag library.
Third approach would be to use JavaServer Pages Standard Tag Library (JSTL) equivalent for the custom tag libraries. JSTL provides a framework for integrating existing custom tags with JSTL tags. However, note that this approach may not give the exact functionality.
The easiest approach is to use the Migration Tool. Use of this tool will eliminate the effort of manual migration of custom tag libraries and takes care of the migration. See Appendix B, "Migration Resources," for more information on the Migration Tool.

Migrating Servlets

Sun ONE Application Server 6.0 and 6.5 support the Servlet 2.2 API whereas Sun Java System Application Server 7 2004Q2, supports the Servlet 2.3 API.

Servlet API 2.3 actually leaves the core of servlets relatively untouched; most changes are concerned with adding new features outside the core.

The most significant features are:

Servlets now require JDK 1.2 or later
A filter mechanism has been created
Application lifecycle events have been added
New internationalization support has been added
New error and security attributes have been added
The HttpUtils class has been deprecated
Several DTD behaviors have been expanded and clarified

These changes are basically enhancements and are not required to be made while migrating servlets from Servlet API 2.2 to 2.3.

However, if the servlets in the application use JNDI to access resources of the J2EE application (such as data sources, EJBs, and so forth), some modifications may be needed in the source files or in the deployment descriptor.

These modifications are explained in detail in the following sections:

Obtaining a Data Source from the JNDI Context
Declaring EJBs in the JNDI Context

Obtaining a Data Source from the JNDI Context

To obtain a reference to a data source bound to the JNDI context, look up the data source's JNDI name from the initial context object. The object retrieved in this way should then be cast as a DataSource type object:

ds = (DataSource)ctx.lookup(JndiDataSourceName);

For detailed information, refer to section “Migrating JDBC Code” in the previous pages.

Declaring EJBs in the JNDI Context

Refer to section Declaring EJBs in the JNDI Context from Appendix C, "Migrating from the Enterprise Java Beans 1.1 Specification to Enterprise Java Beans 2.0."

EJB Migration

As mentioned in Chapter 2, "Migrating to Sun Java System Application Server, Overview,", while Sun ONE Application Server 6.0 and 6.5 support the EJB 1.1 specification, Sun Java System Application Server 7 2004Q2 also supports the EJB 2.0 specification. The EJB 2.0 specification introduces the following new features and functions to the architecture:

Message Driven Beans (MDBs)
Improvements in Container-Managed Persistence (CMP)
Container-managed relationships for entity beans with CMP
Local interfaces
EJB Query Language (EJB QL)

Although the EJB 1.1 specification will continue to be supported in Sun Java System Application Server 7 2004Q2, the use of the EJB 2.0 architecture is recommended to leverage its enhanced capabilities.

For detailed information on migrating from EJB 1.1 to EJB 2.0, refer to Appendix C, "Migrating from the Enterprise Java Beans 1.1 Specification to Enterprise Java Beans 2.0."

EJB Changes Specific to Sun Java System Application Server

Migrating EJB’s from Sun ONE Application server 6.0/6.5 to Sun Java System Application Server 7 2004Q2 would not require any changes in the EJB code. The following DTD changes are required.

Session Beans

The <!DOCTYPE> definition should be modified to point to the latest DTDs with J2EE standard DDs, such as ejb-jar.xml.
Replace ias-ejb-jar.xml file with the modified version of this file, named sun-ejb-jar.xml,created manually according to the DDs.
In sun-ejb-jar.xml, the JNDI name for all the EJB’s should prepend ‘ejb/’ in all the JNDI names. This is required as, in Sun ONE Application Server 6.5, the JNDI name of the EJB could only be ejb/<ejb-name> where <ejb-name> is the name of the EJB as declared inside ejb-jar.xml.

In Sun Java System Application Server 7 2004Q2, a new tag in the sun-ejb-jar.xml, is used to declare the JNDI name of the EJB.

Note	To avoid changing JNDI names throughout the application, we recommend that the JNDI name of the EJB should be declared as ejb/<ejb-name> inside the <jndi-name> tag.

Migrating EJB Applications that Support SFSB Failover (Enterprise Edition)

Sun ONE Application Server 6.5 supports failover of stateful session beans. To take advantage of the SFSB failover in 6.5, the session bean need to be configured with failover and DSync. The DSync (Distributed Store) mechanism is used to save the session beans’s conversational state during runtime.

Note	Sun ONE Application Server 6.5 does not support failover of stateful session beans for rich clients on the RMI/IIOP path. Such applications can take advantage of SFSB failover on the RMI/IIOP path in Sun Java System Application Server 7 2004Q2. For more information on SFSB failover configuration, see the ”Session Persistence” chapter of the Sun Java System Application Server Administration Guide.

Sun Java System Application Server 7 2004Q2, Enterprise Edition supports failover of stateful session beans. Application Server 7 2004Q2 uses the High Availability DataBase (HADB) for storing session data. The principle followed in supporting SFSB failover in saving the conversational state of an SFSB at pre-defined points in its lifecycle to a persistent store. This mechanism is referred to as ’checkpointing’. In case of a server crash, the checkpointed state of an SFSB can be retrieved from the persistent store. In order to use HADB for storing session data, you must configure HADB as the persistent store. The underlying store for the HTTP sessions and stateful session beans is same and the configuration of persistent store is exactly similar to configuration of session store.

For information on configuring HADB for session store, see the Sun Java System Application Server Administration Guide.

Migration of stateful session beans deployed in Sun ONE Application Server 6.5 to Sun Java System Application Server 7 2004Q2 does not require any changes in the EJB code. However, the following steps must be performed:

The <!DOCTYPE definition should be modified to point to the latest DTD url in case of J2EE standard DDs, like ejb-jar.xml.
Replace ias-ejb-jar.xml with the modified version of this file, i.e., sun-ejb-jar.xml, which is created manually according to the DTDs.
Replace all the <ejb-name>-ias-cmp.xml files with one sun-cmp-mappings.xml file, which is created manually.
No changes are required in the application source code for taking advantage of the SFSB state failover support. All configuration needed for checkpointing SFSBs will be applied at the Application Server specific deployment descriptor (sun-ejb-jar.xml), or in the server configuration file (server.xml).

For more information see the Sun Java System Application Server Administration Guide.

However, if you are accessing the ejb’s through webpath(i.e., servlets) then you need to store the ejb home and remote references in the session. The following is the code example to store ejbHome and ejbRemote interfaces in the session:

session.setAttribute("ejbhome", ejbHome);
session.setAttribute("ejbremote", ejbRemote);

The following code example demonstrates how to retrieve the ejbHome and ejbRemote from the session:

ejbHome = session.getAttribute("ejbhome");
ejbRemote = session.getAttribute("ejbremote");

In the server.xml, make sure that the availability-enabled attribute of availability-service element is set to TRUE. If availability-enabled attribute is set to TRUE indicates that failover is enabled at the server instance level. That is, if a server instance fails to process a request, the request is routed to the next available server instance.

SFSB checkpointing adds performance overhead on the EJB container, you may want to restrict checkpointing to a list of SFSBs whose state failover is critical to the application.

You can enable/disable the checkpointing at the method level. This is configurable in sun-ejb-jar.xml. For more details see the “Enabling SFSB Checkpointing” section of the Sun Java System Application Server Developer’s Guide to Enterprise JavaBeans Technology.

If, in the deployment descriptor for the SFSB ejb module in 6.5 (ias-ejb-jar.xml), the failoverrequired attribute of the session element is set to TRUE, you might want to enable availability-service for such ejb modules in the Application Server 7 2004Q2 environment.

Entity Beans

The <!DOCTYPE> definition should be modified to point to the latest DTDs with J2EE standard DDs, such as ejb-jar.xml.
Insert <cmp-version> tag with the value 1.1 for all CMPs in ejb-jar.xml.
Generate dbschema by using the capture-/spaceschema utility in the Sun Java System Application Server 7 2004Q2 installation’s bin directory and place it above META-INF folder for Entity beans.
ias-ejb-jar.xml should be replaced with its new version, named sun-ejb.jar.xml, in Sun Java System Application Server 7 2004Q2.
In Sun ONE Application Server 6.5, the finders sql was directly embedded inside the <ejb-name>-ias-cmp.xml. In Sun Java System Application Server, this has changed such that, now mathematical expressions are used to declare the <query-filter> for the various finder methods.

Message Driven Beans

Sun Java System Application Server 7 2004Q2 provides seamless Message Driven Support through the tight integration of Sun Java System Message Queue 3.5 with the Application Server, providing a native, built-in JMS Service.

This installation provides Sun Java System Application Server with a JMS messaging system that supports any number of Application Server instances. Each server instance, by default, has an associated built-in JMS Service that supports all JMS clients running in the instance.

Both container-managed and bean-managed transactions as defined in the Enterprise JavaBeans Specification, v2.0 are supported.

Message Driven Bean support in Sun ONE Application Server 6.x was restricted to developers, and used many of the older proprietary APIs. Messaging services were provided by Sun ONE Message Queue for Java 2.0. An LDAP directory was also required under Sun ONE Application Server6.x to configure the Queue Connection Factory object.

The QueueConnectionFactory, and other particulars required to configure Message Driven Beans in Sun Java System Application Server should be specified in the ejb-jar.xml file.

For more information on the changes to deployment descriptors, see Migrating Deployment Descriptors. For information on Message Driven Bean implementation in Sun Java System Appserver 7 2004Q2, see Sun Java System Application Server Developer’s Guide to Enterprise Java Bean Technology.

---

Migrating Web Applications

Sun ONE Application Server 6.0 and 6.5 support servlets (Servlet API 2.2), and JSPs (JSP 1.1). Sun Java System Application Server 7 2004Q2 on the other hand supports servlets (Servlet API 2.3) and JSPs (JSP 1.2).

Within these environments it is essential to group the different components of an application (servlets, JSP and HTML pages and other resources) together within an archive file (J2EE-standard Web application module) before you can deploy it on the application server.

According to the J2EE 1.3 specification, a Web application is an archive file (.WAR file) with the following structure:

a root directory containing the HTML pages, JSP, images and other "static" resources of the application.
a META-INF/ directory containing the archive manifest file (MANIFEST.MF) containing the version information for the SDK used and, optionally, a list of the files contained in the archive.
a WEB-INF/ directory containing the application deployment descriptor (web.xml file) and all the Java classes and libraries used by the application, organized as follows:
a classes/ sub-directory containing the tree-structure of the compiled classes of the application (servlets, auxiliary classes), organized into packages.
a lib/ directory containing any Java libraries (.jar files) used by the application.

Migrating Web Application Modules

Migrating applications from Sun ONE Application server 6.0/6.5 to Sun Java System Application Server 7 2004Q2 would not require any changes in the Java/JSP code. The following changes are, however, still required.

web.xml

Sun Java System Application Server 7 2004Q2 adheres to J2EE 1.3 standards, according to which, the web.xml file inside a WAR should adhere to the revised DTD available at http://java.sun.com/dtd/web-app_2_3-1.dtd. This DTD fortunately, is a superset of the previous versions’ DTD, hence only the <!DOCTYPE definition needs to be changed inside the web.xml, which is to be migrated. The modified <! DOCTYPE declaration should look like:

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3-1.dtd">

ias-web.xml

In Sun Java System Application Server 7 2004Q2 the name of this file is changed to sun-web.xml.

This XML file is required to declare the Sun Java System Application Server 7 2004Q2 specific properties/resources that will be required by the web application.

Note: See the next section for some important inclusions to this file.

If the ias-web.xml of the Sun ONE Application Server 6.5 application is present and does declare Sun ONE Application Server 6.5 specific properties, then this file needs to be migrated to Sun Java System Application Server 7 2004Q2 standards. The DTD file name has to be changed to sun-web.xml.

Once the web.xml and ias-web.xml are migrated in the above-mentioned fashion, the Web application (.WAR archive) can be deployed from the Sun Java System Application Server 7 2004Q2’s graphical user interface of the admin server or from the command line utility asadmin, where the deployment command should mention the type of application as web.

The command line utility asadmin can be invoked by running asadmin.bat file kept at Sun Java System Application Server 7 2004Q2 installation’s bin directory.

The command at asadmin prompt would be:

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

Deployment can also be done from the Sun ONE Studio for Java development environment. For more information, see the Sun ONE Studio for Java documentation.

Particular setbacks when migrating servlets and JSPs

The actual migration of the components of a Servlet / JSP application from Sun ONE Application Server 6.0/6.5 to Sun Java System Application Server 7 2004Q2 will not require any modifications to be made to the component code.

In case if the web-application is using a server resource, for example, a DataSource, then Sun Java System Application Server 7 2004Q2 requires that this resource be declared inside the web.xml and correspondingly inside sun-web.xml. For declaring a DataSource called jdbc/iBank, the <resource-ref> tag as declared inside the web.xml would look like this:

<resource-ref>

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

<res-type>javax.sql.XADataSource</res-type>

<res-auth>Container</res-auth>

<res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

Corresponding declaration inside the sun-web.xml will look like this:

<?xml version="1.0" encoding="UTF-8"?>

<! DOCTYPE FIX ME: need confirmation on the DTD to be used for this file

<sun-web-app>

<resource-ref>

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

<jndi-name>jdbc/iBank</jndi-name>

</resource-ref>

</sun-web-app>

---

Migrating Enterprise EJB Modules

Sun ONE Application Server 6.0 and 6.5 support the EJB 1.1 API whereas Sun Java System Application Server 7 2004Q2 supports the EJB 2.0 API. Thereby, both can support:

Stateful or Stateless Session Beans.
Entity beans with bean managed persistence (BMP), or container managed persistence (CMP).

EJB 2.0 API however, introduces a new type of enterprise bean, called a message-driven bean in addition to the session and entity beans.

J2EE 1.3 specification dictates that the different components of an EJB must be grouped together in a JAR file with the following structure:

META-INF/ directory with an XML deployment descriptor named ejb-jar.xml
The .class files corresponding to the home interface, remote interface, the implementation class, and the auxiliary classes of the bean with their package.

Sun Java System Application Servers observe this archive structure. However, the EJB 1.1 specification leaves each EJB container vendor to implement certain aspects as they see fit:

Database persistence of CMP EJBs (particularly the configuration of mapping between the bean's CMP fields and columns in a database table).
Implementation of the custom finder method logic for CMP beans.

As we might expect, Sun ONE Application Server 6.0 or 6.5 and 7 and Sun Java System Application Server 7 2004Q2 diverge on certain points, which means that when migrating an application certain aspects require particular attention. Some XML files have to be modified:

The <!DOCTYPE definition should be modified to point to the latest DTD url in case of J2EE standard DDs, like ejb-jar.xml.
Replace ias-ejb-jar.xml with the modified version of this file, i.e., sun-ejb-jar.xml, which is created manually according to the DTDs.
Replace all the <ejb-name>-ias-cmp.xml files with one sun-cmp-mappings.xml file, which is created manually.
Only for CMP entity beans: Generate dbschema by using the capture-schema utility in the Sun Java System Application Server 7 2004Q2 installation’s bin directory and place it above META-INF folder for the Entity bean.

---

Migrating Applications to Support HTTP Failover (Enterprise Edition)

Sun ONE Application Server 7 and Sun Java System Application Server, Enterprise Edition 7 2004Q2 supports load balancing and HTTP session persistence. The primary goal of load-balancing is to distribute the work load between multiple server instances, thereby increasing overall throughput of the system.

The Application Server uses sticky round-robin algorithm to load balance the incoming HTTP or HTTPS requests.

For information on configuring HTTP failover, see the Sun Java System Application Server Administration Guide.

To migrate 6.x HTTP applications to 7 2004Q2 environment and enable load-balancing capabilities, perform the following steps. Note that, no code changes will be required in the application.

Make sure that at least two application server instances are created and configured.
Rename the ias-web-app.xml to sun-web.xml. For more information on migrating the deployment descriptors, see the Migrating Deployment Descriptors.
Update the <DOCTYPE definition with the following code:

<!DOCTYPE web-app PUBLIC ’-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN’ ’http://java.sun.com/j2ee/dtds/web-app_2_3-1.dtd’>

In Sun ONE Application Server 6.5, the failover of HTTP applications was based on Dsync mechanism. The configuration for HTTP failover was done in the ias-web-app.xml file.

The <server-info> element defined under the <servlet-info> element, specifies whether the server on which the servlet will be served from is enabled.

The <session-info> element defines the following:

dsync-type: This can take the value dsync-distributed or dsync-local.

dsync-distributed implies that the session is distributed and thus available on all configured servers.

dsync-local implies that the session is available on available only on the server on which the session was created.

impl: This can take the values distributed or lite.

distributed implies that the session on distributed.

lite implies that the session is local to the Java engine where the session was created. If this value is set, the dsync-type setting is ignored. I

In Sun Java System Application Server 7 2004Q2, to enable failover of applications on the HTTP route, you define the following properties in the sun-specific web application deployment descriptor file: sun-web.xml.

persistence-store - This can take the values memory, file, or ha. In 6.5, however, only memory based persistence store was supported.
persistence-scope - define the scope of persistence.
session - For every session, the session information will be saved.
modified-session - Only the modified session data will be stored.
modified-attribute - Only the modified attribute data will be stored. In 6.5, only modified-attribute sope was supported.
persistenceFrequency - The frequecy can be for every web method or time based. In 6.5, only web-method was supported.
web-method - The session state is stored at the end of each web request prior to sending a response back to the client. This mode provides the best guarantee that the session state is fully updated in case of failure.
time-based - The session state is stored in the background at the specified frequency. This mode provides less of a guarantee that the session state is fully updated. However, it can provide a significant performance improvement because the state is not stored after each request.

A sample of the sun-web.xml file is given below:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE sun-web-app PUBLIC ’-//Sun Microsystems, Inc.//DTD Sun ONE Application Server 7.1 Servlet 2.3//EN’ ’http://www.sun.com/software/sunone/appserver/dtds/sun-web-app_2_3-1.dtd’>

<sun-web-app>

<session-config>

<seession-manager>

<manager-properties>

<property = persistence-type, value = “ha”>
<property=”persistenceFrequency, value =”web-based”>

</manager-properties>

<store-properties>

<property = “persistenceScope” value=”session”>

</store-properties>

</session-manager>

</session-config>

</sun-web-app>

For more information on sun-web.xml configuration file, see the Sun Java System Application Server Developer’s Guide to Web Applications.

Sun Java System Application Server 7 2004Q2 requires the load balancer plug-in to be installed and configured, in order to load-balance the HTTP request and failover the requests to available server instances in a cluster when there is a failure.

For more information about the load balancer, see the Sun Java System Application Server Administration Guide.

In the load-balancer.xml file, make sure that the web-module enabled element is set to true.

<loadbalancer>

<cluster name=cluster1>

...

<web-module context-root=”abc” enabled=true>

</cluster>

<property name="https-routing" value="true"/>

</loadbalancer>

enabled=true specifies that the web module is active (enabled) for requests to be load balanced to it.

Define the https-routing property and set its value to true.

For more information on editing the load-balancer.xml file, see the Sun Java System Application Server Administration Guide.

Deploy the applications on all server instances that is participating in load balancing.

---

Migrating Enterprise Applications

According to the J2EE specifications, an enterprise application is an EAR file, which must have the following structure:

a META-INF/ directory containing the XML deployment descriptor of the J2EE application called application.xml.
the .JAR and .WAR archive files for the EJB modules and Web module of the enterprise application, respectively.

In the application deployment descriptor, we define the modules that make up the enterprise application, and the Web application's context root.

Sun ONE Application server 6.0/6.5 and 7 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.

It is therefore essential to follow the steps listed here before deploying an enterprise application:

Package EJBs in one or more EJB modules,
Package the components of the Web application in a Web module,
Assemble the EJB modules and Web modules in an enterprise application module,
Define the name of the enterprise application's root context, which will determine the URL for accessing the application.

Note	Sun Java System Application Server 7 2004Q2 uses a new class loader hierarchy as compared to Sun ONE Application Server 6.0/6.5. In the new scheme, for a given application, one class loader loads all EJB modules and another class loader loads web modules. These two are related in a parent child hierarchy where the JAR module class loader is the parent module of the WAR module class loader. Hence all classes loaded by the JAR class loader are available/ accessible to the WAR module but the reverse is not true. Suppose there is a certain class which is required by the JAR as well as the WAR, then it should be packaged inside the JAR module only. If this guideline is not followed it would lead to class conflicts.

Application Root Context and Access URL

There is one particular difference between Sun ONE Application Server 6.0/6.5 and Sun Java System Application Server 7 2004Q2, concerning the applications access URL (root context of the application's Web module):

If AppName is the name of the root context of an application deployed on a server called hostname, then the access URL for this application will differ depending on the application server used:

With Sun ONE Application Server 6.0 or 6.5, which is always used jointly with a Web front-end, the access URL for the application will take the following form (assuming the Web server is configured on the standard HTTP port, 80):

http://hostname/NASApp/AppName/

With Sun ONE Application Server 7 and Sun Java System Application Server 7 2004Q2, the URL will take the form:

http://hostname:port/AppName/

The TCP port used as default by Sun ONE Application Server 7 is port 80.

Although the difference in access URLs between Sun ONE Application Server 6.0/6.5 and Sun Java System Application Server 7 2004Q2 may appear minor, it can however be problematical when migrating applications that make use of absolute URL references. In such cases, it will be necessary to edit the code to update any absolute URL references so that they are no longer prefixed with the specific marker used by the Web Server plug-in for Sun ONE Application Server 6.0/6.5.

If you are using the Migration Tool, it automatically searches for any occurrences of /NASApp in the input application (only if the application is a Sun ONE Application Server 6.5 application), and replaces it with "". The migration report lists down all occurrences of such instances, so that you are aware of this change. If you are migrating a rich client application that contains hard-coded urls with /NASApp, consider any of the following workarounds:

Modify the application context root to change from ’app’ to ’/NASApp/app’. While this will help the Application Server 7 2004Q2 plug-in forward the request to the correct application it would fail in places where an application performs operations based on application context value.
Modify client application to remove any references to ‘NASApp’.

Applications With Form-based Authentication

Applications developed on Sun ONE Application Server 6.5 that use form-based authentication can pass the request parameters to the Authentication Form or the Login page. The Login page could be customized to display the authentication parameters based on the input parameters.

For example:

http://gatekeeper.uk.sun.com:8690/NASApp/test/secured/page.jsp?arg1=test&arg2=m

Sun Java System Application Server 7 2004Q2 does not support the passing of request parameters while displaying the Login page. The applications that uses form-based authentication, which passes the request parameters can not be migrated to Sun Java System Application Server 7 2004Q2. Porting such applications to Application Server 7 2004Q2 requires significant changes in the code. Instead, you can store the request parameter information in the session, which can be retrieved while displaying the Login page.

The following code example demonstrates the workaround:

Before changing the code in 6.5:

---------index-65.jsp -----------

<%@page contentType="text/html"%>
<html>

<head><title>JSP Page</title></head>
<body>

go to the <a href="secured/page.htm">secured area</a>

</body>

</html>

----------login-65.jsp--------------

<%@page contentType="text/html"%>
<html>
<head> </head>
<body>

<!-- Print login form -->

<h3>Parameters</h3><br>
out.println("arg1 is " + request.getParameter("arg1"));
out.println("arg2 is " + request.getParameter("arg2"));

</body>
</html>

After changing the code in 7 2004Q2:

---------index-7.jsp -----------

<%@page contentType="text/html"%>

<html>

<head><title>JSP Page</title></head>
<body>

<%session.setAttribute("arg1","test"); %>
<%session.setAttribute("arg2","me"); %>
go to the <a href="secured/page.htm">secured area</a>

</body>

</html>

The index-7.jsp shows how you can store the request parameters in a session.

----------login-7.jsp--------------

<%@page contentType="text/html"%>
<html>
<head> </head>
<body>

<!-- Print login form -->
<h3>Parameters</h3><br>

<!--retrieving the parameters from the session -->
out.println("arg1 is"+(String)session.getAttribute("arg1"));
out.println("arg2 is” + (String)session.getAttribute("arg2"));

</body>
</html>

---

Migrating Proprietary Extensions

A number of classes proprietary to the Sun ONE Application Server 6.0/ 6.5 environment may have been used in applications. Some of the proprietary Sun ONE packages used by Sun ONE Application Server 6.x are listed below:

com.iplanet.server.servlet.extension
com.kivasoft.dlm
com.iplanetiplanet.server.jdbc
com.kivasoft.util
com.netscape.server.servlet.extension
com.kivasoft
com.netscape.server

These APIs are not supported in Sun Java System Application Server 7 2004Q2. Applications using any classes belonging to the above package will have to be re written such that the applications use standard J2EE APIs. Applications using Custom JSP tags and UIF framework also needs to be rewritten to use standard J2EE API.

---

Migrating UIF

Sun Java System Application Server 7 2004Q2 does not support the use of Unified Integration Framework (UIF) API for applications. Instead, it supports the use of J2EE Connector Adapter (JCA) for integrating the applications. However, the applications developed in Sun ONE Application Server 6.5 uses the UIF. In order to deploy such applications to Sun Java System Application Server 7 2004Q2, you need to migrate the UIF to JCA. This section discusses the pre-requisites and steps to migrate the applications using UIF to Sun Java System Application Server 7 2004Q2.

Before migrating the applications, you need to make sure that the UIF is installed on Sun ONE Application Server 6.5. To check for the installation, you can use any of the following two approaches:

Approach 1: Checking in the registry files

UIF is installed as a set of application server extensions. They are registered in app server registry during the installation. Search for the following strings in the registry to check whether UIF is installed.

Extension Name Set:

Extension DataObjectExt-cDataObject
Extension RepositoryExt-cLDAPRepository
Extension MetadataService-cMetadataService
Extension RepoValidator-cRepoValidator
Extension BSPRuntime-cBSPRuntime
Extension BSPErrorLogExt-cErrorLogMgr
Extension BSPUserMap-cBSPUserMap

The registry file on Solaris Operating Environment can be found at the following location:

Install_dir/AS/registry/reg.dat

Approach 2: Checking for UIF binaries in installation directories

UIF installers copy specific binary files in to the application server installation. A successful find of these files below indicate that UIF is installed.

The location of the following files on Solaris and Windows is:

Install_dir/AS/APPS/bin

List of files to be searched on Solaris:

libcBSPRlop.so
libcBSPRuntime.so
libcBSPUserMap.so
libcDataObject.so
libcErrorLogMgr.so
libcLDAPRepository.so
libcMetadataService.so
libcRepoValidator.so
libjx2cBSPRuntime.so
libjx2cDataObject.so
libjx2cLDAPRepository.so
libjx2cMetadataService.so

List of files to be searched on Windows:

cBSPRlop.dll
cBSPRuntime.dll
cBSPUserMap.dll
cDataObject.dll
ErrorLogMgr.dll
cLDAPRepository.dll
cMetadataService.dll
cRepoValidator.dll
jx2cBSPRuntime.dll
jx2cDataObject.dll
jx2cLDAPRepository.dll
jx2cMetadataService.dll

Before migrating the UIF to Sun Java System Application Server 7 2004Q2, make sure that the UIF API is being used in applications. To verify its usage:

Check for the usage of netscape.bsp package name in the java sources.
Check for the usage of access_cBSPRuntime.getcBSPRuntime method in the sources. Calling this method is essential in acquiring the UIF runtime.

Migration Process

To migrate the UIF, you can use the Sun ONE Connector Builder tool. This tool is also integrated into Sun ONE Studio and hence you can use Sun ONE Studio to migrate the UIF based applications to JCA based applications. The key features of the Sun ONE Connector Builder Tool are:

Connector code generation
Testing and debugging support
Deployment support
Creates connector deployment descriptors
Assembles connectors for deployment
Administration hooks
Monitoring hooks
Customize-able environment

Note: Migration of applications using the UIF in Sun ONE App Sever 6.5 does not require any changes in the code.

For more information on using the Sun ONE Connector Builder tool, visit the following URL:

http://docs.sun.com/db/coll/s1.conbldr

---

Migrating Rich Clients

This section describes the steps for migrating RMI/IIOP and ACC clients developed in Sun ONE Application Server 6.x to Sun Java System Application Server 7 2004Q2 EE.

Authenticating a Client in 6.x

Sun ONE Application Server provides a client-side callback mechanism that enables applications to collect authentication data from the user such as the username and the password.The authentication data collected by the Sun ONE CORBA infrastructure is propagated to the Application Server via IIOP.

If ORBIX 2000 is the ORB used for RMI/IIOP, portable interceptors implement security by providing hooks, or interception points, which define stages within the request and reply sequence.

Authenticating a Client in 7 2004Q2 SE/EE

The authentication is done based on JAAS (Java Authorization and Authentication System API) and the client can that implement a CallBackHandler. If a client does not provide a CallbackHandler, then the Default CallbackHandler called the LoginModule will be used by the ACC for obtaining the authentication data.

For detailed instructions on using JAAS for authentication, see the Sun Java System Application Server Developer’s Guide to Clients.

Note	Sun Java System Application Server 7 2004Q2 does not support authentication of stand-alone (non-ACC) clients.

Using ACC in 6.x and 7 2004Q2 EE

In 6.x, no separate appclient script is provided. You are required to place the iasacc.jar file in the classpath instead of the iascleint.jar file. The only benefit of using the ACC for packaging application clients in 6.x is that the JNDI names specified in the client application are indirectly mapped to the absolute JNDI names of the EJBs.

In case of 6.x applications, a stand-alone client would use the absolute name of the EJB in the JNDI lookup. That is, outside an ACC, the following approach would be used to lookup the JNDI:

initial.lookup(“ejb/ejb-name”);
initial.lookup(“ejb/module-name/ejb-name”);

If your application was developed using 6.5 SP3, you would have used the prefix “java:comp/env/ejb/” when performing lookups via absolute references.

initial.lookup(“java:comp/env/ejb/ejb-name”);

In Sun Java System Application Server 7 2004Q2, the JNDI lookup is done on the jndi-name of the EJB. The absolute name of the ejb must not be used. Also, the prefix, java:comp/env/ejb is not supported in Version 7 and 7 2004Q2. Replace the following jar files in the classpath with appserv-ext.jar:

iasclient.jar, iasacc.jar, or javax.jar

Load-balancing and Failover Features in ACC Clients (Enterprise Edition)

Load balancing is handled implicitly by the CXS engine in SunONE Application Server 6.5 upon number of Java engines registered. In Sun Java System Application Server 7 2004Q2, Enterprise Edition, this feature requires explicit configuration details from the clients.

After migrating the deployment descriptors from 6.x to 7 2004Q2, provide the configuration details in the sun-acc.xml file to enable failover capabilities in your ACC client. See Migrating Deployment Descriptors for information on migrating deployment descriptors.

Define the load balancing properties in the sun-acc.xml file to provide a highly available ACC client. The properties are defined as property elements in the sun-acc.xml file.

com.sun.appserv.iiop.endpoints

This property defines the list of one or more IIOP endpoints. An endpoint is specified as host:port where host is the name or IP address of the system where Sun Java System Application Server is running. Port is the IIOP port at which the server is listening for IIOP requests.

com.sun.appserv.iiop.loadbalancingpolicy

If the endpoint property is specified, then, this property is used to specify the load balancing policy. The value for this property must be InitialContext-based.

For example:

<client-container>

  <target-server name="qasol-e1" address="qasol-e1" port="3700">

  <property name="com.sun.appserv.iiop.loadbalancingpolicy" value="ic-based" />

<property name="com.sun.appserv.iiop.endpoints" value="qasol-e1:3700", “qasol-e1:3800”/>

</client-container>

To failover an ACC client on the RMI/IIOP path, information about all the endpoints in a cluster to which the RMI/ IIOP requests can be failed over must be available. You must have defined the IIOP endpoints in the server.xml file. The iiop-cluster element under the availability-service element defines the IIOP endpoints.

For more information, see the Sun Java System Application Server Administration Guide.

---

Migrating Deployment Descriptors

The following table summarizes the deployment descriptor migration mapping.

Source Deployment Descriptor	Target Deployment Descriptor
ejb-jar.xml - 1.1	ejb-jar.xml - 2.0
ias-ejb-jar.xml	sun-ejb-jar.xml
<bean-name>-ias-cmp.xml	sun-cmp-mappings.xml
web.xml	web.xml
ias-web.xml	sun-web.xml
application.xml	application.xml

The J2EE standard deployment descriptors ejb-jar.xml, web.xml and application.xml are not modified significantly. However, the ejb-jar.xml deployment descriptor is modified to make it compliant with EJB 2.0 specification in order to make the application deployable on Sun Java System Application Server 7 2004Q2.

Majority of the information required for creating sun-ejb-jar.xml and sun-web.xml comes from ias-ejb-jar.xml and ias-web.xml respectively. However, there is some information that is required and extracted from the home interface (java file) of the CMP entity bean, in case the sun-ejb-jar.xml being migrated declares one. This is required to build the <query-filter> construct inside the sun-ejb-jar.xml, which requires information from inside the home interface of that CMP entity bean. If this source file is not present during the migration time, the <query-filter> construct will get created, but with lots of missing information (which will manifest itself in the form of "REPLACE ME" phrases in the migrated sun-ejb-jar.xml).

Additionally, if the ias-ejb-jar.xml contains a <message-driven> element, then information from inside this element is picked up and used to fill up information inside both ejb-jar.xml and sun-ejb-jar.xml. Also, inside the <message-driven> element of ias-ejb-jar.xml, there is an element <destination-name>, which holds the JNDI name of the topic or queue to which the MDB should listen to. In Sun ONE Application Server 6.5, the naming convention for this jndi name is "cn=<SOME_NAME>". Since a JMS Topic or Queue with this name is not deployable on Sun Java System Application Server 7 2004Q2, change this to "<SOME_NAME>", and insert this information in the sun-ejb-jar.xml. This change must be reflected for all valid input files, namely, all .java, .jsp and .xml files. Hence, this change of JNDI name is affected globally across the application, and in case of non availability of some source files that contain reference to this jndi-name, you need to make the change manually in them so that the application becomes deployable.

---

Migrating Sun ONE Application Server 7 Applications

Sun Java System Application Server 7 2004Q2 is an extension to Sun ONE Application Server 7, Enterprise Edition. The following new features are introduced in Application Server 7 2004Q2, Enterprise Edition.

Stores Stateful Session Beans (SFSB) state and recover it upon planned or unplanned software or hardware failover.
Integration of Message Queue 3.5
Automatic retry of failed HTTP requests onto a new server instance.
Ability to customize the error page displayed when an error occurs due to unavailability of application along HTTP path.
Supports the following Database Systems:
Oracle 9.1
DB2 8.1
Sybase 12 or late
MS SQL Server 2000
Pointbase 4.5 or later

This section discusses the migration issues for the following types of J2EE Applications:

Migrating Rich Clients
Migrating EJB Applications

Migrating Rich Clients

This section describes the steps to migrate rich clients from Sun ONE Application Server 7.0 A to Sun Java System Application Server 7 2004Q2. The following scenarios are discussed:

Migrating Rich Clients From 7 PE/SE to 7 2004Q2 EE
Migrating Rich Clients From 7EE to 7 2004Q2EE

Migrating Rich Clients From 7 PE/SE to 7 2004Q2 EE

Migrating rich clients that are deployed in Sun ONE Application Server 7 PE/SE to Sun Java System Application Server 7 2004Q2 is rather simple. The deployment descriptors used in Sun ONE Application Server 7 can be used as is in Sun Java System Application Server 7 2004Q2. However, if you wish to enable load-balancing and failover features in your client applications, you will need to configure the load-balancing and failover capabilities in the deployment descriptors.

The following procedure describes the steps to migrate the applications:

Identify the components which were installed previously.
Find out the server-instances, using asadmin command or through the directory listing. asadmin command requires administration instances to be running. However, administration instances need not be running if the directory listing is used to identify the instances.
In the server.xml file, add the following jvm-options under jvm-config element to enable RMI/IIOP failover feature:

<jvm-config java-home=path...server-classpath=path>

<jvm-option>Dorg.omg.PortableInterceptor.ORBInitializerClass.com.sun.ap pserv.ee.iiop.EEORBInitializer</jvm-option>

<jvm-option>Dorg.omg.PortableInterceptor.ORBInitializerClass.com.sun.ap pserv.ee.iiop.EEIORInterceptorInitializer </jvm-option>

<jvm-option>-Dcom.sun.CORBA.connection.ORBSocketFactoryClass=com.sun.ap pserv.ee.iiop.EEIIOPSocketFactory </jvm-option>

</jvm-config>

Update the availability-service element with availability-enabled flag set to True:

<availability-service availability-enabled=”true”>

<persistence-store>

<property-name=”store-pool-jndi-name” value=”” />
<property-name=”cluster-id” value=”cluster1” />

</persistence-store>

</availability-service>

Modify the server classpath entry under the java-config element to include:

install_dir/SUNWhads/4.2.2-17/lib/hadbjdbc.jar;

install_dir/lib/appserv-rt-ee.jar

Add the following jvm-option under java-config element:

<jvm-option>

Dcom.sun.aas.hadbRoot=install-dir/SUNWhadb/4.2.2-17

</jvm-option>

Update the sun-acc.xml with the following new load-balancing properties:

<property-name=”com.sun.appserv.iiop.loadbalancingpolicy” value=”ic-based” />

<property name=”com.sun.appserv.iiop.endpoints” value=<host>:<port>” />

Migrating Rich Clients From 7EE to 7 2004Q2EE

To migrate 7 EE applications to 7 2004Q2 EE, follow the steps given below:

Add the following jvm-options under java-config element for enabling RMI/IIOP failover feature:

<jvm-config java-home=path...server-classpath=path>

<jvm-option>Dorg.omg.PortableInterceptor.ORBInitializerClass.com.sun.ap pserv.ee.iiop.EEORBInitializer</jvm-option>

<jvm-option>Dorg.omg.PortableInterceptor.ORBInitializerClass.com.sun.ap pserv.ee.iiop.EEIORInterceptorInitializer </jvm-option>

<jvm-option>-Dcom.sun.CORBA.connection.ORBSocketFactoryClass=com.sun.ap pserv.ee.iiop.EEIIOPSocketFactory </jvm-option>

</jvm-config>

Add the following entry in server.xml to setup the iiop-cluster.

<iiop-cluster>

<iiop-server-instance name=<server-name>>

<iiop-endpoint id=<orb-listener-id>, host=<hostname>, port=<orb-listener-port>/>

</iiop-server-instance>

</iiop-cluster>

Update sun-acc.xml with the following new entries:

<property-name=”com.sun.appserv.iiop.loadbalancingpolicy” value=”ic-based” />

<property name=”com.sun.appserv.iiop.endpoints” value=<host>:<port>” />

The host and port is that of ORB-lister-1 ‘s which is defined under iiop-listener element in server.xml.

Migrating 7 2004Q2, SE Applications to Sun Java System Application Server 7 2004Q2, EE

To migrate the applications from 7 2004Q2 SE, follow the steps described in the section Migrating Rich Clients From 7 PE/SE to 7 2004Q2 EE.

Migrating EJB Applications to Support SFSB Failover

Sun ONE Application Server 7 does not support failover of stateful session beans. Sun Java System Application Server 7 2004Q2, Enterprise Edition supports failover of stateful session beans on the HTTP and RMI/IIOP path. This section describes the procedure to migrate EJB applications from Sun ONE Application Server 7 SE/PE/EE to Sun Java System Application Server 7 2004Q2 EE to support SFSB state failover.

Migrating EJB Applications From 7.0SE/PE/EE to 7 2004Q2EE

To achieve high availability of EJB applications that use stateful session beans to persist the data, you need to configure a persistent store for each cluster of application servers, where client session information can be maintained across potential failures of individual appserver instances. In addition, the availability-enabled flag must be turned on for each server instance in the cluster.

Sun Java System Application Server supports the failover of stateful session beans. In order to enable this feature in your EJB applications that were deployed to Sun Java System Application Server 7 2004Q2 EE, follow the steps below:

To migrate Entity beans from previous version of Sun’s Application Server, follow the procedure described in Entity Beans.

SFSB failover is supported in the following deployment scenario:

When SFSB is accessed from EJBs/Servlets/JSP in J2EE applications executing in the same application server process. The SFSB can be accessed through either a local or remote interface.

In order to take advantage of SFSB state failover support, you need not edit the code. However, you need to provide all the configuration parameters needed for checkpointing the SFSBs in the Sun-specific deployment descriptor (sun-ejb-jar.xml) or in the server configuration file.

For detailed information on SFSB Failover, see the Sun Java System Application Server Administration Guide.

Previous      Contents      Index      Next

---

Copyright 2004 Sun Microsystems, Inc. All rights reserved.