When and whether to use Enterprise JavaBeans (EJB) components is one of the more vexing questions that a project team can face today, given the current state of the technology. To help you make these decisions, we provide some questions that you can ask if you are considering moving to EJB components from other technologies, or considering a new project that might use EJB components. We also compare two projects that used EJB components and see how they have been properly, and improperly, applied in practice.

What is an EJB component? EJB components are the Java component model for enterprise applications.

• EJB components are Java server-side components that are based on standard distributed object technologies, CORBA and RMI. EJB components are always distributed, which makes them fundamentally different from standard JavaBeans components.
• EJB components provide the _business logic_ part of an application. They are not concerned with presentation issues, and therefore must be used in conjunction with display technologies like servlets or JavaServer Pages (JSP) technology for HTML clients, or Java applications that use technologies such as AWT or Swing.
• Application servers that implement the EJB specification can simplify business application systems by providing services that handle the complexities: security, resource pooling, persistence, concurrency, and transactional integrity.

The EJB component model from Sun requires that EJB components run in the context of an EJB server, commonly called an application server. Our examples use the WebSphere Application Server, Advanced Edition, but the capabilities that we are discussing apply to most EJB servers.

Technical questions to ask

Let_s examine some questions that you can use to determine whether EJB components are an appropriate technology for your situation. If you can answer _yes_ to any of these questions, then EJB components may be an appropriate technology in your situation. If these questions do not apply, other technologies might be more appropriate.

Do you need to isolate business logic components from the public Internet?
Many companies consider their application software, particularly the rules and data structures that make up the business logic, to be key corporate assets (for example, proprietary analysis tools that make up part of a stock trading Web site). Allowing outsiders to have access to the source or object code for these assets would be extremely damaging to the company. As a result, these companies strongly prefer to keep business logic behind a secure set of firewalls (often referred to as a demilitarized zone, or DMZ).

In this case, distributed object component architecture such as EJB technology allows you to isolate valuable corporate assets behind the DMZ while allowing presentation code to access the EJB servers behind the DMZ. This kind of distribution solution is shown in the following figure:

We assume here that presentation logic is less _valuable_ than the back-end business logic. If this is not the case, then this option is less warranted, and the entire system can be placed either entirely behind the DMZ, or inside the DMZ. If the entire application must (or can) be held behind the second firewall, then other technology choices (such as directly accessing databases through JDBC calls from the Java Servlets) then become reasonable.

There are some also efficiency disadvantages to this solution. For example, in a WebSphere installation, if you separate the clients -- servlets and JavaServer Pages (JSP) files -- from the EJB components in a separate JVM as shown, this option reduces overall performance. It can increase the time for each call through the firewall by up to 20% over placing them in the same JVM.

Do you need to have more than one client type access shared data?
Often, a single application will have multiple client types that need to access the same set of information. For instance, an application might have a Web-based HTML front end for external customers, and a more complete Java application front end for internal users. Traditionally, this problem has been solved by writing two versions of the same application that share the same data sources (database tables). However, this is not efficient, either in programming time or in utilization of the database if multiple database locks could be held at one time.

The EJB technology solution to this problem is to put common data and business logic in a single set of EJB components that are accessed by different client types (such as servlet/HTML and application). The EJB components control the access to the back-end data and manage the current transactions and database locking internally. This reduces the total programming effort by removing duplicated code in the application and by reducing the amount of effort spent in writing database control logic.

There are other solutions that work in this space -- for instance, Java applications can access Java servlets through HTTP, while a browser can access a Java servlet through HTTP as well. The problem with these solutions is that if a servlet is used to present information in a browser, it will necessarily contain some presentation logic that is unnecessary for conveying information to another program. Thus, you end up with two sets of (partially overlapping) servlets to handle both cases. In addition, HTTP is not the most efficient protocol for program-to-program communication. You must devise some format for transmitting information from program to program along the HTTP pipe -- this is usually either a text-based format like XML (which must be parsed on the receiving end and generated on the sending end) or an object-based format like Java serialization. Both of these options involve substantial programming effort, and neither is as fast as native IIOP.

Do you need concurrent read and update access to shared data?
Traditional, _fat client_ solutions require the application to manage access to shared data at the database level. This often results in highly complex schemes to deal with database locking and concurrency, or alternatively, loss of data integrity when these issues are not considered.

EJB technology automatically handles these complex threading and simultaneous shared-data issues. As mentioned previously, the EJB components control the access to the back-end data and manage the current transactions and database locking internally. This reduces the total programming effort by reducing the amount of effort spent in writing database control logic, while ensuring the consistency and validity of the data.

