This chapter provides important supplementary information upgrading Oracle SOA applications to Oracle Fusion Middleware 11g.
Use Chapter 8, "Overview of Upgrading Oracle SOA Suite, WebCenter, and ADF Applications" for the tasks required to upgrade any Oracle SOA Suite, WebCenter, and ADF application.
Use the following sections to understand tasks specific to upgrading Oracle SOA applications:
Section 9.2, "Upgrade Tasks Associated with All Java Applications"
Section 9.3, "Upgrade Tasks Associated with All Oracle SOA Suite Applications"
Section 9.4, "Upgrade Tasks Associated with Oracle BPEL Process Manager Applications"
Section 9.5, "Upgrade Tasks Associated with Oracle Enterprise Service Bus"
Section 9.6, "Upgrade Tasks Associated with Oracle Business Activity Monitoring"
Section 9.7, "Upgrade Tasks Associated with Technology Adapters"
Section 9.8, "Upgrade Tasks Associated with Human Workflow Tasks"
Section 9.9, "Upgrade Tasks Associated with Oracle Business Rules"
Section 9.10, "Upgrading Oracle SOA Suite Client Applications"
Section 9.11, "Upgrading Oracle Web Services Manager (WSM) Policies"
Section 9.12, "Upgrading Oracle Containers for J2EE (OC4J) Security Environments"
When you open an Oracle Application Server 10g Oracle SOA Suite application in Oracle JDeveloper 11g, the Oracle JDeveloper Migration Wizard attempts to upgrade your application automatically to Oracle Fusion Middleware 11g.
However, there are some limitations to what the Oracle JDeveloper Migration Wizard can perform automatically. Refer to specific sections of this chapter for information about the types of manual tasks you might have to perform on your Oracle SOA Suite applications before or after using the Migration Wizard.
Applying the Latest Patch Sets
For best results, Oracle recommends that you apply the most recent patch sets to your Oracle SOA Suite environment and that you use the latest 10g Release 3 (10.1.3) Oracle JDeveloper before upgrading to 11g.
Keeping Oracle JDeveloper and Oracle SOA Suite at the Same Version Level
As a general rule, you should always update your Oracle SOA Suite and Oracle JDeveloper installations at the same time and run the same version of both these Oracle products.
Verifying That You Have the Required SOA Composite Editor Oracle JDeveloper Extension
To upgrade your Oracle SOA Suite applications to 11g, you must have the Oracle SOA Composite Editor extension for Oracle JDeveloper 11g.
To verify that the extension is installed, select About from the Oracle JDeveloper Help menu, and click the Version tab. You should see an entry in the list of components called SOA Composite Editor.
If this component does not appear on the Version tab of the About dialog box, close the About dialog and select Check for Updates from the Help menu. Use the Check for Updates wizard to locate and install the latest version of the SOA Composite Editor extension.
Before you begin upgrading your Oracle SOA Suite applications, be sure to review the Oracle Fusion Middleware Upgrade Guide for Java EE, which contains information about upgrading standard Java EE applications to Oracle WebLogic Server.
If your applications contain any custom Java code, you should review the Java code against the procedures and recommendations available in the Oracle Fusion Middleware Upgrade Guide for Java EE.
The following information should reviewed when you are upgrading any Oracle SOA Suite application to Oracle Fusion Middleware 11g:
Understanding Oracle SOA Suite API Changes for Oracle Fusion Middleware 11g
Upgrading Applications That Require Proxy Settings for Web Services
Recreating build.xml and build.properties Files Not Upgraded by the Migration Wizard
Table 9-1 describes the APIs you can use in an Oracle SOA Suite application. For each Oracle Application Server 10g API, it provides a summary of the changes for Oracle Fusion Middleware 11g and where you can get more information about upgrading your applications that use the API.
Table 9-1 Summary of Oracle SOA Suite API Changes for Oracle Fusion Middleware 11g
| 10g API | Action for 11g | 11g JavaDoc |
|---|---|---|
|
Updated for Oracle Fusion Middleware 11g, but the new 11g version is backward compatible with 10g. |
||
|
Oracle Application Server Integration B2B Instance Message Java API |
Updated for Oracle Fusion Middleware 11g, but the new 11g version is backward compatible with 10g. |
Oracle Fusion Middleware Instance Data Access Java API Reference |
|
Updated for Oracle Fusion Middleware 11g, but the new 11g version is backward compatible with 10g. |
Oracle Fusion Middleware Workflow Services Java API Reference for Oracle BPEL Process Manager |
|
|
See Section 9.3.1.1, "Upgrading to the Oracle Fusion Middleware Java API for Oracle Business Rules" |
Oracle Fusion Middleware Java API Reference for Oracle Business Rules |
|
|
See Section 9.3.1.2, "Upgrading to the Oracle Fusion Middleware Infrastructure Management Java API for Oracle SOA Suite" |
See Section 9.3.1.2, "Upgrading to the Oracle Fusion Middleware Infrastructure Management Java API for Oracle SOA Suite" |
|
|
Updated for Oracle Fusion Middleware 11g, but the new 11g version is backward compatible with 10g and part of the new Infrastructure Management Java API. |
"Using Oracle BPEL Process Manager Sensors" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite |
The following sections introduce the Oracle Business Rules 11g SDK and API and provide instructions for upgrading to the Oracle Business Rules API:
In Oracle Fusion Middleware11g, the Oracle Business Rules SDK and API has been significantly improved.
In Oracle Application Server 10g, developers were required to manually manage accessing the repository and creating and using RuleSession instances. In Oracle Fusion Middleware 11g, the Decision Point API and decision function features provide an interface and implementation that simplifies the definition and execution of rules.
When upgrading to Oracle Business Rules 11g, look first at how you can use these new features, as documented in the Oracle Fusion Middleware User's Guide for Oracle Business Rules.
However, if you want to continue to use the Oracle Business Rules SDK in the same way as you did for 11g, then the following sections describe how to directly translate the Oracle Business Rules 10g SDK to the 11g SDK.
All of the classes discussed in this section are in the rulesdk2.jar file and under the oracle.rules.sdk2 package.
In Oracle Business Rules 10g, it was common for an application developer to use a file-based repository while developing the application, and then switch to using a WebDAV repository for production.
In Oracle Business Rules 11g, you can instead access the rule dictionary file directly before it is packaged into a format which can be deployed to MDS.
In the following examples, compare the code required to access a dictionary in development mode in 10g (Example 9-1) with the code required in 11g (Example 9-2).
Note that in general, you should use the Decision Point API rather than continuing to access the RuleRepository directly.
Example 9-1 Accessing a Dictionary with Oracle Business Rules 10g in a Development Environment
String path; // the path to the file repository
Locale locale; // the desired Locale
// The following code assumes that the path and locale have been set appropriately
RepositoryType rt =
RepositoryManager.getRegisteredRepositoryType("oracle.rules.sdk.store.jar");
RuleRepository repos = RepositoryManager.createRuleRepositoryInstance(rt);
RepositoryContext rc = new RepositoryContext();
rc.setLocale(locale);
rc.setProperty("oracle.rules.sdk.store.jar.path", path);
repos.init(rc);
Example 9-2 Accessing a Dictionary with Oracle Business Rules 11g in a Development Environment
protected static final String DICT_LOCATION ="C:\\scratch\\CarRental.rules";
...
RuleDictionary dict = null;
Reader reader = null;
try {
reader = new FileReader(new File(DICT_LOCATION));
dict = RuleDictionary.readDictionary(reader, new
DecisionPointDictionaryFinder(null));
List<SDKWarning> warnings = new ArrayList<SDKWarning>();
dict.update(warnings);
if (warnings.size() > 0 ) {
System.err.println("Validation warnings: " + warnings);
}
} catch (SDKException e){
System.err.println(e);
} catch (FileNotFoundException e){
System.err.println(e);
} catch (IOException e){
System.err.println(e);
} finally {
if (reader != null) {
try { reader.close(); } catch (IOException ioe)
{ioe.printStackTrace();}
}
}
In Oracle Business Rules 10g, WebDAV was the recommended production repository.
In Oracle Business Rules 11g, WebDAV is no longer supported and Metadata Services (MDS) is the recommended repository. Also, the dictionary "name" and "version" have been replaced with a "package" and "name" (similarly to the Java class naming scheme).
In Oracle Business Rules 10g, the version did not provide true versioning. In Oracle Business Rules 11g, the equivalent to specifying a version is to simply change the name. For example, a 10g dictionary with the name foo.bar.MyDict and version 2 would in 11g be packaged as foo.bar and name MyDict2.
In the following examples, compare the code required to access a dictionary in production mode in 10g (Example 9-3) with the code required in 11g (Example 9-4).
Example 9-3 Accessing a Dictionary with Oracle Business Rules 10g in a Production Environment
String url; // the URL for the WebDAV repository
Locale locale; // the desired Locale
// The following code assumes that the url and locale have been set appropriately
RepositoryType rt =
RepositoryManager.getRegisteredRepositoryType("oracle.rules.sdk.store.webdav");
RuleRepository repos = RepositoryManager.createRuleRepositoryInstance(rt);
RepositoryContext rc = new RepositoryContext();
rc.setLocale(locale);
rc.setProperty("oracle.rules.sdk.store.webdav.url", url);
repos.init(rc);
RuleDictionary dictionaryWithInitialVersion =
repos.loadDictionary(dictionaryName);
RuleDictionary dictionarySpecificVersion = repos.loadDictionary(dictionaryName,
dictionaryVersion);
Example 9-4 Accessing a Dictionary with Oracle Business Rules 11g in a Production Environment
import static
oracle.rules.sdk2.repository.RepositoryManager.createRuleRepositoryInstance;
import static
oracle.rules.sdk2.repository.RepositoryManager.getRegisteredRepositoryType;
import static oracle.rules.sdk2.store.mds.Keys.CONNECTION;
...
private static final String DICT_PKG = "oracle.middleware.rules.demo";
private static final String DICT_NAME = "CarRental";
private static final DictionaryFQN DICT_FQN =
new DictionaryFQN(DICT_PKG, DICT_NAME);
...
RuleRepository repo =
createRuleRepositoryInstance(getRegisteredRepositoryType(CONNECTION));
repo.init(new RepositoryContext() {{
setDictionaryFinder(new DecisionPointDictionaryFinder(null));
}});
RuleDictionary dict = repo.load(DICT_FQN);
Oracle SOA Suite 11g introduces a new infrastructure management API that replaces several other APIs previously available in Oracle SOA Suite 10g.
For more information about the new API, refer to the Oracle Fusion Middleware Release Notes, which are available as part of the Oracle Fusion Middleware 11g documentation library.
If you are upgrading an Oracle SOA Suite application that depends upon references to custom JAR file libraries. note that these references may not get upgraded automatically when you open and upgrade your application in Oracle JDeveloper 11g.
As a result, you should review your projects for these types of dependencies and, after the upgrade, make sure that you add any missing references, by selecting the Libraries and Classpath link in the Oracle JDeveloper 11g Project Properties dialog.
If you are upgrading an application that uses Web services resources outside your company firewall, you must modify a configuration file that will enable the upgrade to accesses proxy settings and adjust them accordingly during the upgrade of the application.
To configure Oracle JDeveloper 11g to use the proxies during the upgrade process:
Locate the following file in the JDEV_HOME/bin directory:
sca-upgrade.xml
Edit the file and modify the following settings to identify the proxy server and port required to resolve the Web services addresses for the applications you are upgrading.
<jvmarg value="-Dhttp.proxySet=true"/> <jvmarg value="-Dhttp.proxyHost=PROXY_SERVER"/> <jvmarg value="-Dhttp.proxyPort=PROXY_PORT"/>
Note that there are two locations in the file to modify these settings. One location is used to set the proxy when you are upgrading an ESB project to Oracle Mediator 11g; the other is used when you are upgrading Oracle BPEL Process Manager projects.
Stop and start Oracle JDeveloper 11g so your changes can take effect and then open and upgrade your application in Oracle JDeveloper 11g.
When you open and upgrade an application in Oracle JDeveloper 11g, the build.xml and build.properties files associated with your application projects are not upgraded.
Instead, you must recreate these files in Oracle JDeveloper 11g after the upgrade.
The following information is important if any of your Oracle BPEL Process Manager or Oracle Enterprise Service Bus 10g projects use remote resources that are registered in a UDDI (Universal Description, Discover and Integration) registry, such as Oracle Service Registry (OSR).
Refer to the following for more information:
If you have a 10g Release 3 (10.1.3) project that references an endpoint URL that uses a serviceKey from OSR, then you must be sure that the endpoint URL is up and available when you upgrade the application. Otherwise, the upgrade of the application will fail. To prevent such a failure, verify that the endpoint URLs are available, and if necessary, modify the endpoint URLs in bpel.xml or the routing service to point to new URL which is accessible.
In Oracle Application Server 10g Release 3 (10.1.3), Oracle BPEL Process Manager and Oracle Enterprise Service Bus projects used the uddi protocol to obtain resource references from OSR. In Oracle Fusion Middleware 11g, Oracle BPEL Process Manager and Oracle Mediator projects use the orauddi protocol.
As a result, prior to upgrading your Oracle BPEL Process Manager or Oracle Enterprise Service Bus projects, you must do the following:
Use the service registry to modify the registered service so it uses the new bindings supported by Oracle Fusion Middleware 11g.
For example, in OSR, do the following:
Log in to your Oracle Service Registry.
On the Search tab, click Businesses.
Click Add Name to search for a business by name.
From the search results, click the name of the business you want to modify.
In the left pane of the View Business page, right-click the service you want to modify and select Add Binding from the context menu.
From the Type drop-down menu on the Add Binding page, select wsdlDeployment.In the Access Point field, enter the URL.
For example:
http://machine:port/Proj_ep?WSDL/
Click Add Binding.
Click Save Changes.
Open and upgrade the application in Oracle JDeveloper 11g.
In Oracle JDeveloper, edit the composite.xml file for the upgraded project and configure the endpoint URL using the UDDI Registry option on the Resource Palette.
For more information about the UDDI registry, visit the following URL:
http://www.oracle.com/technology/tech/soa/uddi/index.html
The following sections describe how to use the Oracle SOA Suite command-line upgrade tool:
Benefits of Using the Oracle SOA Suite Command-Line Upgrade Tool
Using the Oracle SOA Suite Command-Line Upgrade Tool with Oracle JDeveloper 11g
Upgrading BPEL Projects with the Oracle SOA Suite Command-Line Upgrade Tool
The Oracle SOA Suite Command-Line Upgrade Tool has the following benefits:
You can use the command-line tool to automate your application upgrade work, using scripts or other command-line automation tools.
The command-line tool upgrades both Oracle BPEL Process Manager projects, and upgrades Oracle Enterprise Service Bus 10g projects to Oracle Mediator 11g.
With the command-line tool, you can merge BPEL projects together and create a single composite out of multiple BPEL projects. This is not possible when you use the Oracle JDeveloper Migration Wizard.
The functionality is exactly the same as the JDeveloper mode when it comes to dealing with SOA project contents because the same codebase is used.
The Oracle SOA Suite Command-Line Upgrade Tool is compatible (with restrictions) with the Oracle JDeveloper Migration Wizard. In other words, you can choose to remain in command-line mode all the way through the upgrade process (upgrade, compile, package, and deploy), or you can choose to move to Oracle JDeveloper, or you use both tools, with no functionality loss.
However, it is important to note that the command-line tool upgrades SOA project artifacts only. Other Oracle JDeveloper artifacts (for example, the .jpr and .jws files) are ignored.
To work around this restriction, note the following:
The Oracle SOA Suite Command-Line Upgrade Tool copies files from the BPEL suitcase directory (the BPEL subdirectory or the directory hosting the BPEL files) to the specified target directory, specified on the command line.
The above copying action does not copy the .jpr or .jws files. After the upgrade, the target directory contains only the upgraded SOA project contents.
To remedy this problem in Oracle JDeveloper, you can create a new application or new project, and then define the project directory to be the newly upgraded composite directory.
If you attempt to use the Oracle SOA Suite Command-Line Upgrade Tool to upgrade an application that contains Oracle Human Workflow projects, note that the tool will create a separate project for each upgraded task form.
This resulting project is an Oracle ADF project and Oracle ADF does not support command line deployment. As a result, after using the Oracle SOA Suite Command-Line Upgrade Tool, you must open the upgraded projects in Oracle JDeveloper 11g deploy it from JDeveloper.
For information about how to open the upgraded project in Oracle JDeveloper, see Chapter 9, "Using the Oracle SOA Suite Command-Line Upgrade Tool with Oracle JDeveloper 11g".
The files required to run the Oracle SOA Suite Command-Line Upgrade Tool are installed automatically when you install Oracle JDeveloper 11g and when you install Oracle SOA Suite 11g:
When you install the Oracle SOA Suite 11g, the required XML files are installed in the bin directory of the Oracle SOA Suite Oracle home.
When you install Oracle JDeveloper 11g, the required XML files are installed in the bin directory of the Oracle JDeveloper home.
You can use this files in this directory, together with Apache Ant, to migrate your 10g Release 3 (10.1.3) SOA projects to 11g.
Note:
For the purposes of this procedure, it is assumed you are running the Oracle SOA Suite Command-Line Upgrade Tool from the Oracle home of an Oracle SOA Suite installation.If you are running it from a Oracle JDeveloper home, replace ORACLE_HOME with JDEV_HOME in the following procedures.
To use the ANT project:
Set the required environment variables, by running the following script:
On UNIX systems:
ORACLE_HOME/bin/soaversion.sh
On Windows systems:
ORACLE_HOME\bin\soaversion.bat
Run the Ant project, as follows:
ant -f ORACLE_HOME/bin/ant-sca-upgrade.xml -Dsource sourceDir -Dtarget targetDir -DappName app_name
When you run the Ant command, note the following:
Your BPEL files from the source directory are migrated to the target directory you specified on the command line. The migration tool creates an application subdirectory using the value you entered as the appName value on the command line.
The sourceDir you specified on the command line can be the bpel folder, the parent directory that hosts the bpel folder, or the Oracle Enterprise Service Bus project folder.
Note that the source directory is backed up before migration; if you must re-run the upgrade, be sure to restore the source files using the backup that was created before the invoking the tool. You can identify the backup directory by the ".backup" suffix in its name.
The sourceDir and targetDir parameters must be fully-qualified path names.
After upgrade, the logs can be found in the following output directory:
ORACLE_HOME/upgrade/logs
After upgrade, you must run the SCA-Compiler (ant-sca-compile.xml) which will verify the migrated sources. Because the SCA-Upgrade will not generate complete artifacts in all cases, you will see some errors or warnings from SCA-Compiler with pointers on how to fix them. Check the SCA Compiler for reference.
After getting a clean pass from the SCA-Compiler you can use the ant-sca-package.xml tool to package your application. You can then deploy the application using ant-sca-deploy.xml. After deployment, your project will be available to the server for testing.
Note, however, that in most cases, you will likely want to open the upgraded project in Oracle JDeveloper 11g. From there, you can easily review, verify, and make any necessary updates to the application projects.
For more information, see Section 9.3.6.2, "Using the Oracle SOA Suite Command-Line Upgrade Tool with Oracle JDeveloper 11g".
Using the Oracle SOA Suite Command-Line Upgrade Tool, you can merge BPEL projects together and create a single composite. This is not possible when you use the Migration Wizard in Oracle JDeveloper.
To combine multiple BPEL projects into a single composite, provide multiple source directories as part of the -Dsource property on the command line.
Path separators can be a colon (:) or a semicolon (;). Ant will convert the separator to platform's local conventions. As a guideline, also use double quotes to identity the multiple source directories to prevent Ant from parsing the input in an unexpected manner.
The first source directory specified will be considered as the root of the 11g project and will determine the composite name.
For example:
ant -f ORACLE_HOME/bin/ant-sca-upgrade.xml -Dsource "sourceDir1:sourceDir2" -Dtarget targetDir -DappName app_name
The first project in the source list is considered the root project and only those services are exposed as Composite Services. Anytime you use the merge feature, it is recommended that the projects be related.
Merging of projects is supported for BPEL projects only. ESB projects cannot be merged with other BPEL or other ESB projects.
The Oracle SOA Suite Command-Line Upgrade Tool can also be used to upgrade ESB projects to Oracle Mediator 11g.
To upgrade an ESB project, use the instructions in Section 9.3.6.4, "Upgrading BPEL Projects with the Oracle SOA Suite Command-Line Upgrade Tool", but replace the Ant command with the following:
ant -f $ORACLE_HOME/bin/ant-sca-upgrade.xml -Dsource sourceDir -Dtarget targetDir -DappName app_name mediator
If you use domain value maps (DVMs) or Cross References in your Oracle BPEL Process Manager 10g or Oracle Enterprise Service Bus 10g projects, then note the following:
The xPath functions you use to access the domain value maps or cross references are upgraded automatically to Oracle BPEL Process Manager and Oracle Mediator 10g when you open and upgrade your applications in Oracle JDeveloper 11g.
However, you must perform a manual upgrade task to upgrade the domain value maps and cross references that are saved in the Oracle Enterprise Service Bus repository. The upgrade process moves the domain value maps from the ESB repository to the Oracle Fusion Middleware 11g Metadata Services (MDS) repository.
For more information, see "Managing the MDS Repository" in the Oracle Fusion Middleware Administrator's Guide.
To upgrade your 10g domain value maps in the ESB repository perform the following tasks.
Change directory to the Oracle Enterprise Service Bus Oracle home.
Use the export script to export the metadata to a ZIP file.
For example, on UNIX systems:
ORACLE_HOME/export.sh metadata10g.zip
Use Apache Ant and the upgrade-xrefdvm target in the sca-upgrade.xml file to use the metadata ZIP file to generate an Oracle SOA Suite archive JAR file:
Change directory to the Oracle SOA Suite 11g Oracle home.
Use the following command to generate a SOA archive file, which will automatically be called sca_XrefDvmFiles10g_rev1.0.jar:
ant -f ant-sca-upgrade.xml upgrade-xrefdvm -Dsource=location_of_the_zip_file -Dtarget=location_of_the_soa_archive
For example:
ant -f ant-sca-upgrade.xml upgrade-xrefdvm -Dsource=$ORACLE_HOME/temp/upgrade/metadata10g.zip -Dtarget=$ORACLE_HOME/temp/upgrade
Start Oracle JDeveloper 11g and create a new application.
Import the Oracle SOA Suite archive into a new SOA project:
From the Oracle JDeveloper 11g File menu, select Import, then SOA Archive into SOA Project.
In the Create SOA Project from SOA Archive Dialog Box, click Browse and locate the sca_XrefDvmFiles10g_rev1.0.jar file that you created previously in this procedure.
Make sure that the Project Name and Composite Name in the Create SOA Project from SOA Archive dialog box have the same name, which must be XrefDvmFiles10g.
Click OK to create the new SOA project, which is called XrefDvmFiles10g.
The new project consists of an empty composite, along with the upgraded XRef and DVM files.
Create a metadata archive (MAR) file for the application, which includes the XRef and DVM metadata, and then deploy the MAR to the Oracle WebLogic Server domain.
For information about creating a MAR, see "Creating a Deployment Profile" in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
After you upgrade the DVM and cross reference metadata to 11g, you can then use Oracle JDeveloper 11g to modify the entries in the XrefDvmFiles10g project as needed. Each time you make changes, you must then transfer them to the proper MDS repository using the MAR deployment process.
Use the following sections to learn about the upgrade tasks you will likely need to perform to upgrade your Oracle BPEL Process Manager applications and projects to Oracle Fusion Middleware 11g:
Manual Upgrade Steps After Migrating Oracle BPEL Process Manager Applications
Additional Considerations for Oracle BPEL Process Manager Applications
The following sections describe some of the common upgrade tasks you will have to perform after you open your Oracle Application Server 10g Oracle SOA Suite application in Oracle JDeveloper 11g.
These tasks represent items that are not upgraded automatically by the Oracle JDeveloper Migration Wizard:
Providing Missing Binding Information for External References
Correcting Problems With Oracle BPEL Process Manager Test Suites
Using Oracle BPEL Process Manager Deployment Plans After Upgrade
Upgrading Fault Policies in an Oracle BPEL Process Manager Project
This section describes how to fix compiler warning messages about missing bindings after you upgrade an Oracle BPEL Process Manager project in Oracle JDeveloper.
Why the Warning Messages Occur When a source project in your application depends on Oracle Application Server 10g Release 3 (10.1.3) Oracle BPEL Process Manager or Oracle Enterprise Service Bus (ESB) services, then as a pre-cursor to migration, the Oracle JDeveloper Migration Wizard creates local copies of their abstract WSDLs.
The abstract WSDLs, by definition, lack service and port endpoint information. During upgrade, when the Migration Wizard creates external composite references for the service dependencies, the references are created as abstract references with no binding information.
These abstract references are flagged with WARNING messages in the upgrade log. After upgrade, when you attempt to compile the projects, Oracle JDeveloper will generate compilation errors alerting you to the presence of abstract references in the composite.
Note that a similar message also appears when you are using Oracle SOA Suite 10g Web services that use HTTP bindings, which are not supported in Oracle SOA Suite 11g.
Using 10g Release 3 (10.1.3) or 11g Dependency Services Based on the upgrade and deployment schedules of all the services in the dependency tree, you can choose to continue to use 10g Release 3 (10.1.3) dependency services or proceed with the upgrade and redeployment of the dependency service.
In general, Oracle recommends that users study their source project and their dependencies before any upgrade work. This analysis will result in a smoother upgrade experience.
How to Correct Binding Errors Discovered During the Recompile To correct binding errors due to the abstract references, right-click on the reference node in the Oracle JDeveloper 11g composite editor and choose the correct concrete WSDL. If you want to continue using a 10g Release 3 (10.1.3) dependency service, you can do so. Some of the dependency service endpoint URLs that are captured in the upgrade log and can be used for this step.
You can also redesign the dependency in Oracle JDeveloper 11g, using the WSIL Browser (Resource Palette), and discover the service from the UI in the composite modeler.
For more information, refer to the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
During upgrade in Oracle JDeveloper, BPEL test suites are converted to composite test suites. However, only the "instance initiate" action is migrated. This results in a composite test which initiates only a test run. The rest of any BPEL-based test actions are not automatically migrated and must be manually set up after the upgrade.
To set up the tests in your 11g environment, refer to "Testing SOA Composite Applications" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Deployment and configuration plans that you set up in Oracle Application Server 10g for your Oracle BPEL Process Manager user projects are not upgraded in Oracle JDeveloper 11g.
In Oracle Fusion Middleware11g, a composite can be accompanied by deployment and configuration plan during deployment. However, you must create the 11g deployment plan manually, after you have migrated the application in Oracle JDeveloper.
For more information about creating configuration plans in 11g, see "Moving SOA Composite Applications to and from Development, Test, and Production Environments" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
When you open your 10g application in Oracle JDeveloper and use the Oracle JDeveloper Migration Wizard to upgrade the application, any fault policies and bindings that you set up in a user project are not automatically upgraded to 11g.
The reasons are as follows:
In Oracle BPEL Process Manager 10g, fault policies were stored with the server and bindings were either stored with the server or specified in bpel.xml. In Oracle BPEL Process Manager 11g, fault policies and fault bindings are stored in the Oracle JDeveloper 11g project.
In general, fault policies and bindings in Oracle BPEL Process Manager 11g are different than those in previous releases. For example, the file name and syntax is different, fault policies apply both to Oracle Mediator and Oracle BPEL Process Manager, and bindings are at a reference, component, and composite level in 11g.
For these reasons, you must manually recreate the fault policies and bindings in the Oracle JDeveloper 11g project after you upgrade your applications.
Similarly, when you upgrade an Oracle Enterprise Service Bus 10g Release 3 (10.1.3) project to 11g, you must add the retry parameters defined in esb_config.ini file to the 11g fault-policy.xml file.
For more information, see:
"Using Fault Handling in a BPEL Process" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite
"Using Mediator Error Handling" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
If the 10g Release 3 (10.1.3) application you are upgrading includes a project where all the project artifacts are in one folder and the BPEL artifacts are not separated into their own folder in the project, then the Oracle JDeveloper Migration Wizard will not be able to upgrade those artifacts.
To avoid this problem, do one of the following:
Before upgrading the project, use Oracle JDeveloper 10g to create a BPEL folder and move all the artifacts (except the build.xml and build.properties files) into that folder. Then you can proceed with upgrading the project.
Use the Oracle SOA Suite command-line upgrade tool. The command-line tool will upgrade the artifacts even if a BPEL folder does not exist in the project. For more information, see Section 9.3.6, "Using the Oracle SOA Suite Command-Line Upgrade Tool".
The following sections describe additional considerations you should review after upgrading Oracle BPEL Process Manager applications:
Verifying New and Deprecated Properties in the bpel.xml Deployment Descriptor
Upgrading User-Defined (Custom) XPath Functions in an Oracle BPEL Process Manager Project
Upgrading Projects With the transaction=participate Property
Specifying Domain Descriptor Properties in Oracle BPEL Process Manager 11g
If any of your Oracle Application Server 10g Release 3 (10.1.3) applications reference any properties that were stored in the bpel.xml deployment descriptor, note that these properties are now set in the composite.xml deployment descriptor file.
For more information about the properties available in the composite.xml deployment descriptor, as well as important information about properties that are no longer supported in Oracle Fusion Middleware 11g, refer to "Deployment Descriptor Properties" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
When you open and upgrade your applications in Oracle JDeveloper 11g, any custom XPath functions in the application projects are not upgraded automatically.
As a result, after you upgrade your application, you must copy any XPath function classes into the server classpath and register the function in the server configuration file. This is a manual step because the Oracle JDeveloper Migration Wizard cannot assume the server information.
For more information, refer to "Creating User-Defined XPath Extension Functions" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
You cannot upgrade a single BPEL file with multiple implementations in Oracle BPEL Process Manager 11g.
To migrate and merge multiple 10g Release 3 (10.1.3) projects with a single BPEL implementation file, you must rename the BPEL file in each project. In the bpel.xml file in each project, the bpel filename and deployment ID name must be renamed the same name, as well.
Before you upgrade the application, review the bpel.xml file and *.bpel file. Make sure that the BPEL file name and the process name are the same; then review the bpel.xml file and verify that the BPEL file name is the same as the deployment ID name.
If you created an Oracle BPEL Process Manager 10g project that used correlation sets in an asynchronous service, as described in the Oracle BPEL Process Manager 10g Release 3 (10.1.3) Developer's Guide, make sure that the correlation set properties file uses the following proper naming convention:
BPEL_FILE_NAME_Properties.wsdl
If this file naming convention is not followed in the Oracle BPEL Process Manager 10g project, the properties will not be upgraded correctly. If you need to change the name to meet the file naming conventions, then also update the wsdl file that imports the property file name, accordingly.
If you open and upgrade an Oracle BPEL Process Manager 10g project that has a configuration property, transaction=participate, then that property will not be migrated to 11g when you open the application in Oracle JDeveloper 11g. This configuration property is no longer supported in Oracle Fusion Middleware 11g.
If you open and upgrade an Oracle BPEL Process Manager 10g project has a partnerLink binding property, transaction=participate, then that property will be dropped on the caller side. The callee project instead should have the property setting bpel.config.transaction=required. This caller to callee setting propogation is not performed by upgrade and must be performed manually after you upgrade the application and before you attempt to deploy it on Oracle Fusion Middleware 11g.
In Oracle BPEL Process Manager 10g, you specify domain properties in the domain.xml descriptor file. In Oracle BPEL Process Manager 11g, you specify Oracle BPEL Process Manager engine properties in bpel-config.xml and soa-infra-config.xml (both are accessible as MBeans).
There is only one domain in Oracle BPEL Process Manager 11g, which means that these properties will affect the entire server.
Table 9-2 Domain Descriptor Properties in Oracle BPEL Process Manager 10g and 11g
Refer to the following sections for information about upgrading Oracle Enterprise Service Bus 10g to Oracle Mediator 11g:
Upgrading Oracle Enterprise Service Bus Routing Rules That Are Not Exposed as Services
Upgrading Oracle Enterprise Service Bus Domain Value Maps (DVMs) and Cross References
Upgrading Oracle Enterprise Service Bus Projects with SOAP Headers to Oracle Mediator 11g
Upgrading Projects with Multiple Routing Services That Use the Same Namespace
Upgrading Filtering or Setting Message Headers in Oracle Enterprise Service Bus
If you upgrade an Oracle Enterprise Service Bus 10g project that contains an ESB routing service that is not exposed as a Web service, then the routing service and related composites cannot be invoked after upgrade.
To resolve this issue, modify the routing service in Oracle Mediator 11g so it is exposed as a Web service. For more information, see "Creating Mediator Routing Rules" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Alternatively, you can ensure that all routing services in your Oracle Enterprise Service Bus 10g projects are exposed as Web services before you begin the upgrade process.
If you use domain value maps in your and Oracle Enterprise Service Bus 10g projects, then note that while the xPath functions for DVMs and cross-references are upgraded automatically, you must perform a post-upgrade task to upgrade the DVM and cross reference metadata to 11g.
For more information, see Section 9.3.6.7, "Upgrading Domain Value Maps (DVMs) and Cross References with the Oracle SOA Suite Command-Line Upgrade Tool".
If you used XSLT functions to manipulate SOAP headers in Enterprise Service Bus (ESB) 10g, then after you upgrade your application, those header manipulation will be modeled as assignments in Oracle Mediator 11g.
For complex header manipulations, you should manually verify the SOAP headers before deploying the upgraded Oracle Mediator 11g projects.
For more information, see "Creating Static Routing Rules" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Oracle Enterprise Service Bus 10g supports multiple routing services that have WSDLs that reference the same targetNameSpace within a single ESB project.
For example, at least one of the sample 10g applications available on the Oracle Technology Network (the samples_102_responseForward sample application) supported this scenario.
However, Oracle Mediator 11g no longer supports this configuration. During the upgrade of the application in Oracle JDeveloper 11g, whenever a second service is found to have the WSDL pointing to the same targetNameSpace, the namespace is modified by suffixing _service-qname to the namespace. In addition, a warning message is added to the log file.
For example, in the Samples_102_ResponseForward sample application, the targetNameSpace of the service DispatchShipmentDetails is:
@ http://oracle.com/esb/namespaces/Samples_102_ResponseForward
After the upgrade of the application, it appears as follows:
@ http://oracle.com/esb/namespaces/ Samples_102_ResponseForward_Samples.102_ResponseForward.DispatchShipmentDetails
In this example, Samples.102_ResponseForward.DispatchShipmentDetails is the qname of service DispatchShipmentDetails.
In Oracle Enterprise Service Bus 10g, there was no support for asynchronous routing services. Instead, when Oracle Enterprise Service Bus called an Oracle BPEL Process Manager asynchronous process, then a OneWay service was created.
If you created a project that uses such a OneWay service, then after you open and upgrade the application in Oracle JDeveloper 11g, you can remove the old routing service and recreate the routing service to use an Oracle Mediator 11g asynchronous routing instead of the OneWay invocation.
Oracle Enterprise Service Bus 10g supports filtering or setting message headers for standard and custom header properties for adapters, such as SOAP, JCA, JMS, and AQ adapters. Filtering in Oracle Enterprise Service Bus is done as part of the <filterExpression> tag of the routing rule.
When you open your Oracle Enterprise Service Bus projects in Oracle JDeveloper 11g, each routing rule is upgraded into case, and the filter expression is converted to condition. These changes can be found in the mplan file of the Routing Service.
For example, the following code snippet shows the filter expression in an Oracle Enterprise Service Bus 10g routing rule:
<filterExpression>{ehdr:getRequestHeader
('/fhdr:InboundFileHeaderType/fhdr:fileName') = 'Mobile.xml'};{ namespace
fhdr=http://xmlns.oracle.com/pcbpel/adapter/file/ namespace
ehdr=http://www.oracle.com/XSL/Transform/java
/oracle.tip.esb.server.headers.ESBHeaderFunctions }
</filterExpression>
During upgrade, this example is converted to the equivalent condition of the case in the mplan file:
<condition language="xpath" xmlns:ehdr="http://www.oracle.com/XSL
/Transform/java/oracle.tip.esb.server.headers.ESBHeaderFunctions"
xmlns:fhdr="http://xmlns.oracle.com/pcbpel/adapter/file/">
<expression>$in.property.jca.file.FileName ='Mobile.xml'</expression>
</condition>
Setting message headers is accomplished as part of the transformation files and these are upgraded to assign statements.
The following code snippet shows an example of setting message headers in Oracle Enterprise Service Bus 10g:
<xsl:variable name="inputCountry" select="/imp1:CustomerData/Country"/>
<select="ehdr:setOutboundHeader
('/jhdr:JMSOutboundHeadersAndProperties
/jhdr:JMSOutboundProperties/jhdr:Property[position()=1]/@value',$inputCountry,
'jhdr=http://xmlns.oracle.com/pcbpel/adapter/jms/;')"/>
During upgrade, this example is converted to the following equivalent assign element t in 11g:
<assign>
<copy expression="$in.CustomerData/CustomerData/Country"
target="$out.CustomerData/jhdr:JMSOutboundHeadersAndProperties
/jhdr:JMSOutboundProperties/jhdr:Property[position()=1]/@value"/>
</assign>
Most of the standard header properties are upgraded to their equivalent 11g headers. Customized headers are upgraded using a best effort approach, but it is not possible to upgrade all the variations of customized headers.
As a result, you must manually upgrade any customized headers the equivalent condition or assign element and equivalent mplan artifacts.
For more information, see "Getting Started with Oracle Mediator" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Refer to the following sections for information on upgrade tasks associated with Oracle Business Activity Monitoring:
If your Oracle BAM 10g environment takes advantage of an LDAP directory server to store your Oracle BAM user names or other Oracle BAM information, then you should make sure that the LDAP directory you were using in Oracle Application Server 10g is associated with your new Oracle Fusion Middleware 11g environment.
In general, after upgrade of the Oracle BAM schema, any Oracle BAM 10g users will appear in the Oracle BAM Administrator as inactive if they don't exist in the 11g LDAP directory. However, you can use Oracle BAM Administrator software to remap 10g users to new Oracle BAM 11g users.
For more information, see Section 6.8.1, "Configuring Oracle SOA Suite 11g to Use Identity Management Components".
After you upgrade from Oracle BAM 10g to Oracle Fusion Middleware 11g, some of the Action Form templates you created in Oracle BAM 10g may not function correctly.
As a result, after you perform the upgrade, you should review the templates and verify that they are functioning correctly.
Specifically, use the following instructions to search for typical issues that might need to be corrected after the upgrade to Oracle Fusion Middleware 11g:
See Also:
"Creating Action Form Templates" in the Oracle Fusion Middleware User's Guide for Oracle Business Activity MonitoringOpen the Oracle BAM Start Page.
See Also:
"Starting the Oracle BAM Web Applications," in the Oracle Fusion Middleware User's Guide for Oracle Business Activity MonitoringStart Oracle BAM Architect.
Select Data Objects from the menu.
Expand the System folder and open the Views folder.
Select the Action Form Templates data object and click Contents.
Click Edit Contents.
Click Edit next to the first row.
Copy the contents of the FormInput column to a text editor and remove any white space following an element. (in other words replace "> " with ">").
Search for the mixed case "ReportServer" and change to lower case "reportserver" to fix the links to the style sheets.
Copy and paste the updated text back into the FormInput column.
Repeat these steps for each entry in the FormInput column that contains data.
External data sources defined in your Oracle BAM 10g environment are not upgraded to Oracle BAM 11g.
As a result, if you use external data sources in your Oracle BAM 10g environment, you must manually recreate those data sources in Oracle BAM 11g. This is because Oracle Fusion Middleware 11g supports a new set of database drivers, which are used to connect to an external database.
To configure external data sources for Oracle BAM 11g, refer to "Creating External Data Sources" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
If you used any images in your Oracle BAM 10g reports, the images in any existing reports will not be upgraded to Oracle BAM 11g and will be missing from the reports in the upgraded environment.
However, in your new Oracle Fusion Middleware 11g environment, you can add images to any new or existing reports using Oracle BAM Active Studio 11g.
For more information, see "Setting Backgrounds for Reports" in the Oracle Fusion Middleware User's Guide for Oracle Business Activity Monitoring.
The following sections describe how Oracle BAM Web services support in Oracle BAM 10g is affected by upgrade to Oracle Fusion Middleware 11g:
If you have developed client applications that communicate via Web services with Oracle BAM 10g servers, then you can continue to use those clients after you upgrade to Oracle BAM 11g, with no changes to the client code.
This is possible because the DataObjectOperations Web service available in Oracle BAM 10g is still available in Oracle BAM 11g. The DataObjectOperations Web service has been renamed to DataObjectOperations10131, but the WSDL end point URL remains the same, so client processes can continue working with Oracle BAM 11g.
However, to ensure that your clients continue to work successfully with Oracle BAM 11g, Oracle recommends that you apply the latest patch set to any Oracle BPEL Process Manager 10g clients that are using Oracle BAM 11g environment.
Note:
At the time of this document was published, the latest patch set available for Oracle SOA Suite 10g and Oracle JDeveloper was 10g Release 3 (10.1.3.5).However, for more information on the latest patch sets required for Oracle Fusion Middleware 11g interoperability and upgrade, refer to the Oracle Fusion Middleware 11g Release Notes available in the Oracle Fusion Middleware documentation library on the Oracle Technology Network (OTN):
http://www.oracle.com/technology/documentation/
If you are using the latest version of Oracle JDeveloper 10g Release 3 (10.1.3), to create a connection to Oracle BAM 11g, the Domain field in the BAM connection wizard is completely ignored and can be left blank.
For more information about the DataObjectOperations10131 Web service in Oracle BAM 11g, refer to "Using Oracle BAM Web Services" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
In Oracle BAM 11g, you could configure alerts to invoke a Web service by invoking an external action. This method of using alerts to invoke a Web service is no longer supported in Oracle BAM 11g.
Instead, in Oracle BAM 11g, you can create an alert rule that calls the "Call a Web Service" action.
For more information, see "Creating Oracle BAM Alerts" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
If you used the ManualRuleFire Web service in Oracle BAM 10g, note that the end point URL for this Web service has changed in Oracle BAM 11g.
For more information, refer to "Using the ManualRuleFire Web Service" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
For complete information about the new Web services features in Oracle BAM 11g, refer to "Using Oracle BAM Web Services" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
When you open and upgrade a Oracle BPEL Process Manager 10g Release 3 (10.1.3) project in Oracle JDeveloper 11g, any Oracle BAM sensor actions are migrated automatically to 11g.
Unlike the behavior in 11g, Oracle BAM sensor actions in Oracle Fusion Middleware 11g use the Oracle BAM connection Factory JNDI (as shown in the BAM Sensor Action dialog box) to connect to Oracle BAM server. They do not use the bpel.xml file as they did in 10g Release 3 (10.1.3).The migrated Oracle BAM 11g sensor actions can be identified by the eis/bam/soap connection Factory JNDI name. The Oracle BAM connection specified in the 10g bpel.xml file is migrated to an Application Resource BAM connection with the name of Migrated1.
All connection properties are preserved "as is" except for PORTS, which are set to 9001.
Note that Oracle JDeveloper 11g cannot connect to Oracle BAM 10g Release 3 (10.1.3). When you open an application in Oracle JDeveloper 11g, it is assumed that you have already installed and upgraded to Oracle BAM 11g.
Similarly, the Oracle BPEL Process Manager 11g runtime cannot connect to Oracle BAM 10g Release 3 (10.1.3).
Enterprise Link for Oracle Business Activity Monitoring 10g is no longer available in Oracle BAM 11g. Instead, Oracle BAM 11g supports integration with Oracle Data Integrator (ODI), which replaces Enterprise Link.
When you upgrade to Oracle BAM 11g, you have the following options, depending on how you use Enterprise Link in Oracle BAM 10g:
If used Enterprise Link primarily for integrating JMS messages into Oracle BAM, then you should review the Direct EMS functionality available in Oracle BAM 11g. Direct EMS allows JMS messages to be sent directly to Oracle BAM without the need for adapters or ODI.
For more information, see "Creating Oracle BAM Enterprise Message Sources" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
If your Oracle BAM 10g EnterpriseLink plans are more complex, then you must manually recreate them as ODI scenarios. Oracle BAM 11g supports all the Oracle BAM 10g transformations (for example, insert, update, delete, and so on) as ODI Knowledge Modules via the ODI integration with Oracle BAM 11g.
For more information, see "Using Oracle Data Integrator With Oracle BAM" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
The following sections describe upgrade tasks you might need to perform when upgrading Technology Adapters to Oracle Fusion Middleware 11g:
Verifying Adapters with the Oracle JDeveloper 11g Adapter Configuration Wizard
Upgrading Non-Managed Connection Information in the Adapter JCA File
After upgrading your Oracle SOA Suite 10g projects to Oracle SOA Suite 11g, Oracle recommends that you use the adapter configuration wizard to verify the upgrade of your technology adapters. This will ensure that all required fields in your 11g are populated and that the adapter connections to your new Oracle Fusion Middleware 11g environment are valid.
For more information, see the information the specific adapters you are using in the Oracle Fusion Middleware User's Guide for Technology Adapters.
After you upgrade an application that uses adapter headers, you will likely receive an error after you open the application in Oracle JDeveloper 11g. The error will indicate that a variable or parameter was not recognized while it was parsing a header function.
This is caused by a change in the way adapter header variables are defined in Oracle Fusion Middleware 11g.
In Oracle Application Server 10g Release 3 (10.1.3), you create adapter header variables in a wsdl file that has a name such as the following, or a similar name for the direction and adapter type you are using:
fileAdapterOutboundHeader.wsdl
In Oracle Fusion Middleware 11g, adapter header variables are now properties that you set on the Properties tab of the Invoke dialog box in Oracle JDeveloper.
For example, the properties you can set for the JCA Adapter for Files/FTP are described in the section, "Inbound Headers" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
After you open your project in Oracle JDeveloper 11g, the wsdl header files you created for Oracle Application Server 10g will no longer be attached to the project. You must define each of the variables in the wsdl files as properties for each adapter type that uses header variables.
For more information, refer to the appropriate chapter for each adapter type in the Oracle Fusion Middleware User's Guide for Technology Adapters.
In Oracle Application Server 10g, you can use non-managed connections in the JCA file to point to your development resources. For example, data source definitions can be specified using the non-managed-connection element in the JCA file.
In Oracle Application Server 10g, using non-managed connections was reserved for development only. In Oracle Fusion Middleware 11g, non-managed connections are not supported.
Ideally, before upgrading your Oracle Application Server 10g projects to Oracle Fusion Middleware 11g, you should already be using JCA files that include only JNDI references to connections that are defined properly in the datasources.xml or oc4j-ra.xml files.
If you attempt to upgrade applications that use non-managed connections for adapter connections, you must modify the projects after upgrade to use proper connections defined by using supported administration tools, such as the Oracle WebLogic Server Administration Console.
If you created an 10g Release 3 (10.1.3) technology adapter using the Adapter Configuration Wizard, and you entered a description for the adapter in the Description field of the wizard, the description will be lost when you open and migrate the project in Oracle JDeveloper 11g.
This is because the documentation element in removed from the WSDL file during the upgrade.
If the adapter is important, you can use the Oracle JDeveloper 11g Adapter Configuration Wizard to add the description after you have upgraded the project.
In Oracle SOA Suite 10g, if you used the MQSeries Adapter inbound synchronous request-reply use case, you will notice that there is only one message type, which is REQUEST.
In Oracle SOA Suite 11g, the MQAdapter supports two message types: REQUEST and NORMAL. The REQEUST MQ message type always has replyToQueue set on its header so there is no need for FallbackQueueName and FallbackQueueManagerName. On the other hand, a NORMAL Message may or may not have FallbackQueueName and FallbackQueueManagerName.
So, when a 10g inbound synchronous request-reply scenario is upgraded to 11g, then the Message Type remains as REQUEST type. Therefore, at runtime, there is no need for FallbackQueueName and FallbackQueueManagerName, even though these properties would resides in the .jca file. If you want to use these properties, you must set the message type to NORMAL.
For more information about the inbound synchronous request-reply use case, see "Oracle MQ Series Adapter Use Cases" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
If you used the MQSeries Adapter outbound dequeue use case, which was a documented use case scenario in 10g Release 3 (10.1.3), then note that these types of projects cannot be upgraded by Oracle JDeveloper 11g.
Instead, you must recreate these types of projects after the upgrade to Oracle JDeveloper 11g. While recreating the project you must ensure that you set the value for UITransmissionPrimitive to SynchronousDequeue.
For more information, see "Outbound Dequeue Scenario" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
If you are upgrading an application that uses the Oracle Application Server Adapter for Advanced Queuing (AQ adapter), then note that the AQ Adapter header is accessed differently in Oracle Fusion Middleware 11g.
Specifically, you must perform the following post-upgrade steps for AQ adapter headers after you upgrade to Oracle SOA Suite 11g. This procedure is required for both Oracle BPEL Process Manager and for Oracle Enterprise Service Bus projects that are upgraded to Oracle Mediator.
After upgrading to Oracle Mediator, assign the "jca.aq.HeaderDocument" value from inbound to outbound in the .mplan file of the Oracle Mediator file.
After upgrading to Oracle BPEL Process Manager 11g:
Define a new variable 'vInboundHeaders' of type string.
For example:
<variable name="vInboundHeaders" type="xsd:string"/>
In the receive activity, make sure that the jca.aq.HeaderDocument property gets written to the above variable.
For example:
<bpelx:property name="jca.aq.HeaderDocument"
variable="vInboundHeaders"/>
At the time of invocation, make sure that the "vInboundHeaders" value is copied back to the jca.aq.HeaderDocument property:
<invoke name="Invoke_1"
inputVariable="Invoke_1_Enqueue_InputVariable"
partnerLink="EnqueueClobPayload" portType="ns2:Enqueue_ptt"
operation="Enqueue">
<bpelx:inputProperty name="jca.aq.HeaderDocument"
variable="vInboundHeaders"/>
</invoke>
In Oracle Fusion Middleware 11g, the procedure you use to create AQ outbound request-reply scenarios for Oracle BPEL Process Manager projects has changed.
As a result, when you upgrade an Oracle SOA Suite 10g application that uses this scenario, the WSDL file that is created during the upgrade does not contain the required binding information.
To correct this problem, do the following after you open and upgrade the application in Oracle JDeveloper 11g:
Add the JCA entry to the WSDL file created by the upgrade, as follows:
<?binding.jca CombinedRequestReply_aq.jca?> <wsdl:definitions name="CombinedRequestReply" ... > . . . </wsdl:definitions>
Add the binding entry in the composite.xml file:
<reference ui:wsdlLocation="CombinedRequestReply.wsdl"
name="CombineRequestReply">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel
/adapter/aq/EnqueueRequest/#wsdl.interface(Enqueue_ptt)"
callbackInterface="http://xmlns.oracle.com/pcbpel
/adapter/aq/DequeueReply/#wsdl.interface(Dequeue_ptt)"
xmlns:ns="http://xmlns.oracle.com/sca/1.0"/>
<binding.jca config="CombinedRequestReply_aq.jca"/>
</reference>
Remove any unused WSDL references from the .bpel file.
As described in Section 9.1, "About Using the Oracle JDeveloper 11g Migration Wizard for Oracle SOA Suite Applications", Oracle recommends that you apply the latest patch sets to your Oracle SOA Suite environment and use the latest 10g Release 3 (10.1.3) Oracle JDeveloper before upgrading to 11g.
However, if you are upgrading from 10g Release 3 (10.1.3.3) or earlier, note the following if you are using a database adapter for stored procedures.
In Oracle SOA Suite 10g Release 3 (10.1.3.3) and earlier, the XSD generator of the adapter generated an XSD that contained unqualified elements. You can identify unqualified elements by viewing the InputParameters root element in the XSD file. The unqualified element appears as follows:
<db:InputParameters ... ></db:InputParameters>
The db: namespace is specified in the definition of the schema, which is the same as the target namespace.
In 10g Release 3 (10.1.3.4) and later, the XSD generator generates qualified elements, which appear as follows in the InputParameters root element:
<InputParameters ..></InputParameters>
Note that the db: namespace has been removed.
If you were using a version of Oracle JDeveloper 10g Release 3 (10.1.3) that was incompatible with the Oracle SOA Suite version, you could also encounter a scenario where the elements are removed:
<null>(some value)</null>
The solution is as follows:
First, make sure that you are using a version of Oracle JDeveloper that matches the version of your Oracle SOA Suite environment.
Second, after you upgrade to Oracle JDeveloper and Oracle SOA Suite10g Release 3 (10.1.3.4) or to Oracle SOA Suite and Oracle JDeveloper 11g, regenerate the XSD.
After you upgrade and regenerate the XSD, you must then modify any related assign activities and any xPath expressions accordingly.
The following upgrade tasks should be considered when you are upgrading Oracle SOA Suite applications that use human workflow tasks:
Upgrading Task Details for an Associated Human Workflow Task
Upgrading Multiple Projects That Share a Common Human Workflow Task
When you are upgrading Oracle SOA Suite 10g applications that include task details for a human task, note the following:
In Oracle SOA Suite 10g Release 3 (10.1.3), task details were generated inside same composite project and was deployed during composite deployment.
In Oracle SOA Suite 11g, task details are generated as a separate project that must be deployed separately.
As a result, during the upgrade of Oracle Human Workflow, Oracle JDeveloper 11g automatically creates a new project for the task details UI and upgrades the task detail pages. You must then deploy this project separately, after deploying the associated composite application.
If you are upgrading an application that contains multiple Oracle JDeveloper projects that share a common human workflow task, then be sure to review the upgraded application carefully in Oracle JDeveloper 11g.
In some cases, because the projects are moved into a common directory during the upgrade, data associated with the workflow task in one project may overwrite data from another project if the workflow task in the second project uses the same name.
When you upgrade projects that use Oracle Business Rules, refer to the following documentation resources:
While you are in the process of upgrading your Oracle SOA Suite applications to 11g, and while your Oracle SOA Suite 10g environment is still up and running, you should begin to review, upgrade, and test the client applications that depend upon your Oracle SOA Suite environment.
Use the following list to analyze your client applications for required updates that will allow them to work with your newly upgraded 11g Oracle SOA Suite environment:
Review the client applications to understand which remote Oracle SOA Suite APIs they are using.
For more information, refer to Section 9.3.1, "Understanding Oracle SOA Suite API Changes for Oracle Fusion Middleware 11g".
Search your client applications for any references to Oracle SOA Suite HTTP URLs. The syntax of the Oracle SOA Suite 11g HTTP URLs has changed from 10g.
To obtain the new URL that a client can use to access a deployed Oracle SOA Suite 11g application, use the home page of the application deployment in Oracle Enterprise Manager Fusion Middleware Control. For more information, see "Monitoring SOA Composite Applications" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.
If any of your client applications are using Web Services Addressing (WS-Addressing), then you must modify the client.
Oracle SOA Suite 11g supports WS-Addressing 1.0 for clients. As a result, you must either use a SOAP processor that understands WS-Addressing 1.0, or if you are using a SOAP processor that does not support WS-Addressing 1.0, then you must manually modify the 11g WSDL and change the client to get or set the WS-Addressing 1.0 headers.
Refer to Example 9-5 and Example 9-6 for a before and after example of how to modify a WSDL so it can be invoked by a SOAP processor that does not support WS-Addressing 1.0.
If the clients using WS-Addressing are running on a Oracle SOA Suite 10g environment that you do not plan to upgrade at the same time, then you must apply the following patch to the Oracle SOA Suite environment before the client applications running on the 10g server can invoke 11g BPEL processes.
For more information, see "Applying Patch Sets to Address Specific Upgrade Interoperability Issues" in the Oracle Fusion Middleware Upgrade Planning Guide.
Review your client applications for references to message targets, such as JMS queues and data source. Any references to these resources must be updated to point to the upgraded, Oracle SOA Suite 11g environment.
If a client application is using Oracle Service Bus (OSB) to invoke an Oracle BPEL Process Manager process with the optimized transport, you must modify the client application so it uses SOAP/HTML to invoke the Oracle BPEL Process Manager process.
For more information, see the Oracle Service Bus 10g Release 3 (10.3) documentation, which is available on the Oracle Technology Network (OTN):
http://www.oracle.com/technology/documentation/bea.html
Example 9-5 Example of WSDL Code That Can Be Used by a SOAP Processor that Supports WS-Addressing 1.0
<?xml version="1.0" encoding="UTF-8" ?>
<definitions
name="UnitedLoan"
targetNamespace="http://services.otn.com"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:s1="http://www.autoloan.com/ns/autoloan"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://services.otn.com">
<plnk:partnerLinkType name="UnitedLoan">
<plnk:role name="UnitedLoanProvider">
<plnk:portType name="tns:UnitedLoan"/>
</plnk:role>
<plnk:role name="UnitedLoanRequester">
<plnk:portType name="tns:UnitedLoanCallback"/>
</plnk:role>
</plnk:partnerLinkType>
<wsp:Policy xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="wsaddr_policy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsaw:UsingAddressing xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"/>
</wsp:Policy>
<documentation>
<abstractWSDL>http://stadg55.us.oracle.com:7001/soa-infra/services/default/
UnitedLoan!1.0/UnitedLoan.wsdl
</abstractWSDL>
</documentation>
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://www.autoloan.com/ns/autoloan"
schemaLocation="http://stadg55.us.oracle.com:7001/soa-infra/services/
default/UnitedLoan!1.0*05ed6481-93e6-4b46-b2d7-a21fa27a36a9/
UnitedLoan_client?XSD=AutoLoanTypes.xsd"/>
</schema>
</types>
<message name="UnitedLoanResultMessage">
<part name="payload" element="s1:loanOffer"/>
</message>
<message name="UnitedLoanRequestMessage">
<part name="payload" element="s1:loanApplication"/>
</message>
<portType name="UnitedLoanCallback">
<operation name="onResult">
<input message="tns:UnitedLoanResultMessage"/>
</operation>
</portType>
<portType name="UnitedLoan">
<operation name="initiate">
<input message="tns:UnitedLoanRequestMessage"/>
</operation>
</portType>
<binding name="UnitedLoanBinding" type="tns:UnitedLoan">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
<wsp:PolicyReference
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
URI="#wsaddr_policy" wsdl:required="false"/>
<operation name="initiate">
<soap:operation style="document" soapAction="initiate"/>
<input>
<soap:body use="literal" namespace="http://services.otn.com"/>
</input>
</operation>
</binding>
<binding name="UnitedLoanCallbackBinding"
type="tns:UnitedLoanCallback">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="onResult">
<soap:operation style="document" soapAction="onResult"/>
<input>
<soap:body use="literal" namespace="http://services.otn.com"/>
</input>
</operation>
</binding>
<service name="UnitedLoan">
<port name="UnitedLoanPort" binding="tns:UnitedLoanBinding">
<soap:address
location="http://stadg55.us.oracle.com:7001/soa-infra/services/
default/UnitedLoan!1.0*05ed6481-93e6-4b46-b2d7-a21fa27a36a9/
UnitedLoan_client"/>
</port>
</service>
</definitions>
Example 9-6 Example of WSDL Code Modified So It Can Be Used by a SOAP Processor That Does Not Support WS-Addressing 1.0
<?xml version="1.0" encoding="UTF-8" ?>
<definitions
name="UnitedLoan"
targetNamespace="http://services.otn.com"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s1="http://www.autoloan.com/ns/autoloan"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:tns="http://services.otn.com"
>
<plnk:partnerLinkType name="UnitedLoan">
<plnk:role name="UnitedLoanProvider">
<plnk:portType name="tns:UnitedLoan"/>
</plnk:role>
<plnk:role name="UnitedLoanRequester">
<plnk:portType name="tns:UnitedLoanCallback"/>
</plnk:role>
</plnk:partnerLinkType>
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://www.autoloan.com/ns/autoloan"
schemaLocation="http://stadg55.us.oracle.com:7001/
soa-infra/services/default/
UnitedLoan!1.0*05ed6481-93e6-4b46-b2d7-a21fa27a36a9/
UnitedLoan_client?XSD=AutoLoanTypes.xsd"/>
</schema>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://www.w3.org/2005/08/addressing"
schemaLocation="http://www.w3.org/2006/03/
addressing/ws-addr.xsd"/>
</schema>
</types>
<message name="UnitedLoanResultMessage">
<part name="payload" element="s1:loanOffer"/>
</message>
<message name="UnitedLoanRequestMessage">
<part name="payload" element="s1:loanApplication"/>
</message>
<message name="WSAMessageIDHeader">
<part name="MessageID" element="wsa:MessageID"/>
</message>
<message name="WSAReplyToHeader">
<part name="ReplyTo" element="wsa:ReplyTo"/>
</message>
<message name="WSARelatesToHeader">
<part name="RelatesTo" element="wsa:RelatesTo"/>
</message>
<portType name="UnitedLoanCallback">
<operation name="onResult">
<input message="tns:UnitedLoanResultMessage"/>
</operation>
</portType>
<portType name="UnitedLoan">
<operation name="initiate">
<input message="tns:UnitedLoanRequestMessage"/>
</operation>
</portType>
<binding name="UnitedLoanBinding" type="tns:UnitedLoan">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="initiate">
<soap:operation style="document" soapAction="initiate"/>
<input>
<soap:header message="tns:WSAReplyToHeader"
part="ReplyTo"
use="literal"/>
<soap:header message="tns:WSAMessageIDHeader"
part="MessageID"
use="literal"/>
<soap:body use="literal" namespace="http://services.otn.com"/>
</input>
</operation>
</binding>
<binding name="UnitedLoanCallbackBinding"
type="tns:UnitedLoanCallback">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="onResult">
<soap:operation style="document" soapAction="onResult"/>
<input>
<soap:header message="tns:WSARelatesToHeader"
part="RelatesTo"
use="literal"/>
<soap:body use="literal" namespace="http://services.otn.com"/>
</input>
</operation>
</binding>
<service name="UnitedLoan">
<port name="UnitedLoanPort" binding="tns:UnitedLoanBinding">
<soap:address location="http://stadg55.us.oracle.com:7001/
soa-infra/services/default/
UnitedLoan!1.0*05ed6481-93e6-4b46-b2d7-a21fa27a36a9/
UnitedLoan_client"/>
</port>
</service>
</definitions>
In Oracle WSM 10g, you specify policy steps at each policy enforcement point. Each policy step is a fine-grained operational task that addresses a specific security operation, such as authentication and authorization; encryption and decryption; security signature, token, or credential verification; and transformation. Each operational task is performed on either the Web service request or response.
For more details about the Oracle WSM 10g policy steps, see “Oracle Web Services Manager Policy Steps” in the Oracle Web Services Manager Administrator's Guide in the Oracle Application Server 10g Release 3 (10.1.3.1.0) documentation library at:
http://www.oracle.com/technology/documentation/
In Oracle WSM 11g, you attach policies to Web service endpoints. Each policy consists of one or more assertions, defined at the domain-level, that define the security requirements. A set of predefined policies and assertions are provided out-of-the-box. For more details about the predefined policies, see “Predefined Policy Reference” in Security and Administrator's Guide for Oracle Web Services.
Before you upgrade Oracle WSM policies, you must perform the following tasks:
Install Oracle WSM 11g. For more information, see the Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.
Upgrade your Oracle Containers for J2EE (OC4J) 10g Web services to Oracle WebLogic Server 11g Web services.
For more information, see "Task 6: Upgrade the Application Web Services" in the Oracle Fusion Middleware Upgrade Guide for Java EE.
As described in "Examining the Rearchitecture of Oracle WSM in Oracle Fusion Middleware" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services, Oracle Fusion Middleware 11g Release 1 (11.1.1) does not include a Gateway component.
You can continue to use the Oracle WSM 10g Gateway components with Oracle WSM 10g policies in your applications. For information about Oracle WSM 10g interoperability, see "Interoperability with Oracle WSM 10g Security Environments" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
As described in "Examining the Rearchitecture of Oracle WSM in Oracle Fusion Middleware" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services, Oracle WSM 10g supported policy enforcement for third-party application servers, such as IBM WebSphere and Red Hat JBoss. Oracle Fusion Middleware 11g Release 1 (11.1.1) only supports Oracle WebLogic Server.
You can continue to use the third-party application servers with Oracle WSM 10g policies. For information about Oracle WSM 10g interoperability, see "Interoperability with Oracle WSM 10g Security Environments" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Table 9-3 describes the most common Oracle WSM predefined policy upgrade scenarios based on the following security requirements: authentication and authorization, message protection, transport, and logging. A comparison of the steps required to implement each security requirement in both the Oracle WSM 10g and Oracle WSM 11g environments is provided.
For more information about:
Attaching policies in Oracle Fusion Middleware 11g, see "Attaching Policies to Web Services" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Oracle WSM 10g policy steps, see “Oracle Web Services Manager Policy Steps” in Oracle Web Services Manager Administrator's Guide in the Oracle Application Server 10g Release 3 (10.1.3.1.0) documentation library at:
http://www.oracle.com/technology/documentation/
Table 9-3 Upgrading Oracle WSM 10g Predefined Policies
| Security Requirements | Oracle WSM 10g | Oracle WSM 11g |
|---|---|---|
|
Anonymous authentication with message protection (WS-Security 1.0) |
Attach policy steps as follows:
|
|
|
Anonymous authentication with message integrity (WS-Security 1.0) |
Attach policy steps as follows:
|
|
|
Anonymous authentication with message confidentiality (WS-Security 1.0) |
Attach policy steps as follows:
|
|
|
Username token with message protection (WS-Security 1.0) |
Attach policy steps as follows:
Note: You can substitute File Authenticate with LDAP Authenticate, Oracle Access Manager Authenticate, Active Directory Authenticate, or SetMinder Authenticate. |
|
|
Username token with message protection (WS-Security 1.0) and file authorization |
Attach policy steps as follows:
Note: You can substitute File Authenticate with LDAP Authenticate, Active Directory Authenticate, or SetMinder Authenticate. Similarly, you can substitute File Authorize with LDAP Authorize, Active Directory Authorize, or SetMinder Authorize. |
|
|
ID propagation with SAML token (sender vouches) with message protection (WS-Security 1.0) |
Attach policy steps as follows:
|
|
|
HTTP basic authentication |
Attach policy steps as follows:
|
Attach policies as follows:
|
|
Oracle Access Manager security (WS-Security 1.0) |
Attach policy steps as follows:
|
Attach policies as follows:
|
|
Mutual authentication with message protection (WS-Security 1.0) |
Attach policy steps as follows:
Note: You can substitute File Authenticate with LDAP Authenticate, Oracle Access Manager Authenticate, Active Directory Authenticate, or SetMinder Authenticate. |
|
|
Username token over SSL |
|
|
|
ID propagation with SAML token (sender vouches) over SSL (WS-Security 1.0) |
|
|
|
Log information |
Attach the following policy step to the client or Web service: Log |
Attach the following policy to the client or Web service: oracle/log_policy |
In Oracle WSM 10g, you create, develop, and deploy custom policy steps using the procedures described in the Oracle Web Services Manager Extensibility Guide in the Oracle Application Server 10g Release 3 (10.1.3.1.0) documentation library at:
http://www.oracle.com/technology/documentation/
In Oracle WSM 11g, you create, develop, and deploy custom policy assertions. You will need to redefine your custom policy steps as custom policy assertions using the procedures described in "Creating Custom Assertions" in Security and Administrator's Guide for Oracle Web Services.
In OC4J 10g, you configure your security environment by modifying the contents of the XML-based deployment descriptor files. For complete details about securing OC4J environments, see Oracle Application Server Web Services Security Guide at:
http://www.oracle.com/technology/documentation/
In Oracle WSM 11g, you attach policies to Web service endpoints. Each policy consists of one or more assertions, defined at the domain-level, that define the security requirements. A set of predefined policies and assertions are provided out-of-the-box. For more details about the predefined policies, see “Predefined Policy Reference” in Security and Administrator's Guide for Oracle Web Services.
The following sections describe the most common OC4J upgrade scenarios based on the following security requirements: authentication, message protection, transport, and logging. A comparison of the steps required to implement each security requirement in both the OC4J 10g and Oracle WSM 11g environments is provided.
Section 9.12.2, "Anonymous Authentication with Message Protection (WS-Security 1.0)"
Section 9.12.3, "Anonymous Authentication with Message Integrity (WS-Security 1.0)"
Section 9.12.4, "Anonymous Authentication with Message Confidentiality (WS-Security 1.0)"
Section 9.12.5, "Username Token with Message Protection (WS-Security 1.0)"
Section 9.12.8, "Mutual Authentication with Message Protection (WS-Security 1.0)"
Section 9.12.10, "ID Propagation with SAML Token (Sender Vouches) over SSL (WS-Security 1.0)"
Note:
For information about configuring attaching policies in Oracle Fusion Middleware 11g, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services.The next section describes the prerequisites required before you upgrade.
Before you upgrade the OC4J security environment, you must perform the following tasks:
Install Oracle WSM 11g. For more information, see the Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.
Review "Task 6: Upgrade the Application Web Services" in the Oracle Fusion Middleware Upgrade Guide for Java EE.
This section provides general information about upgrading OC4J Web services to Oracle WebLogic Server.
The following sections describe how to implement authentication with message protection that conforms to the WS-Security 1.0 standard, and compare the steps required for the OC4J 10g and Oracle WSM 11g environments.
Edit the deployment descriptors for the Web service and client, as described in the following sections.
For more information about the deployment descriptor elements, see "OracleAS Web Services Security Schema" in Oracle Application Server Web Services Security Guide in the Oracle Application Server 10g Release 3 (10.1.3.1.0) documentation library at:
http://www.oracle.com/technology/documentation/
Web Service Client (with sample data)
Define the <signature> and <encrypt> elements in the client deployment descriptor. For example:
<signature> <signature-method>RSA-SHA1</signature-method> <tbs-elements> <tbs-element local-part="Body" name-space= "http://schemas.xmlsoap.org/soap/envelope/" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> </tbs-elements> <add-timestamp created="true" expiry="28800" /> </signature> <encrypt> <recipient-key alias="orakey"/> <encryption-method>AES-128</encryption-method> <keytransport-method>RSA-OAEP-MGF1P</keytransport-method> <tbe-elements> <tbe-element local-part="Body" name-space= "http://schemas.xmlsoap.org/soap/envelope/" mode="CONTENT" /> </tbe-elements> </encrypt>
Web Service (with sample data)
Define the <verify-signature> and <decrypt> elements in the service deployment descriptor. For example:
<verify-signature> <tbs-elements> <tbs-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> </tbs-elements> <verify-timestamp expiry="28800" created="true" /> </verify-signature> <decrypt> <tbe-elements> <tbe-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" mode="CONTENT" /> </tbe-elements> </decrypt>
Perform the following steps:
Attach policies as follows:
Client: oracle/wss10_message_protection_client_policy.
Web service: oracle/wss10_message_protection_service_policy.
For more information about attaching policies in Oracle Fusion Middleware 11g, see "Attaching Policies to Web Services" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Leave the configuration set for message body signing and encryption.
The following sections describe how to implement authentication with message integrity that conforms to the WS-Security 1.0 standard, and compare the steps required for the OC4J 10g and Oracle WSM 11g environments.
Edit the deployment descriptors for the Web service and client, as described in the following sections.
For more information about the deployment descriptor elements, see "OracleAS Web Services Security Schema" in Oracle Application Server Web Services Security Guide in the Oracle Application Server 10g Release 3 (10.1.3.1.0) documentation library at:
http://www.oracle.com/technology/documentation/
Web Service Client (with sample data)
Define the <signature> element in the client deployment descriptor. For example:
<signature> <signature-method>RSA-SHA1</signature-method> <tbs-elements> <tbs-element local-part="Body" name-space= "http://schemas.xmlsoap.org/soap/envelope/" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> </tbs-elements> <add-timestamp created="true" expiry="28800" /> </signature>
Web Service (with sample data)
Define the <verify-signature> element in the service deployment descriptor. For example:
<verify-signature> <tbs-elements> <tbs-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> </tbs-elements> <verify-timestamp expiry="28800" created="true" /> </verify-signature>
Perform the following steps:
Attach policies as follows:
Client: oracle/wss10_message_protection_client_policy.
Web service: oracle/wss10_message_protection_service_policy.
For more information about attaching policies in Oracle Fusion Middleware 11g, see "Attaching Policies to Web Services" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Configure the policy assertion for message body signing only.
The following sections describe how to implement authentication with message confidentiality that conforms to the WS-Security 1.0 standard, and compare the steps required for the OC4J 10g and Oracle WSM 11g environments.
For more information about the deployment descriptor elements, see "OracleAS Web Services Security Schema" in Oracle Application Server Web Services Security Guide in the 10g Release 3 (10.1.3.1.0) documentation library at:
http://www.oracle.com/technology/documentation/
Edit the deployment descriptors for the Web service and client, as described in the following sections.
Web Service Client (with sample data)
Define the <encrypt> element in the client deployment descriptor. For example:
<encrypt> <recipient-key alias="orakey"/> <encryption-method>AES-128</encryption-method> <keytransport-method>RSA-OAEP-MGF1P</keytransport-method> <tbe-elements> <tbe-element local-part="Body" name-space= "http://schemas.xmlsoap.org/soap/envelope/" mode="CONTENT" /> </tbe-elements> </encrypt>
Web Service (with sample data)
Define the <decrypt> element in the service deployment descriptor. For example:
<decrypt> <tbe-elements> <tbe-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" mode="CONTENT" /> </tbe-elements> </decrypt>
Perform the following steps:
Attach policies as follows:
Client: oracle/wss10_message_protection_client_policy.
Web service: oracle/wss10_message_protection_service_policy.
For more information about attaching policies in Oracle Fusion Middleware 11g, see "Attaching Policies to Web Services" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Configure the policy assertion for message body encryption only.
The following sections describe how to implement username token with message protection that conforms to the WS-Security 1.0 standard, and compare the steps required in the OC4J 10g and Oracle WSM 11g environments.
Edit the deployment descriptors for the Web service and client, as described in the following sections.
For more information about the deployment descriptor elements, see "OracleAS Web Services Security Schema" in Oracle Application Server Web Services Security Guide in the 10g Release 3 (10.1.3.1.0) documentation library at:
http://www.oracle.com/technology/documentation/
Web Service Client (with sample data)
Define the <username-token>, <signature>, and <encrypt> elements in the client deployment descriptor. For example:
<username-token password-type="PLAINTEXT" add-nonce="false" add-created="false" /> <signature> <signature-method>RSA-SHA1</signature-method> <tbs-elements> <tbs-element local-part="Body" name-space= "http://schemas.xmlsoap.org/soap/envelope/"/> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" local-part="UsernameToken" /> </tbs-elements> <add-timestamp created="true" expiry="28800" /> </signature> <encrypt> <recipient-key alias="orakey" /> <encryption-method>AES-128</encryption-method> <keytransport-method>RSA-OAEP-MGF1P</keytransport-method> <tbe-elements> <tbe-element local-part="Body" name-space= "http://schemas.xmlsoap.org/soap/envelope/" mode="CONTENT" /> <tbe-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" local-part="UsernameToken" /> </tbe-elements> </encrypt>
Web Service (with sample data)
Define the <verify-username-token>, <verify-signature>, and <decrypt> elements in the service deployment descriptor. For example:
<verify-username-token password-type="PLAINTEXT" require-nonce="false" require-created="false" /> <verify-signature> <tbs-elements> <tbs-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> </tbs-elements> <verify-timestamp expiry="28800" created="true" /> </verify-signature> <decrypt> <tbe-elements> <tbe-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" mode="CONTENT" /> </tbe-elements> </decrypt>
Perform the following steps:
Attach policies as follows:
Client: oracle/wss10_username_token_with_message_protection_client_policy.
Web service: oracle/wss10_username_token_with_message_protection_service_policy.
For more information about attaching policies in Oracle Fusion Middleware 11g, see "Attaching Policies to Web Services" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Leave the configuration set for message body signing and encryption.
Configure the Authentication and Identity Assertion provider.
The following sections describe how to implement ID propagation using SAML token sender vouches with message protection that conforms to the WS-Security 1.0 standard, and compare the steps required in the OC4J 10g and Oracle WSM 11g environments.
For more information about the deployment descriptor elements, see "OracleAS Web Services Security Schema" in Oracle Application Server Web Services Security Guide 10g (10.1.3.1.0) at:
http://www.oracle.com/technology/documentation/
Edit the deployment descriptors for the Web service and client, as described in the following sections.
Web Service Client (with sample data)
Define the <saml-token>, <signature>, and <encrypt> elements in the client deployment descriptor. For example:
<saml-token issuer-name="www.oracle.com" name="weblogic" name-format="UNSPECIFIED"> <subject-confirmation-method> <confirmation-method>SENDER-VOUCHES</confirmation-method> </subject-confirmation-method> </saml-token> <signature> <signature-method>RSA-SHA1</signature-method> <tbs-elements> <tbs-element local-part="Body" name-space="http://schemas.xmlsoap.org/soap/envelope/" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> </tbs-elements> <add-timestamp created="true" expiry="28800" /> </signature> <encrypt> <recipient-key alias="orakey" /> <encryption-method>AES-128</encryption-method> <keytransport-method>RSA-OAEP-MGF1P</keytransport-method> <tbe-elements> <tbe-element local-part="Body" name-space= "http://schemas.xmlsoap.org/soap/envelope/" mode="CONTENT" /> </tbe-elements> </encrypt>
Web Service (with sample data)
Define the <verify-saml-token>, <verify-signature>, and <decrypt> elements in the service deployment descriptor. For example:
<verify-saml-token> <subject-confirmation-methods> <confirmation-method>SENDER-VOUCHES</confirmation-method> </subject-confirmation-methods> </verify-saml-token> <verify-signature> <tbs-elements> <tbs-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> </tbs-elements> <verify-timestamp expiry="28800" created="true" /> </verify-signature> <decrypt> <tbe-elements> <tbe-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" mode="CONTENT" /> </tbe-elements> </decrypt>
Attach policies as follows:
Client: oracle/wss10_saml_token_with_message_protection_client_policy.
Web service: oracle/wss10_saml_token_with_message_protection_service_policy.
For more information about attaching policies in Oracle Fusion Middleware 11g, see "Attaching Policies to Web Services" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
The following sections describe how to implement ID propagation using SAML token holder of key with message protection that conforms to the WS-Security 1.0 standard, and compare the steps required in the OC4J 10g and Oracle WSM 11g environments.
For more information about the deployment descriptor elements, see "OracleAS Web Services Security Schema" in Oracle Application Server Web Services Security Guide in the 10g Release 3 (10.1.3.1.0) documentation library at:
http://www.oracle.com/technology/documentation/
Edit the deployment descriptors for the Web service and client, as described in the following sections.
Web Service Client (with sample data)
Define the <saml-token>, <signature>, and <encrypt> elements in the client deployment descriptor. For example:
<saml-token issuer-name="www.oracle.com" name="weblogic" name-format="UNSPECIFIED"> <subject-confirmation-method> <confirmation-method>HOLDER-OF-KEY</confirmation-method> </subject-confirmation-method> </saml-token> <signature> <signature-method>RSA-SHA1</signature-method> <tbs-elements> <tbs-element local-part="Body" name-space="http://schemas.xmlsoap.org/soap/envelope/" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> </tbs-elements> <add-timestamp created="true" expiry="28800" /> </signature> <encrypt> <recipient-key alias="orakey" /> <encryption-method>AES-128</encryption-method> <keytransport-method>RSA-OAEP-MGF1P</keytransport-method> <tbe-elements> <tbe-element local-part="Body" name-space= "http://schemas.xmlsoap.org/soap/envelope/" mode="CONTENT" /> </tbe-elements> </encrypt>
Web Service (with sample data)
Define the <verify-saml-token>, <verify-signature>, and <decrypt> elements in the service deployment descriptor. For example:
<verify-saml-token> <subject-confirmation-methods> <confirmation-method>HOLDER-OF-KEY</confirmation-method> </subject-confirmation-methods> </verify-saml-token> <verify-signature> <tbs-elements> <tbs-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> </tbs-elements> <verify-timestamp expiry="28800" created="true" /> </verify-signature> <decrypt> <tbe-elements> <tbe-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" mode="CONTENT" /> </tbe-elements> </decrypt>
Attach policies as follows:
Client: oracle/wss10_saml_hok_with_message_protection_client_policy.
Web service: oracle/wss10_saml_hok_with_message_protection_service_policy.
For more information about attaching policies in Oracle Fusion Middleware 11g, see "Attaching Policies to Web Services" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
The following sections describe how to implement mutual authentication with message protection that conforms to the WS-Security 1.0 standard, and compare the steps required in the OC4J 10g and Oracle WSM 11g environments.
For more information about the deployment descriptor elements, see "OracleAS Web Services Security Schema" in Oracle Application Server Web Services Security Guide in the 10g Release 3 (10.1.3.1.0) documentation library at:
http://www.oracle.com/technology/documentation/
Edit the deployment descriptors for the Web service and client, as described in the following sections.
Web Service Client (with sample data)
Define the <x509-token>, <signature>, and <encrypt> elements in the client deployment descriptor. For example:
<x509-token /> <signature> <signature-method>RSA-SHA1</signature-method> <tbs-elements> <tbs-element local-part="Body" name-space="http://schemas.xmlsoap.org/soap/envelope/" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> </tbs-elements> <add-timestamp created="true" expiry="28800" /> </signature> <encrypt> <recipient-key alias="orakey" /> <encryption-method>AES-128</encryption-method> <keytransport-method>RSA-OAEP-MGF1P</keytransport-method> <tbe-elements> <tbe-element local-part="Body" name-space="http://schemas.xmlsoap.org/soap/envelope/" mode="CONTENT" /> </tbe-elements> </encrypt>
Web Service (with sample data)
Define the <verify-x509-token>, <verify-signature>, and <decrypt> elements in the service deployment descriptor. For example:
<verify-x509-token /> <verify-signature> <tbs-elements> <tbs-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" /> <tbs-element name-space= "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" local-part="Timestamp" /> </tbs-elements> <verify-timestamp expiry="28800" created="true" /> </verify-signature> <decrypt> <tbe-elements> <tbe-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body" mode="CONTENT" /> </tbe-elements> </decrypt>
Perform the following steps:
Attach policies as follows:
Client: oracle/wss10_x509_token_with_message_protection_client_policy.
Web service: oracle/wss10_x509_token_with_message_protection_service_policy.
For more information about attaching policies in Oracle Fusion Middleware 11g, see "Attaching Policies to Web Services" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Leave the configuration set for message body signing and encryption.
Configure the Authentication and Identity Assertion provider.
The following sections describe how to implement username token over SSL, and compare the steps required in the OC4J 10g and Oracle WSM 11g environments.
For more information about the deployment descriptor elements, see "OracleAS Web Services Security Schema" in Oracle Application Server Web Services Security Guide in the 10g Release 3 (10.1.3.1.0) documentation library at:
http://www.oracle.com/technology/documentation/
Configure the application server for SSL and edit the deployment descriptors for the Web service and client, as described in the following sections.
Web Service Client (with sample data)
Define the <username-token> and <signature> elements in the client deployment descriptor. For example:
<username-token password-type="PLAINTEXT" add-nonce="true" add-created="true" /> <signature> <add-timestamp created="true" expiry="28800" /> </signature>
Web Service (with sample data)
Define the <verify-username> element in the service deployment descriptor. For example:
<verify-username-token password-type="PLAINTEXT" require-nonce="false" require-created="false" /> <signature> <verify-timestamp expiry="28800" created="true" /> </signature>
Perform the following step:
Configure the application server for SSL.
Attach policies as follows:
Client: oracle/wss_username_token_over_ssl_client_policy.
Web service: oracle/wss_username_token_over_ssl_service_policy
For more information about attaching policies in Oracle Fusion Middleware 11g, see "Attaching Policies to Web Services" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
The following sections describe how to implement ID propagation with SAML token sender vouches over SSL that conforms to WS-Security 1.0, and compare the steps required in the OC4J 10g and Oracle WSM 11g environments.
For more information about the deployment descriptor elements, see "OracleAS Web Services Security Schema" in Oracle Application Server Web Services Security Guide in the 10g Release 3 (10.1.3.1.0) documentation library at:
http://www.oracle.com/technology/documentation/
Configure the application server for SSL and edit the deployment descriptors for the Web service and client, as described in the following sections.
Web Service Client (with sample data)
Define the <saml-token> and <signature> elements in the client deployment descriptor. For example:
<saml-token name="weblogic" issuer-name="www.oracle.com" name-format="UNSPECIFIED"> <subject-confirmation-method> <confirmation-method>SENDER-VOUCHES</confirmation-method> </subject-confirmation-method> </saml-token> <signature> <add-timestamp created="true" expiry="28800" /> </signature>
Web Service (with sample data)
Define the <verify-saml-token> element in the service deployment descriptor. For example:
<verify-saml-token> <subject-confirmation-methods> <confirmation-method>SENDER-VOUCHES-UNSIGNED</confirmation-method> </subject-confirmation-methods> </verify-saml-token> <signature> <verify-timestamp expiry="28800" created="true" /> </signature>
The following sections describe how to enable the collection of log information, and compare the steps required in the OC4J 10g and Oracle WSM 11g environments.
Attach the following policy to the Web service or client: oracle/log_policy.
For more information about attaching policies in Oracle Fusion Middleware 11g, see "Attaching Policies to Web Services" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.