Using SOAP with Scala

It seems I have inadvertently become “that guy who does SOAP with Scala”. Given this illustrious position it seemed prudent to get around to putting up an article that explains how to use the SOAP support now present in “Scalaxb”:http://scalaxb.org/.

Scalaxb is a nice tool for working with XSD Schema from Scala, and recently WSDL support was added. In short this means that you can use native Scala types (such as Option[T]) for interacting with SOAP methods.

Prerequisites

Before you get going, its necessary to install Scalaxb, which itself requires “Conscript”:https://github.com/n8han/conscript/, so install that first. With ConScript in place, install Scalaxb by running:

cs eed3si9n/scalaxb

This will install Scalaxb and make it available on your $PATH. You can verify this by running the scalaxb command.

Generating Contracts

With Scalaxb installed and your WSDL to hand, you can run something like:

scalaxb -p eu.getintheloop.sample \ 
        -d src/main/scala \
        src/main/wsdl/weather.wsdl

This will generate a range of .scala files pertaining to the WSDL contract you passed as the last argument to the scalaxb tool. In addition this sample includes the -p to specify your own package and also the -d argument to place the output files into my Scala source directory. In this particular case, I’m using “this SOAP endpoint”:http://www.deeptraining.com/webservices/weather.asmx?wsdl, and you can freely do so too for the sake of this example.

Understanding Generated Classes

Scalaxb generates three separate components:

• SOAP protocol classes: These are the ancillary classes that are used to operate the SOAP protocol for things like the message envelope.
• Default transport implementation: The HTTP driver to actually POST the SOAP message to the endpoint URI. This default implementation is based on the blocking HTTP “Scala Dispatch”:http://dispatch.databinder.net/Dispatch.html
• Your service contracts: This is the only service specific part of the generated files. These relate to your specific service whilst the other two parts are completely decoupled and reusable over implementations / services you might have.

Enough talking, lets look at some code.

Usage

The Scalaxb SOAP mechanism makes heavy use of the cake pattern, and thus allows you to mix and match different components as your situation dictates. Here’s the default usage pattern:

package eu.getintheloop.sample

import scalaxb._

object Main {
  def main(args: Array[String]){
    
    val remote = new WeatherSoap12s 
       with SoapClients 
       with DispatchHttpClients {}
    
    println {
      remote.service.getWeather(Some("New York"))
    }
  }
}

Note specifically that by combining the weather service contracts with the SOAP protocol classes and the transport implementation, the result is a working driver from which you can directly call the SOAP methods.

The result of the service call itself is a Either[Fault[_], Option[T]], so if you want to get at the actual value you can just simply fold on the Either.

Suggestions for Customisation

If you have multiple services to interact with then it can be nice to cake together all your service implementations so that you just have a single client that lazily loads the appropriate service classes as needed. Additionally, you could also replace the transport implementation with something asynchronous and based on futures… that also is fun.

The sample code for this example can be found at: “https://github.com/timperrett/scalaxb-soap-example":https://github.com/timperrett/scalaxb-soap-example

Enjoy.