Not surprisingly, the Document Object Model is based around the central abstraction of a document, realized as the Java interface org.w3c.dom.Document. An object of this type will hold our datastore.

The Java way of retrieving a document is through the parse method of a DocumentBuilder (= parser). This method takes an InputStream to read the XML from. So a first attempt of reading is

def doc = builder.parse(new FileInputStream('data/plan.xml'))

Now, where does builder come from? We are working slowly backward to find a solution. The builder must be of type DocumentBuilder. Instances of this type are delivered from a DocumentBuilderFactory, which has a factory method called newDocumentBuilder:

def builder = fac.newDocumentBuilder()
def doc     = builder.parse(new FileInputStream('data/plan.xml'))

Now, where does this factory come from? Here it is:

import javax.xml.parsers.DocumentBuilderFactory

def fac     = DocumentBuilderFactory.newInstance()
def builder = fac.newDocumentBuilder()
def doc     = builder.parse(new FileInputStream('data/plan.xml'))

Java’s XML handling API is designed with flexibility in mind.^[2] A downside of this flexibility is that for our simple example, we have a few hoops to jump through in order to retrieve our file. It’s not too bad, though, and now that we have it we can dive into the document.

The document object is not yet the root of our datastore. In order to get the toplevel element, which is plan in our case, we have to ask the document for its documentElement property:

def plan = doc.documentElement

We can now work with the plan variable. It’s of type org.w3c.dom.Node and so it can be asked for its nodeType and nodeName. The nodeType is Node.ELEMENT_NODE, and nodeName is plan.

The design of such DOM nodes is a bit strange (to put it mildly). Every node has the same properties, such as nodeType, nodeName, nodeValue, childNodes, and attributes (to name only a few; see the API documentation for the full list). However, what is stored in these properties and how they behave depends on the value of the nodeType property.

We will deal with types ELEMENT_NODE, ATTRIBUTE_NODE, and TEXT_NODE (see the API documentation for the exhaustive list).

It is not surprising that XML elements are stored in nodes of type ELEMENT_NODE, but it is surprising that attributes are also stored in node objects (of nodeType ATTRIBUTE_NODE). To make things even more complex, each value of an attribute is stored in an extra node object (with nodeType TEXT_NODE). This complexity is a large part of the reason why simpler APIs such as JDOM, dom4j, and XOM have become popular.

As an example, the nodes and their names, types, and values are depicted in figure 12.1 for the first week element in the datastore.

Figure 12.1. Example of a DOM object model (excerpt) for element, attribute, and text nodes

The fact that node objects behave differently with respect to their nodeType leads to code that needs to work with this distinction. For example, when reading information from a node, we need a method such as this:

import org.w3c.dom.Node

String info(node) {
    switch (node.nodeType) {
        case Node.ELEMENT_NODE:
             return 'element: '+ node.nodeName
        case Node.ATTRIBUTE_NODE:
             return "attribute: ${node.nodeName}=${node.nodeValue}"
        case Node.TEXT_NODE:
             return 'text: '+ node.nodeValue
    }
    return 'some other type: '+ node.nodeType
}

With this helper method, we have almost everything we need to read information from our datastore. Two pieces of information are not yet explained: the types of the childNodes and attributes properties.

The childNodes property is of type org.w3c.dom.NodeList. Unfortunately, it doesn’t extend the java.util.List interface but provides its own methods, getLength and item(index). This makes it inconvenient to work with. However, as you saw in section 9.1.3, Groovy makes its object iteration methods (each, find, findAll, and so on) available on that type.

The attributes property is of type org.w3c.dom.NamedNodeMap, which doesn’t extend java.util.Map either. We will use its getNamedItem(name) method.

Listing 12.2 puts all this together and reads our plan from the XML datastore, walking into the first task of the first week.

Example 12.2. Reading plan.xml with the classic DOM parser

