In-Depth

Simple EJB: Is it ready yet?

• By Johanna Ambrosio
• June 1, 2004

Working with Enterprise JavaBeans (EJBs) is not rocket science, but it is close. At least it can seem that way to a new generation of programmers who may know and love the Java language and used it for fairly straightforward and small Web apps, but who do not know “beans” about developing full-fledged enterprise software. In a bit of geek irony, the thing that was supposed to make life simpler for developers -- providing services like middleware for distributed computing, security, persistence and many others -- has wound up instead to be too complex for many newbies. This situation exists because EJB comprises so many associated technologies that inexperienced programmers can wind up shying away from the technology.

Making optimum use of EJBs requires a fairly steep learning curve. One needs to learn the different types of beans and how they relate to each other, how to use EJB within the context of the larger J2EE server-side programming model, how to tune EJBs for the best performance, and so on. And you had better know lots about the basics, at the very least, regarding object-oriented programming.

With more viable developer tools in existence than ever before, particularly in the open-source world, the EJB community is deciding it needs to simplify.

“We’re targeting mainstream corporate developers,” said Linda DeMichiel, EJB architect at Sun and a key member of the team within the Java Community Process (JCP) that is helping to define the EJB 3.0 spec. “We want to make it as easy to write an EJB component as it is to write a Java class that’s configured through meta data,” she said.

One way to do this is to “drastically simplify” the Container-Managed Persistence (CMP) model, which is “more complex than it needs to be,” DeMichiel said. “We’re looking at POJO -- plain old Java objects -- that are lighter-weight domain objects that don’t have all the interface components” as does CMP. Even with the POJO model, though, “the container still does all the heavy lifting” in terms of managing persistence among the related EJBs, she noted. It will just do so in a different way.

Does simplicity always equal goodness?
How this will all play out is still up for grabs -- this is, after all, a process with many voices and several rounds of feedback that are ongoing. And, as is the tradition with programmers’ conversations in most venues, there is no universal agreement. Some EJB old-timers say that simpler is not better in this situation. They do not want to “dumb down” the technology much -- if at all -- because they know and love it just as it is, thank you. And for them it works fine the way it is.

“Sure EJB is complex,” said Michael Bouchard, director of training at Richmond, Va.-based CapTech Ventures, and someone who has been using EJB since it first emerged in 1998. “But look at all it does for you -- there’s a reason.” CapTech has helped to build EJB-based systems for clients, including the State of Virginia, Campbell Soup and Dominion Power.

Bouchard and some other EJB fans claim that there is nothing else around that helps developers to write distributed corporate applications that require high transaction rates and all the usual “bulletproof” features needed at this level. If you take too much of that away, they fear, the technology simply will not perform as well.

“I can’t imagine anything substantial being needed at this point,” Bouchard said. “To me, the standard is pretty much done.”

For its part, the JCP is trying to be sensitive to these types of concerns from EJB old-timers. “We need to distinguish from the inherent complexity of enterprise apps -- they do need to deal with topics such as concurrency management,” Sun’s DeMichiel said. “What we’re trying to do in EJB 3.0 is to look at what’s regarded as complexity from the programmer’s point of view, the actual writing of an app.” So even EJB 3.0 will not hide everything; developers will still need to understand a lot of what is going on — just not quite as much as they did with earlier EJB versions.

Nor is any perceived complexity stopping all comers. Nexstar Financial Corp., a mortgage services provider in Creve Coeur, Mo., is migrating to J2EE and EJB to help improve performance for both employees and outside customers. They work with third parties as the “behind-the-scenes” mortgage approval engine that connects to Fannie Mae and other systems. Nexstar offers mortgage processing services ranging from loan apps to underwriting to closings. They help facilitate approvals and tap into credit reports.

Until now, Nexstar has used a Java servlet-based architecture, said Thomas Richardson, VP of technology at Nexstar. But an EJB approach -- which isolates the business logic from the other application components -- will allow the firm to more easily change the specifics of an application based on customer requests.

“EJB will let us better service our customers,” Richardson said. The migration is ongoing, he said, but Nexstar is aiming to complete it by the end of this year.

The majority view
Indeed, the notion of “don’t ruin a good thing” is the minority view. Much more typical is this programmer’s lament, posted on an online EJB discussion forum on Feb. 17, 2004: “I remember when I wrote an app using servlets ... It could let me do something which was fulfilling the needs of the 200 people using it. It’s been more than six months that I am struggling with my beans to get deployed without me sitting for more than an hour.”

And another person’s viewpoint, posted on that same online list on Feb. 7, 2004: “I’ve written at least seven different EJB systems from scratch and maintained about the same number. Lately, I’ve deserted EJB because I do not believe it adds enough value for the pain you have to go through to create them.”

After all, if everyone used EJBs and Java server-side development, there would be no need for the JCP to consider major changes. While it is true that most Fortune 500 companies are using EJB -- if nothing else, by default through their Java-based app servers from IBM and BEA -- not all of these customers are actively engaged in developing specific beans. Most of the major EJB-centric apps that exist, however, can be found within the walls of the nation’s largest firms that have dedicated Java server-side experts.

