Guido Sohne
10/24/2006 11:21:00 AM
On 10/19/06, John Baylor <john.baylor@gmail.com> wrote:
> I know a lot of people are using ruby on rails for web apps, usually with
> Apache as the underlying app, but I don't know of anyone using ruby itself
> for a 24/7 application. Yes, some people are using webrick as their web
> server but they don't necessarily lose $$$ if their personal web site goes
> down.
I wrote several applications using Rails that are not web apps per se.
Rails is mostly used as a back end permitting rapid prototyping /
development and very quick domain modeling leveraging ActiveRecord
especially.
a) Check bank balance via SMS
User sends an SMS to a number attached to a GSM modem. Uses smstools
to retrieve the message, and execute a Ruby shell script that parses
the message and builds an HTTP GET request to transmit that
information to the Rails application. The application then does a
telnet into a legacy banking application (Temenos Globus, running on a
variant of the Pick database system called UniVerse) and does screen
scraping and such to login, query the balance and parse the results.
Once the information is retrieved, it uses a web based sms service to
transmit the results back to the user. Functionality to request new
cheque books, to retrieve the last N transactions on the account etc
also included. Also uses drb to move some of the lengthy operations
offline (such as transmitting the sms back).
b) Check bank balance via touch tone telephone
User dials a number which is handled by the Asterisk PBX software.
Uses voice synthesis software (Loquendo TTS engine, high quality
voices) to issue the voice prompts and to deliver the results in voice
format. Uses RAGI (ruby asterisk gateway interface) to handle the
incoming calls and to orchestrate the transaction. Uses
Rails/ActiveRecord as above, same infrastructure, different interface.
c) User verification via telephone call back
User initiates a transaction via web or via SMS and the system calls
the user back and asks him/her to authenticate using a PIN. Works only
from a mobile phone registered to the system and associated with that
user to achieve two factor authentication (what you have + what you
know). Built with RAGI + Rails + Asterisk.
d) Back end for point of sale handheld device applications
Merchant uses a GSM handheld point of sale device to perform various
transactions such as selling mobile topups, internet access (prepaid),
school fee payment etc. UI is on the point of sale device, fulfillment
/ business logic is handled remotely with a rails application. HTTP
GET is used to transmit parameters to the back end and the document
returned is a parseable response (JSON encoded). Secured by using
HTTPS, possible to use HTTPS certificates to ensure that each device
is uniquely identifiable and that a particular device can be disabled
remotely in case of fraud etc. POS application written in Lua / C.
GPRS / SMS message used as the network (data transmission) layer.
> I'm trying to talk my company into using ruby in a remote environment (a
> merchant's store) where it has to be solidly up 24/7 or the merchant will
> stop using our product. We should be able to SSH to the box if we need to
> but we'd rather not need to. While I have confidence that ruby can run in
> that environment, management would like to hear that someone else is already
> using it for a similar purpose. Are they?
Rails has been very, very stable for this purpose. Ran into a few
problems only using native extension written in C such as Ferret which
caused some crashes. Other problems came not from Ruby but from
interfacing with the external systems, such as having a server running
the banking software restarting, or hanging, and having to recover
from that situation. The best solution was to queue up messages in a
database table, and flag / purge them depending on whether they failed
or succeeded. A background or intermittent task then processes failed
attempts and informs the user if necessary.
I recommend sticking to pure Ruby if you want to have stability. Some
problems are with the Ruby application server going down (such as
Mongrel) but can be solved with some effort / luck / catching
exceptions properly, or using lighttpd and scripts to monitor or
restart the application when necessary.
Combined with capistrano for management of the remote applications,
SSH works very well for deploying / management and very much automated
with capistrano. With stability, you'll need to go through a test
period where you can shake out the little bugs that are inevitable.
-- G.