Note how we use the object iteration method find to access the first week element under plan. We use indexed access to the first task child node at . But why is the index one and not zero? Because in our XML document, there is a line break between week and task. The DOM parser generates a text node containing this line break (and surrounding whitespace) and adds it as the first child node of week (at index zero). The task node floats to the second position with index one.

Groovy wouldn’t be groovy without a convenience method for the lengthy parsing prework:

def doc  = groovy.xml.DOMBuilder.parse
                (new FileReader('data/plan.xml'))
def plan = doc.documentElement

Dealing with child nodes and attributes as in listing 12.2 doesn’t feel groovy either. Therefore, Groovy provides a DOMCategory that you can use for simplified access. With this, you can index child nodes via the subscript operator or via their node name. You can refer to attributes by getting the @attributeName property:

use(groovy.xml.dom.DOMCategory){
    assert 'plan' == plan.nodeName
    assert 'week' == plan[1].nodeName
    assert 'week' == plan.week.nodeName
    assert '8'    == plan[1].'@capacity'
}

Although not shown in the example, DOMCategory has recently been improved to provide additional syntax shortcuts such as name, text, children, iterator, parent, and attributes. We explain these shortcuts later in this chapter, because they originated in Groovy’s purpose-built XML parsing classes. Consult the online Groovy documentation for more details.

This was a lot of work to get the DOM parser to read our data, and we had to face some surprises along the way. We will now do the same task using the Groovy parser with less effort and fewer surprises.

Let’s start with the commonalities of XmlParser and XmlSlurper: They both reside in package groovy.util and provide the constructors listed in table 12.1.

Besides sharing constructors with the same parameter lists, the types share parsing methods with the same signatures. The only difference is that the parsing methods of XmlParser return objects of type groovy.util.Node whereas XmlSlurper returns GPathResult objects. Table 12.2 lists the uniform parse methods.

These are the most commonly used methods on XmlParser and XmlSlurper. The description of additional methods (such as for using specialized DTD handlers and entity resolvers) is in the API documentation.

The result of the parse method is either a Node (for XmlParser) or a GPathResult (for XmlSlurper). Table 12.3 lists the common available methods for both result types. Note that because both types understand the iterator method, all object iteration methods are also instantly available.

GPathResult and groovy.util.Node provide additional shortcuts for method calls to the parent object and all descendent objects. Such shortcuts make reading a GPath expression more like other declarative path expressions such as XPath or Ant paths.^[3]

Objects of type Node and GPathResult can access both child elements and attributes as if they were properties of the current object. Table 12.4 shows the syntax and how the leading @ sign distinguishes attribute names from nested element names.

Listing 12.4 plays with various method calls and uses GPath expressions to work on objects of type Node and GPathResult alike. It uses XmlParser to return Node objects and XmlSlurper to return a GPathResult. To make the similarities stand out, listing 12.4 shows doubled lines, one using Node, one using GPathResult.

Example 12.4. Using common methods of groovy.util.Node and GPathResult

Note that the GPath expression node.week.task first collects all child elements named week, and then, for each of those, collects all their child elements named task (compare the second row in table 12.4). In the case of node.week.task, we have a list of task nodes that we can ask for its size. In the case of path.week.task, we have a GPathResult that we can ask for its size. The interesting thing here is that the GPathResult can determine the size without collecting intermediate results (such as week and task nodes) in a temporary datastructure such as a list. Instead, it stores whatever iteration logic is needed to determine the result and then executes that logic and returns the result (the size in this example).

At , you see that in GPath, attribute access has the same effect as access to child elements; node.week.task.'@done' results in a list of all values of the done attribute of all tasks of all weeks. We use the spread-dot operator (see section 7.5.1) to apply the toInteger method to all strings in that list, returning a list of integers. We finally use the GDK method sum on that list.

The line at can be read as: “Assert that the done attribute in every task of week[1] is '0'.” What’s new here is using indexed access and the object iteration method every. Because indexing starts at zero, week[1] means the second week.