Do you need to access multiple disparate data sources with transactional capabilities?
Many applications require the ability to access multiple data sources. For instance, a program may use data in both a middle-tier Oracle database and a mainframe CICS or IMS system accessible through middleware such as MQSeries. The key is that some applications require that this access be fully transactional _- that data integrity be maintained across the data sources. For example, an application may demand that placing a user order will consist of storing the detailed order information in an Oracle database and simultaneously placing a shipment order with a CICS system through MQSeries. If either the database update or the MQ enqueuing fails, then the entire transaction should roll back.

In the past, the only choices with which to build systems like these were transaction monitors like Encina, CICS, or Tuxedo, which used nonstandard interfaces and required development in languages like COBOL, C, or C++. For example, the WebSphere Advanced Edition EJB container supports multiple concurrent transactions with full commit and rollback capabilities across multiple DB2 data sources in a full 2-phase commit-capable environment. Currently, WebSphere supports other data sources (such as Oracle, MQSeries, and CICS) with 1-phase commit transaction support. The WebSphere Enterprise Edition EJB container can support more data sources with 2-phase commit.

Most containers are getting better at supporting 2-phase commit over a wide range of data sources. This is an area where we will see constant improvement as time goes on.

Do you need method-level object security seamlessly integrated with security for HTML documents, servlets, JSP files and client logins?
Certain types of applications have security restrictions that have previously made them difficult to implement in Java applications. For instance, certain insurance applications must restrict access to patient data in order to meet regulatory guidelines. Until the advent of EJB technology, there was no way to restrict access to an object or method by a particular user. Previously, restricting access at the database level, and then _catching_ errors thrown at the JDBC level, or restricting access at the application level by custom security code were the only implementation options.

However, EJB technology allows method-level security on any EJB component or method. Users and user groups can be created that can be granted or denied execution rights to any EJB component or method. In WebSphere, these same user groups can be granted or denied access to Web resources (servlets, JSP files and HTML pages), and the user IDs can be seamlessly passed from the Web resources to the EJB components by the underlying security framework.

Is there an architectural push toward a standard, portable, component-based architecture?
For many forward-looking companies, the key issue is achieving platform, vendor, and application-server implementation independence. The industry-standard EJB component architecture can help achieve these goals. EJB components developed for WebSphere can usually be deployed on competitive application servers, and vice versa. While this promise has not been completely achieved, this is a strategic direction that many customers choose to take. While in the short-term it is often easier and faster to take advantage of features that may precede standardization, standardization provides the best long-term advantage.

Also, you should consider the increasing availability of tools and optimized implementations of the EJB standard that you would not get with home grown managed object frameworks. Since most companies are not in the middleware business, your effort can be more effectively targeted at activities that are more directly related to your business.

Do you need multiple servers to handle the throughput or availability needs of the system?
Fat-client systems simply do not scale to the thousands or millions of users that Web-based systems may have. Software distribution problems also have led to a desire to trim down fat clients. The 24-hour, seven-day-a-week nature of the Web has also made up time a crucial issue. However, not everyone needs a system designed for 24/7 operation, and able to handle millions of concurrent users. You should be able to design a system so that scalability can be achieved without sacrificing ease of development, or standardization.

So, you need a way to write business logic that can scale to meet these kinds of requirements. EJB technology can provide the backbone for building this kind of highly scalable, highly available system. WebSphere, for example, assists developers in building these kinds of systems through the following features. These features are representative of what other EJB servers provide:

• Object caching and pooling _- WebSphere automatically pools stateless session EJB components at the server level, reducing the amount of time spent in object creation and garbage collection. This will result in more processing cycles being available to do real work.
• Workload optimization at the server -_ WebSphere also features EJB server cluster management. In WebSphere Application Server, you can create server groups that span nodes. In addition, you can create models (abstract representations of a server), which are then cloned into multiple JVMs. You can configure clones to run on any of the server machines in the cluster. In addition, multiple clones of a single server can run on a single machine, taking advantage of multiprocessor architectures. Likewise, you can administer an entire set of clones as a single group. This improves availability and prevents a single point of failure in the application server.
• Cloning supports automatic failover. With several clones available to handle requests, it is more likely that failures will not damage throughput and reliability. With clones distributed to various nodes, an entire machine can fail without producing devastating consequences.

All of these features happen without specifically being programmed into the system. No changes to the server-side code are necessary to take advantage of this kind of scalability.

Note that WebSphere supports distribution, cloning, and automatic failover of other server-side Java technologies like Java servlets and JSP files. However, these more presentation-oriented technologies serve as a complement to EJB components rather than as a competitor. When up time and scalability are key, EJB components should be a part of the overall solution.

Back to top

A tale of two projects, or the proper use of EJB components

Now that you_ve seen some of the ways of qualifying an application to determine if it is a good candidate for the use of EJB technology, we'll compare two applications that have used EJB components to see how the technology either helped or hindered the developers in achieving their goals. In one case proper use of EJB components resulted in less, and more easily understood code. In the other, EJB component use resulted in an excessively complicated system that did not perform well.

