A Gradle Case Study
Tutorial - Gradle SOAP - Features Revealed
We face the following problem: While the SOAP-based approach to web services is currently out of favor, SOAP-based web services are certainly not out of existence, and the tools for building simple clients to SOAP services are built into Java. Creating a simple client is an almost trivial exercise. All you need is the wsimport tool (part of the JDK installation) and access to a Web Services Description Language (WSDL) file. The wsimport script reads the WSDL file and generates all the required stubs necessary to build the client.Since Groovy and Java can be freely intermixed, it’s easy enough to build a client in Groovy that uses the generated Java stubs.
Here a Spock test case will be used to check the behavior of a web service. A freely available Microsoft web service used to compute currency exchange rates will be accessed. Hopefully the use of a Microsoft web service won’t turn away the readers of this article that didn’t leave once the term SOAP was used. The service doesn’t matter – it’s the Gradle stuff that’s good. The goal is to automate the entire process, from stub generation to test, using Gradle.
A Web Service Client
Microsoft supports a number of simple web services. One of these services is a currency converter (Which they even misspelled as “convertor”. Don’t get me started.), whose WSDL file is located here. By convention, the service is at the same URL with the WSDL parameter removed. Since this is certainly not the place to discuss the vagaries of WSDL, observe only that from the source of the WSDL file the service name is CurrencyConvertor and the portType (i.e., the interface) is CurrencyConvertorSoap. That means that once the stubs have been generated, accessing the web service is as simple as writing:
CurrencyConvertorSoap stub = new CurrencyConvertor().getCurrencyConvertorSoap()
Then just use the stub to invoke any operations defined in the WSDL file. The only operation needed is called getConversionRate, which takes two Currency instances defined in an XML Schema inside the WSDL file. For example, a typical request would look like:
double rate = stub.getConversionRate(Currency.USD, Currency.INR)
to get the exchange rate between US dollars and Indian rupees. The key benefit (if any) to SOAP web services is in the stub generation. Java comes with the wsimport tool, whose usage takes the form:
c:\> wsimport -d buildDir -s srcDir -keep http://...path.to.WSDL.file...
where the -d flag specifies the directory to use for the compiled stubs, the -s flag says where to put the generated source code, the -keep flag means to save the generated source code, and the last argument is the location of the WSDL file.
This is easy enough to run from the command line, but how do you make it part of an automated build? Fortunately, there is an Ant task defined for it. The job now is (1) add the proper repository so Gradle can find the required jars for the Ant task, (2) define a custom Gradle task for wsimport, and (3) make the execution of the task part of the regular build process. The rest of this article shows how to do each of those tasks.