reading soap-envelop messages

Hi List,

I am sitting at consumer end and getting response of web service in soap-envelop. Below is response snippet:



My question is:

1: How I read this response in my Java class? Do I need to write parser?
2: This is 1 web service response. But in real there are 40+ web services and am not aware of response xml structure. How to deal with this when using parser to read response.

Please advise.

Bye,
Viki.

1: How I read this response in my Java class? Do I need to write parser?

You could use the API in the javax.xml.soap package. No, you do not need to write a parser.

If the originating web service publishes a WSDL (web sevice description langauge) file (the service contract) you can use a code generation tool to generate a consumer stub.

JAX-WS wsimport

Axis2 WSDL2Java

Otherwise, as James mentioned, there is SAAJ.
What is the simplest possible Java client for a web service?
"Java Web Services in a Nutshell" Sample: Chapter 3 SAAJ (PDF)
[ December 01, 2008: Message edited by: Peer Reynders ]

Hi,

Thanks for the guidance.

I have tried creating client stubs using Axis2 WSDL2Java but it gives me below error:

"Error parsing WSDL"

Another thing I notice is that the web service which I want to consume have publish their WSDL with "?" added at the end of url. Here its format

http://123.456.789.222:7778/some/web/subs?wsdl

Check the "?wsdl" appended at the end.

I tried with ".wsdl" but it says file not found.

What to do, what am missing?

I used:
WSDL2Java -uri http://123.456.789.222:7778/some/web/subs?wsdl -p com.my.test.stubs -d adb -s

Bye,
Viki,

Originally posted by Vikrama Sanjeeva:
I have tried creating client stubs using Axis2 WSDL2Java but it gives me below error:

"Error parsing WSDL"

The full error and the relevant WSDL and referenced schemas are usually necessary to diagnose these types of problems.

Another thing I notice is that the web service which I want to consume have publish their WSDL with "?" added at the end of url.

That is a common way of publishing the WSDL that is associated with a web service endpoint.

http://www.mywebservice.com/endpoint is the web service endpoint URL that SOAP messages are HTTP POSTed to.
http://www.mywebservice.com/endpoint?wsdl is the URL where you can HTTP GET the published WSDL of that endpoint.

In fact you should be able to see the WSDL at http://123.456.789.222:7778/some/web/subs?wsdl in your browser.

Yes, I am able to see full WSDL in browser for URL: "http://123.456.789.222:7778/some/web/subs?wsdl"


Here is the full Error:

Originally posted by Vikrama Sanjeeva:

This suggests problems inside the types section of the WSDL.
There might be some mixup with the default and target namespaces.

Can you please figure out what wrong in below WSDL?

I have copied WSDL generated on browser (url: http://123.456.789.222:7778/some/web/subs?wsdl) and pasted below




[ December 02, 2008: Message edited by: Vikrama Sanjeeva ]

I don't see the WSDL namespace declared in the definitions element, e.g. xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/".

Also, the elements don't have the WSDL namespace qualifier.

Strange looking WSDL instance.

That WSDL uses the RPC/encoded messaging mode. Axis2 like other current generation SOAP web service stack do not support RPC/encoded because of all the problems that it caused in the past.

Try Axis 1.x instead. It may work - however as it is RPC/encoded it may experience some other problems.

Axis 1.x WSDL2Java
[ December 02, 2008: Message edited by: Peer Reynders ]

Hi,

I have tried with Axis 1.4 and its giving same error [Extension elements must be in a namespace other than WSDL's] except some initail warning for "Attachment support is disabled." [Axis 1.4 It does not include WSDL2Java script, but I got from net and used]


Here is the output:



I have also read 4 different encoding schemes:

RPC/encoded
RPC/literal
Document/encoded
Document/literal

1: Now my question is "How you have identified that this is RPC/encoded style? What elements in WSDL reveals this information?"

2: If this is not correct WSDL, then what should I explain to its publisher in order to make it correct?

Thanks!
Bye,
Viki [In Need...]
[ December 03, 2008: Message edited by: Vikrama Sanjeeva ]

Originally posted by Vikrama Sanjeeva:
1: Now my question is "How you have identified that this is RPC/encoded style? What elements in WSDL reveals this information?"

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" />
...
<soap:operation soapAction="" style="rpc" />
...
<soap:body
use="encoded"
namespace="SUBS_DETAIL"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
/>

Which style of WSDL should I use?

2: If this is not correct WSDL, then what should I explain to its publisher in order to make it correct?

This is a generated WSDL - so it should be "correct" (correct in the most minimalistic sense) - however it looks like somebody corrupted it (see XML comments).


[ December 03, 2008: Message edited by: Peer Reynders ]

Thanks Mr. Peer for your support.

Actually, now I have realized that publisher has not published web services as per WS-I compliant standards. Since RPC/encoded is not WS-I compliant.

On the other hand, RPC/iteral, Document/literal and Document/encoded are WS-1 compliant standards for WSDL style.

Well, as per the below real situation, I need your advise.

Situation is: publisher has already developed and published several web services using RPC/encoded scheme. We however have successfully consumed some in Windows OS but failed to do in Solaris.

I am not sure why same service is failed on Solaris, but its giving me notion of encoding-decoding problem due to different OS of publisher and consumer ends. Means, as per my understanding, RPC calls involve marshalling and de-marshalling mechanism. And when we [consumer] calls/involkes a service from Solaris OS, the remote end [publisher] marshall's the message and sends response to us[consumer]. And while de-marshalling response at consumer it fails. This could be due to marshallig is done on different OS [suppose Win] and demarshalling is done on Soaris.

This was just a doubt. Please give your expert advise.

Thanks once again.

Bye,
Viki.

Originally posted by Vikrama Sanjeeva:
Situation is: publisher has already developed and published several web services using RPC/encoded scheme. We however have successfully consumed some in Windows OS but failed to do in Solaris.

RPC/encoded has always been plagued with interoperability problems which is why current generation SOAP web service stacks have abandoned it. Which SOAP web service stack are you using? Axis 1.x was able to interface with some RPC/encoded web services implemented with older MS-based technology - though there always was a breaking point.

Theoretically you could "wing it" by using SAAJ - but that would quickly become too tedious and error-prone.

Frankly I think the easiest solution is to put a Windows box (proxy) in-between.


Basically design a WS-I Basic Profile document/literal style contract that the windows-based SOAP web service stack can publish and use that to implement a web service proxy on the windows box. Solaris consumers can then call the proxy document/literal style and the proxy service delegates the request to the rpc/encoded provider.


You have a better option if you have ownership over the provider.

A Service Fa�ade.

Basically you have to make sure that your service logic is separated from the message processing logic/service contract. Then through the use of a Service Fa�ade you can let consumers use the service logic through an RPC/encoded or Document/literal contract (each at a separate endpoint).



Once the Fa�ade is operational you "hide" the RPC/enc WSDL (and throw away the key) to avoid further proliferation of RPC/enc consumers and only publish the new Doc/lit WSDL for new consumers. If you ever add new capabilities to the Service make them only available via the Doc/lit WSDL not the RPC/enc WSDL. That way you encourage the RPC/enc consumers to migrate to the Doc/lit contract to use the new capabilities. Once the RPC/enc endpoint is no longer used you can retire the Service Fa�ade and go back to operating through a single (Doc/lit) contract.
[ December 04, 2008: Message edited by: Peer Reynders ]