In-Depth

To EJB...or Not

Deciding whether or not to employ Enterprise JavaBean (EJB) technology in Web and other enterprise applications is not an easy choice. On the plus side are developers who code in Java on the J2EE platform and swear by EJB for high-volume transactions and tricky integration. This point of view is supported not only by Sun Microsystems Inc., but by other industry heavyweights, including IBM and BEA Systems, which incorporate EJB into their WebSphere and WebLogic e-business platforms, respectively.

But some consultants doing enterprise development say that while EJB technology is great for some applications, it is unnecessary or not feasible in others. That point of view is supported in part by a recent report from Gartner Inc., Stamford, Conn., warning that corporations are wasting billions of dollars on high-end server apps based on J2EE with EJB, when the same tasks could be accomplished with simpler, less costly technology. And, finally, there is Bill Gates, king of worldwide de facto standards, whose .NET platform and tools claim they are better, faster and easier than Java and its standards.

Will Java, J2EE and EJB go the way of WordPerfect, Lotus 1-2-3, OS/2 Warp and Netscape Navigator? No one outside the walls of Redmond, Wash., is saying that. But certainly, Java technology, including EJB, is at a crossroads. Will it build on the widespread industry support it enjoys or possibly face stiff competition from the marketing and technology Bigfoot of the Pacific Northwest?

What Is EJB?
Like most technical jargon, the people who work with Java every day casually mention EJB as if it were a household name like Jell-O or Kleenex. But on the off-chance that some readers of this article may not be EJB aficionados, it may be good to define the term. (Those in the know can skip this section.) In a FAQ on its Java developers Web site, Sun defines EJB this way:

EJB, the widely-adopted server-side component architecture for Java 2 Platform, Enterprise Edition (J2EE), enables rapid development of mission-critical applications that are versatile, reusable and portable across middleware while protecting IT investment and preventing vendor lock-in. EJB technology is the core of J2EE. It enables developers to write reusable portable server-side business logic for the J2EE platform.
To the question "Is EJB a product?" the Sun FAQ answers:

No, EJB is a specification, which defines the EJB component architecture and the interfaces between the Enterprise JavaBeans technology-enabled server and the component. Vendors like BEA, Sun, Oracle and IBM are providing commercial products that implement the EJB specification."
As a vendor using EJBs in business management applications, Don Namenan, vice president at Savvion Corp., Santa Clara, Calif., defines EJBs as "executable components that can be easily implemented on top of an application server.

"They're defined in containers," he explained, "so that they can interact with all the other activities and programs that may be running on the app server."

This "write once, run anywhere" quality makes EJBs portable and scalable, while their containers offer security. Those capabilities draw developers to the Java spec.

How EJB is working today
Now that we all know what EJB is, it might be helpful to look at where it is being used by developers in business applications.

At Centrifusion Inc., a Chicago-based software consulting services company, CTO Bob Lytle and Lead Architect Joe Kline work every day with companies that are developing applications in Java using EJBs. In their experience, the companies that are using the Java specification successfully are working with high-volume transaction applications where scalability and security are paramount concerns.

"The reason you would go with EJBs is if you have a high-transaction unit of work that needs to execute safely in a distributed environment," said Kline. "That's basically what an EJB container gives you. You can write your business logic and you don't have to worry about contending for database access, lockouts or scalability."

While most of the buzz surrounding EJB has to do with Web-based applications, Lytle and Kline said that in their consulting practice, corporations are also using Java and its specifications in traditional client/server applications.

"An EJB implementation could be a payment system that's traditionally client/ server," noted Kline, who is a Sun Certified Enterprise Architect. "You could take that server piece and implement it as an EJB container."

Use of EJB technology in a typical client/server-based CRM application makes it possible for two users to work with the same customer data simultaneously without creating what Kline calls "undetermined results."

"If we have clerks that are in a CRM environment and they are adjusting claims," Kline explained, "one could be adjusting claims with a customer on the phone, and another person could have a batch workflow where they need to go in and adjust that same claim."

