August 10, 2001
Enterprise JavaBeans (EJB) Best Practices
As EJB's Go Mainstream, Sun Works Hard to Divide the Tiers--You Should Too
By: Rich Dragan

¡¡Table of Contents:
¡¡Introduction EJB's Go Mainstream EJB Accelerates Application Development Sun's 'Blueprints' for Success With EJB's: Split Those Tiers Blurring the Tiers is Bad News Reducing Java Code in JSP's Using Command Bean Patterns Creating Custom Tag Libraries Do You Really Need EJB's After All? Web Application Frameworks Arrive The Future of EJB's
¡¡For developers and IT managers alike, the success of Sun's Enterprise JavaBeans (EJB) component standard is another of today's Java success stories. The latest round of application servers from vendors like IBM, iPlanet (a Sun / Netscape Alliance), WebLogic, Borland, and Sybase, put this powerful component standard into the hands of virtually every corporate Java developer. In fact, with the notable exception of Microsoft, most every large vendor has endorsed EJB's. According to Sun, there are currently at least ten 'branded' J2EE-compatible server products. This certification means that a EJB server product has passed over 5,000 compatibility tests, and this helps make it easy to move Java applications between platforms from different vendors.
¡¡Besides commercial app servers, there is even an 'open source' application server (Jboss--see www.jboss.org) so you can use EJB's without incurring licensing fees. With real projects using this powerful cross-vendor standard, EJB's have moved well beyond theory into practice in serious enterprise projects. But EJB's are only part of the Java 2 Enterprise Edition (J2EE), and figuring out how EJB's best fit into your next project is a must for any IT manager or Java developer. New initiatives, recommendations, and standards from Sun are about to change the way you develop with EJB's and impact the front-ends that make use of them.
¡¡So listen up. We talked to several experts from Sun and other vendors to find out what's next for EJB's and related standards, and how to take advantage of some of the latest thinking about how to program successfully with these powerful components.
¡¡Finally, we all have a component standard in Enterprise JavaBeans. Milena Volkovich, from the Sun EJB team sums it up like this, "EJB technology allows you to focus on business problems rather than the underlying infrastructure." By standardizing such features as persisting the state of Java components to and from a database, and managing transactions and messaging, the J2EE platform gives developers a leg up in a world with shorter and shorter deadlines, where none of us has time to re-invent the proverbial wheel when it comes to an architecture.
¡¡Another win for developers with EJB's is that you may not even have to start from scratch when looking to solve particular business problems, thanks to an emerging market for third-party EJB components. "You can also incorporate other people's components in your application and assemble applications from off-the-shelf components, so your efficiency and productivity as a developer increases," advises Volkovich. Web sites like www.componentsource.com offer EJB wares from a host of vendors. Sun's own listing of available EJB solutions in its Solutions Marketplace includes over 100 entries, with components for a variety of uses including for e-commerce and workflow, plus vertical markets like financial, telecommunications and manufacturing. (Click here for a complete list.) With all this pre-existing technology for sale, Sun touts the role of an EJB assembler, a developer who 'wires together' new applications from existing EJB components.
¡¡While still a leading-edge approach, it's clear that EJB has achieved critical market mass to go along with its developer mindshare, and widely available components are a part of this trend. As Microsoft readies its own vision of .NET components and Web services, re-saleable EJB's have already hit the marketplace for a wide variety of applications.
¡¡Besides assembling from existing components, a new generation of Java tools is set to take the bite out of building new EJB's from scratch. Where a first generation of programmers needed to write everything by hand, new tools are making the job much easier. Many readers probably know that the EJB standard allows developers to model two things: 1) database entities in the database and 2) business processes or rules. Entities, first and foremost, are the 'nouns' of the business solutions, and today, tools like WebGain VisualCafe and Borland JBuilder make it extremely easy to model all the entities in your tables, essentially without writing a line of code yourself. (Of course, experts will always want to tweak or add custom code.) Run a wizard, and you can generate dozens and dozens of EJB classes that represent your entire database schema in just a few minutes.
¡¡The 'action verbs' of the EJB component standard are session beans, and these involve writing some real code yourself to do actual business processing. To illustrate the difference, entity beans could be used to model a Customer, Product, ShoppingCart and Order while a session bean called ProcessShoppingCart might turn all the items in a customer's shopping cart into actual orders. Session beans would make use of entity beans to do this work. At this point in time, creating entity beans is getting to be an entirely automated process, one that even a novice EJB developer can do, without having to understanding the finer points of these components.
¡¡Just three years ago, doing EJB's required that you learn Java thoroughly, read some leading-edge books, and dig in with a do-it-yourself spirit of design. For entity beans, there are two ways to get to the underlying database. The first way, bean-managed persistence (BMP), was the choice for 'early adopters,' and involves writing the database connection code using Java Database Connectivity (JDBC) manually. According to Geoffrey Goetz, a Senior System Engineer at Borland, who has worked mentoring teams with EJB's from the very beginning, using the BMP approach was a mark of real distinction for the early adopters of a few years back. These early adopters "didn't really trust container managed persistence because they didn't understand it or they didn't want to understand it, or they knew they could already solve that problem," Goetz observes. "They wanted bean-managed persistence and their trusted codebase" instead.
¡¡But today, most teams are now relying on container managed persistence (CMP), not only because the EJB modeling tools are getting better, but because more and more programmers are using EJB's without the expertise that was once required to re-invent the proverbial wheel. "Mainstream developers are using CMP more and more because they don't have that same skillset to rely upon as the early adopters did," Goetz believes. The combination of these factors have lead to the current renaissance in using EJB's and CMP for new projects.