Ruby Based App Server

I posted a similar question a few days ago, but didn’t get any
responses, so I’ll try again.

I’d like to know what the Ruby community thinks of app servers,
especially whether a Ruby based app server might be a good idea? Or
perhaps someone is already working on this?

I’ve worked on web applications built on the J2EE platform as well as
web applications done in Perl and PHP. Although I think Ruby is a
better choice in many respects than Perl and PHP for web applications,
it doesn’t have the database abstraction capabilities that you get
with EJBs in a Java app server. Of course there are less heavy-duty
ways to abstract access to a database than creating an app server, but
providing a framework for component based database access might be the
killer app that would make Ruby the language/platform of choice for
web applications.

What does the Ruby community think?

I’ve worked on web applications built on the J2EE platform as well as
web applications done in Perl and PHP. Although I think Ruby is a
better choice in many respects than Perl and PHP for web applications,
it doesn’t have the database abstraction capabilities that you get
with EJBs in a Java app server.

What is it that you like about EJBs that you would want to see done with
Ruby?
My experience with EJBs as a data abstraction layer soured me on the whole
thing. I found them to be bloated, inefficient, and buggy (well, the
iPlanet implementation at least).

Of course there are less heavy-duty
ways to abstract access to a database than creating an app server, but
providing a framework for component based database access might be the
killer app that would make Ruby the language/platform of choice for
web applications.

That may be, but I’m unconvinced that EJB/J2EE should be a model for any of
that.

James

well to get you started someone posted a whole database pool/persistence
module here about a month ago in response to my asking about persistent
connections in web apps. if you want, i dig around for it, but you may
be able to fins it just as easily. so as far as that portion of such a
beast goes it’s already ready to go!

~transami

What does the Ruby community think?

I have wrestled for 6 months with a idea of writing somthing like this
in C++ and embedding Ruby into a C++ shell of rich objects.
Ultimately I would extend the server using both C/C++ and Ruby.

I have recently come to the conclusion that writing such a beast in
pure Ruby is the only way. Writing an app server covers so much
ground. The implementation could remain a prototype for three years
if it were written in C++. Ruby would be the only way to get off the
ground in less than a year. Porting would be much easier if the
server were written in pure Ruby.

Application servers are mini-operating systems in their own right.

iPlanet was a disaster; JBoss, BEA, JRun, and Tomcat are fantastic
implementations. Even Zope/Python has made a run.

//ed

Also, don’t forget about IOWA, which was an app server written in pure
ruby which the original author abandoned for Small-Talk.

I’m sure we could patch together a lot of great code to get us
started; my only objection is having a quick start only to end up with
a kludge isn’t a great idea. Better to caulk board this out for
awhile, find out who the real design team is going to be, and make
coding the last thing we do since it will be a long long journey.

//ed

