Configuring WebSphere Application Server after migration

Before you begin

The installation wizard automatically configures IBM WebSphere Application Server, Version 5.x and all other bundled products. There is no need for additional configuration if you do not migrate from an earlier version.

Why and when to perform this task

If you use the installation wizard to migrate a previous installation of WebSphere Application Server, Version 3.5.x, there are some items to review before considering your environment fully configured.

Steps for this task

  1. Check the WASPostUpgrade.log file for deployment details of the Version 3.5.x enterprise beans. Make any necessary changes and redeploy.

    Note: No redeployment is required when moving EJB 1.1 JAR files from Version 4.

    The J2EE programming model specifies an architecture for how applications are created and deployed. The WASPostUpgrade tool recreates applications because Version 3.5.x applications do not have the same architecture as Version 5.x applications. The Version 5.x J2EE applications contain all migrated Web resources and enterprise beans. All Version 3.5.x enterprise applications become Version 5.x J2EE applications with the same name, deployed in the same server.

    The WASPostUpgrade tool maps Web resources and enterprise beans that are not included in an enterprise application, into a default J2EE application that includes the name of the server. The tool maps Web applications to J2EE WAR files. The tool deploys enterprise beans as EJB 1.1 beans in J2EE JAR files. The tool combines resources in a J2EE EAR file and deploys it in the Version 5.x configuration. There are some differences between the EJB 1.0 and EJB 1.1 Specifications, but in most cases, EJB 1.0 beans can run successfully as EJB 1.1 beans.

    Version 3.5.x supports only the EJB 1.0 components specification level. Version 5.x supports EJB 1.1 components. However, many EJB 1.0 beans can successfully deploy as EJB 1.1 beans. The migration tools redeploy enterprise beans automatically as part of the application migration phase.

    Note: After federating an Application Server node into a deployment manager cell, you cannot use the migration tools on the Application Server node. To use these tools again, remove the node from the cell, use the tools, and add the node to the cell again.

  2. Examine any Lightweight Third Party Authentication (LTPA) security settings you might have used, and apply the settings in the WebSphere Application Server security settings.

    The WASPostUpgrade tool migrates applicable security settings in the Version 3.5.x environment to J2EE security attributes.

    Global security that uses Lightweight Third Party Authentication (LTPA) authentication in Versions 3.5.x and 4.0.x is migrated to the base WebSphere Application Server product and to the Network Deployment product. However, although global security was enabled in Versions 3.5.x and 4.0.x, it is disabled during migration to Version 5.x.

    If you add this node later to an IBM WebSphere Application Server Network Deployment, Version 5.x configuration, you can enable and use the LTPA configuration. Use the administrative console to generate keys for the migrated LTPA authentication mechanism. After generating the keys, you can enable global security.

    Global security that uses localos authentication mechanisms in versions 3.5.x and 4.0.x is migrated to the Network Deployment product. However, although global security was enabled in Versions 3.5.x and 4.0.x, it is disabled during migration to Version 5.x. The Network Deployment product does not support the SWAM authentication mechanism. Migration sets the authentication mechanism in Version 5.x to LTPA. Use the administrative console to generate keys for the migrated LTPA authentication mechanism. After generating the keys, you can enable global security.

  3. Check the WASPostUpgrade.log file in the logs directory, for details about JSP 0.91 objects that the migration tools do not migrate.

    Version 5.x does not support JSP 0.91 objects. The migration tools do not migrate JSP objects configured to run as JSP 0.91 objects. The migration tools do, however, recognize the objects in the output and log them. Version 5.x runs JSP 1.0 and 1.1 objects as JSP 1.2 objects, which is its only supported level.

  4. Review Version 3.5.x models and clones to identify non-migrated objects that you must recreate in Version 5.x.

    Version 3.5.x models and clones and Version 4.0.x server groups have been dramatically redefined in Version 5.x as clusters and cluster members. Application servers are the only objects supported as models and cluster members in Version 5.x. This change is a significant difference from Version 3.5.x, in which many objects are models and clones. All models and clones relating to Application Servers are mapped to cluster members in Version 5.x.

    During the migration of all other objects that you could previously clone, special mapping occurs. All clones are treated as simple objects and are mapped as if they are not cluster members. Models that are not Application Server models are ignored and not mapped.

    Version 4.0.x Server Groups are converted to Version 5.x clusters.

  5. Identify and use the migration tools to migrate non-migrated nodes in Version 3.5.x and Version 4.0.x repositories that have multiple nodes.

    A Version 3.5.x and a Version 4.0.x repository can contain more than one node name and its associated children. The WASPostUpgrade tool processes only those objects and children that match the migrating node. This determination is made by checking the names of nodes in configuration files with fully qualified and non-qualified network names of the migrating machine.

  6. Examine any applications that use IBM extensions.

    In many cases, IBM provides additional features and customization options that extend the specification level even further. If your existing Version 3.x applications use IBM extensions from earlier product versions, you might need to perform mandatory or optional migration to use the same kinds of extensions in the Version 5.x.

    Migration from Version 4.0.x requires little conversion.

  7. Update J2EE resources in client JAR files to the new resource format with the ClientUpgrade tool.

    J2EE applications might exist on the client, if the client has client JAR files with J2EE resources.

  8. [5.0 only]Migrate V4.0.x applications to use the XML4J 4.0.6 parser and the XSLT4J 2.5.4 transformer.

    JAXP defines a pluggability mechanism for a SAX and DOM parser via javax.xml.parsers APIs. Transformers are pluggable via javax.xml.transform APIs.

    The IBM SDK 1.3.1 bundles in Version 5.0.x include an XML4J 4.0.6 parser and an XSLT4J 2.5.4 transformer. To use a different implementation of JAXP in an application, package the parser and transformer in the application and change the class loader delegation to PARENT_LAST on the application or Web module.

    It is recommended that applications do not use the parser or transformer implementation API directly, but that the applications use the JAXP API.

    You can change an application to remove its dependency on the API in a previous version of the parser or the transformer from an earlier version of WebSphere Application Server. Package the JAR files in the application and set the classloader delegation mode to PARENT_LAST.

    You must only recompile a Version 4.0.x XML application to migrate it to the Version 5.0.x level.

    Version 5.1 applications use the XML4J 4.2.2 parser and the XSLT4J 2.5.4 transformer, as described in XML parser for Java code.

  9. Configure WebSphere Application Server to use a database.
    For example, you can configure WebSphere Application Server to use DB2, as described in Configuring WebSphere Application Server for DB2 access.
  10. Review your Java virtual machine settings to verify that you are using a heap size of at least 50 for improved startup performance.
    See Java virtual machine settings for more information.

    If you have used a smaller heap size in the past, you can use the default heap size, which is now 50.

Results

Now you are finished with pre-test configuration. You might have to fine tune your WebSphere Application Server environment as you test it. Test all redeployed applications before moving them into production.

What to do next

Return to Installing WebSphere Application Server products to continue.

Related concepts
Migrating
Configuration mapping during migration
Related reference
XML parser for Java code



Searchable topic ID:   tins_config2
Last updated: Jun 21, 2007 8:07:48 PM CDT    WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/ae/tins_config2.html

Library | Support | Terms of Use | Feedback