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