• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JAX-RPC client for JAX-WS service

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there are implications to have a JAX-RPC client generated for the Web Services created using JAX - WS.

One of our consumer is having issues using JAX-WS client with IBM WebSphere Portal server (IBM advocates to install a service pack fix) but for other reasons they don't want to install

Thoughts please..
 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
could you provide more details on how the client is generated?

do you see any exceptions

 
Ranch Hand
Posts: 2198
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!
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.
Best wishes!
 
Ranch Hand
Posts: 491
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Imagination is more important than knowledge.



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

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.

 
Venkataprasath Padmanabhan
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let me explain the issue in detail.

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.




 
H Paul
Ranch Hand
Posts: 491
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1 .CXF implements JAX-WS and uses JAXB 2.x as its default databinding.
http://cxf.apache.org/docs/databindings.html

So both client and server end use the same JAXB mar/unmar.

2. Now, why not using JAX-WS Metro RI? (Yes, out of curiosity.)
 
Venkataprasath Padmanabhan
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Paul,

1. Our Service provider uses IBM provided JAX-WS and JAXB.

2. JAX-WS Metro RI is a good option we are yet to explore.

Thanks for your ideas.,
 
H Paul
Ranch Hand
Posts: 491
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I mean use JAX-WS Metro RI on the client side only.
Good luck any way.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic