One potential issue that I immediately come to think of is that JAX-WS web service stacks use JAXB for XML marshalling and unmarshalling, which JAX-RPC uses an API being part of the web service stack itself(?). The important think to note is that there are different APIs for marshalling and unmarshalling. This may lead to unexpected results.
If I were to consider keeping the JAX-RPC client, I would at least make sure that the communication with the JAX-WS web service is without problems, by testing thoroughly.
I do not know what the functional and/or technical aspects of your JAX-WS web service involved.
But as an Imaginary consumer to your service, I have some questions out of curiosity:
1. Even if JAX-RPC client is testing as suggested and working perfectly as of today.
Would that means the JAX-RPC client and JAX-WS service have common supported Data type
regardless of the underlying XML ser/des (marshall/unmarshall) mechanism OR it works by chance and not by design.
Unless the JAX-WS web service is static for ever, some questions (or obvious) need to be answered because things change
2. Data type aspect:
What happen if there is a change: a new field/property/element in the request
Let's say a data type that JAX-WS supports and is not supported by JAX-RPC client, then what happen in this use case?
3. Binding type aspect:
What happen if there is a change: a new attachment in the request
Let's say JAX-WS support MTOM whereas JAX-RPC won't, would the JAX-WS has MTOM disabled for the sake of the JAX-RPC client?
4. Contract type aspect:
If the intention is to support JAX-RPC client at all cost for business reason, would that imply JAX-WS a dummy JAX-RPC?
i.e, a developer who is supposed to use JAX-WS now has to know and/learn JAX-RPC (hopefully not a lot)
to support the backward compatibility aspect.
One of our consumer is an existing portal application running on WebSphere Portal v 6.1. To consume a JAX-WS client created using WebSphere runtime, IBM recommends Web Services Feature pack to be installed however this feature pack is not compatible with portal server version.
Trying to use JAX-RPC client for a JAX-WS service failed due to various data type issues. Even if we write a data mapper to convert the data types returned from JAX-WS to JAX-RPC, we foresee issues going forward.
So Web Services client was generated using Apache CXF, deployed on WebSphere Portal server with the configuration to force consumer application to use CXF runtime while hitting the service. This approach worked well after passing the huddles of resolving various jar conflicts.