Web services migration best practices

 

+

Search Tips   |   Advanced Search

 

If you have used the Apache SOAP support to develop Web services client applications in WAS Vs 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.

WAS V 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 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 WAS V4.0.x, 5.0 and 5.0.1 have been deprecated. IBM recommends that applications that are using these SOAP implementations migrate to Web Services for J2EE (JSR 109) support that is provided in current WAS versions.

IBM recommends that new Web services be developed using the Web services for J2EE specification.

Security cannot be directly migrated from SOAP 2.3 to the J2EE standards.

Follow these best practices for the most optimal migration experience:

 

Migrate a 32-bit WAS environment to be compatible with 64-bit

If you 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 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.

 

Migrate a V5 JAX-RPC client that uses SOAP over JMS to invoke a Web service

A JAX-RPC client that is executed on WAS V5, can use SOAP over JMS to invoke a Web service that is executed on a V5 appserver. A user ID and password are not required on the target WebSphere MQ queue. After the appserver is migrated to V6.x, and uses the V6.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 appserver with endpoint <endpoint name> in bus <bus_name> with reason: CWSIT0016E: The user ID null failed authentication in bus <bus_name>.

When the appserver is migrated to V 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:

 

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 J2EE specification.

 

Migrate Web services assembled with early versions of the Application Server Toolkit or Assembly Toolkit

If you are migrating your 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 your success:

.


 

Related information

Task overview: Implement Web services applications
Migrate Apache SOAP Web services to Web Services for J2EE standards
Configure HTTP basic authentication with the console
Web services: Resources for learning