WebSphere Application Server & Liberty

 View Only

Modernizing JAX-RPC applications

By Cheryl King posted Thu March 24, 2022 04:44 PM


For the last several years, we’ve been focusing on providing a variety of tools that help traditional WebSphere customers streamline the migration process to Liberty. While our tools have helped a large portion of customers on their migration journey, one major roadblock remains: JAX-RPC. The JAX-RPC technology is not supported on Liberty, but many other web service technologies are supported such as JAX-RS and JAX-WS.

So we set out to develop a tool to modernize JAX-RPC applications with one goal in mind: automate as much of the JAX-RPC related application changes as possible. We met that goal by designing a tool that replaces JAX-RPC with JAX-WS, which is the successor to JAX-RPC. There were a few ways we could achieve this, and the following options were considered:

  1. Runtime byte code rewrite from JAX-RPC to JAX-WS
  2. Build time byte code rewrite from JAX-RPC to JAX-WS
  3. Source code rewrite from JAX-RPC to JAX-WS

Before we dive into the pros and cons of each option, it’s important to address a request we have received a lot over the years: a JAX-RPC feature on Liberty. There are a variety of reasons why we’ve not gone that route, but the biggest reason, and probably the most important for our users, is the integrity of our product. There are no longer any active open-source communities working on JAX-RPC implementations. When we compare that to the Apache CXF implementation used by Liberty’s JAX-WS feature, it’s clear that relying on and contributing back to active open-source communities helps maintain a more secure and reliable platform for our users.

Runtime byte code rewrite

With a runtime byte code rewrite from JAX-RPC to JAX-WS, all applications would need to be analyzed at load time to determine whether they contain JAX-RPC web service providers and/or consumers. If the use of JAX-RPC was detected, the JAX-WS stubs would need to be generated on the fly, merged with the business logic, and somehow tied to the loaded application. Client code would need to be shimmed to utilize the JAX-WS stubs underneath. Plus, the JAX-WS feature would need to be enabled in the server if it was not already. Whenever a request came in for the JAX-RPC web service, it would need to be intercepted and rerouted to the JAX-WS web service and vice versa for the client.

The Pros:

The upside of this approach would be that the application developer wouldn’t have to do anything to their JAX-RPC application to run on it Liberty.

The Cons:

This approach would not only create a huge impact on application start-up times, it would also drag performance on the inbound-outbound flow for each web service request and response due to the message interception. This implementation would seriously slow down the application load time and potentially the throughput of the application. Also, the application may not be able to be converted to JAX-WS depending on the contents of the WSDL and could fail at deployment time, or worse, at runtime.

Build time byte code rewrite

A build time byte code rewrite would analyze the already built application and determine whether it could be converted to use JAX-WS. If not, the tool would generate error messages that indicate what prevents the application from being converted, enabling the application developer to potentially modify the application to allow conversion. If the application could be converted, all necessary changes would be completed using byte code injection, resulting in a repackaged application ready to deploy onto Liberty. Any changes made to the application could be detailed through logging, thereby giving the application developer insight into what was modified during the conversion.

The Pros:

The converted applications would benefit from the improved load time and throughput inherent to JAX-WS and Liberty. Also, any problems preventing a conversion would be identified at build time rather than deployment time. The original source code would not be required to convert the application, and lastly all JAX-RPC references would be removed from the application.

The Cons:

The application developer would need to add something to their build pipeline to convert their application before deploying to Liberty. Also, a minimal shim layer would still be required in order to maintain continuity of behavior between JAX-RPC and JAX-WS method signature changes. However, since this shim layer would be integrated into the application itself, it would no longer impact start up time or throughput for the app.

Source code rewrite

A source code rewrite by a migration tool would be significantly more complex than the other two options. First, the JAX-WS stubs would need to be generated from the WSDL. Second, all code changes and deployment descriptor changes would need to be identified and interlinked. If the application developer accepted one change in one class file or deployment descriptor file, all related and required changes in other files would need to be applied at the same time. There would also be files that would need to be deleted from the application. Finally, some additional classes would need to be generated and made part of the application source in order to minimize the changes needed in the application code.

The Pros:

There are two main benefits of this approach. First, the application developer would be involved in and aware of the changes being made to the application. Second, the changes would be present in the source code making it easier to maintain and modify the application going forward.

The Cons:

First, the source code would be required. Second, an application developer that knows the application well would need to be intimately involved in applying the changes to the application. Also, there would be a danger that only part of the necessary changes are applied to the application. Finally, if any of the generated classes were modified or removed, the application would not function properly.

WebSphere Liberty JAX-RPC Conversion Tool for Maven and Gradle

The recently released WebSphere Liberty JAX-RPC Conversion Tool utilizes option 2 – build time byte code rewrite. We felt it provided the best path forward for several reasons. First, it does not require the source code or significant involvement from the application developer. Second, it should only impact the application load time and throughput positively, not negatively. Finally, it provides the best chance at producing a converted application that runs correctly since all changes are identified and applied at once.

One benefit we mentioned earlier for option 2 is that the conversion tool can validate whether a traditional WebSphere application that uses JAX-RPC technology can be converted into an application that uses JAX-WS technology. This is done by validating the WSDL files used by the application. If the application passes validation, the tool can convert the application binary to use JAX-WS so that it can run on Liberty.

When moving any application from traditional WebSphere to Liberty, it’s important to note that the first step should be to analyze the application with a tool like IBM Cloud Transformation Advisor or the Migration Toolkit for Application Binaries to identify other changes needed unrelated to JAX-RPC. Once those changes are made, simply add a step to the build pipeline to run our Maven or Gradle plugin before deploying the converted application to Liberty.

Visit our support page to download the build tool of your choice and give it a try! For an in-depth discussion with the lead architect and designers of the tool, view our IBM Expert TV session - App Transformers - Modernizing JAX-RPC without source code changes.