From: JamesBritt <james@...>
Date: 2002-08-27T09:06:31+09:00
Subject: RE: Distributed Object Container

> > But how can you have Enterprise *Java(tm)* Beans without, well,
> *Java(tm)*?
>
> Two sides:
> 1. You can't.  They are defined in such a way that they use Java.
> 2. 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(tm) 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
> "(tm)" 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 (tm) 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