I need to implement a web client in a Rails app. The existing web service is SOAP and can often take several seconds to respond to requests. Using SOAP4R, the requests block.
Is it acceptable to call these blocking methods directly from a rails controller? If not, should the rails controller buffer up commands with a separate service that would process SOAP commands and replies. Is there a third, better way?
It depends -- do they need to be processed in realtime (e.g. when the user hits GO it should actually fire?). If you are using mongrel, remember that any mongrel that is doing "something" will block and that is gross from a concurrency perspective (unless you have a ton of mongrels around). If you are using passenger, the hit from a long-running controller action isn't much of a problem provided you've got spare passenger instances open, too.
For things that can take place out-of-band (and have some delay, such as report processing or video conversion) I have a model called "JOBS" and then use script/runner (combined with cron) to call Jobs.process_jobs every few minutes.
Or, you could create a little script and place it in script/yourscript and call that every few minutes, too.
There's a third option, use a drb process, but -- in my experience -- I've found it to be a bit more "moving parts" than simply firing a cron every few minutes (or even just letting the controller action fire) and so I tend to avoid it unless I really need to (e.g. ferret).