These applications are composite examples of several applications. They are not specific to a single company or project team.

Back to top

An EJB technology failure

A project team that was part of an advanced technologies group chartered with the goal of evaluating new technologies started this project. The project had the following architecture (each box represents a different process running on its own physical hardware):

Some specifics about this particular architecture make the use of EJB components less attractive than it might seem at first glance:

• The bulk of the application was in the display of information, which was done in the Java servlets. The EJB components were used only to fetch and update data.
• The particular connection the team was using to the back-end mainframe transaction was not an XA-aware data source. They could not roll back or commit transactions as a group, but instead each mainframe access was a separate, independent function call.
• They did not use the security features of EJB technology since they could not come up with a mapping between the user coming in from the Web and a user in the mainframe.
• Every access from the servlet to the entity EJB components was a network call. The logic within their finder methods and the ejbLoad() methods performed the actual mainframe calls, but from then on the EJB component was simply acting as a data cache until the transaction committed, at which point the ejbStore() method would write the information back to the mainframe. Every access and update up to that point incurred a substantial network overhead.

This team was using EJB components simply as a data mapping mechanism between the mainframe data and the servlets, which is not an effective use of the technology. In this case the application did not take advantage of the:

• Transactional nature of EJB components
• Method-level security of EJB components
• Scaling and distribution of EJB components (the team only had one EJB server)
• Sharing of business logic among multiple clients and client types
• Automatic data-mapping capabilities of CMP EJB components

Using EJB components made their system significantly slower than it would have been had they directly coded the data mapping as JavaBeans components within the same JVM as the Java servlets and avoided the network overhead. Also, the system was more complex (due to the need for the home and remote interfaces and the distribution code) than it needed to be. In fact, the project was later scrapped and rearchitected without EJB components, with the data mapping done within a set of standard JavaBeans components used by the servlets. This made the final system both faster and simpler.

Back to top

An EJB technology success story

A project team at a financial institution developed this project, originally using Java and RMI technology. Their system had the following architecture:

In addition to having multiple client types, the project team had built two additional frameworks into the system that are not visible from the diagram:

• A database mapping layer, using JDBC within their RMI server, that mapped their Oracle tables to Java classes and vice versa.
• A custom security framework, which validated the users coming in from the browser or application clients and then determined if the RMI calls and database calls could be made by those users.

Because their application requirements were so closely aligned with the goals of EJB technology, the project team was able to quickly refactor their design into the following architecture:

Using container-managed persistence (CMP) entity EJB components allowed the group to abandon their database mapping framework and take advantage of the complete and efficient implementation that is part of WebSphere and VisualAge for Java. By using EJB technology security, the project team was also able to abandon their custom security framework, while still retaining method-level security in their application. As a result, their application became simpler because there was less code to maintain.

So in short, this application was a good candidate for EJB technology because it:

• Had multiple client types sharing the same business logic
• Used transactions
• Needed the object-relational mapping possible through CMP beans
• Needed method-level security

The final architecture of this system was a particularly good use of EJB components because the system was designed to minimize the network traffic by using session EJB components codeployed with entities. The alternative, having the clients have lots of fine-grained calls, would likely have increased network traffic and complicated the system by requiring clients to start and commit or roll back transactions.

Back to top

Summary

Understanding how to decide whether EJB technology is appropriate in a particular application, including some of the pros and cons of choosing EJB components as an implementation option, is the first step to making the right choice in building a new system that might use EJB components.

Resources

• A Mini-pattern language for Distributed Component Design (in PDF) describes a small pattern language for building applications that use systems like EJB technology.
  
  
• The Enterprise JavaBeans specification describes what an EJB component is and how they should be built.
  
  
• Enterprise Java Beans, published by O'Reilly & Associates, Sebastapol, California, 1999, is the best current reference on how to use EJB components.
  
  
• For more information about WebSphere's transaction and persistence features, visit the WebSphere home page.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Technical questions to ask
• A tale of two projects, or the proper use of EJB components
• An EJB technology failure
• An EJB technology success story
• Summary
• Resources
• About the authors
• Comments

Next steps from IBM

With the WebSphere Application Server you can benefit from the simplified EJB 3.0 development experience, new persistence model, and interceptors.

---

• Try: Download a free trial version of WebSphere Application Server Community Edition, the lightweight Java 5 application server with robust EJB 3.0 funtionality.
• Article: Learn how call patterns and components involved in making calls to EJB components deployed in the EJB container operate in WebSphere Application Server.
• Tutorial: This tutorials shows you how to create an enterprise J2EE application that implements both Plain Old Java Object (POJO) and EJB Web services endpoints.
• Demo: Watch this demo and learn how to configure and use the WebSphere Application Server and the Eclipse IDE with the Web Tool Project Platform.
• Buy: WebSphere Application Server

Dig deeper into SOA and Web services on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers