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.
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.
Peer Reynders
Bartender
Joined: Aug 19, 2005
Posts: 2906
posted
0
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.
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.
Vikrama Sanjeeva
Ranch Hand
Joined: Sep 02, 2001
Posts: 756
posted
0
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:
Peer Reynders
Bartender
Joined: Aug 19, 2005
Posts: 2906
posted
0
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.
Vikrama Sanjeeva
Ranch Hand
Joined: Sep 02, 2001
Posts: 756
posted
0
Can you please figure out what wrong in below WSDL?
[ December 02, 2008: Message edited by: Vikrama Sanjeeva ]
Jimmy Clark
Ranch Hand
Joined: Apr 16, 2008
Posts: 2187
posted
0
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.
Peer Reynders
Bartender
Joined: Aug 19, 2005
Posts: 2906
posted
0
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.
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]
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?"
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 ]
Vikrama Sanjeeva
Ranch Hand
Joined: Sep 02, 2001
Posts: 756
posted
0
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.
Peer Reynders
Bartender
Joined: Aug 19, 2005
Posts: 2906
posted
0
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.
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 ]
0
