Web services migration best practices

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.

Table 1.

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	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 V4.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 V6 applications based on WS-Security.

Follow these best practices for the most optimal migration experience:

Migrating a V5 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 executed on WebSphere Application Server V5, can use SOAP over JMS to invoke a Web service that is executed on a V5 application server. A user ID and password are not required on the target WebSphere MQ queue. After the application server 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 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 administrative console. To disable administrative and application security, click Security > Secure administration, applications and infrastructure. 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 you can configure in V5.

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

Migrating 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.

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

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

.

Related information

Reference topic