Steven Stanfield is working on `Ocelot’, a simular architecture to Tomcat.

//ed

If you are interested in building unit tested websites, check out
NARF:

http://narf-lib.sourceforge.net/doc/

NARF is a cgi api designed to facilitate unit testing of cgi scripts
w/out a web server. In addition to using get / post / mod_ruby ways
of setting state, there are also programmatic shortcuts to set things
like parameters, cookies, the output stream, etc.

The goal is to make testing cgis in a black box manner as easy as
possible. Given these inputs, the following output is returned, etc.
We test cgi’s from the lowest possible level, so that in larger
applications the appropriate framework can evolve.

NARF is currently tagged as alpha. If you want to experiment give it
a try and let us know what you think!

~ Patrick May

JamesBritt wrote:

What is it that you like about EJBs that you would want to see done with
Ruby?
My experience with EJBs as a data abstraction layer soured me on the whole
thing. I found them to be bloated, inefficient, and buggy (well, the
iPlanet implementation at least).

I’ve heard some bad things about early versions of iPlanet, but don’t
know how it is now.

Of course there are less heavy-duty
ways to abstract access to a database than creating an app server, but
providing a framework for component based database access might be the
killer app that would make Ruby the language/platform of choice for
web applications.

That may be, but I’m unconvinced that EJB/J2EE should be a model for any of
that.

As a whole it is kind of horrible, but it has some nice qualities: The
transaction model (every call to a bean starts a new transaction if
there isn’t one already), the name-lookup of beans, and perhaps even
parts of the persistence model. On top of those nice ideas are a ton of
huge and complicated APIs and configuration options.
It would be possible to build something nice and much simpler in Ruby
based on those ideas, with transparent object persistence, among other
things.

/Anders

···

A n d e r s B e n g t s s o n | ndrsbngtssn@yahoo.se
Stockholm, Sweden |


Följ VM på nära håll på Yahoo!s officielle VM-sajt www.yahoo.se/vm2002
Håll dig ajour med nyheter och resultat, med vinnare och förlorare…

JamesBritt wrote:

What is it that you like about EJBs that you would want to see done with
Ruby?
My experience with EJBs as a data abstraction layer soured me on the whole
thing. I found them to be bloated, inefficient, and buggy (well, the
iPlanet implementation at least).

I was of the same opinion, really, until I found that I created most of the
same bloat, on the fly, without any real design, because it was needed.
Better to sit down and plan it, and best, to share it, so we don’t all
write the same thing twice. Keeping it small and simple, of course, is
still desirable. I like a lot of the stuff happening at
jakarta.apache.org, though I am not a fan of Java. Perhaps some of that
would be a useful place to start.

It wouldn’t hurt to better define what is meant by “Application Server”. To
me, good things to have would include:

– A persistent/pooled connection server for Ruby-DBI, as well as persistent
connections at the mod_ruby level.
– An object server that brings objects into being from dups or from in-core
serialization (when designing web sites in ruby, the require statements can
take forever, and this is magnified with a good sized framework)
– Lightweight object persistence for Ruby-DBI
– XML-defined controller-level abstraction for interface objects/use case
objects
– A flexible templating system (not sure that ERb isn’t fine already)

Keys to this: they have to be able to work adequately as separate
components, and very well together. They should all use only freely
available components. Last of all, and this is just something that bothers
me: they shouldn’t just be copies of the way Language X does something,
with the assumption that you have used Language X and would rather read the
documentation to original Language X implementation.

–Gabriel

may i offer a suggestion for the communication protocol for this
promising App Server you all are cooking up?

i recently needed to create an mini-app server myself for my accounting
application in order to make it a 3-tier system. so i created ONI or
Object Network Interface (very soon to be put on the RAA). the best part
is that it uses YAML for message headers and serialization of objects.
it works fantastically! it just needs to be beefed up. would you all be
interested in using it in your pursuits? (i also would like to get it
using the philosopy of REST if possible)

~tom

p.s. BTW, here’s that DB pool code i was talking about before:

···

–=-=-=
Content-Type: application/octet-stream
Content-Disposition: attachment; filename=dbasePool.rb

require ‘config’
require ‘dbi’
require ‘thread’

=begin
=end

class DbasePool
@@classMutex = Mutex.new
@@connectionFreed = ConditionVariable.new
@@instance = nil
@monitorThread
@pool
@poolSize
@monitorThread

attr_reader :host, :dbaseName
attr_reader :userName, :password, :monitorInterval

def initialize(host = nil, dbaseName = nil, userName = nil, password =
nil,
poolSize = 5, monitorInterval = 3600)
if @@instance then raise “Attempted to re-init DbasePool” end

@@classMutex.synchronize {
  @host = host
  @dbaseName = dbaseName
  @userName = userName
  @password = password
  @poolSize = poolSize
  @monitorInterval = monitorInterval #in seconds, 0 to disable

monitoring.
@pool =
0.upto(@poolSize-1) do |i|
conn = @pool[i] = connect
class << conn
attr_accessor :status
attr_accessor :parent
def freeConnection
parent.freeConnection(self)
end
#Now override several DBI’s methods.
#The default methods suck big time.
#Also, the MySQL DBD driver does not
#reflect true capability of MySQL.
#So, the following changes allows for nested transaction,
#and also provide transaction for any database that support it
#regardless of what the DBD driver may say.
attr_accessor :transaction_depth
def begin_transaction
if @transaction_depth == 0
self.do(“BEGIN”)
puts “DBASE_POOL: Transaction started”
end
@transaction_depth += 1
end
def commit_transaction
if @transaction_depth == 1
self.do(“COMMIT”)
puts “DBASE_POOL: Transaction stopped”
end
@transaction_depth -= 1
end
def rollback_transaction
if @transaction_depth == 1
self.do(“ROLLBACK”)
puts “DBASE_POOL: Transaction rolled back”
end
@transaction_depth -= 1
end
def transaction
raise InterfaceError,
“Database connection was already closed!” if @handle.nil?
raise InterfaceError, “No block given” unless block_given?
begin_transaction
begin
yield self
commit_transaction
rescue Exception
rollback_transaction
raise
end
end
end
conn.status = “IDLE”
conn.parent = self
conn.transaction_depth = 0
end
@monitorThread = Thread.new do
while(true)
sleep(monitorInterval)
@@classMutex.synchronize {
#puts “HAI, monitoring is awake”
@pool.each do |conn|
if (conn.status == “IDLE”) && (not conn.ping)
conn = connect
end
end
}
end
end
@@instance = self
}
end

def connect
DBI.connect(“DBI:Mysql:#{@dbaseName}:#{@host}”, @userName,
@password)
end

#What’s the destructor name in Ruby?
def finish
@@classMutex.synchronize {
@monitorThread.stop
@pool.each do |conn|
conn.disconnect
end
}
end

#Get the next idle connection. If there is no idle connection, will
block
#until there is one.
#Optionally accepts a block. If a block is given, will execute the
block
#and free up the connection afterwards.
def getConnection
idleConn = nil #predeclare
@@classMutex.synchronize {
callcc do |cont|
idleConn = @pool.find do |conn|
conn.status == “IDLE”
end
if not idleConn
puts “No more free connection in DBASE_POOL. Waiting…”
puts @@instance.inspect
puts caller.join(“\n”)
@@connectionFreed.wait(@@classMutex)
puts “DBASE_POOL: a connection is freed. Resuming.”
cont.call
end
end
idleConn.status = “BUSY”
}
if block_given?
yield idleConn
idleConn.freeConnection
else
idleConn
end
end

def freeConnection(usedConn)
conn = nil #predeclare
@@classMutex.synchronize {
conn = @pool.find do |conn|
conn == usedConn
end
}
if conn
conn.status = “IDLE”
@@connectionFreed.signal
else
raise “Cannot found the referred connection!”
end
end
end

Initialise DBASE_POOL

DBASE_POOL = DbasePool.new(Config::DBASE_HOST,
Config::DBASE_DBNAME,
Config::DBASE_USER,
Config::DBASE_PASSWORD)

if $0 == FILE
#test, and also benchmark.
#on AMD-K62 400MHz, can do 217 SELECT NOW() statements per second.
1.upto(1000) do |i|
puts i if i % 100 == 0
dbh =
1.upto(5) do |i|
dbh[i] = DBASE_POOL.getConnection
end
1.upto(5) do |i|
dbh[i].execute(“SELECT NOW()”)
end
1.upto(5) do |i|
DBASE_POOL.freeConnection dbh[i]
end
1.upto(5) do
DBASE_POOL.getConnection do |dbh|
dbh.execute(“SELECT NOW()”)
end
end
end
end

–=-=-=–
<^>

On Tue, 2002-08-27 at 23:43, Edward Wilson wrote:

What does the Ruby community think?

I have wrestled for 6 months with a idea of writing somthing like this
in C++ and embedding Ruby into a C++ shell of rich objects.
Ultimately I would extend the server using both C/C++ and Ruby.

I have recently come to the conclusion that writing such a beast in
pure Ruby is the only way. Writing an app server covers so much
ground. The implementation could remain a prototype for three years
if it were written in C++. Ruby would be the only way to get off the
ground in less than a year. Porting would be much easier if the
server were written in pure Ruby.

Application servers are mini-operating systems in their own right.

iPlanet was a disaster; JBoss, BEA, JRun, and Tomcat are fantastic
implementations. Even Zope/Python has made a run.

//ed


~transami

What does the Ruby community think?

When you start with the project just send me an e-mail and I will partecipate.
I have experience with JBoss and a little of Zope, architectural and design
patterns, Java, C++, OO Perl and, of course, Ruby.

Best regards,
Mauro

Do you have a URL for Ocelot?

How will it differ from WEBrick?

Cheers,
Nat.

···

On Wed, 2002-08-28 at 16:50, Edward Wilson wrote:

Steven Stanfield is working on `Ocelot’, a simular architecture to Tomcat.


