Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Like it or not, service-oriented architecture (SOA) is a hot topic, and SOAP-based Web services have emerged as the most common implementation of SOA. But, as James Governor put it, "SOA reality brings SOA problems." You can mitigate these problems by creating useful Web service clients, and also by thoroughly testing your Web services on both the server side and the client side. WSDL files play a central role in both of these activities, so in this article Klaus P. Berg presents an extensible toolset that facilitates client-side WSDL processing using Gant and Groovy.
As part of a cross-platform Web service testing team responsible for testing functional aspects as well as the performance,
load, and robustness of Web services, I recently realized the need for a small, easy-to-use, command-line-based solution for
WSDL processing. I wanted the toolset to help testers and developers check and validate WSDL 1.1 files coming from different
sources for compatibility with various Web service frameworks, as well as generating test stubs in Java to make actual calls.
For the Java platform, that meant using Java 6
wsimport, Axis2, XFire, and CXF. (We also needed an environment based on Visual Studio .Net, and C# that tested WSDL and the services themselves in a pure-Windows environment -- but that's another story not suited to an article in a Java magazine.)
We started client-side test development with XFire, but then switched to Axis2 because of changing customer requirements in
our agile project. (Axis2 was considered to be more popular and widespread than XFire.) We also used ksoap2 -- a lightweight Web service framework especially for the Java ME developer. We didn't expand the toolset to use
ksoap2 because it has no WSDL-to-Java code generator.
Besides being controllable via simple commands, the toolset had to be able to integrate at least the WSDL checker into an
automated build environment like Ant. One solution would have been to develop everything as a set of Ant targets. But executing everything with Ant is cumbersome
when tasks become more complex, and you need control structures like
ant-contrib binds you to XML-structures that are not easy to read, although you will have more functionality available. Anyhow, in the
end you might need to implement some jobs as Ant tasks. All of this is possible, of course, but I was looking for a more elegant
solution. Finally, I decided to use Groovy and a smart combination of Groovy plus Ant, called Gant. The components I have
developed for the resulting Toolset can be divided into two groups:
That is an overview of the programming and scripting languages I used to build the Groovy and Gant Toolset. Now let's consider the technologies in detail.
Apache Ant is a software tool for automating software build processes. It is similar to
make but is written in the Java language, requires the Java platform, and is best suited to building Java projects. Ant is based on an XML description of targets and their dependencies. Targets include tasks that every project needs, like
jar. Ant is the de-facto standard build tool for Java, although Maven is making inroads.
Groovy is an object-oriented programming and scripting language for the Java platform, with features like those of Perl, Ruby, and Python. Groovy sources are dynamically compiled to Java bytecode that works seamlessly with your own Java code or third-party libraries. By means of the Groovy compiler, you can also produce bytecode for other Java projects. It is fair to say that I am biased towards Groovy compared to other scripting languages such as Perl or Ruby. While other people's preferences and experiences may be different from mine, the integration between Groovy and Java code is thorough and smooth. It was also easy, coming from Java, to get familiar with the Groovy syntax. What made Groovy especially interesting for solving my problems was its integration with Ant, via AntBuilder.
Gant (shorthand for Groovy plus Ant) is a build tool and Groovy module. It is used for scripting Ant tasks using Groovy instead of XML to specify the build logic. A Gant build specification is just a Groovy script and so -- to quote Gant author Russel Winder -- can deliver "all the power of Groovy to bear directly, something not possible with Ant scripts." While it might be considered a competitor to Ant, Gant relies on Ant tasks to actually do things. Really it is an alternative way of doing builds using Ant, but using a programming language, instead of XML, to specify the build rules. Consider using Gant if your Ant XML file is becoming too complex, or if you need the features and control structures of a scripting language that cannot be easily expressed using the Ant syntax.
Before you start examining the code in the next sections, here's a word about the OS and Java environment for the tools presented in this article, as well as a preview of what you will find if you download the toolset and associated files.
|Forum migration complete By Athen|
|Forum migration update By Athen|
tools.jar, but only if you want to use Java 6
wsimportwith Java 5 installed. Note that you do not have to install a Java 6 JRE to use
wsimportwith the Groovy and Gant Toolset.