Okay, that makes sense. It really comes down to using a web server with
plugins for the dynamic elements. I do that in the Java world anyway,
but mostly for load balancing and other administrative purposes. I’ve
often thought separating the web server from the application server was
sometimes too many layers of indirection for small systems. It seems
now that I need an app server for the J2EE components and something else
(FastCGI, I guess) for the Rails applications.
A J2EE app server does more than just executing the servlets and JSPs.
It also provides a wide range of services, like naming, security,
transactions, resource pooling, and all the other so-called enterprise
services that the big vendors charge so much for.
(Other than open source JBoss, but you get the idea.)
It sounds to me, then, that there is no “Rails Application Server”.
Instead, the Rails framework builds those services into each web
application individually. That must be what convention over
configuration is all about. FastCGI handles the multithreading of web
apps, but everything else is in the framework itself.
It’s hard not to feel like we’re going backwards there, but the gain in
simplicity and productivity is wonderful.
I do wonder, though, whether that means there will eventually be a
market for a Rails Application Server, though.
Thanks for your help,
James Duncan Davidson wrote:
Ken K. wrote:
The Rails book talks about running Rails under Apache, but is there a
(relatively) easy way to deploy it to either Tomcat or JBoss? Is the
CGI servlet the only option?
Sounds like a relatively easy way to set yourself up a very bruised
forehead. First, running Rails in CGI mode is anticlimatic at best. The
setup of the Rails environment on each request would be painful. So,
you’d really want some Servlet that ran FCGI. And, even if one exists
(which, quite frankly I don’t know if one does), just thinking about it
makes my head hurt. Setting up Rails in a production environment can be
Even if you get it working, it’s not the right tool for the job. If
you’re just trying to dink around with Rails, use WEBrick. If you want
to put something up for real, use Lighty or Apache. If you want to
set up a server with some requests going to Rails and other requests
going to some Servlets, set up Apache with connectors to send some
requests to Tomcat and others to Rails via FCGI.
That’s interesting. One of the big reasons to use J2EE is that servlets
scale much better than CGI scripts because only a single instance of each
servlet is used to service all requests. Does that mean that using Rails
with Apache is going back to the CGI approach? The Rails book lists FastCGI
as an alternative to CGI. Does that change the situation?
FastCGI != CGI. The ability to have a long running program serve
multiple requests is exactly what FastCGI is all about.
Bottom line: This is a very different world than the Servlet one,
especially when it comes to setting things up. Lots of learning and
grappling with some very different concepts has to be done to make the
transition well. But don’t worry, it can be done.