This example should serve as an appetizer for your own experiences with applying GPath expressions to XML documents.

In addition to the convenient GPath notation, you might also wish to make use of traversal methods; for example, we could add the following lines to listing 12.4:

assert 'plan->week->week->task->task->task->task->task' ==
        node.breadthFirst()*.name().join('->')

assert 'plan->week->task->task->task->week->task->task' ==
        node.depthFirst()*.name().join('->')

So far, you have seen that XmlParser and XmlSlurper can be used in a similar fashion to produce similar results. But there would be no need for two separate classes if there wasn’t a difference. That’s what we cover next.

Despite the similarities between XmlParser and XmlSlurper when used for simple reading purposes, there are differences when it comes to more advanced reading tasks and when processing XML documents into other formats.

XmlParser uses the groovy.util.Node type and its GPath expressions result in lists of nodes. That makes working with XmlParser feel like there always is a tangible object representation of elements—something that we can inspect via toString, print, or change in-place. Because GPath expressions return lists of such elements, we can apply all our knowledge of the list datatype (see section 4.2).

This convenience comes at the expense of additional up-front processing and extra memory consumption. The GPath expression node.week.task.'@done' generates three lists: a temporary list of weeks^[4] (two entries), a temporary list of tasks (five entries), and a list of done attribute values (five strings) that is finally returned. This is reasonable for our small example but hampers processing large or deeply nested XML documents.

XmlSlurper in contrast does not store intermediate results when processing information after a document has been parsed. It avoids the extra memory hit when processing. Internally, XmlSlurper uses iterators instead of extra collections to reflect every step in the GPath. With this construction, it is possible to defer processing until the last possible moment.

Table 12.5 lists the methods unique to Node. When using XmlParser, you can use these methods in your processing.

Table 12.6 lists the methods that are unique to or are optimized in GPathResult. As an example, we could add the following line to listing 12.4 to use the optimized findAll in GPathResult:

assert 2 == path.week.task.findAll{ it.'@title' =~ 'XML' }.size()

Additionally, some classes may only work on one type or the other; for example, there is groovy.util.XmlNodePrinter with method print(Node) but no support for GPathResult. Like the name suggests, XmlNodePrinter pretty-prints a Node tree to a PrintStream in XML format.

You have seen that there are a lot of similarities and some slight differences when reading XML via XmlParser or XmlSlurper. The real, fundamental differences become apparent when processing the parsed information. Coming up in section 12.2, we will look at these differences in more detail by exploring two examples: processing with direct in-place data manipulation and processing in a streaming scenario. However, first we are going to look at event style parsing and how it can be used with Groovy. This will help us better position some of Groovy’s powerful XML features in our forthcoming more-detailed examples.

You use XmlSlurper to parse the original XML. Because the final output format is XML again, you need some device that can generate XML in a streaming fashion. The groovy.xml.StreamingMarkupBuilder class is specialized for outputting markup on demand—in other words, when an information sink requests it. Such a sink is an operation that requests a Writable—for example, the leftshift operator call on streams or the evaluation of GStrings. The trick that StreamingMarkupBuilder uses to achieve this effect is similar to the approach of template engines. StreamingMarkupBuilder provides a bind method that returns a WritableClosure. This object is a Writable and a closure at the same time. Because it is a Writable, you can use it wherever the final markup is requested. Because it is a closure, the generation of this markup can be done lazily on-the-fly, without storing intermediate results.

Listing 12.8 shows this in action. The bind method also needs the information about what logic is to be applied to produce the final markup. Wherever logic is needed, closures are the first candidate, and so it is with bind. We pass a closure to the bind method that describes the markup logic.

