| Oracle® Application Server Migrating from JBoss 10g Release 3 (10.1.3.1.0) Part Number B25219-02 |
|
|
View PDF |
| Oracle® Application Server Migrating from JBoss 10g Release 3 (10.1.3.1.0) Part Number B25219-02 |
|
|
View PDF |
This chapter provides an overview of the J2EE platform, application servers, and Oracle Application Server. In addition, it provides an understanding of what is involved in migrating from JBoss to Oracle Application Server 10g Release 3 (10.1.3.1.0).
This chapter contains the following topics:
The application server market is evolving rapidly. In particular, the most significant development over the last few years is the emergence of Sun Microsystems' Java 2 Platform, Enterprise Edition (J2EE) Specification that promises to create a level of cross-vendor standardization.
The J2EE platform and component specifications define, among other things, a standard platform for developing and deploying multi-tier, web-based enterprise applications.
J2EE provides a solution to the problems encountered by companies moving to a multi-tier computing model. The problems addressed include reliability, scalability, security, application deployment, transaction processing, web interface design, and timely software development. It builds upon the Java 2 Platform, Standard Edition (J2SE) to enable Sun Microsystems' "Write Once, Run Anywhere" paradigm for multi-tier computing. J2EE includes the components in the following table:
Table 1-1 J2EE Architecture Components
| Component | Description |
|---|---|
|
J2EE Application Model |
An application model for developing multi-tier, thin client services. |
|
J2EE Platform |
A platform for hosting J2EE applications. |
|
J2EE Compatibility Test Suite |
A compatibility test suite for verifying that a J2EE platform product meets the requirements set forth in the J2EE platform and component specifications. |
|
J2EE Reference Implementation |
A reference implementation of the J2EE platform. |
The J2EE application model is a multi-tier application model. Application components are managed in the middle tier by containers. A container is a standard runtime environment that provides services, including life cycle management, deployment, and security services, to application components. This container-based model separates business logic from system infrastructure.
The J2EE platform consists of a runtime environment and a standard set of services that provide the necessary functionality for developing multi-tiered, web-based enterprise applications. The following two tables list the J2EE platform components and services:
Table 1-2 J2EE Runtime Application Components
| Component | Description |
|---|---|
|
Application clients |
A Java program, typically used for GUIs, that executes on a desktop computer. |
|
Applets |
A component of a Java program that typically executes in a web browser. |
|
Servlets |
A Java program, used to generate dynamic content, that executes on a web server. |
|
Java Server Page (JSP) |
A technology used to return dynamic content to a client, typically a web browser. |
|
Enterprise Java Bean (EJB) |
An applications architecture for component-based distributed computing |
|
Containers |
A runtime environment that provides services for application components, including life cycle management, deployment, and security services. |
|
Resource Manager Drivers |
A system-level component that enables network connectivity to external data sources. |
|
Database |
A set of related files used to store business data and accessible through the JDBC API. |
Table 1-3 J2EE Standard Services
| Service | Description |
|---|---|
|
HTTP |
The standard protocol used on the Internet to send and receive messages between web servers and browsers. |
|
HTTPS |
A security protocol used on the Internet to send and receive messages between web servers and browsers. |
|
Java Transaction API (JTA) |
An API that allows applications and application servers to access transactions. |
|
RMI-IIOP |
RMI: A protocol that enables Java objects to communicate remotely with other Java objects. IIOP: A protocol that enables browsers and servers to exchange things other than text. RMI-IIOP is a version of RMI that uses the CORBA IIOP protocol |
|
JavaIDL |
A standard language for interface specification primarily used for CORBA object interface definition. |
|
JDBC |
An API that provides connectivity between databases and the J2EE platform. |
|
Java Message Service (JMS) |
An API that enables the use of enterprise messaging systems. |
|
Java Naming and Directory Interface (JNDI |
An API that provides directory and naming services. |
|
JavaMail |
An API that provides the ability to send and receive e-mail. |
|
JavaBeans Activation Framework (JAF) |
An API required by the JavaMail API. |
An application server is software that runs between web-based client programs and back-end databases and legacy applications. Application servers help separate system complexity from business logic, enabling developers to focus on solving business problems. Application servers reduce the size and complexity of client programs by enabling these programs to share capabilities and resources in an organized and efficient way.
Application servers provide benefits in the areas of usability, flexibility, scalability, maintainability, and interoperability.
Oracle Application Server is a comprehensive, integrated application server that provides all of the infrastructure and functionality needed to run any e-business. All development teams face a similar set of challenges—the need to rapidly deliver web sites and applications that run fast over any network and on every device; while providing business intelligence to support operational adjustments and strategic decisions. Oracle Application Server enables teams to address all of these e-business challenges.
Oracle Application Server has generated a great deal of interest in the application server market, and many organizations are embracing it to deploy their web-based enterprise applications.
Oracle Application Server offers the only integrated infrastructure to develop and deploy web sites and applications. It provides a complete J2EE platform for developing enterprise Java applications. It enables developers to develop web applications in any language including Java, Perl, PL/SQL, XML, and Oracle Forms. It enables the reduction of development and deployment costs through a single, unified platform for Java, XML, and SQL.
The J2EE server implementation in Oracle Application Server is called Oracle Containers for J2EE (OC4J). OC4J is J2EE 1.3 compliant and runs on the standard JDK version 1.4, which is installed with the product (JDK 1.3 is supported). It is lightweight, provides high performance and scalability, and is simple to deploy and manage. OC4J can be deployed in standalone mode, which is ideal for development environments or with Application Server Control Console to provide enterprise-level monitoring and management facilities.
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 failover implementations among application servers. These differences are sparsely documented, and are thus an even bigger challenge to the migration process.
These challenges make the migration work unpredictable and difficult to reliably plan and schedule. This document addresses the challenges in migrating your applications from JBoss to Oracle Application Server, providing an approach to migration with solutions based on the J2EE version 1.3 specification.
The J2EE platform provides a multi-tiered distributed application model. Central to the J2EE component-based development model is the concept of containers. Containers are standardized runtime environments that provide specific services to components. Thus, Enterprise Java Beans (EJB) developed for a specific purpose in any organization can expect generic services such as transaction and EJB life cycle management to be available on any J2EE platform from any vendor.
Containers also provide standardized access to enterprise information systems; for example, providing database access through the JDBC API. Containers also provide a mechanism for selecting application behavior at assembly or deployment time.
As shown in Figure 1-1, the J2EE application architecture is a multi-tiered application model. In the middle tier, components are managed by containers; for example, J2EE Web containers invoke servlet behavior, and EJB containers manage life cycle and transactions for EJBs. The container-based model separates business logic from system infrastructure.
Given the inherent challenges outlined above, it is helpful to examine the applications to be migrated in terms of the following before quantifying the migration effort.
Code may not be portable because it contains embedded references to vendor- specific extensions to the J2EE specification. In such cases, runtime exceptions, (for example, "class not found") may occur when applications are migrated and run from one J2EE-compliant application server to another. In addition, some J2EE application servers still support deprecated APIs and others are strictly compliant to the J2EE specifications. JBoss contains extentions to servlets, JSPs, EJBs, JNDI, and JDBC. In such cases, evaluating code and planning for its modification may be a significant part of the migration effort.
If JBoss-specific services are in use, migration of those components becomes difficult or unfeasible. These components may need to be redesigned and reimplemented, instead of being identified as migration candidates. This guide does not address complete redesign toward J2EE specifications.
Different application server vendors have different levels of support for J2EE standards, and some variations in behavior. For example, JBoss 3.2.6 supports J2EE 1.3 specifications, but was not certified. Oracle Application Server fully supports J2EE 1.3. This fact raises issues with servlet, EJB, JNDI, and security migration. This guide addresses those issues and explains how to migrate to Oracle Application Server without major code changes.
Our approach for this guide is to document our experiences with migrating components and/or example applications from JBoss 3.2.6 to Oracle Application Server 10g Release 3 (10.1.3.1.0).
The Oracle JDeveloper Application Migration Assistant (AMA) is a 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 JBoss to Oracle Application Server.
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 JBoss 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://otn.oracle.com/tech/migration/exchange.html). In addition to writing your own, you can download and use any of these search rules files.
To download the tool and for more information on it, go to http://otn.oracle.com/tech/migration/ama
This guide details the migration of components from JBoss 3.2.6 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 JBoss 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
Note:
In this document, unless otherwise specified, any reference to JBoss without a version number implies reference to JBoss 3.2.6.
