Ruby on Rails is a great RAD framework. We use it all the time. But one place Rails loses its magic–while not the fault of the framework itself–is with external integrations to legacy systems.
First of all, soap4r sucks. Everyone I’ve seen try to pick it up has gotten frustrated and angry at how awkward it is to write a SOAP client in Ruby compared to Java and .Net tools, which can do the same thing in a matter of minutes. Since RoR IDEs aren’t exactly 1337 yet, we need to put some serious love here as a community to prevent larger companies with heavy SOA leanings from running away screaming.
For some reason, many people seem to think that pouring t3h Rails int3rn3ts into an infrastructure will suddenly trim 75%+ off all development and maintenance costs, complete with rounded corners and shrink-wrapped buttons. Wrong. Many of the development tasks will take significantly shorter times to develop under timeframe expectations relative to Java and .Net, yes, but you can’t avoid costs associated with migrating legacy data and integrating with retarded external systems such as your ghetto-ass SOAP services. Nor should you avoid design activities such as usability analysis or proper testing practices.
So if you have a web project that lives in complete isolation and does not have any legacy issues with which to deal, OpenRain can bust out that web project in a heartbeat. But if you have unresolved data management and integration issues, there is no acts_as_silver_bullet plugin which can save you the burden of having to actually think about and address those problems. Rails isn’t the cold bucket of water for your data nightmares.
5 replies on “The Truth About Integrating Rails In The Enterprise”
Why use soap4r? Doesn’t ActionWebService have its own SOAP interface?
I’ve used neither, btw, but you should bring up issues on ruby-talk if they haven’t been already.
It is unfortunate that the author has decided to disable the trackers and mailing list on the RubyForge project page.
the truth is that SOAP itself sucks
@soup
I think SOAP was very well intentioned, but overly complex for most situations. It takes too much time and code to produce and consume simple web services when having to deal with WSDLs and generate client objects. Granted it’s occasionally nice to have extremely well defined XML schemas, but for my own practical purposes I’d prefer simple REST or even XML-RPC APIs. I suppose the overhead of SOAP is culturally diametrically opposed to the “make the simple cases simple, and complex cases possible” attitude of the Rails community.
I’m not a SOAP fan, but I’ve done alot of legacy conversion and integration work.
And rails has hung in there with the best of them.
Even in one case the complete application was lost, and I re-did the application in rails,
just with the data. And it was days, instead of years.
Large Enterprises, are like the BORG, they absorb everything, and thus a huge wealth of
plugins are needed to solve it. I’m sure if there not a good soap plugin out there, it’s
easy enough to write one. (Having done a dbi from scratch, SOAP seems easy in comparison).
@glennswest
I agree 100% that Rails hangs in there with the rest of them!