For our initial example of pumping the path through, we use a special feature of StreamingMarkupBuilder that allows us to yield the markup generation logic to a Buildable, an object that knows how to build itself. It happens that a GPathResult (and thus path) is buildable. In order to yield the building logic to it, we use the yield method. However, we cannot use it unqualified because we would produce a <yield/> markup if we did. The special symbol mkp marks our method call as belonging to the namespace of markup keywords.

import groovy.xml.StreamingMarkupBuilder

def path = new XmlSlurper().parse(new File('data/plan.xml'))

def builder = new StreamingMarkupBuilder()
def copier = builder.bind{ mkp.yield(path) }
def result = "$copier"

assert result.startsWith('<plan><week ')
assert result.endsWith('</week></plan>')

There is a lot going on in only a few lines of code. The result variable for example refers to a GString with one value: a reference to copier. Note that we didn’t call it “copy” because it is not a thing but an actor.

When we call the startsWith method on result, the string representation of the GString is requested, and because the one GString value copier is a Writable, its writeTo method is called. The copier was constructed by the builder such that writeTo relays to path.build().

Figure 12.4 summarizes this streaming behavior.

Figure 12.4. UML sequence diagram for streamed building

Note how in figure 12.4, the processing doesn’t start before the values are requested. Only after the GString’s toString method is called does the copier start running and is the path iterated upon. Until then, the path isn’t touched! No memory representation has been created for the purpose of markup or iteration. This is a simplification of what is going on. XmlSlurper does have memory requirements. It stores the SAX event information you saw in section 12.1.3 but doesn’t process or store it in the processing-friendly Node objects.

Calling startsWith is like opening the outlet tap to draw the markup from the copier, which in turn draws its source information from the path inlet. Any code before that point is only the plumbing.

As a variant of listing 12.8, you can also directly write the markup onto the console. Use the following:

System.out << copier

Remember that System.out is an OutputStream that understands the leftshift operator with a Writable argument.

For this simple example, we could have used the SAX or StAX approaches you saw earlier. They would be even more streamlined solutions. Not only would they not need to process and store the tree-like data structures that XmlParser creates for you, but they also wouldn’t need to store the SAX event information. The same isn’t true for the more complicated scenarios that follow. As is common in many XML processing scenarios, the remaining examples have processing requirements that span multiple elements. Such scenarios benefit greatly from the ability to use GPath-style expressions.

Until now, we copied only the “cold” input. It’s time to light our heater. The goal is to produce the same GUI as in figure 12.3.

We start with the basis of listing 12.8 but enhance the markup closure that gets bound to the builder. In listing 12.9, building looks almost the same as in the “boiling” example of listing 12.7; only the evaluation of the week and task status needs to be adapted. We do not calculate the status in advance and store it for later reference, but do the classification on-the-fly when the builder lazily requests it.

Example 12.9. Streamed heating from XML to HTML

The cool thing here is that at first glance it looks similar to listing 12.7, but it works very differently:

This allows us to produce lots of output, because it is not assembled in memory but directly streamed to the output as the building logic demands. However, because of the storage of SAX event information on the input, this approach will not allow input documents as large as would be possible with SAX or StAX.

Figure 12.5 sketches the differences between both processing approaches with respect to processing requirements and memory usage. The process goes from left to right either in the top row (for “boiling”) or in the bottom row (for “streaming”). Either process encompasses parsing, evaluating, building, and serializing to HTML, where evaluating and building are not necessarily in strict sequence. This is also where the differences are: working on intermediate data structures (trees of lists and nodes) or on lightweight objects that encapsulate logic (iterators and closures).

Figure 12.5. Memory usage characteristics for the “boiling” vs. “streaming” strategies

That’s it for the basics of processing XML with the structures provided by the Groovy XML parsers.

In section 12.1.1, you saw that classic Java DOM parsers return objects of type org.w3c.dom.Node, which differs from what the Groovy parsers return. The Java way of processing such nodes is with the help of XPath. The next section shows how Java XPath and Groovy XML processing can be used in combination.

