Is anyone out there in the Ruby community working on an object
container similar to those in J2EE app servers? I’m aware of dRuby,
but according to my understanding (please correct me if I’m wrong) an
object container does a lot more than just enable remote access to
objects, it also provides such things as caching of recently fetched
objects, database connection pooling, and transactional support. It
seems to me that this would be a killer app for Ruby that would make
it stand head and shoulders above Python and Perl. It would also
eliminate any last thoughts in my mind about using Java for web apps.
After building a proof of concept DB-Mixin for internal use I got
mgalomaniac and thought of the same 
I’d like to start with a real
ObjectRationalBridge cause i’m bound to a relational db environment at
work. Using dRuby as remote access seems fine. Outstanding issues are:
a command framework (I like the design of webwork and I am implementing
a ruby clone, right now), access control (steel design from PAM?) and,
ehm, transaction control. Any volunteers? g
-billy.
···
On Sat, Aug 24, 2002 at 03:00:02PM +0900, Jason Underdown wrote:
Is anyone out there in the Ruby community working on an object
container similar to those in J2EE app servers? I’m aware of dRuby,
but according to my understanding (please correct me if I’m wrong) an
object container does a lot more than just enable remote access to
objects, it also provides such things as caching of recently fetched
objects, database connection pooling, and transactional support. It
seems to me that this would be a killer app for Ruby that would make
it stand head and shoulders above Python and Perl. It would also
eliminate any last thoughts in my mind about using Java for web apps.
–
Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0
eLösungen 89077 Ulm Fax: +49-731-399 499-9
Good question. Here’s my take.
J2EE - more specifically, EJB - enables those nice things like pooling,
transactions, caching, security, persistance (it may provide more or less than
this ;). You’re asking if we can make Ruby do the same, somehow.
The problem is, Ruby is analogous to Java (a computer programming language),
not EJB, which is essentially a standard which is more to do with services
that application servers provide rather than a programming language. The
only reason it has come about is because Sun has sat down with IBM, Oracle,
etc., and nutted out a standard so that EJBs can be deployed on all these
different application servers. This is the benefit of Sun controlling Java -
they have the muscle and the organisation to create these agreements at a high
corporate level.
This is why I say to myself: Java is a good environment; it needs a good
language.
And it can’t really be done in Ruby. My hope is than within two years Ruby
code can be compiled into JVM byte-code (via Parrot?) so that the J2EE platform
can be used in Ruby, Python, Perl, …
Gavin
···
----- Original Message -----
From: “Jason Underdown” junderdown@msn.com
Is anyone out there in the Ruby community working on an object
container similar to those in J2EE app servers? I’m aware of dRuby,
but according to my understanding (please correct me if I’m wrong) an
object container does a lot more than just enable remote access to
objects, it also provides such things as caching of recently fetched
objects, database connection pooling, and transactional support. It
seems to me that this would be a killer app for Ruby that would make
it stand head and shoulders above Python and Perl. It would also
eliminate any last thoughts in my mind about using Java for web apps.
Gavin Sinclair wrote:
This is why I say to myself: Java is a good environment; it needs a good
language.And it can’t really be done in Ruby. My hope is than within two years Ruby
code can be compiled into JVM byte-code (via Parrot?) so that the J2EE platform
can be used in Ruby, Python, Perl, …
Compiled Ruby would remove one major benefit with Ruby, its dynamic
nature. However, interpreted Ruby within a JVM is already a reality,
although still in beta, see http://jruby.sourceforge.net/.
We hope to have some kind of Java bytecode generation in the future.
/Anders
···
–
A n d e r s B e n g t s s o n | ndrsbngtssn@yahoo.se
Stockholm, Sweden |
Gratis e-mail resten av livet på www.yahoo.se/mail
Busenkelt!
J2EE - more specifically, EJB - enables those nice things like pooling,
transactions, caching, security, persistance (it may provide more
or less than
this ;). You’re asking if we can make Ruby do the same, somehow.The problem is, Ruby is analogous to Java (a computer
programming language),
not EJB, which is essentially a standard which is more to do
with services
that application servers provide rather than a programming
language.
Well, a standard in the sense that the single proprietary owner dictates the
rules.
But how can you have Enterprise Java™ Beans without, well, Java™?
The
only reason it has come about is because Sun has sat down with
IBM, Oracle,
etc., and nutted out a standard so that EJBs can be deployed on all these
different application servers. This is the benefit of Sun
controlling Java -
they have the muscle and the organisation to create these
agreements at a high
corporate level.
Was it agreement, or was it simply Sun declaring what the New Hot Java™
Technology would be, and others compelled to follow or drop out of the
Java™ game?
There are a lot of smart people at Sun, but, ultimately, decisions about
Java™ are based on what’s the best marketing strategy for Sun, not what’s
the best computer science.
This is why I say to myself: Java is a good environment; it needs a good
language.And it can’t really be done in Ruby. My hope is than within two
years Ruby
code can be compiled into JVM byte-code (via Parrot?) so that the
J2EE platform
can be used in Ruby, Python, Perl, …
What a nightmare. One reason I quit may previous job was because I was
compelled to work with J2EE™, on iPlanet™. There are some interesting
things about J2EE™, but none of them have to do with, or require,
Java™. There is no need to seek J2EE™ compatibility other than to
convince clueless managers to go ahead with some technology because it
adheres to familiar buzzwords.
I would hate to see Ruby get caught up in trying to play Sun’s game. If it
came to that, I’d much rather see effort put into getting Ruby compiled to
CLR byte-code and Ruby.net; Microsoft’s got a much slicker IDE. 
James
···
Gavin
“Gavin Sinclair” gsinclair@soyabean.com.au wrote in message news:000201c24d03$2caa8ad0$0c6332d2@nosedog…
Good question. Here’s my take.
J2EE - more specifically, EJB - enables those nice things like pooling,
transactions, caching, security, persistance (it may provide more or less than
this ;). You’re asking if we can make Ruby do the same, somehow.The problem is, Ruby is analogous to Java (a computer programming language),
not EJB, which is essentially a standard which is more to do with services
that application servers provide rather than a programming language. The
only reason it has come about is because Sun has sat down with IBM, Oracle,
etc., and nutted out a standard so that EJBs can be deployed on all these
different application servers. This is the benefit of Sun controlling Java -
they have the muscle and the organisation to create these agreements at a high
corporate level.
Yes, you are right, J2EE is just a standard implemented by several app
server vendors. But why couldn’t we adapt the J2EE standard so that
something like it could be implemented in Ruby? Corporate backing
would be helpful, but I don’t see it as necessary.
This is why I say to myself: Java is a good environment; it needs a good
language.
I agree.
And it can’t really be done in Ruby. My hope is than within two years Ruby
code can be compiled into JVM byte-code (via Parrot?) so that the J2EE platform
can be used in Ruby, Python, Perl, …Gavin
Why can’t it be done in Ruby??? The main obstacle as I see it is
coming up with a workable ‘component’ model. Obviously because Ruby
is an interpreted language, these would not be bytecode components let
alone binary components, but I think the word component is still
applicable here.
Gavin Sinclair wrote:
This is why I say to myself: Java is a good environment; it needs a good
language.And it can’t really be done in Ruby. My hope is than within two years Ruby
code can be compiled into JVM byte-code (via Parrot?) so that the J2EE
platform
can be used in Ruby, Python, Perl, …Compiled Ruby would remove one major benefit with Ruby, its dynamic
nature. However, interpreted Ruby within a JVM is already a reality,
although still in beta, see http://jruby.sourceforge.net/.
We hope to have some kind of Java bytecode generation in the future.
I hope to try JRuby in the not-too-distant-future.
Would Java bytecode generation preclude the dynamic nature?
/Anders
Gavin
···
----- Original Message -----
From: “Anders Bengtsson” ndrsbngtssn@yahoo.se
Yes, you are right, J2EE is just a standard implemented by several app
server vendors.
No, J2EE™ is something Sun owns, controls, drives, and dictates. It is
not a standard in any meaningful use of the word. We might just as well
talk about the Visual Basic “standard”.
But why couldn’t we adapt the J2EE standard so that something like it
could be implemented in Ruby?
Because getting caught up in Sun’s game would be self-defeating.
James
J2EE - more specifically, EJB - enables those nice things like pooling,
transactions, caching, security, persistance (it may provide more
or less than
this ;). You’re asking if we can make Ruby do the same, somehow.The problem is, Ruby is analogous to Java (a computer
programming language),
not EJB, which is essentially a standard which is more to do
with services
that application servers provide rather than a programming
language.Well, a standard in the sense that the single proprietary owner dictates the
rules.
But how can you have Enterprise Java™ Beans without, well, Java™?
Two sides:
- You can’t. They are defined in such a way that they use Java.
- EJBs is a “way of doing things” (relating to disributed objects) that is not
hardcoded in any language.
It’s a standard in the sense that together with prospective implementors and
prospective users, they have defined a mechanism, EJBs, and a set of services
(transactions, persistence, …) that the app server implementors must provide
so the users can:
- benefit from this technology
- port their distributed apps to other (compliant) platforms
So Sun is not dictating things. J2EE is IMO too verbose and a bit hacky, but
at least it was designed, with consultation, to give people what they want.
The
only reason it has come about is because Sun has sat down with
IBM, Oracle,
etc., and nutted out a standard so that EJBs can be deployed on all these
different application servers. This is the benefit of Sun
controlling Java -
they have the muscle and the organisation to create these
agreements at a high
corporate level.Was it agreement, or was it simply Sun declaring what the New Hot Java™
Technology would be, and others compelled to follow or drop out of the
Java™ game?
It was agreement. You probably don’t repect the people/companies that were
part of the agreement, but it was a collaborative effort. It’s not in Sun’s
interest to be so dictatorial, for the very reason that the services J2EE
provides is not in the realm of a programming language. If they didn’t
“co-operate” to some degree, the vendors, or somebody else, would fill the void
with another language.
There are a lot of smart people at Sun, but, ultimately, decisions about
Java™ are based on what’s the best marketing strategy for Sun, not what’s
the best computer science.
Of course. What’s your point? Of course Sun is trying to paint themselves
onto the scene. Their aim is not to create good computer science, but to make
money. We can expect, however, that the two will intersect somewhere.
Their aim is for people to be able to create distributes systems and integrate
with application severs in a standard way. What on earth is wrong with that?
This is why I say to myself: Java is a good environment; it needs a good
language.And it can’t really be done in Ruby. My hope is than within two
years Ruby
code can be compiled into JVM byte-code (via Parrot?) so that the
J2EE platform
can be used in Ruby, Python, Perl, …What a nightmare. One reason I quit may previous job was because I was
compelled to work with J2EE™, on iPlanet™. There are some interesting
things about J2EE™, but none of them have to do with, or require,
Java™. There is no need to seek J2EE™ compatibility other than to
convince clueless managers to go ahead with some technology because it
adheres to familiar buzzwords.
If you took over a large project that heavily used EJB, J2EE, app servers, and
the whole shebang, how would you reimplement it? Extra credit will be given to
solutions that are “pure computer science” and do not contain “™” anywhere.
Nor should there be any buzzwords.
I would hate to see Ruby get caught up in trying to play Sun’s game. If it
came to that, I’d much rather see effort put into getting Ruby compiled to
CLR byte-code and Ruby.net; Microsoft’s got a much slicker IDE.James
Ruby can’t play Sun’s game, unless a Sun-like company/consortium pushed Ruby as
the language to use to tie together “all these wonderful technologies”. And I
wouldn’t want to see Ruby playing that game, either.
Gavin
···
----- Original Message -----
From: " JamesBritt" james@jamesbritt.com
Gavin Sinclair wrote:
From: “Anders Bengtsson” ndrsbngtssn@yahoo.se
Compiled Ruby would remove one major benefit with Ruby, its dynamic
nature. However, interpreted Ruby within a JVM is already a reality,
although still in beta, see http://jruby.sourceforge.net/.
We hope to have some kind of Java bytecode generation in the future.I hope to try JRuby in the not-too-distant-future.
Would Java bytecode generation preclude the dynamic nature?
Not necessarily. Ideally we can create both something for just-in-time
compilation as well as something that can emit Java class files.
We’ll see what happens.
/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…
But how can you have Enterprise Java™ Beans without, well,
Java™?Two sides:
- You can’t. They are defined in such a way that they use Java.
- EJBs is a “way of doing things” (relating to disributed
objects) that is not
hardcoded in any language.
That “way of doing things” part is not unique to EJBs. EJBs are one
implementation of some fundamental ideas about distributed computing. If
Sun has devised a particularly clever take on these ideas, then it’s worth
looking at and adopting for Ruby. But not to provide any sort of vendor
compliance.
It’s a standard in the sense that together with prospective
implementors and
prospective users, they have defined a mechanism, EJBs, and a set
of services
(transactions, persistence, …) that the app server implementors
must provide
so the users can:
- benefit from this technology
- port their distributed apps to other (compliant) platforms
So Sun is not dictating things. J2EE is IMO too verbose and a
bit hacky, but
at least it was designed, with consultation, to give people what
they want.
It may be what (some) people want, and it may have come about because Sun
opted to listen to other vendors, but the bottom line is that it is what Sun
decides it is.
There are a lot of smart people at Sun, but, ultimately, decisions about
Java™ are based on what’s the best marketing strategy for
Sun, not what’s
the best computer science.Of course. What’s your point? Of course Sun is trying to paint
themselves
onto the scene. Their aim is not to create good computer
science, but to make
money. We can expect, however, that the two will intersect somewhere.
My point is that J2EE is a poor target to chase. It is changing, and will
always change. The changes will be based on Sun’s self-interest, which may
involve some collaboration, but will not likely pay much heed to
non-corporate interests.
Their aim is for people to be able to create distributes systems
and integrate
with application severs in a standard way. What on earth is
wrong with that?
Nothing. But their aim is to sell hardware and operating systems. If they
can create an interesting and valuable language/app server in the process,
then the stockholders will be happy, or at least not care.
I’m unclear how it is in Ruby’s interest to help prop up Sun’s API. I tend
to think it would doom Ruby to being perceived as a niche language, a mere
scripting tool.
If you took over a large project that heavily used EJB, J2EE, app
servers, and
the whole shebang, how would you reimplement it? Extra credit
will be given to
solutions that are “pure computer science” and do not contain
“™” anywhere.
Nor should there be any buzzwords.
Beats me. Why re-do it? Is it costing too much money to maintain? Would it
save money in the long run to rewrite it in Smalltalk or Lisp or C or
whatever? Can the company afford the initial cost to change? What’s the
business case? Does the company have a no buzzwords, no ™ policy?
I expect that, over time, Ruby will develop a set of libraries for building
app servers (R2EE!)and writing complex, large-scale distributed
applications. I would like to think that, as that happens, people will
prefer to build new systems using Ruby rather than Java (or whatever).
People will choose Ruby because they prefer the Ruby Way. I don’t see it
happening, though, if time is spent getting Ruby to play nice with some
alien API.
If we want to pick goals, don’t aim for J2EE. Aim past it.
James
Yes, you are right, J2EE is just a standard implemented by
several app
server vendors.No, J2EE™ is something Sun owns, controls, drives, and dictates.
It is
not a standard in any meaningful use of the word. We might just as
well
talk about the Visual Basic “standard”.But why couldn’t we adapt the J2EE standard so that something
like it
could be implemented in Ruby?Because getting caught up in Sun’s game would be self-defeating.
James
While blind obedience to J2EE is probably not a good idea, abject
refusal to consider it is arguably no better.
···
=====
Use your computer to help find a cure for cancer: http://members.ud.com/projects/cancer/
Yahoo IM: michael_s_campbell
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
While blind obedience to J2EE is probably not a good idea, abject
refusal to consider it is arguably no better.
Absolutely. Anyone interested in the idea should spend time working with
J2EE and consider the merits. I have, and think it a poor idea. YMMV,
though, and I’d like to hear what others think Ruby could gain borrowing
from app server frameworks.
For example, what (if anything) did J2EE get right? What other frameworks
are worth examining?
James
I expect that, over time, Ruby will develop a set of libraries for building
app servers (R2EE!)and writing complex, large-scale distributed
applications. I would like to think that, as that happens, people will
prefer to build new systems using Ruby rather than Java (or whatever).
People will choose Ruby because they prefer the Ruby Way. I don’t see it
happening, though, if time is spent getting Ruby to play nice with some
alien API.If we want to pick goals, don’t aim for J2EE. Aim past it.
James
Exactly! Nowhere in my initial post did I advocate implementing J2EE
in Ruby. Nor do I care if Ruby plays nicely with Java’s APIs, what I
do care about is having a good platform for developing web
applications.
Since database interaction is so crucial in all but the most trivial
of web applications, it makes sense to create a good abstraction
framework for your data. I think there are some good ideas that could
be borrowed and improved upon from the J2EE spec. I also think the
dynamic nature of Ruby is an even better fit for creating an app
server than Java.
Instead of bickering over J2EE, let’s exchange ideas on how we might
build such a thing. My first course of attack is to read through
Matsuo Hisanori’s Petit+Server and check out his ideas.
Jason
JamesBritt wrote:
For example, what (if anything) did J2EE get right? What other frameworks
are worth examining?
The automatic transactions during calls to components are really nice.
If the call returns, the transaction is committed. If it fails with an
exception, it is rolled back.
This removes the need to fumble with begin()/commit() in the application
code.
Also some of the distributed nature of J2EE is neat, even though I
believe the need for clustering at the app-server tier is exaggerated.
/Anders
···
–
A n d e r s B e n g t s s o n | ndrsbngtssn@yahoo.se
Stockholm, Sweden |
Gratis e-mail resten av livet på www.yahoo.se/mail
Busenkelt!
I sadly use J2EE every day for work and find it lots of work to get it to do
things. Perhaps my mind is too small for J2EE. However, I personally really
like the idea of something like JDO. I think you can achieve something like
JDO (effectively OR mapping) and have some nice tools to help manage your
persistence mappings without the need for an app server though. I am
currently experimenting with something along these lines, and having a blast
doing it too
Signed,
Holden Glova
···
On Wed, 28 Aug 2002 03:23, JamesBritt wrote:
While blind obedience to J2EE is probably not a good idea, abject
refusal to consider it is arguably no better.Absolutely. Anyone interested in the idea should spend time working with
J2EE and consider the merits. I have, and think it a poor idea. YMMV,
though, and I’d like to hear what others think Ruby could gain borrowing
from app server frameworks.For example, what (if anything) did J2EE get right? What other frameworks
are worth examining?James
I recently stumbled over OJB (http://jakarta.apache.org/ojb/) which is a
object relational bridge including a ODMG 3.0 complient API. Although I
didn’t tried it yet I think something like that is missing for ruby. Of
course, the API must be ruby like. The concept of blocks in ruby would
be great for transaction demarkation (sic?), e.g. I imagine writing db
access or generally access to persistent object like this:
def add_item_to_cart(item_ids)
transaction.serializable do
@warehouse.queryByValue(:id, item_ids) do |item|
item.instock -= 1
@cart[@item] += 1
end
end
end
-billy.
···
On Wed, Aug 28, 2002 at 12:23:10PM +0900, Jason Underdown wrote:
If we want to pick goals, don’t aim for J2EE. Aim past it.
Since database interaction is so crucial in all but the most trivial
of web applications, it makes sense to create a good abstraction
framework for your data. I think there are some good ideas that could
be borrowed and improved upon from the J2EE spec. I also think the
dynamic nature of Ruby is an even better fit for creating an app
server than Java.
–
Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0
eLösungen 89077 Ulm Fax: +49-731-399 499-9
For the web GUI side of things, you might want to look at WEBrick and
Amrita (both in the RAA). WEBrick is a Ruby framework for building
servers, and provides Ruby servlets for HTTP. Amrita is an XML and
HTML template system that provides a clean separation between code/data
and presentation.
Cheers,
Nat.
···
On Wed, 2002-08-28 at 04:23, Jason Underdown wrote:
Instead of bickering over J2EE, let’s exchange ideas on how we might
build such a thing. My first course of attack is to read through
Matsuo Hisanori’s Petit+Server and check out his ideas.
–
Dr. Nathaniel Pryce, Technical Director, B13media Ltd.
Studio 3a, 22-24 Highbury Grove, London N5 2EA, UK
http://www.b13media.com
And J2EE prodives transactions outside a database context. This is why
you can e.g. do a “add-to-cart-and-reduce-in-stock” operation can be
made safe even if the cart is held in memory.
-billy.
···
On Wed, Aug 28, 2002 at 04:41:26AM +0900, Anders Bengtsson wrote:
JamesBritt wrote:
For example, what (if anything) did J2EE get right? What other frameworks
are worth examining?The automatic transactions during calls to components are really nice.
If the call returns, the transaction is committed. If it fails with an
exception, it is rolled back.
This removes the need to fumble with begin()/commit() in the application
code.
–
Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0
eLösungen 89077 Ulm Fax: +49-731-399 499-9
while your example is bit more then i have yet provided, if your are
interested in being able to move you objects in and out of a database
with minimal fuss, i have created DBize (soon to be released as well) it
is primarily a mixin module that makes an object instantly
“relationable”. it also provides for subrecords (i.e. many-to-one table
relationships).
~transami
···
On Wed, 2002-08-28 at 02:04, Philipp Meier wrote:
I recently stumbled over OJB (http://jakarta.apache.org/ojb/) which is a
object relational bridge including a ODMG 3.0 complient API. Although I
didn’t tried it yet I think something like that is missing for ruby. Of
course, the API must be ruby like. The concept of blocks in ruby would
be great for transaction demarkation (sic?), e.g. I imagine writing db
access or generally access to persistent object like this:def add_item_to_cart(item_ids)
transaction.serializable do
@warehouse.queryByValue(:id, item_ids) do |item|
item.instock -= 1
@cart[@item] += 1
end
end
end