Dr. Nathaniel Pryce, Technical Director, B13media Ltd.
Studio 3a, 22-24 Highbury Grove, London N5 2EA, UK
http://www.b13media.com

Edward Wilson said:

Also, don’t forget about IOWA, which was an app server written in pure
ruby which the original author abandoned for Small-Talk.

I’ve taken up development on IOWA, and am just about finished uploading
a set of changes that I’ve made to it for my own production use. It’s
still very much alpha, but I’m getting more time to work on it and have a
lot of work planned for it.
I’ll announce the updates to SourceForge in probably the next day or so.

Kirk Haines

In article 5174eed0.0208280719.4c293e39@posting.google.com,

Also, don’t forget about IOWA, which was an app server written in pure
ruby which the original author abandoned for Small-Talk.

I’m sure we could patch together a lot of great code to get us
started; my only objection is having a quick start only to end up with
a kludge isn’t a great idea. Better to caulk board this out for
awhile.

    • caulk board, now there’s a design metaphor. Writing out your
      design in lines of sticky white goo that becomes difficult to
      remove in half an hour. Man, that sounds a lot like some of the
      projects I’ve worked on.
    • Sorry, I just couldn’t resist… that image has burned into
      my brain. I know you meant chalk, but caulk board could catch
      on as an anti-pattern like “spagetti code”.
    • Booker C. Bense