An XPath is an expression that appears in Java or Groovy as a string (exactly like regex patterns or SQL statements do). A full introduction to XPath is beyond the scope of this book, but here is a short introduction from a Groovy programmer’s point of view.^[7]

Just like a GPath, an XPath selects nodes. Where GPath uses dots, XPath uses slashes. For example

/plan/week/task

selects all task nodes of all weeks below plan. The leading slash indicates that the selection starts at the root element. In this expression, plan, week, and task are each called a node test. Each node test may be preceded with an axis specifier from table 12.7 and a double colon.

With these specifiers, you can select all task elements via

/descendant-or-self::task

With the shortcut syntax, you can select all total attribute nodes of all tasks via

//task/@total

A node test can have a trailing predicate in square brackets to constrain the result. A predicate is an expression made up from path expressions, functions, and operators for the datatypes node-set, string, number, and boolean. Table 12.8 lists what’s possible.^[8]

Table 12.9 shows some examples.

The next obvious question is how to use such XPath expressions in Groovy code.

Groovy comes with all the support you need for using XPath expressions in your code. This is because of the xml-apis*.jar and xerces*.jar files in your GROOVY_HOME/lib dir. In case you are running Groovy in an embedded scenario, make sure these jars are on your classpath.

We will use XPath through the convenience methods in org.apache.xpath. XPathAPI. This class provides lot of static helper methods that are easy to use even though the implementation is not always efficient.^[9] We will use

Node     selectSingleNode(Node contextNode, String xpath)
NodeList selectNodeList  (Node contextNode, String xpath)
XObject  eval            (Node contextNode, String xpath)

where XObject wraps the XPath datatype that eval returns. For converting it into a Groovy datatype, we can use the methods num, bool, str, and nodelist.

In practice, we may want to do something with all weeks. We select the appropriate list of nodes via XPathAPI.selectNodeList(plan,'week'). Because this returns a NodeList, we can use the object iteration methods on it to get hold of each week:

XPathAPI.selectNodeList(plan, 'week').eachWithIndex{ week, i ->
    // do something with week
}

For each week, we want to print the sum of the total and done attributes with the help of XPath. Each week node becomes the new context node for the XPath evaluation:

XPathAPI.selectNodeList(plan, 'week').eachWithIndex{ week, i ->
    println "
Week No. $i
"
    println XPathAPI.eval(week, 'sum(task/@total)').num()
    println XPathAPI.eval(week, 'sum(task/@done)').num()
}

Listing 12.10 puts all this together with a little reporting functionality that produces a text report for each week, stating the capacity, the total hours planned, and the progress in hours done.

Example 12.10. XPath to text reporting

XPath is used in two ways here—the querying capability is used to select all the week elements , and then attributes total and done are extracted with the eval method . We mix and match ways of accessing attributes, using DOMCategory to access the capacity attribute with the node.@attributeName syntax .

Such a text report is fine to start with, but it would certainly be nicer to show the progress in a chart. Figure 12.6 suggests an HTML solution. In a normal situation, we would use colors in such a report, but they would not be visible in the print of this book. Therefore, we use only a simple box representation of the numbers.

Figure 12.6. Screenshot of an HTML based reporting

Each box is made from the border of a styled div element. The style also determines the width of each box.

This kind of HTML production task calls for a templating approach, because there are multiple recurring patterns for HTML fragments: for the boxes, for each attribute row, and for each week. We will use template engines, GPath, and XPath in combination to make this happen.

Listing 12.11 presents the template that we are going to use. It is a simple template as introduced in section 9.4. It assumes the presence of two variables in the binding: a scale, which is needed to make visible box sizes from the attribute values, and weeks, which is a list of week maps. Each week map contains the keys 'capacity', 'total', and 'done' with integer values.

The template resides in a separate file. We like to name such files with the word template in the name and ending in the usual file extension for the format they produce. For example, the name GroovyPlans.template.html reveals the nature of the file, and we can still use it with an HTML editor.

