Savon Handsoap Shootout

This documentation is deprecated, please have a look at “”:!

p. Looking into “The Ruby Toolbox”: there are currently two popular “SOAP client libraries”: available. In this short article I am going to crunch the candidates “Savon”:, which is currently the most “popular” library, and “Handsoap”: which follows short after. Both are open source projects hosted on “github”:

h2. Scope

p. This article won’t cover all facets of both libraries. I concentrate on the features that are relevant for integrating a Ruby SOAP client into our particular SOA platform. That platform is commonly based on Java SOAP services based on frameworks such as “CXF”: and “Axis”: providing interfaces to internal business logic.

p. Since this is not a complete feature list, it should show you at least how to work with the APIs and which client might be the best choice for yourself.

h2. Requirements

p. Having lots of Java Guys around here, there is no great focus on things like beautiful API design or Ruby magic, the client should *just work*! Living in a Java environment, the SOAP client has to integrate smoothly with “JRuby”: Since a lot of Ruby libraries lack support for JRuby, we always have to monkey patch a lot of code to make it run on the JRE.

h2. Examples

p. We refer to free, public SOAP services, so everyone can run the examples by themselves.

p. All the examples seen here can be cloned/downloaded from “github”:

h2. Chapters

* “Calling a service”:
* “Accessing a WSDL”:
* “Authentication”:
* “Errors”:
* “Benchmark”:
* “JRuby”:
* “Conclusion”:

p. Have fun!

9 thoughts on “Savon Handsoap Shootout

  1. raus22

    Thanks for this great article series, this made me choose Savon because its just less code. and less code == more productive.

  2. admin Post author

    @raus22 I hope you enjoy using Savon. As as I know, it is still under construction, so it might get even cooler!

    @arun we also use Savon in a Rails app running with JRuby ;-) I might write something about that too…

  3. Jeremy Durham

    I’d love to see you review serviceproxy as well (, since it predates both handsoap and savon, and takes a similar approach. It doesn’t support things like WSSE authentication, because it was build specifically for the needs of our company. Serviceproxy has been used with JRuby apps for the last ~2 years in production.

    Also, nokogiri is available on JRuby 1.4, or libraries could choose to use hpricot as a parser (which is built using ragel and JRuby friendly) to keep performance up.

  4. phoet Post author

    I might come back on this topic later. I am currently writing on some example for integration of SOAP into Rails as a datastore.

  5. Tom Dyer

    I’d also like to see a comparison to ServiceProxy . I’ve used ServiceProxy in a couple of projects and it’s worked out very well.

  6. phoet Post author

    A mail from troels knak-nielsen, creator of Handsoap:

    Hi Peter.

    That’s a good comparison.

    There are a few points I’d suggest that you clarify though:

    First off, you should probably include soap4r. At least mention it as
    an option. It’s the grand old man of soap clients for Ruby, and if
    you’re looking for a reflection-based client, it’s fairly advanced.

    While inheritance is a base concept of object oriented programming,
    it’s usually better to use delegation instead. For not being stuck
    on the API of the Handsoap::Service class, one would wrap things up
    into some other class or module, creating more code than necessary.

    In general I agree on this sentiment, but in this case I don’t think
    it should carry much weight. Services are glue code, and so they
    depend strongly on the API, no matter which implementation style you
    use. I don’t really think it’s realistic to think that such code could
    ever be reused in any other context. So that makes it a moot point.
    There’s of course the matter of code reuse within the constraints of
    the library and there is testing, but Ruby has such powerful
    capabilities to get around this, that I don’t really see it as a
    practical problem. You can stub out the http driver during testing.
    There’s even a test-driver for the purpose.

    Regarding WSDL parsing:

    The WSDL parser is really just sugar on top for the Handsoap project.
    It’s not used during runtime. For most development, you should really
    use soapUI instead. That probably goes the same for Savon btw., but I
    think you should mention this awesome project, since way too few
    people are aware of its existence.

    Regarding authentication:

    Handsoap is quite deliberate about going low level. It might seem like
    a bit more work (and it is), but it makes it easier to code around
    quirky server side implementations in an orderly manner. Personally I
    think that the level of abstraction chosen in Handsoap is perfect, but
    that’s perhaps a subjective matter. Handsoap provides
    wrappers/adapters over the XML parsing and HTTP libraries instead,
    which allows the user to work with these in a uniform way, regardless
    of the underlying gem. I think that’s a very powerful tool.

    Finally, Handsoap has support for asynchronous services, through Event
    Machine. It’s probably a bit of an edge case, but for those that need
    it, it’s a powerful feature worth mentioning.


  7. Pingback: 洛阳铲的日志 : deeply play soap in ruby with SAVON or HandSoap

Comments are closed.