3

I need to make a decision between using Ruby vs. Java for SOAP integration. My entire web application is built on Ruby on Rails, and there is a significant back-end component that has to integrate with legacy systems using SOAP.

Java has extensive SOAP libraries like Apache Axis and seems to integrate very well with this type of "legacy" web services while Ruby has some gems like Savon and handSOAP.

I'm biased towards using Ruby libraries, but am concerned about performance / scalability issues. What are the performance/scalability issues attached with using Ruby?

To get more context, the integration with the legacy system has two components: a daily process, whose performance is less important, and a realtime query engine, whose performance is very important because users are waiting while the query is being handled.

Nicolas M.
  • 789
  • 1
  • 13
  • 23
  • 1
    Why do you believe the SOAP call will be the bottleneck? XML is relatively slow no matter what language you use. The real bottleneck is usually the DB and/or network. – Vladimir Dyuzhev May 04 '11 at 19:25
  • 2
    SAVON is _the_ gem of choice for most when you are forced to consume SOAP webservices. You could use HTTParty but you would have to manually deal with the envelopes. – Caley Woods May 04 '11 at 19:26

1 Answers1

4

I faced the same challenge recently. I originally went with Java, but wound up porting everything over to Ruby using Builder to construct the requests and Nokogiri for parsing the responses. I also use SoapUI to help with development/debugging of requests.

Why did I wind up going with Ruby over Java...

  1. Simpler infrastructure. Why have two different paradigms in your architecture if you don't need it. If your site is Ruby on Rails, why introduce Java into it unless you need it.
  2. Java has some nice libraries like Axis to convert SOAP requests to objects. But that really isn't a big problem., but really that isn't that much of a win when most of my logic is in Ruby. It was much easier for me just to work with the DOM through Nokogiri than to have intermediary Java objects.
  3. All of my logic (ActiveRecord model objects, validation, etc.) were all in Java. I wound up having to replicate logic like database persistence to communicate between the Java code and the Rails code...boo
  4. The performance concern seems like a red herring. If you are making SOAP requests, the network overhead will likely be your bottleneck, not the language parsing/executing.
Rob Di Marco
  • 43,054
  • 9
  • 66
  • 56
  • 1
    Thanks a lot. May I ask why you didn't use Savon or handSOAP in Ruby? – Nicolas M. May 04 '11 at 21:49
  • Sure. Short version is that I didn't see the win for using them. Builder makes it so easy to build the XML request document and then I had complete control over formatting. This was very helpful when using SoapUI for development/debugging as I could make namespace abbreviations match up perfectly so I could easily cut and paste requests back and forth. I really didn't feel that the libraries added any value. I was comfortable with Nokogiri/XPath to get at my results, why complicate anything. If you wanted more detail, I 'd be happy to do a Skype call and talk more about the decision. – Rob Di Marco May 05 '11 at 01:10
  • Thanks a lot for all the info. I contacted you through your website. Thanks! – Nicolas M. May 05 '11 at 23:32