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.
|
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.
This option is useful if the process of creating and customizing a domain has been automated.
This option is useful for maintaining customizations within your test domain if generation of the domain has not been automated.
|
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. |
|
To upgrade an AquaLogic Service Bus 2.0 domain to 2.1, perform the following steps:
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:
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.
For more information about configuring WebLogic Server domain resources, see Overview of WebLogic Server System Administration in Introduction to WebLogic Server and WebLogic Express.
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.
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:
|
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:
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. |