Is There Anything to Javabeans but Gas?
I, personally, believe in the maxim that a program or system should be exactly as complex and flexible as it needs to be. No more. No less. Too much flexibility extends development time and makes maintenance difficult. Too little makes it too difficult to modify the program as business requirements change. A good programmer walks a fine line, indeed. One of the draws of OO is that both the theory (building designs around real user needs, designs that model the real world) and tools (interfaces, design patterns, etc.) make it easier to walk this fine line.
Which brings me to the issue of EJB and Bandwagon-Oriented Programming™. I’m not much of a fan of EJB. EJB often ends up being nothing but a (considerably) expensive bottleneck that adds little or no value to an overall architecture. When you factor in the cost of the hardware and programming (including maintenance) effort, the value of EJB seems even more questionable.
The technology is vastly too complex for most applications that use it, and EJB adds much more flexibility to those applications than they actually need. Virtually nobody uses EJB features like RMI-to-CORBA translation. Container-managed persistence doesn’t work all that well — a BEA rep once advised me to limit my use of EJB to stateless session beans and do the persistence by hand. People haven’t even figured out what it means for a method to be a transactional unit, much less how to roll it back.
From a design perspective, the separation of the session and entity beans violates the most fundamental OO precept of all: implementation encapsulation. Moreover, it’s rare that a good object model will map directly to a good database schema, so even the creation of the entity bean can be problematic. To make matters worse, I’ve seen some programs that actually ship the entity beans around by value using RMI, thereby yielding the world’s least-efficient query mechanism, which returns a single row from a complex join. Lately, I’ve seen things made even more ridiculous by wrapping the entity-bean data in XML and shipping that around. What are we trying to do here — build the slowest system imaginable? To make things worse, trying to splice an OO architecture onto a fundamentally procedural architecture like EJB is difficult at best and also adds unnecessary complications to the program.
EJB, then, is a perfect example of Bandwagon-Oriented Programming™. Too many people just don’t seem to think. They install a “standard” architecture (JSP web server/EJB app server/Relational database) because the prevailing wisdom (whatever that is) says: “Yea, it is good.” They then just build on top of that architecture without first considering whether the architecture is all that good for the actual application they’re building. For example, if you’re using EJB to get failover, you can do the same thing in the router, in the database, and by using a message-oriented middleware encapsulated by JMS. In many scenarios, these alternatives will all do the job better than EJB, but they’re rarely considered. Another example: if you’re using bean-managed persistence and stateless sessions beans, you’re just using the app server as a complicated RMI platform. You can simplify considerably by using straight RMI and a simple naming service — an RMI-accessed HashMap might work just fine.
Of course, most shops don’t do any real up-front design work at all, so I suppose this behavior isn’t all that surprising. The real question then, is one of education. How do you convince panicked get-it-to-market-first companies that relaxing for a few moments and thinking about what they’re about to do is a good idea? This question is actually a more complex question than you might imagine. Someone once told me: “When you ask a really good programmer about their technical abilities, they’ll tell you how good they are. Unfortunately, when you ask a really bad programmer the same question, they’ll also tell you how good they are.” Many management decisions are based on trust, especially if the CEO is non-technical, and unfortunately, people in positions of authority and trust who have courage and technical savvy (or even the ability to ask when they don’t know something) to jump off the bandwagon and take a risk are few and far between. I’m convinced that this lack is one of the big reasons for the dot-com failures: their technical infrastructure was a couple orders of magnitude too flexible for what it actually did, and the correspondingly inflated cost was insupportable. My main hope it that we’ll all learn some lesson from this, though I’m not quite sure what the lesson will be. Maybe you can tell me.
Allen Holub
Senior Editor