Skip navigation.

Roadmap for Upgrading WebLogic and AquaLogic Application Environments

The following sections describe the procedures for upgrading application environments from an earlier release to the following releases:

Note: BEA does not recommend upgrading an application environment that is currently deployed in production. Instead, you should upgrade your application environment while it is under development or test and execute standard procedures for quality assurance and performance tuning before promoting the upgraded environment to production.


 

WebLogic Server 9.1

The following table summarizes the steps to upgrade to WebLogic Server 9.1.


If you are upgrading from...

Then...

WebLogic Server 9.0

Step 1: Update the application environment to reference the WebLogic Server 9.1 installation using one of the options described below.

Create a new 9.1 domain

This option is useful if the process of creating and customizing a domain has been automated.

  1. Install WebLogic Server 9.1 software.
  2. Create a new domain using a default domain template provided in 9.1.

    Note: When upgrading from WebLogic Server 9.0 to 9.1, alternatively you can use a custom 9.0 template to create a new 9.1 domain.

    This step can be accomplished using the Configuration Wizard or using automated scripts, built using WebLogic scripting tools such as WLST.

    You may need to update your automated scripts, for example, to reference the 9.1 domain template and/or to implement new features provided in the 9.1 release.

    For example, in 9.1 the default security providers are XACML-based, as described in Security for BEA WebLogic Server 9.1. You may choose to add support for the WebLogic Server 9.0 default security providers or make the appropriate changes to use the new providers.

  3. Deploy existing WebLogic Server 9.0 applications to the new 9.1 domain.

    Note: If you used a custom 9.0 template in step 2, the 9.0 applications may already be deployed.


Update an existing domain

This option is useful for maintaining customizations within your test domain if generation of the domain has not been automated.

  1. Install WebLogic Server 9.1 software.
  2. Back up the existing application environment, including the domain directory, application and application data that is external to the domain, and log files (if necessary).
  3. Update the script files in the domain to point to the installation of WebLogic Server 9.1. For example, set BEA_HOME, BEA_JAVA_HOME, JAVA_HOME, and WL_HOME to the appropriate values.
  4. Update the CLASSPATH to remove path information that is no longer required, such as patch file information that applies to a pre-9.1 release.

Step 2: If you developed Beehive applications in 9.0, you must upgrade them as described in Upgrading From 9.0 in Beehive Integration in WebLogic Server 9.1.

WebLogic Server 6.0, 7.1, 8.1

See Upgrading WebLogic Application Environments for detailed upgrade procedures.



 

AquaLogic Service Bus 2.1

