• 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 vs JAX-WS

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am trying to figure out how to identify if a specific web service is implemented in JAX-RPC or JAX-WS.

All i have is a wsdl.

Also, i would like to know if it matters at all from consumer perspective if it is JAX-RPC or JAX-WS based?

Thanks,
AA
 
Saloon Keeper
Posts: 7585
176
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, you can't know, and no, it doesn't matter. That's the whole point of WS, after all - that for the client it does not matter how the server is implemented as long as the standards are adhered to.
 
Bartender
Posts: 1051
5
Hibernate Eclipse IDE Chrome
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Alpha

If you have a WSDL, that is enough for a client to build a set of generated classes from which requests can be marshalled to XML and sent to the service.

The underlying implementation of the web service should be of no concern to a client.
 
Alpha Omega
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tim and James,
Thanks for clarification.

H Paul,
Yes i have gone thru the whole series of those articles.

It does explain the difference in terms of implementation and the underlying technology/transport and the specs support.

But i was not able to figure out how can we identify the implementation thru WSDL.

It does make sense when WSDL abstracts out the impl details as that is what an interface contract should be.

I just wanted to make sure i am not missing something big....

Thanks,
AA

 
H Paul
Ranch Hand
Posts: 491
5
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

In theory, theory and practice are the same. In practice, they are not.


How I do my little way:

1. Look at the WSDL schema data type: JAX-RPC and JAX-WS have some common data type. JAX-WS also support new data type which is
not supported by JAX-RPC. 1 of the link mentioned it.

2. Just do it by Nike:

I just take the wsdl and use JAX-RPC soap engine to generate the client side to see if it complain or not.
if it complain, then provider use something NON JAX-RPC.

I just take the wsdl and use JAX-WS soap engine to generate the client side to see if it complain or not.
if it complain, then provider use something NON JAX-WS.

This exercise is to validate the point 1.
 
Alpha Omega
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
H Paul,

Yes, what you are suggesting makes sense but only if the producer is using JAX-RPC or newer JAX-WS data types.

If the response is in simple data types, i guess it might not complain in any of the way you try to generate the client code.

I will give it a try and post the outcome sometime soon...

Here is the result for wsimport

[ERROR] undefined simple or complex type 'soapenc:Array'

It kinda proves your point. The WSDL is JAX-RPC based and it gives error when JAX-WS based wsimport tool

What it means is JAX-RPC based ws using complex data types will not work with JAX-WS generated clients... Kinda confusing...

Cheers,
AA

H Paul wrote:

In theory, theory and practice are the same. In practice, they are not.


How I do my little way:

1. Look at the WSDL schema data type: JAX-RPC and JAX-WS have some common data type. JAX-WS also support new data type which is
not supported by JAX-RPC. 1 of the link mentioned it.

2. Just do it by Nike:

I just take the wsdl and use JAX-RPC soap engine to generate the client side to see if it complain or not.
if it complain, then provider use something NON JAX-RPC.

I just take the wsdl and use JAX-WS soap engine to generate the client side to see if it complain or not.
if it complain, then provider use something NON JAX-WS.

This exercise is to validate the point 1.

 
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. If I have any thing by looking at the wsdl alone, I'll post it.

2. Here is a quick request to play with:
 
Alpha Omega
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
H Paul

Here is the result for wsimport

[ERROR] undefined simple or complex type 'soapenc:Array'

It kinda proves your point. The WSDL is JAX-RPC based and it gives error when JAX-WS based wsimport tool

What it means is JAX-RPC based ws using complex data types will not work with JAX-WS generated clients... Kinda confusing...

Cheers,
AA
reply
    Bookmark Topic Watch Topic
  • New Topic