Web services migration best practices
Use these web services migration best practices when migrating web services applications.
If we have used the Apache SOAP support to develop web services client applications in WebSphere Application Server Versions 4, 5, or 5.1, we might need to migrate the applications or the security files for the applications. The following table summarizes the web services specifications supported by the WebSphere products.
supported by WebSphere Application Server . The product supports the web services specifications
WebSphere Application Server Version Web services specifications supported 4.0 Apache SOAP 2.2 5.0 and 5.0.1 Apache SOAP 2.3 5.0.2 or later Java 2 Platform, Enterprise Edition (J2EE), also known as (JSR 109) 6.0.x and 6.1 J2EE (JSR 109) 7.0 or later Web Services for Java EE 5 also known as JSR 109
Supported configurations: The Apache SOAP 2.2 and Apache SOAP 2.3-based implementations that were available in WebSphere Application Server Version 4.0.x, 5.0 and 5.0.1 are no longer supported. IBM recommends that applications that are using these SOAP implementations migrate to Web Services for Java EE (JSR 109) support provided in current WebSphere Application Server versions.
For more information on migrating the web services, read about migrating Apache SOAP web services to JAX-RPC web services based on Java EE standards.
IBM recommends that new web services be developed using the web services for Java EE specification. To learn more, read about implementing web services applications.
Security cannot be directly migrated from SOAP 2.3 to the Java EE standards. After you have migrated the web services to the Java EE standards, consider securing the web services applications. To learn more, read about securing web services applications using message level security.
Follow these best practices for the most optimal migration experience:
The application server supports the JAX-WS programming model and the Java API for XML-based RPC (JAX-RPC) programming model. JAX-WS is the next generation web services programming model extending the foundation provided by the JAX-RPC programming model.
Existing JAX-RPC applications wanting to use JAX-WS features must be rewritten using the JAX-WS programming model.
Redeploy existing JAX-RPC web services after migrating to a new release of the application server
When migrating to a new release of the application server, IBM recommends that you redeploy the web services applications. You should redeploy the web services application in the new application server environment because of possible changes to the supported levels of web services specifications and web services deployment descriptors in each release. To redeploy the web service, select Deploy Web Services in the Install New Application wizard or use the wsdeploy command. To learn more about this process, see the deploying web services applications onto application servers documentation.
Migrate a 32-bit WebSphere Application Server environment to be compatible with 64-bit
If we are using web services that are implemented on a WAS 32-bit environment, make sure the web services are compatible with a 64-bit environment. For a pure Java application this is not an issue. However, if the application code utilizes the Java Native Interface (JNI) code, you should be aware of the following: the JNI enables the Java code running in a virtual machine to operate with applications and libraries written in other languages, such as C, C++, and assembly. If the Java EE application uses JNI in a 32-bit environment, the code must be re-compiled in the 64-bit environment. It is possible that the JNI calls can be different after the compilation, as the JNI specifications can change from version to version.
Migrate a Version 5 Java API for XML-based remote procedure call (JAX-RPC) client that uses SOAP over Java Message Service (JMS) to invoke a web service
A JAX-RPC client that is run on WebSphere Application Server Version 5, can use SOAP over JMS to invoke a web service that is run on a Version 5 Application Server.
A user ID and password are not required on the target WebSphere MQ queue. After the application server is migrated to Version 6.x, and uses the Version 6.x default messaging feature, client requests can fail because basic authentication is enabled. The following error message displays when this migration problem occurs:
SibMessage W [:] CWSIT0009W: A client request failed in the application server with endpoint <endpoint name> in bus <bus_name> with reason: CWSIT0016E: The user ID null failed authentication in bus <bus_name>.
When the application server is migrated to Version 6.x, and the default messaging provider (service integration technologies) is used, and administrative and application security is enabled for the server or the cell, the service integration bus queue destination inherits the security characteristics of the server or the cell by default. If the server or the cell has basic authentication enabled, the client request fails.
The following options are available to solve this problem. The solutions are listed by the level of security that they impose:
- Disable administrative and application security on the main security panel within the console. To disable administrative and application security, click Security > Global security. Deselect the Enable administrative security and Enable application security options.
- Modify the settings for the service integration bus that hosts the queue destination so that the bus security is disabled and the bus does not inherit security characteristics from the server or the cell. This option is equivalent to the level of security that we can configure in Version 5.
- Configure the basic authentication on each client that uses the service. To learn more, see the information on configuring HTTP basic authentication for JAX-RPC web services with the console.
Migrate Apache SOAP web services
We can migrate web services that were developed using Apache SOAP to web services developed based on the Web Services for J2EE specification. See the information on migrating Apache SOAP web services to JAX-RPC web services based on Java EE standards.
Migrate web services assembled with early versions of the Application Server Toolkit or Assembly Toolkit
If we are migrating the web service or web service components from earlier versions of the Application Server Toolkit or Assembly Toolkit, refer to the following hints and tips to improve the success:
- Secure web services are not migrated by the J2EE Migration Wizard when web services are migrated from J2EE 1.3 to J2EE 1.4.
- The migration of secure web services requires manual steps.
- After the J2EE migration, the secure binding and extension files must be migrated manually to J2EE 1.4 as follows:
- Double click on the webservices.xml file to open the web services editor.
- Select the Binding Configurations tab to edit the binding file.
- Add all the necessary binding configurations under the new sections Request Consumer Binding Configuration Details and Response Generator Binding Configuration Details.
- Select the Extension tab to edit the extension file.
- Add all the necessary extension configurations under the new sections Request Consumer Service Configuration Details and Response Generator Service Configuration Details.
- Save and exit the editor.
Migrate a pre-8.5 WebSphere Application Server node to 8.5 or later
When a customer migrates a pre-8.5 WebSphere Application Server node to 8.5 or later, the following error might be displayed in the deployment manager's JVM log file:[7/31/12 14:48:34:323 CDT] 0000043f EditionHelper E Unexpected Error: ibmasyncrsp -- The Application's Directory in the Repository is EMPTY. [7/31/12 14:48:34:339 CDT] 0000043f FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on c:\opt\WAS85\profiles\dmgr.xd61\logs\ffdc\dmgr_483a68e7_12.07.31_188.8.131.5296174315962980574983.txt com.ibm.ws.xd.appeditionmgr.EditModuleTargetsTaskHandler 104 [7/31/12 14:48:34:339 CDT] 0000043f EditModuleTar E ERROR_IN_EDIT_MODULE_TARGETS_TASK_HANDLER
This error is only displayed if there are application servers other than WebSphere application servers that are federated into the cell. The message is logged regarding the ibmasyncrsp.ear file, which is an internal, system application used by the application server's internal JAX-WS engine. Since the JAX-WS engine has no relevance to the application servers other than WebSphere application servers, there is no functionality disruption. The message can be ignored.
Overview of standards and programming models for web services message-level security
Task overview: Implement web services applications Migrate Apache SOAP web services to JAX-RPC web services based on Java EE standards Configure HTTP basic authentication for JAX-RPC web services with the administrative console Deploy web services applications onto application servers
Web services specifications and APIs