0

  1. We have a web service running on an old version of an application server. It this old application server is running on JAVA EE 1.4. Its clients are on another server also running on the same version of the application server.

  2. The move to upgrade our application server has started. The new version now will run on Java EE 6. The thing is, the clients would still run on the old version. Would it still be able to access the web service that will now be running on Java EE 6?

If yes is the answer to #2, I have a follow up question below

  1. Our web service will now be created using JAX-WS. Does that mean that we should generate client classes as JAX-RPC? for the clients running in the old version to be able to access it? if yes, how?

To rephrase the question, if you have a JAX-WS web service, how do you generate a JAX-WS client and how to generate a JAX-RPC client? ive done some initial research and they seem to be done the same way, which I'm not sure is correct. Im confused.

thanks

Davoin Showerhandles
  • 47
  • 1
  • 9
  • You simply use the right tool for the right job: use `wsimport` to process the jax-ws wsdl; `wsdl2java` for the rpc/encoded wsdl. Use the appropriate stubs depending on the destination webservice – kolossus Apr 02 '15 at 19:37

2 Answers2

0

Since you mentioned J2EE 1.4, I am guessing that the web service is based upon JAX-RPC 1.x standard. As the Java EE 6 based web service is based on JAX-WS, I would suggest generating client stubs using wsimport command by using the WSDL from your new service to generate stub classes.

In case you want to dig deeper and you should always refer to the JAX-WS specification document here (read up on chapter 4 - Client APIs)

Abhishek
  • 1,175
  • 1
  • 11
  • 21
  • if clients stub are generated from JAVA EE 6, how would a client deployed in J2EE 1.4 be able to access it? – Davoin Showerhandles Apr 05 '15 at 08:05
  • Oh. That won't be possible. I think I missed the point you mentioned about the client being restricted to J2EE 1.4. I can think of a couple of other options in case you want to decouple the WS client implementation (1) using POX (plain old XML) to invoke your JAX-WS end points - this might need some work though (2) expose your WS functionality using REST (JAX-RS 1.0 support is a part of Java EE 6). This way, you can use HTTP libraries to simply invoke your REST end points - another way to decouple client and server – Abhishek Apr 07 '15 at 07:30
0

The service consumer (client) and service provider technologies are independent. You can (for the most part) have a JavaEE6/JAX-WS web service provider but still consume with a JAX-RPC client, technically (for that matter, clients might not even be implemented in Java!). The only technical barriers to this would be perhaps if your service provider used SOAP 1.2 constructs that JAX-RPC could not handle, but I suspect that not to be the case if you are strictly migrating/upgrading the provider application.

Several application servers still support JAX-RPC even though it is now (JavaEE 5 & 6) optional for compliant app servers to implement.

I would personally however recommend updating the clients to JAX-WS as you upgrade those applications/appservers. I would think they should work with the upgraded web service provider without change - so long as the service provider WSDL doesn't change when that application is upgraded (though you may have to regenerate them if there are subtle differences in the regenerated WSDLs - the marshal/unmarshal technology in JAX-RPC is notoriously brittle).

-SH

Scott Heaberlin
  • 3,364
  • 1
  • 23
  • 22