By adhering to the EJB rules, the developer builds an application where the EJB container protects data and system integrity even when two users are working with the same files.

This makes EJB ideal for asynchronous communications in e-business applications, according to Stefan Van Overtveldt, an IBM expert on WebSphere's implementation of Java technology.

"If you look at the way an e-business application is typically structured," he said, "basically a user request from an HTTP communication gets passed by the Web server that is sitting underneath to a Java servlet, Java code running on the server; this will then initiate a number of transactional Java components, Enterprise JavaBeans, and use a Java Server Page model to generate the output that gets sent back to the user to dynamically generate the HTML document."

In this way, EJB facilitates the kinds of communications and transactions needed for e-business.

"The way EJB works today is that it is an asynchronous type of communication," explained Van Overtveldt. "This means that EJB A will put a request to EJB B and wait for that response to come back, or for EJB B to do other actions and then come back with a response. More and more companies are focusing on asynchronous types of messaging where Application A will put a message in a message queue, and Application B will go out, read it and put a response in the response queue. In the meantime, Application A can go on and do other things."

This becomes more complex as developers use EJBs to create what Van Overtveldt calls "serialized applications" where the beans containing various business processes are linked together to form a larger application.

"What we're seeing happening in EJB development is that companies are starting to build more serialized applications where you have EJB 1 calling EJB 2, and EJB 3 calling EJB 4, 5, 6 and 7 before finally pushing a result back," he said. "This is a very good practice because it allows you to develop these smaller chunks of code that are easier to build and test."

Are EJBs always necessary?
After talking to an EJB guru for an hour, it begins to seem that the whole developer world should simply embrace this Java specification as if it were what one CTO calls "the Holy Grail." Of course, in software standards there are so many Holy Grails that it seems as if we need a Holy Grail Catalog to keep track of them.

But if you were building a Holy Grail catalog application, or any other kind of catalog application on the Web, Centrifusion's Lytle and Kline argue that you would not necessarily need EJBs.

"Not every project requires or benefits from EJBs," said Lytle. "Most Web initiatives require some level of transaction. But there are certain classes of Web initiatives that are more interested in delivering content—delivering information—than allowing access to orders or processing data."

"Catalogs are a great example," added Kline. "They need to be high performance. They're not transactional. It's simply where you look at what's being sold on the site."

Kline said applications such as a catalog can use Java servlets rather than EJBs to successfully handle the demands of browsers. This echoes a recent warning from Gartner that IT was overspending on server technology, including EJBs, when applications did not require them.

The Gartner report warns that "companies have overspent about $1 billion on application server technology solutions since 1998. Moreover, an additional $2 billion may be wasted between now and 2003." The report specifically points to the deployment of EJBs when JSP/servlets can do the job. "As components of application server technology, J2EE and Enterprise JavaBeans (EJB) are not the same thing," the report states. "Most Java projects use Java Server Pages (JSP)/servlet capabilities and not EJB. Higher-priced application servers are designed to run EJB, yet they are using JSP/servlet capabilities instead."

The Gartner report warns IT departments: "Don't let confusion or hype push you to spend more than necessary."

Performance issues
There also seems to be confusion surrounding performance issues, which is not always an EJB strong suit.

"There is corporate bias in some management circles against EJBs because of a perception that the system just doesn't perform as well as it could," Centrifusion's Lytle said. "When Java first came out, people said, 'That's great, but it sucks on performance.' They're saying the same kind of thing about EJBs right now."

Lytle believes the performance complaints are unfair.

"The issue is more with implementation and servers being able to handle it effectively," he noted. "And there's misuse of EJBs. Again, if you're using an EJB to deliver your product catalog, of course, it's going to be slow. You don't want to use EJBs for that. So EJBs have kind of gotten a bad rap. What we see is that IT is slowly moving to accepting EJB as something that can be high performance, high stability, high scalability. But we've got to get away from the misuse of EJBs for everything, which isn't good, just like EJBs for nothing isn't good."

