[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EJBs are nonsense (was: Re: *URGENT* -- Call for support)

On Thu, 25 Jan 2001, Sean Allen wrote:
> On 25 Jan 2001 21:32:58 +0100, Carl Rosenberger wrote:
> > Hi James, Falko,
> > 
> > > > > * EJB market is a huge potential for ODBMS
> > 
> > > Or should we just switch to EJB?
> > > Or am I completely wrong?...
> > 
> > my 2 cents from reading Monson-Haefel "Enterprise Java Beans":
> > 
> > EJBs are awful, as long as
> > - you have to code them from hand
> > - performant database mapping is not widely provided
> > - the standard is not widely adopted
> > 
> > A friend of mine, roemer@cs.uni-bonn.de is currently experimenting with
> > jBoss and his experiences match my statement.
> > 
> > If an IDE would automate all the work perfectly (not likely to happen) and
> > there would be a bugfree and superfast server (will never happen) I would
> > reconsider my judgement.
> > 
> > If I would need to code business-logic I would not want to worry about
> > session- entity- stateless- or whatever-beans.
> > Three concepts are necessary:
> > - callbacks for load, store and remove.
> > - rights
> > - transaction management.
> > 
> > What is the rest of this complex EJB mess useful for?
> > 
> > >From my point of view EJB are a terrible approach to create a standard for
> > an object-relational mapping layer.
> > Kick'em, if you can use a working object database.
> > 
> > EJB are a strange phenomena:
> <snip/>
> 
> Just my humble opinion
> but I think that you guy's are missing the point of EJB/J2EE slightly
> no matter how pointless EJB's seem, let's not forget that the whole idea
> of the specification is to abstract away from the deployment platform,
> and vendor specific API's, and provide a vendor neutral (besides Sun of
> course ;-) *development platform* for IMHO, relativly inexperienced
> developers (i.e. you don't have to have 5+ years of C++/3+ years of Java
> to get by with EJB) to actually be productive at the enterprise level,
> the rest is academic.
> whether Sun have succeeded remains to be seen, but essentially, the aim
> here really is "Write once, Run Anyware"., 
> So maybe most people who have a real problem with them is more about the
> fact that they de-mystify a lot of enterprise development issues and
> provide a "dumbed down" entry point to stuff that used to require a
> CORBA specialist or worse, a team of them.
> if you write to the spec. it's pretty easy to have a bunch of developers
> producing prototype EJB's that talk to all sorts of divergent
> system's(including the NDS) in quite a short space of time, that's hard
> to do with other thing's.
> please note that I in no way personally prefer EJB's to other things'
> (i.e ozone) and I also have to just touch on the "Ozone is not really a
> Database" point.

> Falko, I agree 100% that Ozone often gets confused as a "Database" by
> people.and this could lead to some funny questions, most notably the
> reoccuring query language question, which I personally don't really see
> a need for (at least not as Ozone is now). maybe the web-site is a
> little misleading in this regard, as ozone is sort of advertized *as* a
> Java ODBMS, which is not really accurate, maybe a re-think about the
> marketing might be in order.
> describing ozone (more accurately) as a persistant runtime environment
> for java-based object models. (unlike EJB, which is an abstraction of
> underlying EIS, or is supposed to be anyway) may go a little way towards
> clearing up this confusion

Yes, I agree. The web site is somewhat confusing. Your description is better.
On the other hand it is not that easy for me to give a good overview
description, since I'm to deep into it. (see current ozone site... ;) We should
discuss this here on the list. This will help to produce a text that reflects
not just my point of view but the ideas of all of us which probably make it
more clear for newbies.


Ok, the list of important points so far:

- persistant runtime environment for java-based object models
- unlike EJB, which is an abstraction of underlying EIS

plus:

- transactional or transaction save

other?


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com