On Fri, 2002-02-01 at 04:14, James Strachan wrote:
> Hi Jeff
> 
> I share your oppinions on EJB. Whenever I ask developers why they are using
> EJB the common answer I get from people is 'well I get transactions for
> free'. When most of the time they don't do 2 phase commit with their
> database anyways. And all that extra work just to get 'acceptable'
> performance from EJB. Jeez this stuff is meant to help us not hinder us.
> 
> I agree that EJB has shoved too many things together in one 'server side
> component' framework. Perhaps working from core specs is better and just
> choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal bias
> is to use 'local' object technologies such as Java Beans, Servlets, JDBC,
> JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS, HTTP
> or whatnot) when distribution is required. I try to avoid RMI if truth be
> told. It seems so 80s ;-)
> 
> I'm still not convinced at all that EJBs are even worth considering when
> when building web applications - why should be business logic be remote in a
> web-centric world? Why not deploy the business logic with the web

I agree with everything but this.

For scalability you should have the option but should not always use
it.  If your application will grow it is good to have a middle tier that
can be moved and load balanced.  With Entity beans of course this is
less possible.  


> application and save all those costly synchronous RMI calls. You can have
> seperation of concerns without making things remote. You only have to look
> at MS's PetShop to see how simple and fast to develop web applications could
> be while still seperating business logic, persistence and presentation - or
> how slow and painful they can be if you follow the EJB path.
> 
> I do think a simple open source alternative to EJB would be a good thing.
> Already Jakarta has most of the bits almost in place, tying them all
> together would be cool.
> 

+1

> FWIW you might want to keep an eye on the AltRMI project at Jakarta Commons
> which hopes to make RMI and the Remote stuff much easier.
> 
> James
> ----- Original Message -----
> From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
> To: "Jakarta General List" <[EMAIL PROTECTED]>
> Sent: Thursday, January 31, 2002 8:38 PM
> Subject: RE: J2EE considered harmful
> 
> 
> Amusingly enough, I've been considering writing an article with this
> exact same title.  I've implemented two medium-sized systems using EJBs
> (http://www.similarity.com and http://mav.sourceforge.net/pig) and I've
> been haunting the ejb-interest list for more than a year.  I was never
> ecstatic about the technology, but now I'm starting to feel downright
> disillusioned with it.
> 
> This is not coming from someone stumbling around with the technology.
> The first thing I did was read Richard Monson-Haefel's book
> cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only
> implementation.  I've got most of the 2.0 spec memorized.  I have no
> trouble writing the deployment descriptors by hand.
> 
> The problem is, even after more than a year of this, I still find that
> writing software using EJBs is a steady progress of fighting the
> technology to make it do what you want.  It shouldn't be like this.
> 
> Having to write three or four different classes, plus an elaborate
> deployment descriptor for each object slows things down a bit.  Tools
> like xdoclet help, but it's still a complicated and painful process to
> refactor anything.
> 
> Basic software design patterns are agonizing or impossible to implement.
> Observable?  Time to learn JMS and Message-Driven Beans.  Singleton?
> Not in the framework... you have to set up an external RMI server.
> 
> Presistance in the EJBland is a disappointment.  Even with EJB 2.0,
> entity beans are not remotely mature.  There is no support for
> relationship attributes or automatically generated primary keys.  The
> query language is constrictive, offering no support for ordering,
> aggregation functions, or retrieving data which spans more than a single
> class.  After 20+ years of research and advancement in RDBMS technology,
> this is a colossal step backwards, and the consequence is that entity
> beans radically underperform systems with more direct database access.
> I find that I must constantly sidestep the container with direct JDBC in
> order to meet performance or feature requirements, and it sounds like
> this is a common problem.
> 
> Overall, my feeling is that Sun tried to cram too many disparate
> technologies into a single API.  EJB!  It's a distributed object model,
> transaction model, security model, persistence model, component model,
> message queue, desert topping, and floor wax all rolled into one!  Some
> of it makes sense, but some of it (especially persistence) doesn't.
> 
> I'm surprised that people can build large applications with EJB.  My
> guess is that it's probably very effective for one particular class of
> problem - ecommerce apps.  I'm sure it's no accident that all the
> examples in the spec are Order, LineItem, etc.  Unfortunately, this
> doesn't help me, or any of the rest of the people who are working on
> applications that are actually interesting.  And my guess is that since
> ecommerce is 90% of the market for expensive app servers, Sun doesn't
> really care.
> 
> 
> Ok, enough whining.  What to do about it?  I really like the idea of an
> Apache community building a truly free competitor to J2EE.  I don't like
> being tied to technologies owned by a single company, so I'm already
> pretty nervous by the stranglehold that Sun has on Java and (especially)
> J2EE.  But it's not enough to build a marginal improvement over the
> existing system, even with Apache's mindshare.  Besides, who wants to
> copy a mediocre idea? :-)
> 
> I've been giving a lot of thought to distributed object models lately.
> I've worked with DCOM, CORBA, RMI, and EJB, and for the most part it's a
> lot of the same.  Since networks are getting so fast these days, I'm
> starting to really wonder what it would be like to have a model in
> which:
> 
> * All objects are inherently remotable.
> * Objects transparently migrate for efficiency.
> 
> I can think of many interesting, fairly revolutionary consequences of
> such a system and I'd love to discuss them.  Ultimately, if such a
> system ever made it out of research and into prototype, it could
> challenge both Java and .NET, and possibly stave off the coming hegemony
> of the Sun/Microsoft duopoly.  (Yeah, yeah, there will always be people
> who enjoy working on nonvirtual machines, but they're crazy :-)
> 
> Does anyone think some variant of this idea to be worth pursuing?  Or is
> everyone wedded to the idea of working on the proprietary Sun platform
> known as Java?
> 
> Jeff Schnitzer
> [EMAIL PROTECTED]
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
                        - fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to