|
| |
| Sun Java System Application Server Platform Edition 8 Migrating and Redeploying Server Applications Guide | |
Chapter 1
Understanding MigrationThis chapter addresses the following topics:
J2EE Component StandardsSun Java System Application Server Platform Edition 8 (hereafter called Application Server) is a J2EE v1.4-compliant server based on the component standards developed by the Java community for Java Servlets (servlets) , Java Server Pages (JSPs), and Enterprise JavaBeans (EJBs).
By contrast, Sun Java System Application Server 7 is a J2EE v1.3-compliant server and Sun ONE Application Server 6.x is a J2EE v1.2-compliant server. Between the three J2EE versions, there are considerable differences with the J2EE application component APIs.
The following table characterizes the differences between the component APIs used with the J2EE v1.4-compliant Sun Java System Application Server Platform Edition 8, the J2EE v1.3-compliant Sun ONE Application Server 7, and the J2EE v1.2-compliant Sun ONE Application Server 6.x.
In addition, the two products support a number of technologies connected with XML standards and Web Services which are not part of the J2EE specification.
J2EE Application Components and MigrationJ2EE simplifies development of enterprise applications by basing them on standardized, modular components, providing a complete set of services to those components, and handling many details of application behavior automatically, without complex programming. J2EE v1.4 architecture includes several component APIs. Prominent J2EE components include:
J2EE components are packaged separately and bundled into a J2EE application for deployment. Each component, its related files such as GIF and HTML files or server-side utility classes, and a deployment descriptor are assembled into a module and added to the J2EE application. A J2EE application is composed of one or more enterprise bean(s), Web, or application client component modules. The final enterprise solution can use one J2EE application or be made up of two or more J2EE applications, depending on design requirements.
A J2EE application and each of its modules has its own deployment descriptor. A deployment descriptor is an XML document with an .xml extension that describes a component’s deployment settings. An enterprise bean module deployment descriptor, for example, declares transaction attributes and security authorizations for an enterprise bean. Because deployment descriptor information is declarative, it can be changed without modifying the bean source code. At run time, the J2EE server reads the deployment descriptor and acts upon the component accordingly.
A J2EE application with all of its modules is delivered in an Enterprise Archive (EAR) file. An EAR file is a standard Java Archive (JAR) file with an .ear extension. The EAR file contains EJB JAR files, application client JAR files and/or Web Archive (WAR) files. The characteristics of these files are as follows:
- Each EJB JAR file contains a deployment descriptor, the enterprise bean files, and related files
- Each application client JAR file contains a deployment descriptor, the class files for the application client, and related files
- Each WAR file contains a deployment descriptor, the Web component files, and related resources
Using modules and EAR files makes it possible to assemble a number of different J2EE applications using some of the same components. No extra coding is needed; it is just a matter of assembling various J2EE modules into J2EE EAR files.
The migration process is concerned with moving J2EE application components, modules, and files.
For more information on migrating various J2EE components please refer to Chapter 3.
For more background information on J2EE, see the following references:
- J2EE tutorial - http://java.sun.com/j2ee/tutorial/
- J2EE overview - http://java.sun.com/j2ee/overview.html
- J2EE topics - http://java.sun.com/j2ee
Migration and RedeploymentThis section describes the need to migrate J2EE applications and the particular files that will need to be migrated. Following successful migration, a J2EE application can be redeployed to the Application Server. Redeployment is also described in this section.
The following topics are addressed:
Why is Migration Necessary?
Although J2EE specifications broadly cover requirements for applications, it is nonetheless an evolving standard. It either does not cover some aspects of applications or leaves implementation details as the responsibility of application providers.
These product implementation-dependent aspects manifest as differences in the way application servers are configured and also in the deployment of J2EE components on application servers. The array of available configuration and deployment tools for use with any particular application server product also contribute to the product implementation differences.
The evolutionary nature of the specifications itself presents challenges to application providers. Each of the component APIs in turn are separately evolving. This leads to a varying degree of conformance by products. In particular, an emerging product, such as the Application Server, has to contend with differences in J2EE application components, modules, and files deployed on other established application server platforms. Such differences require mappings between earlier implementation details of the J2EE standard such as file naming conventions, messaging syntax, and so forth.
Moreover, product providers usually bundle additional features and services with their products. These features are available as custom JSP tags or proprietary Java API libraries. Unfortunately, using these proprietary features will render these applications non-portable.
What Needs to be Migrated
For migration purposes, the J2EE application consists of the following file categories:
Deployment descriptors (XML files)
Deployment is accomplished by specifying deployment descriptors (DDs) for standalone enterprise beans (EJB JAR files), front-end Web components (WAR files) and enterprise applications (EAR files). Deployment descriptors are used to resolve all external dependencies of the J2EE components/applications. The J2EE specification for DDs is common across all application server products. However, the specification leaves several deployment aspects of components pertaining to an application dependent on product-implementation.
JSP source files
J2EE specifies how to extend JSP by adding extra custom tags. Product vendors include some custom JSP extensions in their products, simplifying some tasks for developers. However, usage of these proprietary custom tags results in non-portability of JSP files. Additionally, JSP can invoke methods defined in other Java source files as well. The JSPs containing proprietary APIs needs to be rewritten before they can be migrated.
Java source files
The Java source files can be EJBs, servlets, or other helper classes. The EJBs and servlets can invoke standard J2EE services directly. They can also invoke methods defined in helper classes. Java source files are used to encode the business layer of applications, such as EJBs.Vendors bundle several services and proprietary Java API with their products. The usage of proprietary Java APIs is a major source of non-portability in applications. Since J2EE is an evolving standard, different products may support different versions of J2EE component APIs. This is another aspect that migration will address.
What is Redeployment?
Redeployment refers to deploying a previously deployed application from an earlier version of Sun ONE Application Server 6.x, Sun Java System Application Server 7, or from applications that were previously deployed, but migrated, from third party application server platforms.
The act of redeploying an application typically refers to using the standard deployment actions outlined in the Sun Java System Application Server Platform Edition 8 Administration Guide. However, when migration activities are performed with automated tools, such as the Migration Tool for Sun Java System Application Server Platform Edition 8 (for J2EE applications) or the Sun ONE Migration Toolbox (for NetDynamics and Netscape Application Servers), there might be post-migration or pre-deployment tasks that are needed (and defined) prior to deploying the migrated application.
See Migration Tools and Resources for more information about migration tools that are available.