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]>