···

Edward Wilson web2ed@yahoo.com wrote:

Hi,

I’m sorry since I do not know in detail about J2EE, if wrong.

– An object server that brings objects into being from dups or from in-core
serialization (when designing web sites in ruby, the require statements can
take forever, and this is magnified with a good sized framework)

I wrote a library which manages session objects using dRuby.
It works with WEBrick or CGI, mod_ruby…

– A persistent/pooled connection server for Ruby-DBI, as well as persistent
connections at the mod_ruby level.

I wrote a simple connection pool. It’s included in Div.

  •   while(PQisBusy(conn) == 0) {
    
  •           result = PQgetResult(conn);
    
  •           if(result == NULL)
    
  •                   break;
    
  •   while(result = PQgetResult(conn)) {
              PQclear(result);
      }
    
···
  •   if (!PQsendQuery(conn, RSTRING(str)->ptr)) {
              rb_raise(rb_ePGError, PQerrorMessage(conn));
      }
    

Keys to this: they have to be able to work adequately as separate
components, and very well together. They should all use only freely
available components. Last of all, and this is just something
that bothers
me: they shouldn’t just be copies of the way Language X does something,
with the assumption that you have used Language X and would
rather read the
documentation to original Language X implementation.

I heartily second this last point. I get concerned when I read posts
advocating Ruby applications designed to follow a spec designed with another
language in mind. Compatibility/interoperability are interesting goals in a
general sense, but carry certain risks.

There was a lengthy thread on ruby-talk concerning Ruby, XML, and W3C specs.
By and large, while many people felt adherence to specs made certain tasks
easier to understand, those specs were not written with Ruby in mind, and
blind adherence would mean foregoing much of Ruby’s elegance. The
particular case was the W3C XML DOM. It’s a “standard” in the general
W3C-spec sort of way, and many people are familiar with it, but the API just
falls flat compared to how one can manipulate XML using a Ruby Way API (see
REXML).

So, specs like EJB or J2EE or Ant may be the best thing since sliced bread
for the Java crowd, but they don’t reflect a Ruby Way of doing certain
things. We should steal the better ideas and then build things that play
best with Ruby.

James

···

–Gabriel

“Nat Pryce” nat.pryce@b13media.com schrieb im Newsbeitrag news:1030555421.4703.4.camel@ballsup…

···

On Wed, 2002-08-28 at 16:50, Edward Wilson wrote:

Steven Stanfield is working on `Ocelot’, a simular architecture to Tomcat.

Do you have a URL for Ocelot?

How will it differ from WEBrick?

See http://www.virtualschool.edu/ile/tut/Pages/References/OcelotRefsPage

Cheers
Horst

check in: http://ourworld.compuserve.com/homepages/OCELOTSQL/dbms.htm

···

----- Original Message -----
From: “Nat Pryce” nat.pryce@b13media.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, August 28, 2002 12:35 PM
Subject: Re: Ruby Based App Server

On Wed, 2002-08-28 at 16:50, Edward Wilson wrote:

Steven Stanfield is working on `Ocelot’, a simular architecture to
Tomcat.

Do you have a URL for Ocelot?

How will it differ from WEBrick?

Cheers,
Nat.


Dr. Nathaniel Pryce, Technical Director, B13media Ltd.
Studio 3a, 22-24 Highbury Grove, London N5 2EA, UK
http://www.b13media.com

I have posted a newer version of ocelot. It can be found at
http://www.ocelot.scarecrowtech.com/.

It is substantially the same as what you will get from Brad’s site but I
have cleaned up a few things that might be pain for a new user (handles
missing ‘/’ for webapps better, will log to stdout if it is open instead
of just to the log file, and will return an error 404 in some cases that
caused it to just drop the connection before). The example webapps are
a bit of a mess right now, but they should be able to demonstrate
things. I plan to clean things up some more over the next couple of
days (and add a real website to support it).

Not sure how it compares to WEBrick since I have never used it.

Ocelot started out to be a clone of a Java Servlet container but it’s
API has changed a lot since then (mostly thanks to the influence of Brad
Cox who is using it with his ILE project-
http://www.virtualschool.edu/ile/index.html).

It also supports RSP pages (basically JSP pages that use Ruby instead of
Java), including the Java method of “compiling” the RSP page to a Ruby
class (servlet) and using that. Also it does not require anything other
than Ruby to run. I want to keep it small and simple (at least the core
package) so it should be easy to check out.

Steven Stanfield

···

On Wed, 2002-08-28 at 13:35, Nat Pryce wrote:

On Wed, 2002-08-28 at 16:50, Edward Wilson wrote:

Steven Stanfield is working on `Ocelot’, a simular architecture to Tomcat.

Do you have a URL for Ocelot?

How will it differ from WEBrick?

Cheers,
Nat.


Dr. Nathaniel Pryce, Technical Director, B13media Ltd.
Studio 3a, 22-24 Highbury Grove, London N5 2EA, UK
http://www.b13media.com

Keys to this: they have to be able to work adequately as separate
components, and very well together. They should all use only freely
available components. Last of all, and this is just something
that bothers
me: they shouldn’t just be copies of the way Language X does
something, with the assumption that you have used Language X and would
rather read the
documentation to original Language X implementation.

I heartily second this last point. I get concerned when I read posts
advocating Ruby applications designed to follow a spec designed with
another language in mind. Compatibility/interoperability are
interesting goals in a general sense, but carry certain risks.

There was a lengthy thread on ruby-talk concerning Ruby, XML, and W3C
specs. By and large, while many people felt adherence to specs made
certain tasks easier to understand, those specs were not written with
Ruby in mind, and blind adherence would mean foregoing much of Ruby’s
elegance. The particular case was the W3C XML DOM. It’s a “standard” in
the general W3C-spec sort of way, and many people are familiar with it,
but the API just falls flat compared to how one can manipulate XML using
a Ruby Way API (see REXML).

So, specs like EJB or J2EE or Ant may be the best thing since sliced
bread for the Java crowd, but they don’t reflect a Ruby Way of doing
certain things. We should steal the better ideas and then build things
that play best with Ruby.

James

I agree with all this, too. There must be some good ideas we can steal
from EJB, but I would definitely not want to see a large resemblance.

In the related thread (Distributed Object Containers) when I mentioned
that I hope in N years that Perl, Ruby, Java, etc. are interoperable to a
large degree, I did have in mind that Ruby could then leverage EJB or
whatever (others have mentioned Swing, I would add CPAN). However, these
are general goals, and I do believe that a Ruby way can (most likely will)
evolve to handle application-server-related tasks.

But it won’t happen overnight; it’s a big task.

Gavin