This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
What method do people recommend using to connect to an existing web service in Java? Everytime I search for information on Google, I end up with a lot of links about generating a web service in Java from a WSDL (or visa versa) but not much on connecting to an existing one.
Is it easier to just build the XML on fly using DOM libraries, or do people recommend a more 'clever' approach, such as using the WSDL to generate java POJOS for client access, and have them auto-magically convert to XML for transport? If so, what's the best tool for generating client java code?
-Scott [ February 27, 2008: Message edited by: Scott Selikoff ]
You have two options in order to consume an already available web service, like Amazon web services. You can call use Dispatch class and its related class in order to call the service dynamically without having any pre-generated client stub. this way you have more control on how you want to create your soap message.... you may take a look at http://www.ibm.com/developerworks/websphere/library/techarticles/0707_thaker/0707_thaker.html for more information on this method.
The other way is to generate a client stub using wsimport or similar utilities which are present in each web service framework. for example in jax-ws package (project Metro which is available at http://metro.dev.java.net) you can create an static stub using following command:
This command will generate some java class which represent the above web service, you will only need to interact with this classes in order to invoke some services.
There is an example of how you can use an existing web service (described through a WSDL) in Geronimo 2.0 JSP-based JAX-WS client
Unfortunately the example is silent on how the client side classes are generated. In Glassfish V2 and Java SE 6 wsimport is used. Java 6 SE example
Is it easier to just build the XML on fly using DOM libraries, or do people recommend a more 'clever' approach, such as using the WSDL to generate java POJOS for client access, and have them auto-magically convert to XML for transport?
Generating Java code from the WSDL is the standard approach. Manipulating the SOAP Message or XML directly is only used in special cases or when your application uses "XML in-depth". Java EE 5 tools use JAXB for XML binding. [ February 27, 2008: Message edited by: Peer Reynders ]
Thanks everyone, WSDL2java from Axis worked just fine, although figuring out how to make the initial connection required some detective work with the generated locator.
I did notice Axis 1.4 generated the files with bugs, I should probably report it. In particular, some files generated package names that did not match their directory location (and with matching incorrect package references) so that the code had to be manually corrected to compile. My guess is the WSDL itself probably has some problems (seems to the same namespaces with different upper/lower cases in different URLs), but regardless, the generated code should at least have a package match the directory its placed in. [ February 28, 2008: Message edited by: Scott Selikoff ]
Joined: Aug 19, 2005
Originally posted by Scott Selikoff: I did notice Axis 1.4 generated the files with bugs.
Axis 1.x is no longer under active development. Contemporary web services prefer the document/literal style and while in principle that is supported by Axis 1.x, it can run into some problems with some more complicated content (like attachments). If you can, do yourself a favor and look elsewhere. If JAX-WS isn't an option (which it should be in a Java EE 5 container, otherwise it couldn't call itself a Java EE 5 container) then Axis2/JiBX may be an attractive option.
Thanks Peer, I wasn't aware of the Axis development status. I switched to axis2 since I had experience with Axis1, and I must say, its a lot cleaner. Instead of 3 dozen generated files, I have 2 with a very streamlined interface.