<html>
  <head>
    <title>Current Groovy progress</title>
  </head>
  <body>
    <% weeks.eachWithIndex{ week, i -> %>
    <h1>Week No. $i</h1>
    <table cellspacing="5" >
        <tbody>
             <% ['capacity','total','done'].each{ attr -> %>
             <tr>
               <td>$attr</td>
               <td>${week[attr]} </td>
                 <td>
                     <div style=
"border: thin solid #000000; width: ${week[attr]*scale}px">
                        &nbsp;</div>
                </td>
            </tr>
            <% } // end of attribute %>
      </tbody>
    </table>
    <% } // end of week %>
  </body>
</html>

This template looks like a JSP file, but it isn’t. The contained logic is expressed in Groovy, not plain Java. Instead of being processed by a JSP engine, it will be evaluated by Groovy’s SimpleTemplateEngine as shown in listing 12.12. We use XPath expressions to prepare the values for binding. A special application of GPath comes into play when calculating the scaling factor.

Scaling is required so that the longest capacity bar is of length 200, so we have to find the maximum capacity for the calculation. Because we have already put these values in the binding, we can use a GPath to get a list of those and play our GDK tricks with it (calling max).

Example 12.12. Using XPath, GPath, and templating in combination for HTML reporting

The code did not change dramatically between the text reporting in listing 12.10 and the HTML reporting in listing 12.12. However, listing 12.12 provides a more general solution, because we can also get a text report from it solely by changing the template.

The kind of transformation from XML to HTML that we achieve with listing 12.12 is classically addressed with XML Stylesheet Transformation (XSLT), which is a powerful technology. It uses stylesheets in XML format to describe a transformation mapping, also using XPath and templates. Its logical means are equivalent to those of a functional programming language.

Although XSLT is suitable for mapping tree structures, we often find it easier to use the Groovy approach when the logic is the least bit complex. XPath, templates, builders, and the Groovy language make a unique combination that allows for elegant and concise solutions. There may be people who are able to look at significant amounts of XSLT for more than a few minutes at a time without risking their mental stability, but they are few and far between. Using the technologies you’ve encountered, you can play to your strengths of understanding Groovy instead of using a different language with a fundamentally different paradigm.

Before wrapping up our introduction of processing XML with Groovy, we should mention that although we think that you will find Groovy’s built-in XML features are suitable for many of your processing needs, you are not locked into using just those APIs. Because of Groovy’s Java heritage, many libraries and technologies are available for you to consider. We have already mentioned StAX and Jaxen. Here are a few more of our favorites:^[10]

Our introduction to Groovy XML could finish at this point, because you have seen all the basics of XML manipulation. You should now be able to write Groovy programs that read, process, and write XML in a basic way. You will need more detailed documentation when the need arises to deal with more advanced issues such as namespaces, resolving entities, and handling DTDs in a customized way.

The final section of this chapter deals not with the details of XML but with one of its most important modern applications: exchanging data between systems, and talking to web services in particular.

Our example uses a web service at http://www.webservicex.net, which provides a lot of interesting public web services. First, we fetch the service description for its currency converter like so:

import groovy.xml.Namespace

def url = 'http://www.webservicex.net/CurrencyConvertor.asmx?WSDL'

def wsdl = new Namespace('http://schemas.xmlsoap.org/wsdl/','wsdl')
def doc  = new XmlParser().parse(url)

println doc[wsdl.portType][wsdl.operation].'@name'

This prints the available operations:

["ConversionRate", "ConversionRate", "ConversionRate"]

The service exposes three operations named ConversionRate with different characteristics.^[20] We are interested in one that takes FromCurrency and ToCurrency as input parameters and returns the current conversion rate. Currencies can be expressed using a format like 'USD' or 'EUR'.

