I am having all kinds of trouble developing a client for a web service provided by a third party. Part of the problem is that for several of the ports (I think that's the name - I am new to web services), the wsdl specifies an <xsd:any/> tag where the xml that is supposed to be filled in here is specified by an external xsd.
I generated the client code using wsimport which apparently comes with the jdk. The code for the input class which used the <xsd:any/> tag just had an inner class whose only property was a list of objects. You had to instantiate a class generated from xjc and add that to the list of objects. Several of the setters on this class took JAXBElements (the nillable ones) as arguments instead of Strings or what have you and all the setters that corresponded to dates took XMLGregorianCalendars as arguments
Also, the username and password for the service are supposed to be passed in the soap header. I had to cast the service as a WSBindingProvider and set the headers on it to generate the proper xml. Now I am having a problem because the jdk on the build server and production boxes are too old to include the jaxws code.
I get the very strong feeling that I took the wrong approach to developing a jaxws client. Is there a more common way to do this, or is all this rigamarole because the service was generated by .NET?
If the web service is based on SOAP, then the implementation of the service should be irrelevant to how a client is created. In your example, if the service is implemented in .NET, this does not matter much, or should not matter. If they implemented the service in such a way that you need to consider .NET things in the SOAP message, they did it wrong. There should also be no traces of Java in the SOAP request message either, if there are, they did it wrong.
In the beginning, you can first simply create a SOAP message manually and then send the message to test connectivity and make sure that you format the message correctly. You can do this relatively easy using the SOAP API (javax.xml.soap). Once you understand how the SOAP message must be structure, they you can start to fool around with all the other wonderful gadgets, e.g. JAXB, XML Schemas, etc.
The key here is to first understand how the SOAP request message looks and to learn how to send the message.
Joined: Dec 07, 2010
I was wondering if the .NET web service creation tools (not sure what their java analogues are) generated a service which created the hairy monster that I am dealing with, particularly the inclusion of <xsd:any/> tags in the wsdl. I am successfully calling the service and getting a response, but I had to jump through a great deal of hoops to make it happen.
Joined: Apr 16, 2008
Sounds good. In this case, you are not aware of any "tool"usage. You only have ideas. There are many different ways to create web services in .NET and there are ways that do not involve any "tools".
In regards to "tools", they are not always the best choice. Sometimes "tool" programmers are overly focused on their tool rather than the software products that are to be created using the "tool." In other cases, they strive to make the "tool" as generic as possible to increase potential user base, which in turn usually introduces potential limitations or non-essential aspects that then need to be dealt with by the tool user.
subject: Do .NET SOAP web services not play well with java clients?