SOAP-proxy in Scala - what do I need?

Question

I'm trying to write a program in Scala, that will accept SOAP-requests, get the response from the real server (or read it from the local disc) and return the data to the original client.

I'm new to the java/scala ecosystem, so I have no clue, what libraries to choose. I heard Scala's XML-handling is quite nice, so I don't know, whether I should use some enterprisey soap-library/framework like jax-ws, jboss-ws, axis, cxf, xmlbeans, etc.

Basically, I just need

• a library, that accepts the requests (currently, I'm looking at jetty, but I'd prefer something that natively supports actors. scala-http seems to cover that, but isn't production-ready or maintained, for that matter)
• some library to request the data from the other server (something like curl, libwww-perl for java/scala)
• a build system (ant? sbt?)
• an IDE (I'm used to eclipse, but IntelliJ's scala support is supposed to be better)
• a tool to test it (currently, I'm using SoapUI)

Answer 1

Just a partial answer.

Look at:

• HttpClient for making HTTP requests
• Build system, if you have no prior experience with ant I would recommend sbt
• For the IDE, I had good success with IntelliJ a few months ago. I believe Eclipse has improved but I don't know how much.
• SoapUI would still work perfectly

Answer 2

SOAP is truly a hideous specification, with lots of potential for unusual fringe behaviour. While it's true that XML support in Scala would help you write such a library from scratch, it would still be a major effort (depending on how much of the spec you need).

Likewise, Jetty has years of development behind it; dealing with performance demands and other unexpected behaviour that you probably haven't considered... Even Scala's best-known web framework, Lift, runs atop a Java web server for these very reasons. It still works very happily with actors.

So, at this moment in time, you're almost certainly better off using a tried and tested solution with a Java web server and an off-the-shelf Java SOAP Library. The effort to add a thin Scala wrapper around these will be far less than the effort to build these things from scratch.

For the build system, sbt is the most powerful tool presently available for Scala, but you may need to fall back to Maven if this is needed for code generation by your chosen SOAP library.

Finally, for the choice of editor. If you're happy using Emacs, then the Ensime plugin is just amazing. If a more conventional Java IDE is to your liking, then IntelliJ currently seems to be the most stable option, though be aware that this could change very quickly.

Answer 3

Proxy servers are a classic use case for asynchronous/non-blocking IO. If I were embarking on this project, I'd start by taking a long look at Netty's HTTP support and build a simple reverse proxy (i.e. forwards front-end requests to backend servers, and backend responses to frontend clients) first before moving on to protocol translation.

When it comes time to work on protocol translation, you'll incur the wrath of XML parsers. Unfortunately, to my knowledge there isn't a good, high-performance, low-footprint parser that natively handles asynchronous IO; quite a few of them probably exist but are embedded in commercial products. See this thread for more information.

However, you can "cheat", at the cost of additional thread use, by using a SAX parser, which typically relies on blocking IO, to consume the output of a "push-me-pull-you" pipeline. Since the HTTP parts of your server are non-blocking, you can probably afford to use a few dozen threads just for shoveling bytes around.

As it happens, I've been there, and done that. :)