SOAP uses something called an envelope format for the request. The details are beyond the scope of this chapter—see the specifications for details. Our envelope looks like this:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ConversionRate xmlns="http://www.webserviceX.NET/">
      <FromCurrency>${from}</FromCurrency>
      <ToCurrency>${to}</ToCurrency>
    </ConversionRate>
  </soap:Body>
</soap:Envelope>

As you see from the ${} notation, this envelope is a template that we can use with a Groovy template engine.

Listing 12.19 reads this template, fills it with parameters for US dollar to euro conversion, and adds it to a POST request to the service URL. The request needs some additional request headers—for example, the SOAPAction to make the server understand it. We explicitly use UTF-8 character encoding to avoid any cross-platform encoding problems.

The service responds with a SOAP result envelope. We know it contains a node named ConversionRateResult belonging to the service’s namespace. We locate the first such node in the response and get the conversion rate as its text value.

Example 12.19. Using the ConversionRate SOAP service

At the time of writing, it prints

Current USD to EUR conversion rate: 0.8449

This is straightforward in terms of each individual step, but taken as a whole, the code is fairly cumbersome. One point to note about the implementation is hidden in locating the result in the response envelope. We use the serv namespace and ask it for its ConversionRateResult property, which returns a QName. We assign it to the result variable and make use of the fact that QName implements the equals method with strings such that we find the proper node.

SOAP is verbose compared to other approaches. It is verbose in the code it demands for execution and—more important—it is verbose in its message format. It is not unusual for SOAP messages to have 10 times more XML markup then the payload size.

However, the SOAP standard makes it possible to provide general tools for dealing with its complexity.

One of these tools is the GroovySOAP module, which eases the process of using web services. Download the required jar files as outlined at http://groovy.codehaus.org/Groovy+SOAP, and drop them into your GROOVY_HOME/lib directory. As an example of what you get from the GroovySOAP, listing 12.20 implements the SOAP client for the conversion rate service with a minimum of effort.

import groovy.net.soap.SoapClient

def url = 'http://www.webservicex.net/CurrencyConvertor.asmx?WSDL'
def remote = new SoapClient(url)

println 'USD to EUR rate: '+remote.ConversionRate('USD', 'EUR')

Now, that’s a lot groovier! Should your server be using a complex datatype in its response, GroovySOAP will unmarshall it and define a variable in your script. This can be demonstrated using the weather forecast located at webservicex.net. Using a place name located in the USA as an input, the web service replies with a one-week weather forecast in a complex document. Listing 12.21 nicely presents the data with the help of GroovySOAP.

import groovy.net.soap.SoapClient

def url = 'http://www.webservicex.net/WeatherForecast.asmx?WSDL'
def proxy = new SoapClient(url)
def result=proxy.GetWeatherByPlaceName("Seattle")

println result.latitude
println result.details.weatherData[0].weatherImage

Here’s the output:

47.6114349
http://www.nws.noaa.gov/weather/images/fcicons/sct.jpg

Suppose now that you want to develop your own server. GroovySOAP allows the construction of such a service from a simple Plain Old Groovy Object (POGO) representing your business logic. If you wanted to set up a small math server,^[21] you could have a script that looks like listing 12.22.

  double add(double op1, double op2) {
    return (op1 + op2)
  }

  double square(double op1) {
    return (op1 * op1)
  }

Note that there is nothing about the script that suggests it has anything to do with a web service. Listing 12.23 exposes this POGO as a web service.

import groovy.net.soap.SoapServer

def server = new SoapServer("localhost", 6990)
server.setNode("MathService")
System.out.println("start Math Server")
server.start()

This little bit of magic is possible thanks to the delegation pattern and introspection that enables GroovySOAP to generate automatically the web service interface by filtering the methods inherited from the GroovyObject interface.

It’s worth paying attention to this area of ongoing Groovy development. We anticipate that before long, new SOAP tools will arise and provide more functionality for using web services with Groovy.