Kline is a fan of Sun's Web site dedicated to Java (www.java.sun.com) and the EJB specifications, and he believes it has information that can help developers avoid the hobgoblin of poor performance.

"If you go out and visit Sun's [Java] site," he said, "there's an incredible amount of resources there to help developers implement EJBs correctly. Sun has done an excellent job. The whole thing about EJBs is to make things so much simpler. But you really need to know what you're doing to take advantage of them and not code yourself into a performance or scalability problem."

Vendors that support Java and its standards are also addressing the performance issue by fine-tuning the way their products use EJBs, said Mukund Balasubramanian, CTO and co-founder of Infravio Inc. The Redwood City, Calif.-based firm has a Web Services management product based on Java and XML standards.

"The general notion is that EJBs themselves are heavy," Balasubramanian said. "For example, Entity Beans are performance-intensive; they take too much time. These are things we have heard from our customers."

To overcome EJB performance issues, he said, BEA has built EJB optimizations into WebLogic. His firm's Web Services Management System is customized for those optimizations not only in WebLogic, but WebSphere and Oracle's products.

Enter .NET stage left
Microsoft offers the ultimate workaround for EJB performance issues, real or perceived. Simply port Java applications to .NET and use the .NET tools and platform for all future development.

Of course, application servers do not necessarily require Java technology or EJB as Gartner's report clearly states: "Application server is not the same as Java 2 Enterprise Edition (J2EE). For example, the Microsoft product line lacks J2EE and Java, but has application server functionality."

And Microsoft was claiming superior functionality last fall when it launched its .NET server and tools. As part of the product introduction at the Microsoft Professional Developer's Conference (PDC) in Los Angeles, Bill Gates and company directly challenged the performance of Sun's Pet Store Java demonstration application, which is intended to show off J2EE and EJB capabilities in an e-commerce Web deployment.

Scott Standfield, CEO at Vertigo Software Inc., Point Richmond, Calif., told PDC attendees that his company, a Microsoft partner, ported Sun's Pet Store Java demonstration application from J2EE to .NET with a reduction in lines of code and an increase in performance. Stanfield said the .NET version of the e-commerce application was one-third the size of the Java original and ran 28 times faster.

Standfield invited his audience to see the comparisons for themselves on the Web where the Sun Pet Store demonstration can be viewed at http://java.sun.com/j2ee/blueprints and his company's port of it can be seen at http://www.gotdotnet.com/team/compare/.

Outside the Microsoft developer community, there is more of a wait-and-see attitude.

"Is .NET the Java killer?" asks Centrifusion's Lytle. "I don't think so."

But, at the same time, he is impressed by what Microsoft is doing.

"I believe .NET is a comer," said Lytle. "Gartner and Forrester [Research] have counseled companies over the next five years to factor for both because one is not going to trump the other. From our company's standpoint, we're looking out six months and saying we need to ramp-up on knowledge of .NET, not necessarily the ability to code every piece of it. But we need to know enough so if our clients ask us to do something with .NET, we have to be able to respond to it."

He sees the technologies and corporate strategies behind each firm having strengths and weaknesses.

"Sun beat Microsoft to the punch on much of the core of object orientation and a lot of the core elements of being able to do transactions," Lytle explained. "EJB is a very robust system. Microsoft is trumping Sun right now on Web services. .NET is definitely going to be a player and Sun is playing catch-up with its Web services technologies."

At this point, the issue is far from settled. It seems unlikely that Sun will fold up its Java tent and leave the field open to its archrival. So J2EE and EJB are unlikely to disappear in six months or a year. Nor is .NET likely to take over the world. Developers will need to keep up with both camps and apply EJB to applications where it is most beneficial, such as high-volume transaction Web sites, and perhaps look at less-complex solutions for catalogs and brochureware.

Most   Popular