This topic presents best practices for migrating Web services applications.
If you have used the Apache SOAP support to develop Web services client applications in WebSphere Application Server Versions 4, 5, or 5.1, you might need to migrate your applications or the security files for your applications. The following table summarizes the Web services specifications supported by the WebSphere products.
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) |
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 have been deprecated. It is recommended that applications that are using these SOAP implementations migrate to Web Services for J2EE (JSR 109) support that is provided in current WebSphere Application Server versions.
For more information on migrating your Web services, see Migrating Apache SOAP Web services to Web Services to J2EE standards .
It is recommended that new Web services be developed using the Web services for J2EE specification. For more information, see Task overview: Implementing Web services applications.
Security cannot be directly migrated from SOAP 2.3 to the J2EE standards. After you have migrated your Web services to the J2EE standards, see Securing Web services for Version 6 applications based on WS-Security.
Follow these best practices for the most optimal migration experience:
If you are using Web services that are implemented on a WebSphere Application Server 32-bit environment, you need to make sure the Web services are compatible with a 64-bit environment. For a pure Java application this is not an issue. However, if your application code utilizes the Java Native Interface (JNI) code, you should be aware of the following: the JNI allows Java code running in a virtual machine to operate with applications and libraries written in other languages, such as C, C++, and assembly. Therefore, if your J2EE application uses JNI in a 32-bit environment, your code must be re-compiled in the 64-bit environment. It is possible that the JNI calls could be different after the compilation, as the JNI specifications can change from version to version.
A JAX-RPC client that is executed on WebSphere Application Server Version 5, can use SOAP over JMS to invoke a Web service that is executed on a Version 5 application server.
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.0.x, and the default messaging provider (service integration technologies) is used, and global 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.
See Migrating Apache SOAP Web services to Web Services for J2EE standards to learn how to migrate Apache SOAP Web services. This topic explains how to migrate Web services that were developed using Apache SOAP to Web services that are developed based on the Web Services for Java 2 Platform, Enterprise Edition (J2EE) specification.