To upgrade an AquaLogic Service Bus 2.0 domain to 2.1, perform the following steps:


  1. Export the configuration data from the AquaLogic Service Bus 2.0 domain that you want to upgrade using the AquaLogic Service Bus Console, as described in "Exporting Configuration Data" in System Administration in AquaLogic Service Bus Console Online Help.

    Note: In most cases, you cannot export WebLogic Server resources, such as JMS resources and Work Manager definitions. You must re-create these objects in the new AquaLogic Service Bus 2.1 domain, as described in Step 6.
  2. Export the security configuration from the AquaLogic Service Bus 2.0 domain that you want to upgrade using the WebLogic Administration Console, as described in Migrating Security Data in Securing WebLogic Server.

    The following table summarizes the security configuration objects and the security providers in which they are stored.


    Security Object

    Security Provider

    User accounts

    Authentication Provider

    Group definitions

    Authentication Provider

    Role definitions

    Role Mapping Provider

    Username/password credential map entries*

    Username/Password Credential Mapping Provider

    PKI credential map entries*

    PKI Credential Mapping Provider

    * Note: Username/password credential maps are created when assigning a username/password to a service account, and their import and export is managed by a Username/Password Credential Mapping Provider. PKI key-pair credentials are created when assigning key-pair credentials to proxy service providers, and their import and export is managed by a PKI Credential Mapping Provider.

    The security configuration objects listed in the previous table can be imported and exported using the security Migration screens in the WebLogic Administration Console. You can import and export security configuration from the entire security realm (see note for credential maps below) or from each security provider individually.

    Note: When exporting credential maps from the WebLogic Username/Password Credential Mapping Provider and WebLogic PKI Credential Mapping Provider, ensure that the passwords for the credentials are exported in clear text. The mechanism used to encrypt passwords in each WebLogic Server domain is different; therefore, you want to export passwords in clear text to enable them to be used in a different WebLogic Server domain.

    To export passwords in clear text, export the username/password and PKI credentials directly from the respective security provider Migration screens using the WebLogic Administration Console, and enter the following within the Export Constraints text box: passwords=cleartext. For more information, see Exporting data from a security provider in WebLogic Server Administration Console Online Help.

    Warnings:

    • Carefully protect the directory and file in which you export credential maps in clear text as secure data is available on your system during the upgrade process. When the credential maps are imported into the WebLogic Credential Mapping provider in the new WebLogic Server domain, the passwords are encrypted. After the upgrade is complete, it is recommended that you securely dispose of the file with clear-text passwords.
    • If you export an entire security realm, the password information within the credential maps will be exported in encrypted form. In this case, you should NOT import the DefaultCredentialMapper.dat and PKICredentialMapper.dat files with the encrypted password information into the 2.1 domain.
  3. Install the AquaLogic Service Bus 2.1 software as described in Installation Guide.
  4. Create a new AquaLogic Service Bus 2.1 domain using the offline configuration tools, as described in Creating and Extending Domains in Using Offline Configuration Tools.
  5. Configure the security realm in the new domain, as required. Make sure that you configure the appropriate security providers, server keystores, and SSL. For more information, see Security for BEA WebLogic Server 9.1 and Security Configuration in the Using the AquaLogic Service Bus Console.

    If a PKI Credential Mapper is required, make sure that you copy the keystores to the new domain and configure the PKI Credential Mapper accordingly.

  6. Recreate WebLogic Server objects that could not be exported in Step 1, including:
    • JMS resources, such as connection factories, queues and topics, and so on
    • Work Manager definitions

    For more information about configuring WebLogic Server domain resources, see Overview of WebLogic Server System Administration in Introduction to WebLogic Server and WebLogic Express.

  7. If you customized any of the settings for the AquaLogic Service Bus WebServiceSecurityMBean token handlers, for example, changing the UseX509ForIdentity value, you must reset the customizations. The token handlers can be configured using the WebLogic Administration Console or WLST.
  8. Import the 2.0 security information (from Step 2) into the new 2.1 domain, using the WebLogic Administration Console, as described in Migrating Security Data in Securing WebLogic Server.

    Import the security information for each security provider separately.

    There are two authorization providers that are included by default in 2.1: the WebLogic Default Authorization Provider (this is the same as the 2.0 authorization provider) and a new WebLogic XACML Authorization provider. When creating a new 2.1 domain, the XACML provider is created by default. This is the recommended provider in 2.1. If you are importing access control policies to the XACML authorization provider, make sure that you select DefaultAtn in the Import Format drop-down list.

    There are two role mapping providers that are included by default in 2.1: the WebLogic Default Role Mapper Provider (this is the same as the 2.0 role mapping provider) and a new WebLogic XACML Role Mapping Provider. When creating a new 2.1 domain, the XACML provider is created by default. This is the recommended provider in 2.1. If you are importing role definitions to the XACML role mapping provider, make sure you select DefaultRoles in the Import Format drop-down list.

  9. Import the 2.0 configuration data (from Step 1) into the new 2.1 domain, as described in "Importing Configuration Data" in System Administration in AquaLogic Service Bus Console Online Help.
  10. Some AquaLogic domain configuration changes cannot be automated and must be implemented manually. Review the upgrade considerations in the following table for potential impact.

    Upgrade Consideration

    Workaround

    When importing a security configuration in which you customized the group membership property of any default AquaLogic Service Bus group (such as IntegrationAdministrators, IntegrationOperators, IntegrationMonitors, and IntegrationDeployers) or default WebLogic Server group (such as Administrators, Operators, Monitors, and Deployers), the group membership customizations will not be reflected in the upgraded domain.

    Re-apply the group membership customizations. For example, if you created a new group named IT_personnel and assigned IntegrationDeployers as a member of this group, you re-assign that group as a member of IT_personnel.

    In certain cases, when importing a WSDL that uses the wsp:PolicyURI attribute syntax to reference a policy (where wsp refers to the WS-Policy namespace), the following validation error is generated:

    This resource has been manually updated outside the management API and the set of dependencies is out of sync.

    This error occurs if the policy URI is a reference to a custom policy of the form policy:policy-id or a URL (that is, it does not use the policy: scheme).

    For information about defining Web Service policies see "Web Service Policy" in Securing Inbound and Outbound Messages in the AquaLogic Service Bus User Guide.

    If the policy URI is a reference to a custom policy of the form policy:policy-id, in the Resource Browser, select the WSDL, and then edit, save, and commit the WSDL to resolve the policy-id. For more information, see "Viewing and Changing WSDL Details" in WSDLs in AquaLogic Service Bus Console Online Help.

    If the policy URI is a reference to a URL, resolve the policy reference within the WSDL file, as described in "Resolving Unresolved WSDL References" in WSDLs in AquaLogic Service Bus Console Online Help.

    In AquaLogic Service Bus 2.1, the following changes have been made to the service-level access control policy:

    • The service-level access control policy is invoked after a WS-Policy is successfully processed, regardless of whether the WS-Policy specifies an identity assertion. In 2.0, the access control policy was invoked only if the WS-Policy specified an identity assertion.
    • The default behavior for service-level access control policy is to allow access to all users. In 2.0, the default behavior was to deny access.

    Update service-level access control policies to ensure appropriate user access. For more information, see "Access Control Security" in Securing Inbound and Outbound Messages in AquaLogic Service Bus User Guide.

    In AquaLogic Service Bus 2.1, the implementation of the RPC-based WS-Callout has changed in order to maintain the integrity of namespace information and xsi:type information. The implementation changes impact the behavior of RPC-based WS-Callout in specific circumstances.

    If your application uses RPC-based WS-Callout and the following are true:

    • The response uses simple types
    • The pipeline uses XQueries that depend on the response being a String

    Then, you must update the XQueries to strip the element wrapper using, for example, the fn:string() function.

    When importing a security configuration with an authorization provider that defines time-based entitlement policies (such as Access occurs before or Access occurs after), the policies are not working properly.

    When using the XACML Authorization provider, in order to support time-based entitlement policies, you must apply a software patch (for CR255866). For more information, contact your customer support representative.

    Note: Once Customer Support provides you with access to the patch, you may download and apply it using Smart Update. For information about Smart Update, see Installing Maintenance Updates and Service Packs.