“The key challenge is building components on the server side,” said Eric Herness, chief architect of WebSphere business integration at IBM. “We’re looking at things to help with that, so if someone wants to build a simple state with session beans they can use a tool to implement an algorithm and aren’t even aware they’re building a bean.” Right now, he said, most of IBM’s installed EJB base is working on getting to Version 2.0 of the standard.

“We probably have a slower adoption curve [to 2.0 and later versions] than we’d like,” he said. “We’d like to get you there -- but all in due time.”

Even so, some longtime Java advocates worry that if something is not done soon to help kickstart the development community at large, EJB could become irrelevant and fall out of use altogether.

EJB falling by the wayside?
Floyd Marinescu, author of EJB books and a former EJB developer, is co-founder and general manager of TheServerSide.com online communities. (Formerly a Java-only community, it recently added a .NET site.)

“When I speak at a conference, I always ask who’s using EJB, and about three-quarters of the people put up their hands. But when I ask how many use it as a distributed object on a separate business tier to do remote communications between machines, less than a quarter of the people put up their hands,” noted Marinescu.

To his mind, this is the only legitimate use of EJB, “the whole point of it,” as he says. “Most people are misusing EJB,” he claims. According to Marinescu, two of the three original value propositions of EJB back in the late 1990s have been superseded by newer technologies, and EJB’s remote distribution properties are the only ones that are relevant and critical to today’s generation of corporate developers.

“Most of the people who used EJB back in the day were using it as a framework, as a way to organize business logic. But now there are lots of open-source frameworks -- Struts, Spring” and others, he said.

A second original benefit was to develop reusable enterprise components, “but that market has not taken off the way we thought it would,” Marinescu said. “People don’t like to write or reuse business components unless it’s something that’s applicable across different apps, like a zip code format.” Something that is project-specific is just too much trouble. “So the component aspect of EJB is just a nuisance; it adds weight to the spec,” he said.

Still, EJB remains the best solution for building distributed objects, or for scalability requirements if you need to separate the physical tier from the logical one and so require calling the objects from one or more different machines. But these scenarios apply to “very few projects,” Marinescu said. “Most projects are not that large and require only a few machines.”

In his view, most of the folks who “jumped on EJB” in the early days “have gotten bored and moved on.”

Revamping EJB
To help stem the tide of dissatisfied or frustrated EJB programmers, the JCP has gathered feedback from hundreds of implementers. Richard Monson-Haefel is a member of the committee shepherding the 3.0 spec, and earlier this year asked EJB programmers to tell him what was on their minds. After more than 200 people did just that, he grouped the responses into 13 major points. (The list is available at http://weblogs.java.net/lpt/wlg/997 .)

“What struck me, after counting and grouping relevant posts, was that the developer community desperately desires a simpler programming model for EJB,” he wrote in his blog earlier this year. “Clearly, people feel there is much to be done.”

In a subsequent interview, he said, “EJB became complicated in an attempt to support high transactional business solutions. There’s a difference between designing a bike that will take you to the corner store and designing a rocket that will take you to the moon. Unfortunately, while shooting for the moon we left developers with less ambitious objectives behind.”

The goal with 3.0 will be to help the “complexity problem simply disappear.” At the same time, he said, “we will continue to support the EJB 2.1 model for those who need it -- but moving forward, simplification without the loss of sophistication is the mantra.”

In addition to revamping CMP and adopting a POJO programming model, programmers have asked for the support of inheritance, as well as the ability to develop and test outside of the container system. In this case, a developer will be able to pull out the business logic without having the EJB container actually deploy it.

“We can mock up a testing environment by leveraging patterns to simplify this,” Sun’s DeMichiel explained.

In another nod to simplicity, the JCP is also working to help leverage meta data to automatically generate interfaces and to reduce the need for the developer to produce all the artifacts now required. “We can go to a new level to look at defaults or standardized behavior of the components in an EJB container. So programmers don’t have to explicitly define behavior when the expected cases are used,” said DeMichiel. Programmers would need to define more things only when exceptions are required.

In this scenario, “the component specifies its needs and the container can provide them,” she said.

JCP representatives will not publicly disclose when all this will be done, except to say that EJB 3.0 will be delivered as part of J2EE 1.5. Before that is out, though, J2SE 1.5 will be ready “soon, within the year,” promised Dennis MacNeil, senior product manager of Java Web Services at Sun. That version of J2SE will feed the release of J2EE that will include EJB 3.0.

A key question going forward is how the evolving standard will improve access to data stored in SQL databases. “EJB is embedded in most organizations, which are using the technology primarily for access to back-end data,” said Wayne Kernochan, president of Infrastructure Associates, a consultancy in Wellesley, Mass. “That means you’re operating at arm’s length from the data; you’re writing OO code to access a relational database, and that means there needs to be a fair amount of translation between the two.”

Part of that problem was alleviated with EJB 2.0, which included Finder Methods within the EJB Query Language. “These Finder Methods can make the queries portable now,” explained Mike Sawicki, product manager for Compuware’s OptimalJ development tool. “In the past, the query had to be specific to the SQL version, and that could cause problems.”

Still, the concern for Infrastructure Associates’ Kernochan is that “there’s a certain amount of complexity involved in data access that you need to get your hands around, or you’re never going to get it. You have to know what a commit is. You need to understand what the internal effect of the query is going to be, or you will have created the query from hell.”

So, he said, “simplifying will certainly help, but it’s not going to solve every problem. You can’t simplify everything.”