Stop and consider, if you will, what this posting to theserverside.com implies: that somebody not only believes that “alternatives” to EJB are useful and relevant things, but that they could make a business case out of it and stake a company’s fortune on the idea. Even more interesting, notice that three responders (as of this writing, a day later) picked up on this posting, one of whom said, “I was excited about an EJB alternative….”
What’s going on here?
People are starting to recognize some of the frailty implicit in the EJB specification. In particular, the emphasis on vendor-neutrality within the EJB specification leads to a number of inefficient ways of developing enterprise applications. In order to work around these inefficiencies, developers are forced to adopt “design patterns” that create more work for the average developer, arguably more work than if they’d just abandoned EJB altogether and started from a core architecture of just servlets/JSP and JDBC.
Certainly, there are vendor products that offer value-added features that provide easier workarounds than just straight adoptation of the design patterns mentioned above. For example, WebLogic has a proprietary extension that allows the developer to flag the database as “exclusive” to the EJB app, meaning the EJB server can hold data in local memory until it absolutely has to flush data back to the database; this is a proprietary extension, however, and should the developer (a) not know about it, or (b) move the code to a server on which that extension is not offered, or offered in a different way with different semantics, the system as a whole will suffer.
Is Portability Necessary?
A number of EJB developers code their enterprise apps strictly to the specification, citing adherence to the standard as a holy mission, and criticizing those who do not with holy zeal. In all honesty, however, how many EJB applications actually migrate between server products? With relatively few exceptions, every developer who’s actually had to perform such a migration has reported it’s *not* a trivial task, just as any non-trivial database schema faces “issues” when migrating from Oracle to SQLServer, or to DB/2, or to Sybase, or wherever.
What, precisely, do “portable EJB beans” buy us? The ability to migrate seamlessly between server products? For any but the most trivial beans, this is a patently false hope, just as any but the most trivial Java programs are nonportable. “Write Once, Run Anywhere” has long been seen to be a horrible myth perpetuated by the Marketing department at Sun, and yet, the same developers who scoff at WORA bite–HARD–on the idea that EJBs can be portable. The ugly truth is, there are dozens of little ways your EJB application can be bound up in vendor-specific features, in many cases without the developer even realizing it. They religiously cite adherence to the spec even as they flag the database for exclusive use and take advantage of vendor-specific Entity Bean O-R mapping details.
What else? Beyond the ability to select “best of breed” products (whose features you can’t take advantage of anyway, for fear of becoming nonportable), what does a portable EJB component gain? Absolutely zip.
A Simpler Alternative
Developers seek simpler alternatives to EJB for a simple reason: EJB is not only way overkill for most enterprise applications, but it also represents a huge learning curve for the average Java developer. The goal of “making enterprise applications easier” for developers (a stated aim of the EJB Specification) has been sacrificed on the altar of vendor-neutrality.
One such alternative is to look at what EJB provides, and see if those same features are provided elsewhere:
- Persistence and O-R mappings. Can you say, “JDO”, or “SQLJ”, or “stored procedures”, even “raw JDBC”, anybody? Fact is, SQL was, is, and shall always be a more powerful and better-supported language than EJBQL. Why surrender the expressive power of SQL, particularly when developers have been mastering it for decades and database vendors have been optimizing it for longer, in exchange for a language that’s barely two years old, has varied support from vendors, and doesn’t provide half the functionality of SQL?
- Remoting. The EJB specification “takes care” of all the underlying remoting details–which is to say, it exports your RMI servant objects (the beans) for use from client VMs. That’s it. Everything else–defining the remote interface, writing the business implementation, ensuring the interface inherits from java.rmi.Remote–all of that is the same level of detail required by doing raw RMI programming yourself.
- Synchronization. Along the lines of remoting, EJB also provides synchronization policies for your remote objects–by choosing the worst possible synchronization scheme. When a remote call comes in from a client, the entire bean is locked until that client call completes–any other call from any other client is blocked until that call returns. This is like locking the freeway when a car hits the onramp–great for that one car, but certainly less than optimal for others waiting on the onramps. If you take control of your RMI servants directly, you can replicate this behavior if desired, or adopt a finer-grained synchronization policy to boost scalability.
- Connection pooling. This is probably the most cited reason developers use to persuade managers to adopt EJB…. and probably the least meritous, from a technical perspective. The fact is, a servlet-based application will connection-pool naturally, because all presentation elements are coming through the servlet container anyway. Drop a connection-pooled JDBC driver into the webapp’s WEB-INF/lib directory, and voila! You’re connection pooling with the best of them. In fact, many servlet containers are even providing JNDI contexts from which to discover JDBC DataSources, rather than forcing you to do the Class.forName()/DriverManager thing directly.
The list goes on and on; suffice it to say that there’s very little, in my (and many, many others’) opinion, that the EJB specification really provides.
Don’t Throw the Baby….
For those unfamiliar with the saying, there’s an American proverb that states, “Don’t throw the baby out with the bathwater”–in short, don’t throw the good away with the bad. EJB is not the sum total of J2EE–in fact, it’s probably the one bad apple in the barrel. Servlets, JSP, JMS, RMI, JDBC, all of these are excellent specifications that serve their stated goals quite well. Abandoning EJB doesn’t imply you need to abandon them, either–far from it. Instead, embrace them even more fully, and use them to their fullest capabilities.
In short, next time you’re looking into building an enterprise application in Java, maybe spend less time trying to figure out which EJB server to use, and spend a little more time trying to figure out precisely what you need the EJB server for. I think you might be surprised at the results, and discover that a servlets/JSP->stored procedures/JDBC/JDO/SQLJ scenario might just be all you need.
What, exactly, does EJB offer you?