Hi All I am trying to write a Web Service Client for a wsdl provided by a 3rd party. The problem is their service name contains spaces. It goes something like "Abc Def Ghi". I a using Rational Application Developer to generate most of the code. When using this the generated code shows problem in two files. BTW I am generating an EJB Client. The first file is mapping.xml which has problem with the generated element wsdl-service-name because of the spaces. The second file is the ejb-jar.xml which has problem with the generated ejb-web service reference service-qname again with the spaces. If I remove the spaces the errors go away but at runtime I get the exception saying service not found. I have also tried substituting the spaces with %20 and && but neither of the work.
I am trying to ascertain whether there is any possible alternative before speaking to the 3rd party supplier.
I have tested the service itself using standalone client and the web services explorer tool by IBM. It works.
Thank you Peer for the reply. I did try that which is when I got the exception that said something like the service could not be found. It failed at the service lookup step. Any other ideas.
Sunny X Narula
Joined: Dec 07, 2008
Finally got whats wrong.
The web service was hosted on a Coldfusion Application server by the vendor and we have a Websphere
runtime for the client. Unfortunately these two refuse to talk.
We got the vendor to remove the space but it didn't solve the problem.
It seems both run times follow different standards seems web service does not have a standard standard anymore.
Joined: Aug 19, 2005
SunnyNar ula wrote:It seems both run times follow different standards seems web service does not have a standard standard anymore.
It may simply be that the Coldfusion web service uses the older "rpc/encoded" messaging mode and that the WebSphere and Coldfusion implementations of Section 5 SOAP Encoding aren't compatible. This has always been a recurring problem which lead to the current generation of SOAP stacks altogether abandoning support for the "rpc/encoded" messaging mode (and therefore Section 5 SOAP Encoding).