1 Overview

This chapter provides an overview of the issues involved in migrating J2EE Web applications from WebLogic Server to Oracle Application Server 10g Release 3 (10.1.3), and the effort required.

The chapter contains these topics:

• Section 1.1, "Overview of Oracle Application Server 10g"

• Section 1.2, "Migration Highlights"

• Section 1.3, "Using This Guide"

1.1 Overview of Oracle Application Server 10g

Oracle Application Server 10g is a comprehensive and integrated standards-based application platform suite that provides all of the infrastructure and functionality required to run an agile business. It offers a number of technology solutions based on service-oriented architecture (SOA):

• A J2EE-based SOA platform to develop, deploy, and manage Web services.

• Enterprise integration services for data integration, business process automation, and business activity monitoring.

These solutions share common infrastructures for security, systems management, and grid computing, which allows flexible and scalable deployment of applications on low-cost, modular servers and storage.

Oracle Application Server's SOA infrastructure provides out-of-the-box facilities to develop, wrap, orchestrate, provision, manage, secure, federate, discover, and access enterprise applications and legacy systems as services. All these facilities are available through a single-installed, integrated product.

The following are the main features of Oracle Application Server:

• Oracle Containers for J2EE (OC4J) - a fully J2EE 1.4 compatible container implementation (also backward compatible to J2EE 1.3)

• Oracle Process Manager and Notification Server (OPMN) - a configurable and distributed process manager

• Oracle HTTP Server with mod_oc4j plug-in

• Oracle Enterprise Manager 10g Application Server Control

• JMX management infrastructure

• Web services runtime and management based on JAX-RPC

• Java Object - XML mapping

• Oracle TopLink object - relational mapping with CMP support

For a comparison of features between Oracle Application Server and WebLogic Server, see Chapter 2.

1.2 Migration Highlights

In quantifying the migration effort, it is helpful to examine the application components to be migrated with the following issues in mind:

• Portability

  Code may not be portable because it contains embedded references to vendor-specific extensions to the J2EE specification. Evaluating and planning for code modifications may be a significant part of the migration effort.

• Proprietary extensions

  If vendor-specific extensions are in use, migration of those components becomes difficult or unfeasible. Complete redesign toward J2EE specifications is not addressed in this document. If vendor-specific extensions are in use, they may need to be redesigned and reimplemented, rather than being identified as migration candidates.

• Deviations from J2EE specifications.

  If a component is largely non-compliant with the J2EE specifications, this guide will not be helpful in determining the migration path to Oracle Application Server. If the J2EE specification version of the component is not of version 1.4 (the version on which this guide is based), then the specification implementation differences will need to be addressed.

1.2.1 Migration Approach

The approach in developing this migration guide was to document our experience migrating J2EE application components from WebLogic Server to Oracle Application Server. Examples shipped with WebLogic Server were selected, tested on WebLogic Server, and migrated to Oracle Application Server. Issues encountered in the migration of these examples are the basis for this document.

For most migration projects, a J2EE application can be migrated in the following order:

1. Identify the following differences between WebLogic Server and Oracle Application Server: deployment, runtime (classloaders), third party library support.

2. Remove (if possible) platform specific proprietary features. For example, for WebLogic Server: BEA JOLT, JSP-based Tags.

3. Port platform-specific deployment descriptors.

4. Port a J2EE application in tiers in the following sequence:

   1. Data tier (EJBs).

   2. Web tier.

   3. Java clients.

   4. Data sources, JMS message queues, and/or JCA adaptors.

   5. Other components (for example, single sign-on, JAAS, LDAP repository).

      
      

      Note: JNDI names can be different. Use the JNDI tree browser in Application Server Control Console or Oracle JDeveloper to browse the JNDI tree in OC4J. After migrating the above tiers and components, the recommended deployment approach is to deploy your application to a standalone OC4J instance to validate its full runtime functionality. When the validation is complete, your application can be deployed using Application Server Control to a single node or multi-node cluster of Oracle Application Server installations.

      
      

5. Implement clustering and performance tune OC4J J2EE container.

1.2.2 J2EE Application Migration Challenges

The varying degrees of compliance to J2EE standards can make migrating applications from one application server to another a daunting task. Some of the challenges in migrating J2EE applications from one application server to another are:

• Though in theory, any J2EE application can be deployed on any J2EE-compliant application server, in practice, this is not strictly true.

• Lack of knowledge of the implementation details of the given J2EE application.

• Ambiguity in the meaning of 'J2EE-compliant' (usually, this means the application server has J2EE compliant features, not code-level compatibility with the J2EE specification).

• The number of vendor-supplied extensions to the J2EE standards in use, which differ in deployment methods and reduce portability of Java code from one application server to another.

• Differences in clustering, load balancing, and fail over implementations among application servers; these differences are sparsely documented, and are thus an even bigger challenge to the migration process.

This guide addresses the abovementioned challenges in migrating your applications from WebLogic Server to Oracle Application Server. It provides an approach to migration with solutions based on the J2EE version 1.4 specification.

1.2.3 Migration Effort

Moving from WebLogic Server to Oracle Application Server is a relatively simple process. Standard J2EE applications, using no proprietary APIs, can be deployed with no required code changes. The only actions required are configuration and deployment. Those applications using proprietary utilities or APIs can be ported easily.

1.2.4 Migration Tool

The Oracle JDeveloper Application Migration Assistant (AMA) is a new tool developed by Oracle to simplify the process of migrating applications to the Oracle platform. The tool provides code navigation and progress reporting to guide you through migrating from WebLogic Server to Oracle Application Server 10g.

The AMA tool is installed as a plug-in to Oracle JDeveloper. It uses regular expressions to identify code in your application files that may require modification to work on the Oracle platform. These regular expressions are contained in an XML file called search rules file. AMA can analyze your WebLogic Server application and generate an analysis report that summarizes project statistics, allows navigation between review items, and provides comprehensive status tracking for your migration changes. AMA is customizable by providing an extensible API that allows additional search rules files to be written and tailored for your specific application.

Oracle provides a number of search rules files through the AMA Search Rules Exchange (http://www.oracle.com/technology/tech/migration/ama/exchange/exchange.html). One of these files is the AMA Search Rules for BEA WebLogic Migrations. The rules defined in this file can be used to identify WebLogic-specific code that may require modification for migration to Oracle Application Server. For example, the tool can identify whether you are using Jolt or BEA JCOM. It can also locate any references in your application to Defweblogic startup/shutdown, T3 services, WebLogic XA, and native WebLogic JDBC drivers.

To download the tool and for more information on it, go to http://www.oracle.com/technology/tech/migration/ama/.

1.3 Using This Guide

This guide details the migration of components from WebLogic Server to Oracle Application Server. While it does not claim to be an exhaustive source of solutions for every possible configuration, it provides solutions for some of the migration issues listed above, which will surface, along with others, in your migration effort. The information in this guide helps you to assess the WebLogic Server applications and plan and execute their migration to Oracle Application Server. The material in this guide supports these high-level tasks:

• Survey the components according to the issues listed above

• Identify migration candidates

• Prepare the migration environment and tools

• Migrate and test the candidate components