Web services migration best practices

This topic presents best practices when migrating Web services applications.

 

Migrate a 32-bit

WebSphere Application Server environment to be compatible with 64-bit

If you are using Web services that are implemented on a WebSphere Application Server 32-bit environment, we 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. So, 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 Java API for XML-based remote procedure call (JAX-RPC) client running on WebSphere Application Server V5, can use SOAP over Java Messaging Service to invoke a Web service that is running on a V5 application server.

A user ID and password are not required on the target MQ Series queue. After the application server is migrated to V6, and uses the V6 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 V6, 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.

The following options are available to solve this problem. The solutions are listed by the level of security that they impose:

  • Disable global security on the Global security panel within the administrative console. To disable global security, click Security > Global security. Deselect the Enable global security option.

  • 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 one can configure in V5.

  • Configure the basic authentication on each client that uses the service.

 

Migrate Apache SOAP Web services

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 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:

  • 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:

    1. Double click on the webservices.xml file to open the Web Services editor.

    2. Select the Binding Configurations tab to edit the binding file.

    3. Add all the necessary binding configurations under the new sections Request Consumer Binding Configuration Details and Response Generator Binding Configuration Details.

    4. Select the Extension tab to edit the extension file.

    5. Add all the necessary extension configurations under the new sections Request Consumer Service Configuration Details and Response Generator Service Configuration Details.

    6. Save and exit the editor.

.